cf7k

Всё что нашлось в архивах... версия древняя, хотя новее наверное и нет... GDS820_V200_Readme.txt GDS810_V1.23.zip

Подобные полосы наблюдал на плате с DDR SDRAM (CPU - 260MHz, DDR - 130*2MHz). Проявлялись при плотненькой нагрузке с участием VFP и очень частых прерываний(откуда исполнялся код - уже не помню). Пока остановился на гипотезе, что прерванная инструкция VFP абортится (это как раз в доках описано) и происходит какая-то хрень на шине/буфере записи. После избавления от плавучки в прерываниях - больше полосок вроде не было. Дальнейший НИР не проводил. Видимо не только VFP может вызывать такую бяку. scorp2011 По поводу кэширования видеобуфера - вовсе не гарантированно; может помочь, а может и нет. Всё это - для организации burst-write в SDRAM при рисовании (иначе на каждую операцию записи будет генериться отдельное обращение к SDRAM), контроллеру LCD до кэша нет дела - читать он будет из SDRAM.

1. я еще не добрался до загрузчика, 2. в Keil'е среди имеющихся алгоритмов программирования (готовенькое) есть только LPC31xx NAND Flash LP и LPC3000 NAND Flash SP - один раз ткнулся - не завелось. Поэтому с загрузчиком пока идею оставил. 3. Искал способ "по старинке" - скриптом Keil'a инитить внешнее ОЗУ до загрузки программы, чтобы к моменту загрузки была бы просто "память". (если всё и кратко - не освоил полноценно инструмент)

Победил... окольными путями... В файле проекта выбрасываются все ресурсы, убирается вся добавленная в scatter файл хрень, оставляется хидер с определением типа структуры (он общий для 2х проектов). typedef struct { T_Font *Font1; T_Font *Font2; ... T_BitMap *Picture1; T_BitMap *Picture2; ... } ResStruct; #define ResAccess ((ResStruct *)0x80100000) и далее везде в коде основного проекта : ResAccess->Font1; ResAccess->Picture2 А в ресурсном проекте уже определяется переменная ResStruct и инициализируется указателями на конкретные ресурсы. Единственный минус подобного решения: SlickEdit отказывается выдавать подсказки (по крайней мере 13й).

Всех приветствую :) В связи с полным провалом предполагаемого простейшего варианта http://electronix.ru/forum/index.php?showtopic=80943 пилю другой вариант. Вводная: На данный момент в проге имеется некоторое количество ресурсов - шрифты и картинки. Эти ресурсы генерируются внешней прогой - просто в виде Си-шных константных массивов. И занимают эти ресурсы чуть более 1 МБ (в бинарном виде). В дальнейшем это всё поделие будет загружаться загрузчиком, постадийно и проблем не предвидится, а на данный момент требуется удобство отладки. Задача: К основному проекту(кейловскому) сделал еще один - только для генерирования объектника с ресурсами. scatter файл: ; ************************************************************* ; *** Scatter-Loading Description File generated by uVision *** ; ************************************************************* LR_SDRAM 0x80100000 0x00200000 { RES_EXTRAM 0x80100000 FIXED UNINIT 0x00200000 { Elements.o (+RO) Fonts.o (+RO) arrow_down_blue.o (+RO) arrow_small_down_cyan.o (+RO) arrow_small_left_cyan.o (+RO) arrow_small_right_cyan.o (+RO) arrow_small_up_cyan.o (+RO) ; тут еще куча всякого font_big_black.o (+RO) font_huge_black.o (+RO) font_normal_black.o (+RO) ; тут еще куча всякого } } Keil это проглатывает (естественно, с предупреждением об отсутствии EntryPoint). На выходе имею желанный объектник ***.axf . в основном проекте вставляют в scatter файл приведённый выше кусок: ; ************************************************************* ; *** Scatter-Loading Description File generated by uVision *** ; ************************************************************* LR_SDRAM 0x80100000 0x00200000 { RES_EXTRAM 0x80100000 FIXED UNINIT 0x00200000 { ;идентичная копия того, что было перечислено в предыдущем куске } } LR_IROM1 0x00000000 0x00030000 ; load region size_region { ER_IROM1 0x00000000 0x00020000 ; load address = execution address { *.o (RESET, +First) *(InRoot$$Sections) .ANY (+RO) } RW_IRAM1 0x00020000 0x00020000 ; RW data { .ANY (+RW +ZI) } } т.е. пытаюсь получить точно такую-же линковку, как и во вспомогательном проекте, но только штоб эта секция не загружалась (отсутствовала в объектнике основного проекта). Далее делаю хирый финт ушами - вот такой скрипт загрузки DEFINE INT Entry; DEFINE LONG SYS; //загрузка во внутреннюю статическую память (по заремапленному адресу) //линкер тоже должен подготовить объектник для работы по этим адресам Entry = 0x00000000; //адрес блока управления системными функциями SYS = 0x40004000; //------------------------------------------------------------------------------------------------- FUNC void Remap (void) { LONG BOOT_MAP; BOOT_MAP = SYS + 0x14; // Boot Map Control Address _WDWORD(BOOT_MAP, 0x00000001); // Remap IRAM to 0 } //------------------------------------------------------------------------------------------------- //------------------------------------------------------------------------------------------------- RESET Remap(); exec("LOAD ..\\_obj\\MainProject.axf INCREMENTAL"); PC = Entry; exec("g,main"); P 2 exec("LOAD ResourceProject.axf INCREMENTAL"); //------------------------------------------------------------------------------------------------- Т.е. цель проста: 1. загрузить основной проект во внутреннюю SRAM (а проект без ресурсов туда помещается), 2. выполнить startup код, 3. выполнить пару шажечков отладки - в main'е сразу стоит вызов Init, который производит инициализацию DDR SDRAM (собственно из-за этого куска вся свистопляска) 4. загрузить файл ресурсов в теперь уже доступную DDR SDRAM 5. продолжить отлаживаться Итого: 1. В основном проекте секция ресурсов остаётся в объектнике (превышает бинарник объём внутреннего ОЗУ) ? как сделать так, чтобы её не было, а код, использующий ресурсы нормально бы слинковался. 2. Вынужден все ресурсы пометить противооптимизаторным атрибутом __attribute__((used)) (просто чтоб лежал один раз сгенерированный объектник и не отвлекаться на него в зависимости от меры пользования ресурсами, да и нет внутри никакого кода, который бы обращался к этим ресурсам) 3. в scatter файлах вынужден перечислять все свои объектники, которые нужно разместить во внешней памяти, хотя имею пару массивов указателей с обращением ко всем ресурсам (этакий интерфейс). ? как сделать проще, компактнее и чтоб ручками файлики не прописывать. ??? может есть более простой путь? (пока что без записи/чтения из внешней флэши; COM/USB/... на плате нет - ну не нужны были вот и не запасся :01: )

О! Много полезного для себя нашел. За это большая спасиба. Но меня интересовало то что пишется в файликах "IntRAM.ini" и им подобных: exec("LOAD Obj\\proj.axf INCREMENTAL"); // Download PC = 0x08000000 // PC setup to PSRAM // exec("g,main"); ну или в пользуемом мной варианте DEFINE CHAR Setup; DEFINE INT Entry; DEFINE LONG SYS; SYS = 0x40004000; FUNC void HELLO(void) { printf ("--------------------------------\n\r"); } FUNC void Remap (void) { LONG BOOT_MAP; BOOT_MAP = SYS + 0x14; // Boot Map Control Address _WDWORD(BOOT_MAP, 0x00000001); // Remap IRAM to 0 } FUNC void PC_Setup (void) { PC = Entry; } FUNC void GoMain (void) { exec("g,main"); } FUNC void Download (void) { exec("LOAD D:\\Projects\\lpc3250\\soft\\_obj\\testing-load.axf INCREMENTAL"); } Entry = 0x08000000; // Memory mapped peripherals address definitions DEFINE LONG EMC; EMC = 0x31080000; FUNC void Clock_Setup (void) { if (Setup & 0x01) { // Setup clock: XTAL = 13.00 MHz, // SYSCLK = 13.00 MHz, // HCLKPLL = 208.00 MHz, // ARM_CLK = HCLKPLL = 208.00 MHz // HCLK = HCLKPLL / 2 = 104.00 MHz // PERIPH_CLK = HCLKPLL / 16 = 13.00 MHz LONG PWR_CTRL, OSC_CTRL, SYSCLK_CTRL, PLL397_CTRL, HCLKPLL_CTRL, HCLKDIV_CTRL; PWR_CTRL = SYS + 0x44; // Power Control Register Address OSC_CTRL = SYS + 0x4C; // Main Oscilator Ctrl Reg Address SYSCLK_CTRL = SYS + 0x50; // SYSCLK Control Register Address PLL397_CTRL = SYS + 0x48; // PLL397 Control Register Address HCLKPLL_CTRL = SYS + 0x58; // ARM and HCLK Ctrl Reg Address HCLKDIV_CTRL = SYS + 0x40; // HCLK Divider Settings Address _sleep_ (10); _WDWORD(SYSCLK_CTRL , 0x00000140); _WDWORD(OSC_CTRL , 0x00000000); _WDWORD(HCLKPLL_CTRL , 0x0001401E); _sleep_ (10); _WDWORD(HCLKDIV_CTRL , 0x0000003D); _WDWORD(PWR_CTRL , 0x00000016); } } HELLO(); Remap(); Clock_Setup(); //EMC_Setup(); Download(); PC_Setup(); GoMain(); HELLO();

Собственно, сабж. Основной процессорный код работает без запинки, но на некоторый этап отладки нужен скрипт инициализации DDR контроллера, штоб можно было бы грузить весь код ( с большой Data-RO секцией ) отладчиком сразу во внешнее ОЗУ. В Keil'е есть для SDR SDRAM для фитековских плат, а вот для DDR - нима. Может кто проходил подобный этап?

Может я что-то не так делал или неправильно поставил себе задачу... допускаю... Но что в данном случае означает при копировании, и файлов? Мне не нужно было ничего копировать - я переносил внутри репозитория "назад во времени". Потому так подробно расписал проблему для минимизации вероятности неправильного понимания. TortoiseSVN 1.6.10, Сборка 19898.

#define DMA_SRC 0x7FD00000 #define DMA_DST 0x7FD01000 Воткнул в свой проект Ваш кусок кода... все прекрасно работает... Хотя никаких дополнительных усилий по инициализации сего блока памяти не предпринимал... Попробуйте ради экперимента разместить в основной области памяти, попробуйте снизить скорость JTAG'a, можете попробовать из SEGGER'a напрямую записать в эту память.

Ура!!! нашел!!! svnadmin.exe dump ПУТЬ_К_РЕПОЗИТОРИЮ > d:\tmp.dump удалить старый репозиторий (естественно, сначала попробовал на отдельном) создать там же новый, но пустой импортировать структуру trunk/branches/tags из какого-нить темпа. Можно и ручками в репозитории создать - но это лишние правки в нем появятся. svnadmin.exe load ПУТЬ_К_РЕПОЗИТОРИЮ --force-uuid --parent-dir trunk < d:\tmp.dump История сохраняется, граф ревизий черепаха рисует правильно, номера правок смещаются на +1 (за счет операции импорта структуры t/b/t), можно нормально создавать ветки. Проблема решена. update 02-09-2010 12:31msk. Еще надо ручками в черепахе убить закэшированные хранилища! А то кровушки оно попьёт!

??? Не осознал... Я делал в черепашьем repo-browser'е (именно в нем, а не в виндовом проводнике - т.е. операцию над репозиторием, а не с рабочей копией) - просто схватил все каталоги исходных кодов и перетащил в каталог trunk. И простым командным svn move тоже получал аналогичный результат. Всё бы замечательно, да вот только чтобы что-то переименовать - надо это что-то иметь. В данном случае подразумевается каталог с пустым именем - т.е. его не существует. Его в trunk не переименовать. Весь вопрос в том чтобы всё что есть (все исходники) перенести в подкаталог в репозитории и при этом чтоб история тоже была бы перенесена, а она, видимо, привязана к каталогу в котором сохранялись правки. Мне почему-то кажется, что там делается Copy (создание ветки) и потом Delete оригинала. В результате новая ветка получает новую жизнь (и соответственно пустую историю), а старая - убивается (вместе с историей). Пробовал отзеркалить репозиторий в другой, но в подкаталог trunk. Не даёт. Может есть какой "грязный хак"? :)

Всем здрасьте. :) пользуемая софтина: svn + черепаха Имею некоторый проект, который долго и муторно пилится и хранится всё это под SVN'ом. Изначально я ставил SVN чтоб не плодить много бэкапных копий - чтоб не задумываться "а не потер ли я чего за зря". Соответственно, по неопытности, структурой trunk/branches/tags не заморачивался - все складывал в корень репозитория. Ныне же возникла потребность поддерживать старые аппаратные версии и пилить новые. До некоторого количества терпения пилил всё в одном путем макропереключений в исходном коде, но код стал распухать из-за одновременного присутствия условий компиляции для всех аппаратных версий. Вот я и дошел до необходимости сделать "по-нормальному". Собственно, возникла проблемка. Создаю в имеющемся репозитории папки trunk/branches/tags, переношу в черепашьем repo-browser'е все свои исходники в trunk, делаю branches и т.д. но вся история до переноса более в логе не показывается. Вопрос 1: оно так должно быть и я чего-то не понимаю, или это баг? Вопрос 2: как сделать так, чтоб вся предыстория отображалась? Провел эксперимент: I. создаю "по-нормальному" проект делаю ветвления: Всё нормально. II. моделирую свою ситуацию - сначала создаю в корне проект, правлю его, и далее уже занимаюсь ветками далее импортирую структуру trunk/branches/tags и переношу в нее исходный код. вот собственно то что у меня вызвало закономерный вопрос: А где все мои старания, добытые непосильным трудом? :) Из картинок видно, что все что до ревизии 5 - ну никак не хотит отображаться. Переключаться на корневой каталог репозитория - не кошерно(хотя, вроде, все комментарии изначально привязывались к корню) - тогда в каталог проекта вытаскивается все что есть в репозитории, граф ревизий оно всё равно нормально не строит, а лог, соответственно, отображает для всех аппаратных версий в порядке добавления правок: Хотелось бы, чтоб все стало как будто бы изначально базировалось на trunk/branches/tags: Простите за "многа букафф". Спойлеры ставил вслепую, т.к. они у меня глючат...

К сожалению не знаю досконально, что именно повлияло на такие радикальные шаги, но все же 5 минут маловато... Это ж вроде не чат. Сам, даже с использованием предварительного просмотра, иногда пропускаю ошибки... Если б минут бы 20, пока до самого окончательно дойдёт высказанная мысль :), а далее в течение пары часов с обязательной пометкой, что сообщение отредактировано.

Я до испытаний OLED до сих пор не добрался (хотя в ЛенЭкспо потаращился на них) - уж очень меня порадовал TIC118: достаточно ярко, область изображения больше чем у использованного FDCC1602D, шрифт можно сделать жирный, габариты самые замечательные, равномерная подсветка, которая еще и меняется отдельно от индикатора, ну и, конечно же, цена. Цена вместе с подсветкой - как и у FDCC1602D.

Супер. Действительно медицина способна на многое :) Для себя взял на заметку возможность создания константного типа, хотя все же остановился на неконстанстном типе структуры и отдельном описании константной структуры. Позволю себе подвести резюме... так сказать решение для тех, кто потом будет искать: //по моим (стереотипам) убеждениям - тип - это некий "трафарет" для выделения блока памяти и он не должен зависеть от того, в какой памяти память выделяется. typedef struct { void (*FunctionPointer) (char Param); int (*OtherFuncPointer) (int SomeParam); }PWInterface; //я все же вернулся к имени PWInterfae от предложенного WInterface (оно у меня от PathWayInterface) typedef PWInterface const cPWInterface; //"трафарет" для выделения памяти под структуру в ПЗУ typedef cPWInterface *const pcPWInterface; typedef pcPWInterface *const ppcPWInterface; //выделение памяти в ПЗУ cPWInterface PWMonitor0 = { SomeFunc1, //допустимо через &SomeFunc1 SomeFunc2 }; //массивы указателей на структуры с адресами функций ("уровень 1") в ПЗУ pcPWInterface PWStartArr[] = {&PWMonitor0, &PWMonitor1, &PWMonitor2, &PWMonitor3}; //адрес структуры - с "&" pcPWInterface PWMonitorArr[] = {&PWMonitor4, &PWMonitor5}; pcPWInterface PWStopArr[] = {&PWMonitor6, &PWMonitor7, &PWMonitor8}; //массив указателей на массивы с указателями на структуры с адресами функций ("уровень 2") в ПЗУ ppcPWInterface Pathways[] = {PWStartArr, PWMonitorArr, PWStopArr}; //пример обращения к методу интерфейса result = Pathways[SomeMode][SomePWID]->OtherFuncPointer(SomeParamValue); под C30 все работает. Спасибо Student Pupkin и AHTOXA за оказанную помощь в разрешении проблемы.

Просто как-то не привык задавать "константный тип" (сегодня увидел такой подход впервые). Опять же привычно на месте определить - что в ПЗУ, что в ОЗУ, что не/изменяемо. А "наш" :) компилятор сделан на основе GCC третьей версии. Ща... осваиваю... add: скорее всего придется доосвоить утром ;)

warning: initialization discards qualifiers from pointer target type

Гм... любопытный подход... возьму на заметку. Пасиба. вместо const PWInterface *const PWMonMode1Arr[] = {&PWMonitor0, &PWMonitor0_c, &PWMonitor0_r}; получилось то что хотелось: const pPWInterface const PWMonMode1Arr[] = {&PWMonitor0, &PWMonitor2}; Но это "уровень 1" массива. вот с дефайном не получилось - на самом деле я не define задаю, а пишу в лоб (ну что там вынести для красоты - это уже другое дело). Пока самый человеко понятный код у меня такой: const ppPWInterface const Pathways[] = {(ppPWInterface)(&PWMonMode1Arr), (ppPWInterface)(&PWMonMode2Arr), (ppPWInterface)(&PWMonMode2Arr)}; В общем-то и в объявлении есть двойной указатель и const'ы там где хочется... но... все же хочется знать, как это делается без коррекции типа, так сказать, по правилам языка.

Так уже пробовал, пока писал предыдущий пост - компилятор понимает и так и так... Но для порядку причесал. Ну смысла не много - наверно для выразительности. Я в отрочестве не был сионистом :). Сначала строил структуру, далее инициализировал её указателями (адресами функций) - вот и поставил средний const (сами указатели ж у меня констанстные - хотя для функций это скорее всего само собой разумеющееся). Далее все это разместил в ПЗУ приписав первый const. Вот так и родил монстра :) Но компилятор уживается с этим монстром. Меня ж более интересует последний монстр - "массив указателей на массивы указателей на структуры" (и это все в ПЗУ).

То же, что и полное объявление вместе с инициализацией, но в заголовочный файл вынесено только имя. Т.к. стоит extern - я сообщаю, что полное объявление с инициализацией существует где-то, а другим модулям достаточно знать имя, тип и "модифицируемость" объекта - всё, чтоб обратиться к нему, а компилятору сгенерировать код. Я исходил из следующих утверждений: int *int_ptr; // Модифицируемый указатель на модифицируемый объект const int *int_ptr; // Модифицируемый указатель на константный объект int * const int_ptr; // Константный указатель на модифицируемый объект const int * const int_ptr; // Константный указатель на константный объект Хотя это касается указателей.... а в моем примере... гм... как-то даже по-русски не получается... первый const - разместить в памяти программ, второй -... возможно лишний, но результат компиляции не меняется... возможно пока гонялся за указателями - намудрил лишнего... Идея такова: хочу инициализированную структуру, полям которой при инициализации присвоены указатели на функции. Далее считаю, что сами эти функции константы (собсно адреса никуда не перемещаются, и изменять их не надо) - ставлю второй const; далее хочу чтоб сия структура была компилятором создана в памяти программ, а не в секции данных, которая инициализируется все равно из памяти программ в startup коде - вот появляется первый const. Вот примерно таковы мои рассуждения... Возможно я некорректно выразился, но ведь в инициализированной структуре хранятся адреса функций. Поэтому первичная структура избыточность не содержит. Далее я объявлял массив содержащий указатели на структуры с адресами функций. Цель всей этой затеи - в зависимости от двух параметров, которые выступают индексами по массивам, вызывать нужную функцию. Реализовать пытался без использования "марсианских писем"... так сказать - попонятней.

Дожился... :) Помогите чайнику. Итак... вводная: пользую PIC24H, пишу на Си (без плюсов), компилятор - С30, уже скурил весь гугль, учебники по сям... имею определение интерфейса (структуру указателей на функции): typedef struct { void (*FunctionPointer) (char Param); int (*OtherFuncPointer) (int SomeParam); .... } PWInterface, *pPWInterface, **ppPWInterface; Далее имеется несколько модулей, реализующих некое поведение и предоставляющих указанный интерфейс: заголовочный файл: extern const PWInterface const PWMonitor0; сишный файл с реализацией: static void SomeFunc1 (char Param); static void SomeFunc2 (int SomeParam); const PWInterface const PWMonitor0 = { &SomeFunc1, &SomeFunc2, .... }; ну и далее реализация этих функций. таких модулей несколько, все предоставляют означенный в начале интерфейс. Т.е. я сознательно выделяю память в памяти программ и пишу дважды const. Далее собираю интерфейсы в одну кучу: #include "PWMonitor0.h" #include "PWMonitor1.h" #include "PWMonitor2.h" .................... const PWInterface *const PWMonMode1Arr[] = {&PWMonitor0, &PWMonitor0_c, &PWMonitor0_r}; const PWInterface *const PWMonMode2Arr[] = {&PWMonitor1, &PWMonitor1_r}; const PWInterface *const PWMonMode3Arr[] = {&PWMonitor2}; Т.е. массивы константных указателей на константные структуры заданного типа. конструкцию представленную выше компилятор поглощает без проблем, а если же пользую const pPWInterface const PWMonMode1Arr[] = ... получаю warning: initialization discards qualifiers from pointer target type Вопрос первый: Что именно я недопонимаю? Хотел как лучше (чтоб через typedef... красившее. Вроде корректно определенный тип указателя при определении структуры)... Продолжу... далее имея массивы(константные) (константных)указателей на (константные)интерфейсы, собираю их в свою очередь в массив(тоже константный): const ppPWInterface const Pathways[] = {&PWMonMode1Arr, &PWMonMode2Arr, &PWMonMode3Arr}; чтоб можно было бы где-то в коде сказать нечто подобное: result = Pathways[PowerMode][ID]->OtherFuncPointer(somecode); Вот тут(при определении массива, а не на вызове метода интерфейса) уже имею трижды warning: initialization from incompatible pointer type Пробовал разные вариации... но, видимо, не все... Вопрос второй: как сделать правильно? Компилятор, в общем-то, понимает что я от него хочу. Память распределяет правильно, инициализирует правильно, все компилируется... но этот варнинг... я ж из-за него невыспался. ;) Уфффф... спасибо за терпение дочитавшим сий опус :)

Не практично - проверено практикой. :) И эти резинки после того как полапаются пальцами пару раз - очень быстро превращаются в труху. Да и лень постоянно засовывать под резинку ленточки - проще сразу в складку кинул и никакой возни.

Самый удобный способ для резисторов и конденсаторов (но не для микрух) - взять картонную ленту(длинную), сложить гармошкой(примерно так - WWWWWW), положить в ящищек(коробочку) по ширине ленты и в складки гармошки складывать кусочки ленты с смд-компонентыми. Около складок надписи с номиналами. Размер ячейки жестко не ограничен - где больше компонентов - там и складка распухает больше. Быстро, дешево, сердито. Единственный минус - переворачивать такую кассу совсем не стоит :)

Так белую и пользую (зеленая уж больно невзрачная... да и в цветовую гамму мордочки прибора не вписывается). Денег, как всегда, нет, но руки чешутся :). Поэтому и спрашиваю совета бывалых - где и что из OLED'ов можно приобрести подешевше (даже для экпериментов) и личный опыт общения с OLED'ами.

У Вас индикаторы без подсветки. Вот пример того, чего мне мало - даже так - нужно вглядываться. И дело не совсем в размере символов (хотя это тоже есть). А TIC118 интересен потому, что он как раз на пропускание, несколько больше видимая область, и предлагаемые подсветки содержат в себе 3..5 светодиодов. OLED же - дюже дорого (в силу несравнимости потребности в них с горячими пирожками :)), хотя по контрастности, наверно, превзойдет все ожидания... Посему OLEDы тоже актуальны.