jcxz

Нет RAM-кода нету. Вот как-то непонятно решилась проблема - если написать так: define region RAM_region = mem:[from 0x10000000 size 0x4000] | mem:[from 0x2007C000 size 0x4000]; place in RAM_region { rw, first block CSTACK, section .bss, section .FRAM, section .bssStk, block HEAP }; то не влазит. По map-у вижу, что он почему-то в первую часть региона пихает больше, чем в она сама есть: .bss zero 0x10006514 0x1 solve.o [1] .bss zero 0x10006515 0x1 timeout.o [1] .bss zero 0x10006516 0x1 timeout.o [1] .bss zero 0x10006517 0x1 update.o [1] - 0x10006518 0x6518 Т.е. - почему-то не продолжает .bss который как раз идёт в конце первой части в новую часть, а лепит его в первую часть с переполнением. Но если описать так: define region RAM_region = mem:[from 0x10000000 size 0x4000] | mem:[from 0x2007C000 size 0x4000]; place in RAM_region { rw, first section .bss, block CSTACK, section .FRAM, section .bssStk, block HEAP }; (.bss переместить в начало региона), то начинает нормально линковать, и .bss переносит на 2-ю часть региона: .bss zero 0x1000333c 0xc uart.o [1] .bss zero 0x10003348 0xcc uart.o [1] .bss zero 0x10003414 0x1 update.o [1] - 0x10003415 0x759 "P2", part 3 of 3: 0x3338 .bss zero 0x2007c000 0x4 ade.o [1] .bss zero 0x2007c004 0x4 ade.o [1] .bss zero 0x2007c008 0x4 ade.o [1] .bss zero 0x2007c00c 0xa14 comm.o [1] Чудеса вобщем... :smile3046:

Имеется довольно большой проект для LPC1754, в котором два несмежных региона RAM. IAR 5.50.1. Одного региона для размещения всех секций .bss программы не хватает. Пытаюсь заставить линкёр размещать в два региона, но что-то не получается. Судя по документации два несмежных региона можно описать как: define region RAM_region = mem:[from 0x10000000 size 0x4000] | mem:[from 0x2007C000 size 0x4000]; и потом: place in RAM_region { rw, first block CSTACK, section .FRAM, block HEAP, section .bssStk }; Но не работает - линкёр выдаёт ошибку, что не может разместить в первую часть региона: Error[Lp015]: committed sections in [0x10000000-0x10003fff] too large to fit -- code may need too many veneers Почему он не пытается использовать вторую часть???? Если пытаться определить как 2 региона: define region RAM_regionA = mem:[from 0x10000000 size 0x4000]; define region RAM_regionB = mem:[from 0x2007C000 size 0x4000]; то при попытке направить rw-секции в разные регионы: place in RAM_regionA { rw, ... }; place in RAM_regionB { rw, ... }; Выдаётся сообщение об ошибке: Error[Lc037]: ambiguous section match: "zi section .bss in ade.o" matches more than one pattern Желания определять для каждой переменной свою отдельную секцию, отличную от .bss - нет, ибо это - криво. Надо именно - размазать секцию .bss по двум регионам. Типа как это просто и удобно делается в CCS от TI: .bss : { *(.bss) } >> DARAM1 | DARAM2 | DARAM7 Неужто в IAR об этом не подумали?????

В LPC177x/LPC178x тоже есть.

Если поставить управление линией 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 - будет долго возиться с кодом..... кустарщина вобщем ;)