Axel

В принципе - сколько угодно: оторвать MISO и будет Вам только передача. Ну и наоборот... Все это понятно, но некрасиво...

Понадобилось организовать периодическое чтение из SPI через DMA - по 19 байт за один сеанс. Получилось, но как-то криво: 1. Понадобилось два канала DMA - один ессно на прием, другой на передачу - чтобы клоки гнать. Иначе никак... 2. После каждой транзакции приходится очищать FIFO - там почему-то оказываются лишние пять байт (нулевые). На внешних линиях никаких лишних пересылок не отмечено (смотрел осциллографом). Оно бы ничего, но лишний код в прерываниях... Если кто знает, как сделать лучше - научите...

...в названии топика присутствует ошибка - не "Когда" а "Кому".

Интересно, поскольку ситуация актуальная... Пытаюсь найти логику, но не получается. Это я ее не вижу, или это натуральный бубен?

Спасибо, технично, уже включил в код.

А как Вы это делаете? Я, поскольку так не умею, делаю это как часть инициализации: определяю макс. размер класса, выделяю пул из кучи, и уже его потом использую для placement new... Кривовато выглядит :(

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

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

Из datasheet-ов на DDR чипы и собственных измерений - сопоставлял потребление EVB, на которых DDR память была и своих устройств, где ее не было.

А если "No OS" и "No DDR" то сразу на 200mWt меньше...

Функция tn_cpu_irq_handler() используется только в примерах. Реально в ней нет никакой небходимости ( в смысле RTOS). В TNKernel встроен только обрботчик системного таймера. Все остальные Вы можете оформлять обычным образом.

Не огорчайтесь! Вы нарвались на нормальную реакцию людей, которые сначала делают, а потом - если чего-то не получается, спрашивают. А по сути, если коротко: CAN - сетевой протокол. Реализуется либо программно, либо, что более популярно, аппаратно. MCP2515, если не ошибаюсь, всего лишь физический драйвер, никаких функций собственно протокола не реализует. Т.е. Вам необходим чип с CAN контроллером. Таких сейчас уйма. Есть ли такие среди PIC-ов - к сожалению не знаю.

ISO124 от TI. Недешево, зато брутально...

Можно подумать об аналоговой развязке, напр. оптопара LOC111. Понадобится правда дополнительный усилитель, но точность - без проблем (ввиду симметричной структуры).

Если достаточно точности (1 - 2) % то: ШИМ через оптопару - пассивный ФНЧ(RC цепочка) - конвертер стандарта 4-20mA (напр XTR117A). Вполне себе работает...

Только мне это не нужно... Вроде получилось. После включения и установки Power management битов запретил выход CLCOUT - и все заработало. Спасибо всем откликнувшимся!

В процессе конфигурирования после несколькич записей чип перестает узнавать адрес, так что с чтением пока не очень.

Спасибо, завтра попробую.

Так они по дефолту 111, после подачи питания. Естественно я разбирался с ними (у с другими тоже). Пока не помогло. У чипа снизу есть площадка. Я ее никуда не подключал. Может в этом дело?

Если честно - я менял все, что можно (и, может быть, чего-нибудь, чего нельзя)...

На мой взгляд структура системы существенно зависит от выбранного типа канала. CAN - message-oriented протокол. Можно для каждого Message ID построить индивидуальный обработчик (например класс в C++) со своим, индивидуальным для каждого типа сенсоров, поведением (алгоритмом). Как-то так...

Не могу сладить с сабжем. После подачи питания на VDD (при наличии напряжения на VBAT) на выходе INT появляются импульсы 32kHz. Попытки записи в регистры ничего не меняют. Буду весьма признателен за любые советы...

Похоже и я натолкнулся на проблему из этой же серии (чип LPC1778 208 ног BGA). Прокинулся с подключением к SPI1. При программной реализации (P0.7 - SCK, P0.9 - MISO, P0.10 - MOSI) P0.9 на прием не работал.. PS: "...бит 7 регистра IOCON надо ставить == 1." - действительно... Спасибо!

Авторский вариант. Версия 2.6.

Работает... Я использовал в двух проектах с STM32F103 (среда - CrossWorks). Проблем не заметил. Примеры не разбирал, поскольку уже был опыт с NXP-шными ARMами