yablunivsky

Однако, каким же бывает "красивым" Eclipse :

Контора, не ЕНЕТЕХ, случайно?

Для данных и функций : /*---------------------------------------------------------------------------*/ /* AT91SAM7S256 */ /*---------------------------------------------------------------------------*/ MEMORY { CODE (rx) : ORIGIN = 0x00000000, LENGTH = 256K DATA (rw) : ORIGIN = 0x00200000, LENGTH = 64K STACK (rw) : ORIGIN = 0x00210000, LENGTH = 0 } /* Section Definitions */ SECTIONS { /* first section is .text which is used for code */ .text : { *cstartup.o (.text) } >CODE =0 .text : { *(.text) /* remaining code */ *(.glue_7t) *(.glue_7) } >CODE =0 . = ALIGN(4); /* .rodata section which is used for read-only data (constants) */ .rodata : { *(.rodata) } >CODE . = ALIGN(4); _etext = . ; PROVIDE (etext = .); /* .data section which is used for initialized data */ /* Это секция для инициализируемых при старте данных, а так же для функций __ramfunc. */ /* Занимает пространство : _data ... _edata */ .data : AT (_etext) { _data = . ; . = ALIGN(4); *(.fastrun .fastrun.*) /* Это секция для функций __ramfunc. */ . = ALIGN(4); *(.data) SORT(CONSTRUCTORS) } >DATA . = ALIGN(4); _edata = . ; PROVIDE (edata = .); /* Секция для перезаписываемых настроек */ /* Занимает пространство : 255К ... 256K, если выйдем за 256К - линкер выдаст ошибку. */ .dyndata 255K : { . = ALIGN(256); *(.dyndata .dyndata.*); . = ALIGN(256); } >CODE =0x00 /* =0x00 - незаполненные ячейки заполнить 0x00 */ /* .bss section which is used for uninitialized data */ /* А это секция под все остальные ОЗУ-шные данные (т.е. те которые при старте не инициализируются константами). */ .bss : { __bss_start = . ; __bss_start__ = . ; *(.bss) *(COMMON) } >DATA . = ALIGN(4); __bss_end__ = . ; _end = .; PROVIDE (end = .); . = ALIGN(4); .int_data : { *(.internal_ram_top) } >STACK /* Stabs debugging sections. */ .stab 0 : { *(.stab) } .stabstr 0 : { *(.stabstr) } .stab.excl 0 : { *(.stab.excl) } .stab.exclstr 0 : { *(.stab.exclstr) } .stab.index 0 : { *(.stab.index) } .stab.indexstr 0 : { *(.stab.indexstr) } .comment 0 : { *(.comment) } /* DWARF debug sections. Symbols in the DWARF debugging sections are relative to the beginning of the section so we begin them at 0. */ /* DWARF 1 */ .debug 0 : { *(.debug) } .line 0 : { *(.line) } /* GNU DWARF 1 extensions */ .debug_srcinfo 0 : { *(.debug_srcinfo) } .debug_sfnames 0 : { *(.debug_sfnames) } /* DWARF 1.1 and DWARF 2 */ .debug_aranges 0 : { *(.debug_aranges) } .debug_pubnames 0 : { *(.debug_pubnames) } /* DWARF 2 */ .debug_info 0 : { *(.debug_info .gnu.linkonce.wi.*) } .debug_abbrev 0 : { *(.debug_abbrev) } .debug_line 0 : { *(.debug_line) } .debug_frame 0 : { *(.debug_frame) } .debug_str 0 : { *(.debug_str) } .debug_loc 0 : { *(.debug_loc) } .debug_macinfo 0 : { *(.debug_macinfo) } /* SGI/MIPS DWARF 2 extensions */ .debug_weaknames 0 : { *(.debug_weaknames) } .debug_funcnames 0 : { *(.debug_funcnames) } .debug_typenames 0 : { *(.debug_typenames) } .debug_varnames 0 : { *(.debug_varnames) } } Использование для данных : static const struct DeviceConfig_s StoredSettings __attribute__ ((section (".dyndata"))) = { ...... } Использование для функций в ОЗУ : #define __ramfunc __attribute__ ((long_call, section (".fastrun"))) __ramfunc void UnLockRegion(unsigned int region) { ...... }

Рабочий пример : extern const u8 KeyboardMap[KEYBOARD_ROW_COUNT][KEYBOARD_COL_COUNT] PROGMEM; const u8 KeyboardMap[KEYBOARD_ROW_COUNT][KEYBOARD_COL_COUNT] = { {KEY_UNKNOWN, KEY_IDX_ENTER}, {KEY_IDX_UP, KEY_UNKNOWN}, {KEY_IDX_DOWN, KEY_UNKNOWN} }; Как видите, лечится предварительным обьявлением как "extern".

Если используется CDT. Ошибки разбирает ErrorParser. Он создает в закладке Problems строки, кликнув на которые можно перейти к ошибкам. Т.е. "Внешняя тулза" должна поддерживаться разборщиком ошибок. По умолчанию присутствуют разборщики (парсеры) для GNU C+Asm+Make и для Microsoft Visual C. Так что там за "Внешняя тулза"?

Вот насчет папки с workspace. Нет нужды ее холить и лелеять. Потому как при переходе к новой версии eclipse+cdt есть официальная рекомендация создавать workspace заново. У меня есть опыт перехода, и было это так : Eclipse стоит у меня не на системном диске, поскольку тот за-backup'лен, и может быть восстановлен "в ноль" когда мне захочется. Eclipse же не пользуется системным реестром и поэтому его не обязательно привязывать к текущему состоянию ОС. При первом запуске, на вопрос где держать workspace, я ответил "eclipse\workspace". Когда пришло время установить связку eclipse+cdt более свежей версии, я посмотрел по конфигурационным файлам, и отобрал те из них где описывались подсветки, клавиатура и т.п. Сохранив эти файлы, я удалил каталог eclipse (вместе с workspace), а после установки новой версии скопировал старые файлы поверх новых. Т.о. получился новый eclipse со старыми настройками. На основе приведенного личного опыта можно сделать вывод, что нет смысла организовывать работу с проектами относительно каталога с workspace.

Ну, я привык, что новую версию надо заводить в случае кардинальных изменений в требованиях. Например добавили энкодер, или от 5-ти кнопок оставили 2-3. Поэтому достаточно завести новый каталог, скопировать туда уже существующий проект, в файлах ".cproject" и ".project" изменить пути и название проекта, и всё это новообразование считать новым проектом. Согласитесь, что изменение в органах управления или в системе меню (устройство для заказчика X переделать для заказчика Y) достойно вывода в отдельный проект. Само собой, что одинаковые для всех проектов модули (вроде присловутого delay.c или bcd.c) можно расшаривать между всеми проектами, однако в случае передачи исходных текстов одного из проектов "на сторону" придется тащить за ним весьма сложную и избыточную структуру, что скорей всего приведет, извините к геморрою эдак 4-й стадии. Хотя все выше приведенное есть ИМХО, поскольку я использую SVN только для контроля изменений вида "а что это я когда-то тут правил", а т.ж. для того чтобы иметь некий список произведенных работ и исправленных ошибок.

Позволю себе с вами не согласиться. Веду несколько проектов со следующей структурой каталогов : \ |--Platform ||-arm ||-pc |-System В arm создан проект компилирующийся для ARM7, к нему линком на каталог присоеденен System содержащий всякие менюшки и собственно файл содержащий "int main(void)". В pc создан проект компилирующийся для ПК (ОС Windows), к нему линком на каталог присоеденен System содержащий всякие менюшки и собственно файл содержащий "int main(void)". Т.е. имеется одно устройство и два проекта.

Так вроде ж : ${workspace_loc:/имя проекта} указывает в коневой каталог самого проекта. Вот тут описание : http://publib.boulder.ibm.com/infocenter/w...s/cexttools.htm

Это касается только linked resources общих для всего workspace. Те linked folders, пример которых приводился ранее, касаются только конкретного проекта и хранятся исключительно в файлах описывающих проект (.project & .cproject).

В workspace хранятся общие настройки (позиции диалогов, цвета для подсветки текста, клавиатурные настройки). Переменные и настройки проекта хранятся в файлах ".cproject" и ".project" которые создаются в каталоге проекта. Т.о. когда вы кнопочкой Del удаляете проект из Project Explorer'а, то все намеки на проект напрочь удаляются из workspace. Однако ".cproject" и ".project" не удаляются (ну разве что укажете удалить содержимое проекта), и поэтому можно полностью восстановить проект в eclipse через "File->Import->Existing proect". К примеру, я, при первом запуске eclipse указал ему запихать свой workspace подальше с моих глаз. Теперь, когда создаю новые проекты то прямо указываю в каком каталоге будет создан новый проект. И есстественно, что настройки сохраняемые в workspace "шарятся" между всеми проектами.

Когда мне такое нужно, то я делаю : "NewFolder->Advanced->Link to folder int the file system" И соответственно создается виртуальное имя которое привязано к абсолютному пути.

В файле проекта отсутствуют абсолютные пути. Т.е. для конкретного проекта eclipse пляшет относительно каталога в котором лежат файлы ".cproject" и ".project".

Нету у него команд. Там надо сплошняком проклокать все (80 чтоли?) биты (один бит на один сегмент) представляющие состояние всех сегментов "стекляшки". В документации этому посвящен один абзац.

Их еще можно поженить путем установки (ну например) Linux в vmware под Windows.

Да. Собственно ф-ции посылки без изменения взяты из CDC-шного примера.

Я использую не-HID протокол. Поэтому в контрольной точке жульничаю - отправляю ответы с ожиданием (для пакетов 0-й длины "AT91C_UDP_TXCOMP", а для "штопора" - "AT91C_UDP_ISOERROR"). Для получения данных большого (>8-ми байт) обьема использую прием в "Bulk" точку №1. При этом использую "пинг-понг". Так вот в этом самом случае возникала ситуация, когда я приняв все данные из одного буфера выходил из прерывания не проверив "а не успел ли за это время заполниться второй буфер", и тем самым терял прерывание (мы ведь помним о записи в AIC_EOICR) от приема во второй буфер.

Я говорил о такой ситуации : - вошли в первое прерывание от TX_COMP - отправили второй пакет - достаточно долго чем-то занимались - пришло второе прерывание от TX_COMP (но мы еще обрабатываем первое) - наконец-то решили выйти из обработчика прерывания - записали в AIC_EOICR (тем самым игнорируя второе прерывание от TX_COMP [оно небось по фронту]) - вышли из первого прерывания Итог : второго прерывания как бы и небыло ... Еще "в догонку" : в свое время лажанулся - разрешал прерывание от контрольной точки ДО ее конфигурирования. Как результат : прерываний от приемника не получал ...

А вот еще вариант : может слишком долго в прерывании сидите после отправки данных? Я к тому, что перед выходом из обработчика надо сбросить флаг в AIC, а если до этого пришло следующее прерывание то вы его получается принудительно сбросите ...

А какой размер второго пакета? Случайно не 8, и к тому же это последний пакет?

Теперь ясно.

По поводу UserStack - да, его нет. А вот с SystemStack ... Проверил еще раз и сделал вывод о том, что начитался примеров от криворуких авторов! Примеры для IAR не трогают SysMode, а примеры для GCC содержат инициализацию SysMode в стартап-файле.

Что это такое - "CSTACK"? (использую WinARM)

Мда-с. Сразу не обратил внимание на количество ссылок на "taskYIELD". Должен признать : используется, да еще как [используется]! Значит просто уменьшу размер стека ...

Посмотрел. Увидел следующее : если используется "ручное" переключение потоков, или выбран не вытесняющий планировщик, то вызывая "SWI" мы в итоге вызовем код который почти 1в1 повторяет код в таймерном прерывании. И действительно, этот код будет вызван из Supervisor Mode. Значит ли это, что если я использую вытесняющую многозадачность и не использую со-функции, то могу уменьшить SVC-stack? (смехота, в примерах с вытесняющей многозадачностью - вектор прерывания SWI указывает на заглушку, но SVC-stack имеет размер в 1К)