jcxz

Если поставить управление линией SSEL от SSP, то изредка (раз на неск. сотен-тысяч транзакций) сигнал SSEL прерывается. SSP-мастер. Если поставить управление SSEL от GPIO - всё ок, или если снизить частоты SCLK ниже некоторых значений, то тоже прерывания SSEL пропадали. Хотя, возможно, проблема была в чём-то другом......

А в чём проблема? FIFO с модбас и на приём прекрасно работает. У меня шина на Cortex-M3 NXP изредка перегружается при 2-х параллельно работающих SSP через DMA (по 2 потока tx/rx), один SSP SCLK=20МГц, другой - SCLK=30МГц. Байтовый режим, пакетная передача, CPU_CLK==120МГц

Да??? фуууу...... И как их можно сравнивать с нормальными LPC??? ;)

От FIFO. На RX максимальный уровень срабатывание события == 14, TX - вроде после полного опустошения буфера. Или на STM не так?

Вообще не понимаю зачем народ так упорно пытается юзать UART через DMA??? Ну конечно если скорости из ряда стандартных до 115200 (если больше - тогда ещё есть резон). При скорости 115200 частота прерываний при программной реализации == 115200/10/14 == 823Гц (TX IRQ ещё меньше) - для такого процессора это несущественно (даже на частотах <48МГц тактовой загрузка CPU на ISR будет не более сотых долей процента). И гемору на порядок меньше.

Вопрос-то вроде изначально был про TMS320C5515. Но откуда вдруг в TMS320C5515 взялось RISC-ядро и несколько DSP-ядер - не понятно. :) Тут вообще похоже каша в голове: "...в методички описан один проц а на практике другой.." А пишет похоже вообще о третьем. И о каких процессорах речь из сообщений вообще не ясно.... А TMS320C5515 это как раз вполне себе дешёвый проц. Демоплату на него техасцы даже могут бесплатно выслать.

По-крайней мере у нас не получилось подружить несколько разных модулей - только между одинаковыми работало. Правда это было уже несколько лет назад......

Раз речь идёт о датчиках старта/финиша и фиксации времени, то как вы будете время синхронизировать на устройствах? Если будете использовать ZigBee, то тогда нужен будет отдельный канал для времени (GPS к примеру) на каждый датчик. Наверное это зависит от конкретного модуля. У CC2480/CC2530 насколько помню есть возможность задать. можно Если исключить функцию синхронизации времени на устройствах, думаю - ZigBee вполне подойдёт. Только надо быть осторожнее с большими дальностями и лесами-горами - потребуются промежуточные ретрансляторы (а это доп. задержки) и возможно усилители.

Исключительность конечно-же компенсируется материально в соответствующем размере?

Как здесь уже отмечали - реально только если эти устройства используют модули одного вендора. Да ещё и чтоб модули эти работали в одном режиме (у тех-же TI-ных CC2480/CC2530 есть SimpleAPI, а есть другое API и если на двух сторонах будут разные API использоваться они ни до чего не договорятся). Нормально. Если запустите устройство в роли "enddevice" - должно смочь. Но enddevice-ы не могут ретранслировать - т.е. в условиях плохой связи нужны устройства-роутеры.

Как это сказать IAR-у? (что нужно два прохода, что только на 2-м считать CRC?)

А есть такие ADC, которые работают через UART? При желании можно перевести мультиплексор пина в GPIO и на ввод. А вообще - для приведения уровней сигналов с разным питанием существуют преобразователи уровня.

У меня сейчас CRC32 считается в IAR-е. Но в своё время много потратил времени чтобы разобраться как это правильно делать. Проц - LPC17xx. 1. Область расчёта CRC не должна перекрываться с областью расчёта контрольной суммы первых векторов из таблицы ISR. 2. Место хранения CRC не должно перекрываться с областью расчёта CRC. 3. Размер области, заполняемой шаблоном, должен быть достаточным, чтобы перекрыть всю занимаемую прошивкой память. Если эти условия не выполняются - будет неверная CRC.

Неверно понимаете. В вашем класе вам надо перегрузить new: class myOTL { ... public: void * operator new(uint, myOTL *p) const { return p; } };

Однозначно - в проекте. Если не хватает памяти, проект не должен собираться.

Ужас просто.... К чему приводит нежелание учить матчасть и упорное пользование всякими либами.... :smile3046: На вышеозначенном проце данные операции (и disable и clearpending) выполняются всего по две пары записей в регистры NVIC.

По-моему - проблема выеденного яйца не стоит. Если при завершении передачи (нет больше данных для передачи) в ISR вы маскируете THRE, то потом, когда фоновая задача хочет записать новые даные для передачи, она делает следующее: 1. мьютекс/запрет прерываний. 2. проверка - THRE замаскировано(запрещено)? нет - переход к 5. 3. размаскируем THRE 4. заполняем TX fifo. 5. освобождение мьютекса/разрешение прерываний. Если при завершении передачи (нет больше данных для передачи) в ISR вы не маскируете THRE, а просто выходите из ISR (предварительно сбросив программный флаг "TX в процессе"), то потом, когда фоновая задача хочет записать новые даные для передачи, она делает следующее: 1. мьютекс/запрет прерываний. 2. проверяете флаг "TX в процессе". Если стоит - переход к 5. 3. уставливаем флаг "TX в процессе" 4. заполняем TX fifo. 5. освобождение мьютекса/разрешение прерываний.

При дальнейшем уменьшении проблемной функции, баг пропадает. Даже если обрезать не связанную с багом часть функции. Как будто баг возникает когда размер кода функции превышает некий предел.

Если бы Вы хотя-бы открыли ту тему прежде чем отвечать, Вы бы заметили, что я цеплял там полностью проект. Это понятно. Но хочется работать без гемора с постоянным переключением между компиляторами.....

Если кто отправлять будет, то напишите до кучи и про мой баг (писал о нём недавно сюда: http://electronix.ru/forum/index.php?showtopic=105402 ) Вдруг - поправят? ;) А то сейчас по необходимости пользую IAR 6.21.1 (старый 5.50 который хорошо проверен на вшивость большими проектами с полной оптимизацией, но к сожалению 5.50 не понимает через JTAG LPC1778) :(( И поэтому приходится ставить Low оптимизацию в 6.21.1. ЗЫ: Проверил примеры из этой темы на своём IAR 6.21.1 - бага нет (ни с чётными ни с нечётными размерами циклов). Cortex-M3 High optimization (Size)

Им можно только посочувствовать.... :crying: Один уже похоже отправился проводить опытную эксплуатацию собственной разработки лично на лесоповал

Отсюда - можно подробнее, что за задержки? Сколько работаю с USB вроде ни разу не сталкивался.... Ядро C5000 на порядок лучше любого Cortex-а на сравнимой частоте для сигнальной обработки. Но человек боится этого страшного слова DSP!..... :) И на отладочные платы указали дешёвые, а всё равно - будет что-то паять на коленке заведомо гораздо худшее и по разрядности АЦП/ЦАП и по возможностям обработки и ещё и без JTAG - будет долго возиться с кодом..... кустарщина вобщем ;)

Получается что FIQ вам не нужен. Зачем тогда его используете? Сделайте все прерывания через IRQ. И обнулять в обработчике ничего не нужно. Почитайте мануал на ядро про режимы процессора. Найдите где у вас в начале программы выставляются дефолтные значения для флагов CPSR для режимов FIQ и IRQ и выставьте их там.

Так-ли? К примеру в даташите на F28M35 вроде написано, что можно заблокировать JTAG (см. раздел "JTAG Lock"). На ARM-ах NXP к примеру тоже можно заблокировать. Например в ARM-ах NXP если флешь заблокирована и считать/записать её нельзя и JTAG заблокирован, то можно только выполнить полное стирание флешь (через UART), после этого и защита тоже сбрасывается.

С чего бы это PLC стал мёртвым?