jcxz

А FIFO что - разве не в общей памяти находятся? А как уже организовать обмен через эту общую память если она есть - это другое дело, и решений тут может быть множество. В том числе и FIFO. В FIFO достаточно чтобы были только операции записи указателей атомарными (а это верно практически для всех CPU). Запись самих данных в FIFO не обязательно должна быть атомарна.

Правильно. Что-ж тут непонятного? Ядра работают как независимые CPU, только память у них общая (не вся). Связь через общую память и межядерные прерывания.

Межядерная синхронизация всяко сложнее межзадачной (в одном ядре). К тому-же ведомое ядро надо проинитить, и всё ему настроить таблицу прерываний и т.п. Это лишние телодвижения. Если для задачи хватает одного ядра - зачем усложнять? Второе ядро имеет смысл задействовать только если невозможно реализовать на одном, или задействование 2-го ядра даёт какие-то преференции... имхо PS: С LPC4337 не работал, но работал с OMAP. Там-то однозначно межядерное разделение имело смысл :)

Достаточно накатить заранее подготовленный образ раздела со всем ПО кроме IAR, а его потом поставить поверх.

При провале питания, во время такого обновления, потеряете своё устройство. Во всех наших устройствах на М3 мы давно так и делаем: 1. ПО разделено на 2 независимых: бутлоадер и рабочее. Обновляется только рабочее. 2. Загрузка нового ПО во флешь (внутреннюю флешь программ в нерабочую область или в SPI флешь) в рабочем ПО по рабочему протоколу. 3. По завершении загрузки - выставление флага и ресет. 4. В бутлоадере: проверка наличия флага, проверка валидности ПО во флешь. Если валидно - обновление ПО и снятие флага после. 5. Переход на рабочее ПО из бутлоадера. Бутлоадер и рабочее ПО никак не связаны - при переходе на рабочее ПО, бутлоадер переходит на начальный (стартовый) адрес. Проблем с прерываниями в бутлоадере нет если правильно управлять таблицей прерывания и NVIC и инитить всю периферию с нуля.

Интересно только как тогда взаимодействовать с ISR-ами? Или как быть если в задачах нужно использовать ОС? А вообще - вроде в IAR-е можно объявить секции, занимающие общее место в памяти. Точно не помню ключевых слов. Смотреть нужно мануал на линкер.

Замените на WT12 и не мучайтесь ;)

Тогда - жаль что мск онли... :)

Есть такая вещь как переключение стека ;) Сохраняете контекст задачи (все регистры) на стеке задачи, переключаетесь на стек следующей задачи, восстанавливаете её регистры... И так по кругу... Не знаю как на imx, но на ARM7/9 и Cortex вполне себе обычное. На ARM-ах и Cortex-ах реализация на асм пишется на раз. Про джиттер AlexandrY правильно сказал.

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

Ваяли на LPC+WT12 подобное :)

Вы сами, исходя из частоты CPU, его загрузки, кол-ва прочих прерываний и пр. должны определить частоту для таймера, которая не помешает остальным ISR. Иначе, следуя вашей логике, вообще никакие прерывания (асинхронные одно относительно другого) нельзя использовать, так как они могут наложиться и "что-нибудь не успеет обработаться"

Нехватки каких ресурсов?

Решение навскидку: Читать значение RTC в прерывании какого-то таймера (частоту прерывания выставить в соответствии с необходимой точностью обнаружения момента изменения RTC). По обнаружению изменения значения RTC, перепрограммировать частоту на период немного меньше секунды. После получения этого прерывания, опять установить большую частоту прерывания до изменения RTC. и так далее. Надеюсь идея ясна. Или решение проще: перейти на LPC - там в RTC есть все необходимые прерывания ;)

Может просто купить другой клон? :) Помнится у нас с клонами от Терраэлектроники тоже были проблемы с периодическим слетанием прошивки на всех экземплярах. В конце концов - заменили все на J-Link-и со starterkit.ru и проблемы прекратились. Да и гальваноразвязка для J-Link дороговата. Дешевле купить развязку на USB - стоит около 1000р.

Прочитать наконец доку на используемое ядро. Посмотреть содержимое LR. По нему определить стек возврата (PSP или MSP). Прочитать 8 слов с этого стека.

Вы о каком профиле? SPP? А почему Вы решили, что будет интенсивный траффик? Откуда Вам известна моя задача? Вообще-то SPP - эмуляция UART, который суть - асинхронный интерфейс, т.е. - данные могут быть или их вообще может не быть и известна только максимальная скорость данных, но никак не минимальная. И почему SNIFF может быть не совместим с SPP?

Странно у вас как-то построено.... DMA обычно используется для уменьшения частоты прерываний. Для этого стараются увеличить размер блока. У вас же вижу частота прерываний очень высокая (10кГц). Зачем так - пересылать всего по неск. байт? И это при том, что у DSP вход/выход в ISR обычно требуют сохранения/восстановления большого контекста. Подозреваю что значительная часть из 60% загрузки у вас тратится именно на сохранения/восстановления контекста в ISR.

...или сзади приписать $ :)

Почему? Ведь в доке ясно сказано: F This value enables all of the above modes (the default value) В любом случае - попробовал и 4 и 8 и 12, без разницы, SNIFF всё равно не включается. Разве что перестаёт переключаться в MASTER по команде SET {link} SNIFF. А вы используете переключение role в master? Если верить доке, то это также должно уменьшать потребление в 3-4 раза... Может то, что у меня происходит (переключение в MASTER при подаче SET {link} SNIFF) случается, потому что сторона на PC не поддерживает SNIFF и модуль чтобы хоть как-то выполнить поставленную SNIFF-ом задачу уменьшения потребления, переводит его хотя-бы в MASTER-режим :rolleyes:

Хмм... Я так понял, что там просто опечатка - начало нумерации битов от 1, а не от 0. Там же приведено значение F как "всё включено". Я как раз ставлю F. У меня кстати тоже проблема с режимом SNIFF - не включается никак. Ни через SET BT SNIFF, ни через SET {link} SNIFF после установления соединения. Второй способ работает для переключателя ROLE (по установке SET BT ROLE оно не меняется, а только так - после коннекта через SET {link} ROLE) . Если же пробовать дать SET {link} SNIFF ... после коннекта, то почему-то включается ROLE в режим MASTER, а ACTIVE как было так и остаётся. Может где какой ключик я забыл? Вот лог обмена с модулем после входящего соединения (видно что после непонятного переключения в SLAVE после команды SET {link} SNIFF, моё ПО пытается обратно переключить в SLAVE, но новый SET {link} SNIFF всё гробит): >> CONNAUTH 00:02:72:37:68:ba 0 3? \Gok << CONNAUTH 00:02:72:37:68:BA 0 3 OK >> CONNAUTH 00:02:72:37:68:BA 0 3 OK \Gecho >> OK. \GprintOk Result parse: \GOK >> CONNAUTH 00:02:72:37:68:ba 1 1? \Gok << CONNAUTH 00:02:72:37:68:BA 1 1 OK >> CONNAUTH 00:02:72:37:68:BA 1 1 OK \Gecho >> OK. \GprintOk Result parse: \GOK >> RING 0 00:02:72:37:68:ba 1 RFCOMM 3b538b4 \Gok << LIST >> LIST \Gecho >> LIST 1 \Gok >> LIST 0 CONNECTED RFCOMM 127 0 0 0 8d 8d 00:02:72:37:68:ba 1 INCOMING ACTIVE SLAVE ENCRYPTED 0 \Gcomplete >> OK. \GprintOk Result parse: \GOK FLAGS: 02 01 01 02 << SET 0 SNIFF 100 10 3 10 >> SET 0 SNIFF 100 10 3 10 \Gecho >> OK. \GprintOk Result parse: \GOK << LIST >> LIST \Gecho >> LIST 1 \Gok >> LIST 0 CONNECTED RFCOMM 127 0 0 0 8d 8d 00:02:72:37:68:ba 1 INCOMING ACTIVE MASTER ENCRYPTED 0 \Gcomplete >> OK. \GprintOk Result parse: \GOK FLAGS: 02 01 02 02 << SET 0 SLAVE >> SET 0 SLAVE \Gecho >> OK. \GprintOk Result parse: \GOK << SET 0 SNIFF 100 10 3 10 >> SET 0 SNIFF 100 10 3 10 \Gecho >> OK. \GprintOk Result parse: \GOK << LIST >> LIST \Gecho >> LIST 1 \Gok >> LIST 0 CONNECTED RFCOMM 127 0 0 0 8d 8d 00:02:72:37:68:ba 1 INCOMING ACTIVE MASTER ENCRYPTED 0 \Gcomplete >> OK. \GprintOk Result parse: \GOK FLAGS: 02 01 02 02 << SELECT 0 >> SELECT 0 \Gecho >> OK. \GprintOk Result parse: \GOK CONNECT

Сейчас тоже работаю с WT12A. Коннект с PC через SPP-профиль. Описанной проблемы не наблюдаю - дисконнект менее секунды. Настройки: SET BT PAGEMODE 3 2000 1 SET BT POWER 3 3 3 SET BT ROLE 1 f 7d00 SET BT SNIFF 0 20 1 8 А вы какой профиль используете?

Наверное вы ошиблись конфой. Вам скорее сюда: http://electronix.ru/forum/index.php?showforum=3

не знаю. Я ей не пользуюсь. Но в моём 6.50 имеется описание в мануале на компилёр (стр.282).

Кейлом не пользуюсь, но в IAR всё просто - в линкёре есть соответствующая команда для подлинковки в проект в выбранную секцию бинарного файла. Без всяких конверторов. --image_input filename [,symbol,[section[,alignment]]] Use this option to link pure binary files in addition to the ordinary input files. The file’s entire contents are placed in the section, which means it can only contain pure binary data.