Всем привет,

очень надо сабж, написал в форуме для начинающих, но ответа не получил... Не знаю за что браться, запутался, помогите, пожалуйста.

Спасибо!

ИИВ

Прошивка.
Ответ там стоял: JTAG. Важная особенность этого отладочного интерфейса - каскадируемость (очень похоже на SPI): выход TDO предыдущего контроллера на вход TDI следующего, а остальные сигналы - TCK, TMS, TRST - параллельно. Итого 4 линии (массу не считаем). Любой нормальный отладчик/программатор сможет достучаться до любого в цепочке при указании ему количества бит до и после искомого контроллера. Многие программаторы (софт к ним) сами исследую цепочку и выдают ID устройств в ней; остается только выбрать, с каким нужно работать. В JTAG цепочке можно смешивать разные устройства. Например, контроллер и FPGA.

Теперь по шине коммуникации при работе.
Названая "латентность" (хоть бы слово русское подобрал!) ничего не говорит, пока не ясно будет, какова длина пакетов. Вот ответа и не получил там, т.к. не дал информацию.
USART в "классическом" асинхронном режиме может, судя по докам, в районе 10Mbps. Вполне нормально для RS-485. Это 1мкс на байт. Хватит?

Сообщение отредактировал KnightIgor - Nov 23 2012, 19:15

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

Классно!!! Спасибо _Pasha и Вам большое за простые и понятные объяснения по поводу JTAG. Я им до этого почти не пользовался, прошивая все по ком порту, так-как в основном работал на ардуино подобных системах. Теперь все встало на свои места, понял как и что, буду так действовать.



да, реально, я не смог подобрать правильного русского слова, и, поэтому, мы друг друга не поняли... Обычно в параллельных вычислениях под моделью передачи пакетов между процессорами подразумевают модель время = Sigma + Tau * L, где L - размер передаваемого пакета (например в байтах), Sigma - латентность (latency, измеряется в секундах), Tau - обратная к скорости передачи (секунд в байт). Из этого латентность не зависит от длины пакета. В моем случае так и есть, пакеты могут быть и по 4 байта, и по килобайту, поэтому меня именно волновало как организовать систему, чтобы Sigma была не хуже 2-3мкс, а 1/Tau - не меньше 1мбит/сек.

Понятно, что идеологически I2C - самый простой для этого интерфейс, но, я спросил можно ли на нем реально достичь таких скоростных показателей...

Спасибо

ИИВ

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

Теперь понятно. Слово применю тоже не чисто русское - имеется ввиду аддитивная составляющая, в то время как Tau - мультипликативная. Если говорить о пакетах данных, такой составляющей может быть его преамбула: BREAK в DMX, различные последовательности битов в системах передачи с каналом без постоянной составляющей (радиоканалы, Ethernet, и т.п.). Аппаратной задержкой в драйверах RS485 и подобных тут можно принебречь. Ну, а уж как сами CPU там на все прореагируют...


Можно - на границе спецификации Fast Mode+ I2C. В принципе, выбор неплох: интерфейс мультимастерный, можно передавать широковещательные сообщения... Если шина будет валить фронты (I2C - открытый коллектор), можно поставить ускоритель (ищи у linear). Придется правда повозиться с весьма мудреным I2C в STM.

ну-ну.. разрулите работу 3+ мастеров на шине и сами поймете "простоту" и латентность..


именно для связи между модулями/платами он и предназначен.. например аккумуляторы со встроенными контроллерами, tft матрицы.. (это помимо внутриплатного обмена)
кстати о матрицах, в старых ЭЛТ и устаревающих TFT мониторах с интерфейсом VGA для идентификации использован DDC - тот же i2c.. длина кабеля ~1.5м
да, экранированный, да, скорость невысокая..

Кривой он, а не мудрёный.

Есть с SPI вариант такой:
-два дифференциалных трансивера как в RS485, два моноканала
- один отвечает за передачу/прием клока
- второй соответственно для MISO/MOSI
Это для высокоскоростной передачи.
Договариваться, кто источник кто приемник можно в рамках I2C
------
Сам еще не пробовал, - так, мысли вслух.

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

Во-первых, всем огромное спасибо всем за разъяснения! Многое понял, сейчас планирую плату. Возникло два глупый вопроса, ответы на который быстро не смог найти в мануалах...

Скажите, пожалуйста

1. если у меня только STM32 контроллеры, можно ли как-то по SWIM интерфейсу прошить несколько, организованных в цепочку как и по JTAGу?

2. если я вдруг захочу подсоединить колхоз плисок, atmeg и STM32, достаточно ли мне в этом случае иметь VREF, GND, TCK, TMS, TDO, TDI и могу ли я обойтись без nSRST и nTRST?

Спасибо

ИИВ