jcxz

В сумме тянет на полляма в месяц.... Иээх! И где-ж мой французский??..... :crying:

Переведите процессор в режим ISP (нога 2.10 (или какая там в этом проце?) на GND) и попробуйте в этом режиме подключиться JTAG. Или стереть флеш в этом режиме flashmagic-ом и потом подключиться JTAG. У меня частенько такое помогает с LPC17xx. А в худшем случае - в той прошивке, что вы прошили, могла стоять блокировка JTAG и ISP. Если прошить такую, то FLASH превращется в ROM и процессор можно на помойку. Смотреть надо что шьёте. Читайте раздел даташита про защиту флешь. Или они только в кортексах появилась? Не помню уж.....

Если уж Вы начали изучать ARM9, то сразу отучайтесь от ногодрыганья и изучайте периферию ARM.

Кто-нить имел опыт работы с bitband-GPIO через GPDMA на LPC17xx? Это вообще возможно? Обычный (нет bitband) read-доступ к GPIO через GPDMA работает нормально. Но при попытке работать через bitband область, вылетает ошибка DMA. GPDMA направление: GPIO->память. Bitband пытаюсь делать как на стороне GPIO так и на стороне памяти. Тип передачи: IO->память. bitband GPIO делаю через bitband-область RAM (так как адресное пространство GPIO находится в области RAM-bitband region). Пробовал также и тип передачи память->память - то же самое. События для DMA генерит таймер.

И точно!!! Мой баг исправили, о котором я писал в: http://electronix.ru/forum/index.php?showtopic=105402 Теперь всё верно компилится. УРА!!! :yeah:

Вроде-бы??? какой именно?

Так это же главный и единственный пункт ТЗ. Как же можно обойтись? Главное - чтоб там линух был, остальное - не нужно. :smile3046:

Значит код у вас разрушается после того места, до которого вы дошагиваете по F11. Либо разрушается в ISR, который в пошаговом режиме не вызывается.

Кащенко :1111493779:

Сразу признаюсь - совершенно незнаком с архитектурой MSP430, но даже у меня сразу возникает подозрение, что в этой архитектуре при прерывании используется переключение стека. Обычно с такими проблемами сталкиваются только люди, не желающие изучать документацию на свой процессор...

sprintf не использует динамическую память - не надо фантазий. Но использует много стека, так что использовать его в ISR-ах, имхо, - моветон. Да и вообще имхо - надо всегда стараться избегать динамической памяти в эмбеддед. Тоже фантазии. sprintf не использует ни динамическую ни статическую память, все хранит в автоматической, т.е. - полностью реерентерабелен. Но объём на стеке использует большой.

А зачем Вам M4? Берёте любой порт для M3 и используете его. Только если нужно многозадачное использование FPU, то нужно посмотреть про сохранение контекста FPU (это опционально в мюкосе). Вот ввожу в гугле и среди первых же ссылок получаю: http://www.google.ru/url?sa=t&rct=j&am....44442042,d.bGE Вполне нормальное описание ядра. Ищите в нём OSTaskCreateExt() и так далее. А почему не тыкать, если ответ присутствует на первой-же странице выданной гуглом?

Кросспостинг однако... Нехорошо! OSTaskCreate() или OSTaskCreateExt(). Документация есть на: http://micrium.com/ а ещё очень гугл помогает...

Кеш не бесконечен - значит будут кеш-промахи. Да, вроде шина не одна, но по факту, из опыта SSP+DMA (LPC1778), SCLK=30МГц, при приоритете доступа к шине CPU выше чем DMA, наблюдал разрывы в аппаратно формируемом SSEL (SSP-мастер). При установке приоритета DMA выше чем CPU, эти разрывы пропадали. Благо у LPC1778 есть регистр приоритетов арбитража шины. Писал об этом здесь ранее.

Зачем у вас такая жёсткая привязка? По-моему должен быть обработчик ISR DMA привязанного к McBSP, который принимает блоки сэмплов от DMA/ставит на передачу блоки в DMA и пингует задачу, обрабатывающую входной поток блоков сэмплов и генерящую выходной поток. Это может быть либо фоновая задача, либо задача запускаемая от этого ISR. Задача обработки это должен быть простой цикл, который смотрит - если есть данные во входном буфере - обрабатывает их и кладёт в выходной буфер, если нет данных - может перевести проц в idle или освободить время для другой задачи. Групповая задержка сигнала будет зависеть от глубины буферизации.

Кому надо? Топикстартеру? Он нигде не писал, что пересылка должна идти постоянно. Скорей всего - это кратковременные транзакции. Ранее делал что-то подобное - кратковременные пересылки пакета в неск. килобайт. Запрещал прерывания и программно гнал через GPIO. Выигрыша от DMA в таком режиме не будет - если проц во время такой DMA-пересылки будет выполнять код - будут проблемы с арбитражом шины (если у DMA приоритет доступа ниже чем у CPU), как следствие - замедление работы DMA, следствие - возможные ошибки протокола обмена по этой вашей GPIO-шине. Я шёл путём оптимизации протокола этой GPIO-шины - после всех оптимизаций у меня на передачу одного слова требовалась одна запись в порт GPIO. При таком алгоритме я передавал весь блок за неск. десятков или сотен микросекунд - это не мешало работе ISR-ов. Не использовал сигналы синхронизации (типа CS или WR) на каждое слово. Синхронизировал начало пакета, потом просто гнал весь пакет. Предварительно необходимо весь код это выполняющий переместиить в кеш CPU или разместить его в ОЗУ. Работало в двунаправленном режиме. Хоть стороны обмена тактировались от разных задающих генераторов, но за время передачи блока частоты не успевали рассинхронизироваться. Делал в том же проекте вариант с DMA (растягивал по времени, добавлял синхросигналы на каждое слово, фоновое выполнение с кодом) - выигрыша в общей производительности системы не получал.

А у нас есть счётчик, собирающийся в сети по ZigBee. И скоро будет кроме того ещё и с беспроводным пультом, как Вы описываете :)

Вдогонку - так Вы же указали в условиях задачи, что такое устройство у вас имеется - тот пункт сбора на краю посёлка. В симплисити есть ретрансляция (со сменой маршрутов при изменении условий сети, отключении/подключении устройств)? PS: Устройства номер1 это как я понимаю - счётчики (скорей всего электроэнергии) ? ;)

Я вообще-то Вам советовал не код, а объёмные данные из внешней параллельной флешь перенести в SDRAM, чтобы не переключать параллельную шину. На старте грузить SDRAM из SPI-flash.

Во-первых: изначально Вы говорили про разработку нового устройства: Во-вторых (по поводу SDRAM): где я Вам пишу про выполнение из SDRAM? Вы путаете... В SDRAM - большие данные, во flash - код. Впрочем - хозяин - барин. Зачем тогда совета просите?

Если у вас свой бутлоадер и ПО вы обновляете через свой протокол, то не вижу особой сложности: 1. Если не нужно безопасное обновление ПО: грузите по своему протоколу новое ПО в ОЗУ (из hex-файла, разбирая 2 области), прошиваете загруженные области соответственно - одну во внутреннюю flash, другую - во внешнюю. 2. Если нужно безопасное обновление: грузите в ОЗУ, затем пишете его в теневую копию внешней flash, перегружаетесь, бутлоадер обнаружив новое ПО в теневой области flash, переписывает его с разбивкой по областям (также как в 1-м пункте) во внутреннюю flash и область рабочего ПО внешней flash.

Не понятно - зачем??? Если у вас всё ПО влезает в обычную SPI-flash. Зачем этот лес городить? SDRAM подразумевает большой объём памяти. На старте всё грузить в SDRAM из SPI-flash и дальше работать чисто в ОЗУ. Ну если объём ПО очень большой (что не влазит в SPI-flash или скорость старта не устраивает) - тогда тоже грузить на этапе старта переключая режимы (либо ещё как), а затем - только с ОЗУ работать.

Из опыта работы OMAP-L137+SDRAM могу сказать, что при переносе кода функции из внутренней L2-RAM в SDRAM (для DSP-ядра) практически разницы не заметно в скорости. Хотя при таком же переносе данных из L2-RAM в SDRAM разница существенная (до 6-7 раз замедление). Хотя канеш в L137 в DSP-ядре есть L1-кеши для кода и данных размером 32K. Для ARM-ядра там несколько другая картина. Там насколько помню уже есть разница при переносе кода в SDRAM, хотя не такая катастрофическая как тут пишут. Я точно не помню (тестил давно) и для меня там быстродействие ARM-кода не критично, критичен только DSP-код, но вроде замедление получалось порядка менее 2 раз. Кеш SDRAM там насколько помню есть и в ARM-ядре. Хотя конечно характер кода разный для этих ядер и в DSP-коде с обилием циклов с запретом прерываний и минимумом ветвлений кеш хорошо работает. Но в общем даже для ARM-ядра снижение скорости не такое катастрофическое. Так что если есть кеш SDRAM - можно спокойно работать. Почему-то эффективность кеша данных SDRAM много ниже чем кеша программы SDRAM. Под Keil - не знаю, но под IAR для возможности загрузки отлаживаемого образа в SDRAM по JTAG, нужен .mac-файл конфигурящий SDRAM. Может Вы поспешили со сменой платформы (если быстродействия старой хватает)? А если Вам линковать код и быстрые данные - в одну область памяти (int. flash), а всякие иконки и т.п. тряхомудрию большого размера - в другой регион (SDRAM)? Берёте LPC1788, ставите SDRAM + внешнюю флешку (SPI) большого размера. При старте ПО в бутлоадере инитите SDRAM и грузите второй регион из внешней SPI-флешь в SDRAM. Насчёт DMA из SDRAM - не знаю, но в пакетном режиме (последовательного доступа) SDRAM должна работать гораздо эффективнее.

Это зачем? Если Вы используете стек из примеров IAR к LPC, то обратите внимание на usb_hooks.c - в нём можно поставить хуки на многие события в стеке. В том числе и USB_CONFIGURE_HOOK() для Вашего случая.

Чел, не знающий ни си ни данного МК освоит всё за 2-4 недели да ещё и напишет???!!!! Да он просто гений!