jcxz

Может вы просто неправильно выбрали процессор? Ставить для этого 2 процессора - по-моему избыточно. Если процессор не загружен на 100%, то может проще сделать программную эмуляцию UARTов? Если загружен - взять более мощный и сделать программную эмуляцию на нем. ;)

...или возьмите процессор с ядром ARM7/9 - там есть переключение контекста (на один из теневых наборов регистров) и можно ничего не сохранять (особенно для FIQ) :laugh: В LR грузится не старый PC, а спец. значение (ссылка на вектор прерывания). Адрес возврата сохраняется на стеке как вам уже сказали.

Между разрядностью полинома и разрядностью данных нет никакой связи.

Т.е. - при старте по включению, он проверяет наличие валидной прошивки во флеш выше себя и передаёт управление на неё автоматом? Тогда это подойдёт. Уже и забыл когда последний раз имел дело с 8-битниками.. ;) Речь идёт о замене хорошо знакомых LPC17x, на что-то более экономичное.

Спасибо за оперативный отзыв. Какие могли-бы порекомендовать отладочные платы и где купить? I2C - скорей всего не будет в данном проекте, будут SPI и UART точно, и будет использован DMA. Что-то слышал что DMA там кривоват, это правда? Загрузчик по UART позволяет прошивать флеш или только в ОЗУ грузит? То, что энергопотребляющие режимы очень популярны в еррата - это настораживает. Рассматриваю EFM32 как альтернативу LPC1758. Сейчас проект скорей всего будет делаться на LPC1758 как хорошо освоенном и соответственно - быстром в разработке. Но потом возможна миграция на EFM. В EFM32 (EFM32GG232) привлекают два плюса по сравнению с LPC1758: более низкое потребление (даже без режимов сна) и ОЗУ=128кБ.

Для нового проекта присматриваюсь к семейству EFM32. Но какой-то он малопопулярный. Использовал кто EFM32 в своих разработках? Если да - поделитесь своими впечатлениями? Как он вам? Какие были трудности, какие подводные камни? В первую очередь будет интересовать: низкое потребление, SPI, UART, DMA (должно работать в sleep с SPI и UART).

...и теперь (если они всё-таки не исправились и опять накосячат) виноваты перед начальством будете Вы в их косяках :smile3009:

Это что-то мало у вас... У меня в каком-то режиме до полукилобайта занимал. Как она может быть побайтовой (или вообще привязанной к адресам) если там нигде адрес не указывается? Если логически подумать, то там скорее всего определяется факт срабатывания прерывания внутри секции эксклюзивного доступа (по LDREX взводится флаг в CPU, который сбрасывается если возникло прерывание, а потом он проверяется STREX). Когда у меня была аналогичная проблема с расходованием стека в RTOS sprintf-ом, я просто сделал переключение стека, на стек для sprintf (с семафором ессно).

Неправда. Сторожевик - очень полезная вещь. Всегда использую в своих разработках, причём внешний и неотключаемый и работающий ВСЕГДА. Баги в ПО есть всегда - это неизбежная реальность, даже у самых опытных программистов. Кроме того - наверное вы не сталкивались с испытаниями на помехоустойчивость. И помеха может вогнать проц в совершенно неожиданное состояние на самом прямом ПО. И тут поможет только сторожевик.

А это зачем? Этого не надо.

Так я же привёл пример.

1. При объявлении переменной, задаёте ей альтернативный сегмент. Для IAR: static __no_init int var[N] @ ".eeprom"; или static const int var[N] @ ".eeprom"; 2. В командном файле линкёра компонуете ваш сегмент (.eeprom) в нужные адреса EEPROM.

А сколько ОЗУ в вашем контроллере?

В ZigBee координатор вроде как нужен только в начальный момент времени для сборки сети. Когда узлы вошли в сеть они могут работать и без него (его можно выключить) и даже могут новые узлы входить в сеть. Но в реальности, из-за множества багов в реализации стеков, я в своём ПО периодически проверяю наличие координатора в эфире и перегружаю модуль если координатор не отвечает. Это спасает от многих багов. У нас тоже передача данных возможна между любыми устройствами в сети. Траффик не привязан к координатору. CC2480 & CC2530.

UM10360 LPC17xx User manual: 18.1 Remark: SSP0 is intended to be used as an alternative for the SPI interface, which is included as a legacy peripheral. Only one of these peripherals can be used at the any one time. PS: И вообще непонятно - зачем вы SPI используете, если есть гораздо более функциональный SSP???

Конечно. И глубину очереди и кол-во пакетов в запросе. И приоритет потока: TIME_CRITICAL и всякие критические секции- блокировки убирал, что только ни делал. Дело-то в том, что отключаю это устройство, подключаю другое (со своим самописным стеком) и всё прекрасно работает. Запускал два клиента, параллельно работали с двумя этими устройствами - сворачиваю/разворачиваю любое постороннее окно - в одном клиенте потери почти всегда есть, в другом - никогда. По USB-хабам тоже переставлял их местами.

Пакеты по control-endpoint обрабатываются нормально. Проблема с изохронными IN-кадрами (от контроллера к PC). Эх! если-б у меня был анализатор шины USB! На стороне контроллера-то всё прекрасно - кадры отправляются все, никаких посторонних событий от шины не видно. Когда на PC происходит критическая ситуация (сворачивание/разворачивание окна), на контроллере тишь да гладь - никаких изменений. Даже джиттер вызовов моей функции отправки кадров от стека не превышает 30мкс и не зависит от наличия или отсутствия критического события на стороне PC.

Имеется LPC1758 на нём USB-device-стек взятый из примеров IAR для LPC17x. На LPC имеется ПО (сервер), передающее данные на PC через изохронную точку. На PC имеется ПО (клиент), принимающее данные через драйвер CyUSB. Так вот, при работе CyUSB на winXP 32бит иногда (предположительно - при большой загрузке CPU) возникают потери пачек кадров. Даже собственно и не при очень большой загрузке CPU, но всегда наблюдается данный баг например при свёртывании/развёртывании любого окна на PC. При работе CyUSB под другими виндами (и 32 и 64 бит) такой проблемы нет. Также при работе другого устройства на другом процессоре и с другим USB-стеком (совершенно другое железо USB-контроллера) с данным клиентом проблем не возникает ни под какими виндами. Подозреваю, что баг кроется в CyUSB, но почему он проявляется только при работе NXP-ного стека на LPC и не проявляется с другим контроллером??? Кто-нить сталкивался с подобными проблемами при работе USB-device-стека NXP из примеров IAR?

Вообще-то расположение переменной или функции в памяти определяется не по листингу, а по map-файлу. Ну если 0xa0e - далее берёте даташит на свой CPU и смотрите есть-ли по этим адресам память и какая. Да... не думал что всё так печально... :crying: Барышня, как правильно - вам надо найти книжку по си и читать-читать-читать....

ну значит всё-таки JTAG.... И похоже что у вас проблемы с загрузкой программы JTAG-ом в CPU. Либо в компиляции. Я же говорил - "листинг", а листинг - это не исходник :) Посмотрите по map-файлу куда у вас этот массив попадает

Что значит "не записывает CCS"? Вы заполняете массив через JTAG в отладчике? Или всё-таки - не записывает CPU в программе? Если 2-е - покажите сюда соответствующий участок листинга.

Для C55x есть ещё такая полезная дока: SPRU317H.pdf В нём имеются ссылки на соответствующие даташиты для каждой периферии - можно узнать имя даташита для любой периферии.

Что-то вы развели тут... лес целый... транзисторы, фронты... B) А достаточно посмотреть на график характеристики потребления CPU от частоты - по оси X отложим МГц, по оси Y - мА. Так вот - если его наклон к оси X менее 45градусов, то явно что на большей частоте при пропорционально большем времени сна, потребление будет меньше. Это если предположить, что у вас некий идеальный код, время выполнения которого не зависит от реального времени и обратно пропорционально только частоте CPU (что в реальности обычно не совсем так).

Только один SSP может работать как SPI! См. даташит. Вы что-то путаете, у вас или два SSP или SSP+SPI. У меня в проектах на LPC17x есть два задействованных SSP + куча других интерфейсов - проблем никаких.

Где вы в LPC1769 нашли 3 SPI порта??? Насколько помню - там всего 2 SSP было и только один из них мог быть SPI. И вообще - вроде изначально вы про I2S говорили...