KRS

не может! они нормально описаны, выравнивание ничего не даст! #pragma pack(push,1) typedef struct _CAN_ODENTRY { uint16_t index; uint8_t subindex; uint8_t entrytype_len; uint8_t *val; }CAN_ODENTRY; #pragma pack (pop) размер этой структуры при любом выравнивании будет 8 байт

Так в общем и должно во флеше лежать. можно как const эти структуры объявлять.

Для библиотеки Вам нужен Android NDK посмотрите для начала это http://habrahabr.ru/post/203014/ А вот tcl/tk, может в python под андройд посмотреть, qpython (вроде)

не только! а win привел как пример того что разрядность целого типа слабо зависит от разрядности процессора! Для 64 битного линукса кстати long - 64 битный. 64 битный целый тип на сегодня - long long, но лучше конечно использовать stdint.h стандарт - С99 например, или новый С11 про пример - я же писал по многим причинам! одна из них - шестнадцатеричные константы считаются unsigned.

вы бы лучше стандарт почитали! например на win64 и int и long остались 32 битными! а вот size_t и int_ptr_t уже 64 битные. в данном случае не стукнет, по многим причинам. смотрите стандарт :)

А подскажите их контроллеры уровня архитектуры ARMv7A?

А контрольная сумма есть? Я вот не помню flashmagic ее считает на лету перед записью...

Про Synchro Bitbang - у FTDI есть особенность в этом режиме, почему то иногда возникают паузы (причем довольно часто) причем не важно в одном пакете по USB данные ушли или нет. Поэтому протокол чуствительный к задержкам в этом режиме не реализовать! Когда только появилась RL серия хотел сделать Silabs C2, но из-за этой особенности не получалось, т.к. в данном интерфейсе клоки объеденены с ресетом. Но вот протоколы типа SPI прекрасно работают! И AVR программируется и ARM SWD работает и JTAG именно на FT232RL в режиме синхро битанг, т.к. все происходит по фронтам клоков и не должно быть чувствительно к их неравномерности. По край ней мере у меня никаких проблем не возникало.

Зачем Вам AVR c внешним контроллером? Сейчас можно поставить ARM c встроенным MAC+PHY

с такими скоростями... первый проект выйдет когда чипы на cortex-m3 перестанут выпускаться :bb-offtopic:

Taekun, а у Вас был опыт изготовления плат с "0"? Полный цикл - схема->разводка->отправка в изготовление->мотнтаж->отладка... или Вы сразу за комп на x86?

такая инструкция есть начиная с ARMv5 (т.е. в ARM7TDMI ее нет). Но и ARMv6m и ARMv7m ее нет! А обычная инструкция BLX приводит к exception! И это не косвенная адресация, а переход с возможной сменой режима ARM<->THUMB. У вас где то в опциях ассемблера или компилятора не то ядро стоит! В асм надо ставить THUMB обязательно! Причем именно THUMB, CODE16 не позволит все инструкции использовать!

может не хватить! потому что текст на С, там и так скорее всего есть 1 -2 инструкции между записями (константу хотя бы загрузить)

интересно, а с DMB будет работать?

Попробуйте в начале прерывания считать статусы IntStatF и IntStatR в переменные (а не постоянно читать из регистров) и сразу же очистить прерывания IoIntClr = statf | statr;

SergeiP, Может быть Вам на python написать?

А Вы их чистите? Да, и кстати зачем Вам вложенные прерывания? Кроме того Вы неправильно их используете! в ARM7 нельзя просто так разрешить вложенные прерывания, нужен или wrapper или указать компилятору (у IAR __nested)

mantech, IMHO лучше брать TI SITARA, купите BeagleBon Black... у TI сейчас лучше поддержка по софту, особенно если без линукса! у STARTERWARE есть свой bootloader.

uboot все равно придется допиливать под железо. кроме того в большинстве случаев консоль uboot и его возможности не нужны, только тормозят загрузку! для многих устройств "прибитый гвоздями" индивидуальный загрузчик будет работать и быстрее и надежнее. Написать его не проблема - все необходимое для этого есть!

А зачем тогда копировать? Сразу из ROM и делать развертку...

можно конечно! процесс запуска ядра не сложный. а uboot - хороший пример того как можно все запутать и усложнить :) только Вы же вообще без линукса собирались, тогда uboot смысла использовать нет!

Не отпадает! Начинать работу проще с CCS. Но отладчиком XDS100 пользоваться практически невозможно! Лучше переходить на IAR + Jlink. (это конечно рецепт для голого железа, без линукс)

А Вы кол-во тактов обработчика смотрели? у ARM-v7M вход в прерывание 12 циклов, выход 10 при частоте 204 Mhz - остается 182 цикла, но надо и на другое оставить... Можно избавится от "дрожания" посадив выход на "External Match Output", а в прерывании уже рассчитывать новое значение Match регистра... у NXP удобно сделана работа через EMR регистр, там можно и напрямую ногой управлять и выставить какое действие будет по очередному событию.

цифиркой ошибся lpc1788 а вот видео http://www.youtube.com/watch?v=Jn53eBMfsqQ

Вы сильно устаревшй контроллер рекомендуете! У него уже давно есть замена LPC1768 (пин компатибл) на 120 Mhz и с ядром Cortex-M3! Есть видео где показано быстродействие этих процов - разница впечталяет! Жаль у NXP только SDRAM контроллеры. IMHO очевидно что jlink или его клоном. Это будет основное преимущество IAR! Я вот beaglebon цеплял к IAR - разница конечно колоссальная по скорости отладки, с XDS не сравнить. Но CSS все равно надо ставить,хотя бы для начала работы...