Axel

Думаю Вам и дальше стоит оставаться вдали от этого форума. Вряд ли Вы найдете здесь помощь (и понимание).

Не уверен, что в тему, но... Можно посмотреть в сторону сенсоров охранной сигнализации и систем управления автоматическими дверями. Там вроде используются генераторы на диодах Ганна и похожие частоты. Но мощности там ессно небольшие.

Иногда (часто) не в ручонках дело. Типичный пример - потенциометры на педали газа автомобилей. Пример из программы ECU привести не могу - не сохранился, но когда однажды пришлось разбираться, то обнаружился вполне серьезный фильтр (насколько удалось понять после дизассемблера).

Я объявляю обычным образом или volatile (по необходимости). но для модификации использую циклы ldrex / strex вместо присваивания (ессно без запрета прерываний).

Мне тоже стало интересно... Попробовал фильтр Ekstrom'а для обработки сигналов touch screen (5 - 15 отсчетов). Понравилось (время не измерял).

... или "#pragma once".

Перефразируя известный анекдот про вес младенцев, могу предположить, что (ИМХО): - оптимальная OS под каждый девайс - на радость электронщикам; - везде Linux - на радость программистам; - единый API на все оси - на радость (только) QA-щикам...

А нигде и не написано, что настройка пинов связана их функциями. Вы можете, например, подцепить "пулы" в режиме АЦП. Конфигурирование пинов - как правило "дело рук самих утопающих"...

Аналогично. Плюс RTS/CTS - позволяет минимизировать протокольные навороты.

На каждый канал. В этом контроллере нет интерфейса, способного вывести такой (20 MB/s) поток данных (если речь идет о непрерывном процессе). Далее (по желанию ТС) можно порассуждать о возможной структуре системы...

Ага, чаще всего и не говорится. Только вот упрвляться с сотней имиджей (если у Вас присутствует дисплей), десятком вариантов настроек, таблицами коеффициентов и прочей ерундой без FS - очень себя не любить...

Если нет возможности (или желания) наблюдать за VBUS, можно периодически проверять статус устройства, используя команду SIE "Get Device Status" (0xFE). При коннекте 0-й и 2-й биты возврата должны быть установлены.

"...При попытке зашить программу в нужный адрес..." - означает видимо, что по "ненужному" адресу (0х00000000) присутствует бутлоадер.

...откуда такие выводы про PLL??? Моя интерпретация: имеется бутлоадер, использующий PLL. В основной программе также присутствует инициализация PLL, в теле которой пррграмма глочнет. Известная (мне) проблема: перед переходом PLL надо заглушить. Типа: LPC_SC->CCLKSEL = 0x01; // set sysclk (12MHz) as clock source LPC_SC->PLL0CON = 0; // disable PLL LPC_SC->PLL0FEED = 0xAA; LPC_SC->PLL0FEED = 0x55;

У меня есть работающий проект для ILI9327, правда для LPC1778 и без использования SMSIS. Если это может помочь - пишите в личку.

У меня похожая ситуация: Cortex-M4 - CPLD, так что еще раз спасибо за идею!

Очень кстати... Спасибо!

"Да, но нет!"©. Незаконченность блока определяется (вероятно) по таймауту - непоступлению данных до конца текущего sof. Далее пустой блок, далее запрос хоста на передачу. Видимо как-то так...

А чем не угодил "TNkernel-овский" MemPool?

По-моему логично: незаконченный блок - автоматом пауза до окончания sof, потом еще до 2-х sof между пакетами.

Для надежности даже больше (учитывая 12Мb full speed) Если процессы асинхронные - не думаю. Я использую кольцевые FIFO.

А можно подробнее (картинку про трубочки и что такое "помогло")? Спасибо.

Вы правы. Я неточно выразился, а имел в виду "не для быстрого обменa".

Нельзя. I2C на 0.5м шлейфе устойчиво работает до 250кГц. Да он и не для этого придуман (не для связи между модулями).

Недостаточно информации для "генерации рекомендаций" . Из собственного опыта: для решения похожей задачи (еще на STM32F710) использовал CAN. В системе был хост для "бродкастинга", "енумерации", "апгрейда" и синхронизации. Каждое устройство содержало бутлоадер с независимой поддержкой CAN. Но таких жестких требований к "латентности" не было. Если бы были - вероятно использовал бы аппаратные линии.