jcxz

Вот - уже теплее ;) Да - это команды переходов на процедуры обработки исключений. Не знаю, где это описано в документации L138, но в "OMAP-L137 Applications Processor System Reference Guide" (SPRUG84,C) надо см. раздел "2.4 Exceptions and Exception Vectors" - там описано, и вектора FIQ и IRQ, которые вам нужны. А ещё почитайте описание на ядро ARM926EJ-S - там описано как работает система прерываний в этом ядре. То, про что Вы писали (контроллер прерываний AINTC), идёт уже после этого и может опционально использоваться для FIQ и IRQ прерываний. Или не использоваться вовсе :) Вот как у меня описана таблица векторов, которая располагается с адреса 0xFFFF0000: exceptionsInit: LDR PC, ___c_int00 ;Reset Interrupt LDR PC, __UND_handler ;Undefined Instruction Interrupt LDR PC, __SWI_handler ;Software Interrupt LDR PC, __PAB_handler ;Prefetch Abort Interrupt LDR PC, __DAB_handler ;Data Abort Interrupt .long 0 ;Reserved For Future Expansion LDR PC, __IRQ_handler ;IRQ Interrupt LDR PC, __FIQ_handler ;FIQ Interrupt ___c_int00 .long _c_int00 __UND_handler .long UND_handler __SWI_handler .long SWI_handler __PAB_handler .long PAB_handler __DAB_handler .long DAB_handler .long 0 __IRQ_handler .long IRQ_handler __FIQ_handler .long FIQ_handler Вот ISR IRQ (видите где только начинает использоваться GPVR?): IRQ_handler: SUBS LR, LR, #4 STMFD SP!, {R0-R3, R12, LR} ;Store registers on IRQ stack LDR R0, AINTC_GPVR ;R0 contains address of GPVR (which contains ISR address) LDR R1, [R0] ;R1 contains address of highest prioritized ISR ADD LR, PC, #0 ;Save return address in LR, LDR PC, [R1] ;Go to ISR (still in IRQ mode), will return to following line LDMFD SP!, {R0-R3, R12, PC}^ ;Restore registers from IRQ stack. Return to program current status

У нас это в старом изделии используется, которое уже давно в серии. Уже не помню - откуда мы взяли, возможно из ерраты. Там тож у нас 512k SRAM, остальная часть которой рулится программно. Потому и вспомнил :)

Вообще-то у нас LPC2378, но думаю, что это справедливо и для LPC2388. LPC2378 может выдавать два этих CS одновременно - это и есть 3-я страница. Как - думаю поймёте по *.icf: define region EXTRAM_mem = mem:[from 0x80000000 to 0x8000FFFF] | mem:[from 0x81000000 to 0x8100FFFF] | mem:[from 0x82000000 to 0x8200FFFF]; Дерзайте! :)

Вы совсем не хотите читать то, что я пишу. Тогда зачем спрашиваете если не слушаете советов? Повторяю ещё раз: таблица прерываний находится с адреса 0xFFFF0000 И ещё раз: почитайте в даташите как работает система прерываний в ARM-ядре

Причём здесь Global Prioritized Vector Register??? Вы ещё раз внимательнее перечитайте моё письмо и почитайте в даташите как работает система прерываний в ARM-ядре.

По-крайней мере в OMAP L137/L138 вся периферия доступна обоим ядрам. Даже прерывания - если его сконфигурить в одном ядре, то и другое ядро может получать это прерывание. Для взаимодействия ядер не нужно никаких инструментов - всё взаимодействие очень просто - осуществляется с помощью общей области памяти и 5-ти меж-ядерных прерываний (3+2): каждое ядро может посылать прерывание другому ядру, разместив предварительно некую инфу в общей памяти.

Причина может быть в отсутствии у вас таблицы прерываний. У ARM-ядра L137 (и думаю L138) таблица прерываний находится с адреса 0xFFFF0000. PS: Такие длинные портянки кода, как у вас, следует оформлять используя CODEBOX, а не CODE. Чтобы не листать по неск. экранов....

А ведь в LPC2378/2388 можно активно пользовать (а не программно переключать) 3x64кБ внешней SRAM ;)

Нет 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; } };