iiv 19 23 ноября, 2012 Опубликовано 23 ноября, 2012 · Жалоба Всем привет, очень надо сабж, написал в форуме для начинающих, но ответа не получил... Не знаю за что браться, запутался, помогите, пожалуйста. Спасибо! ИИВ Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
KnightIgor 2 23 ноября, 2012 Опубликовано 23 ноября, 2012 (изменено) · Жалоба ответа не получил... Не знаю за что браться, запутался, помогите, пожалуйста. Прошивка. Ответ там стоял: JTAG. Важная особенность этого отладочного интерфейса - каскадируемость (очень похоже на SPI): выход TDO предыдущего контроллера на вход TDI следующего, а остальные сигналы - TCK, TMS, TRST - параллельно. Итого 4 линии (массу не считаем). Любой нормальный отладчик/программатор сможет достучаться до любого в цепочке при указании ему количества бит до и после искомого контроллера. Многие программаторы (софт к ним) сами исследую цепочку и выдают ID устройств в ней; остается только выбрать, с каким нужно работать. В JTAG цепочке можно смешивать разные устройства. Например, контроллер и FPGA. Теперь по шине коммуникации при работе. Названая "латентность" (хоть бы слово русское подобрал!) ничего не говорит, пока не ясно будет, какова длина пакетов. Вот ответа и не получил там, т.к. не дал информацию. USART в "классическом" асинхронном режиме может, судя по докам, в районе 10Mbps. Вполне нормально для RS-485. Это 1мкс на байт. Хватит? Изменено 23 ноября, 2012 пользователем KnightIgor Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Axel 1 24 ноября, 2012 Опубликовано 24 ноября, 2012 · Жалоба ... Не знаю за что браться... Недостаточно информации для "генерации рекомендаций" . Из собственного опыта: для решения похожей задачи (еще на STM32F710) использовал CAN. В системе был хост для "бродкастинга", "енумерации", "апгрейда" и синхронизации. Каждое устройство содержало бутлоадер с независимой поддержкой CAN. Но таких жестких требований к "латентности" не было. Если бы были - вероятно использовал бы аппаратные линии. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
iiv 19 24 ноября, 2012 Опубликовано 24 ноября, 2012 · Жалоба Важная особенность этого отладочного интерфейса - каскадируемость (очень похоже на SPI): выход TDO предыдущего контроллера на вход TDI следующего, а остальные сигналы - TCK, TMS, TRST - параллельно. Классно!!! Спасибо _Pasha и Вам большое за простые и понятные объяснения по поводу JTAG. Я им до этого почти не пользовался, прошивая все по ком порту, так-как в основном работал на ардуино подобных системах. Теперь все встало на свои места, понял как и что, буду так действовать. Названая "латентность" (хоть бы слово русское подобрал!) ничего не говорит, пока не ясно будет, какова длина пакетов. Вот ответа и не получил там, т.к. не дал информацию. USART в "классическом" асинхронном режиме может, судя по докам, в районе 10Mbps. Вполне нормально для RS-485. Это 1мкс на байт. Хватит? да, реально, я не смог подобрать правильного русского слова, и, поэтому, мы друг друга не поняли... Обычно в параллельных вычислениях под моделью передачи пакетов между процессорами подразумевают модель время = Sigma + Tau * L, где L - размер передаваемого пакета (например в байтах), Sigma - латентность (latency, измеряется в секундах), Tau - обратная к скорости передачи (секунд в байт). Из этого латентность не зависит от длины пакета. В моем случае так и есть, пакеты могут быть и по 4 байта, и по килобайту, поэтому меня именно волновало как организовать систему, чтобы Sigma была не хуже 2-3мкс, а 1/Tau - не меньше 1мбит/сек. Понятно, что идеологически I2C - самый простой для этого интерфейс, но, я спросил можно ли на нем реально достичь таких скоростных показателей... Спасибо ИИВ Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Axel 1 24 ноября, 2012 Опубликовано 24 ноября, 2012 · Жалоба Понятно, что идеологически I2C - самый простой для этого интерфейс, но, я спросил можно ли на нем реально достичь таких скоростных показателей... Нельзя. I2C на 0.5м шлейфе устойчиво работает до 250кГц. Да он и не для этого придуман (не для связи между модулями). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
KnightIgor 2 24 ноября, 2012 Опубликовано 24 ноября, 2012 · Жалоба Sigma - латентность (latency, измеряется в секундах) Теперь понятно. Слово применю тоже не чисто русское - имеется ввиду аддитивная составляющая, в то время как Tau - мультипликативная. Если говорить о пакетах данных, такой составляющей может быть его преамбула: BREAK в DMX, различные последовательности битов в системах передачи с каналом без постоянной составляющей (радиоканалы, Ethernet, и т.п.). Аппаратной задержкой в драйверах RS485 и подобных тут можно принебречь. Ну, а уж как сами CPU там на все прореагируют... Понятно, что идеологически I2C - самый простой для этого интерфейс, но, я спросил можно ли на нем реально достичь таких скоростных показателей... Можно - на границе спецификации Fast Mode+ I2C. В принципе, выбор неплох: интерфейс мультимастерный, можно передавать широковещательные сообщения... Если шина будет валить фронты (I2C - открытый коллектор), можно поставить ускоритель (ищи у linear). Придется правда повозиться с весьма мудреным I2C в STM. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Jury093 2 25 ноября, 2012 Опубликовано 25 ноября, 2012 · Жалоба Понятно, что идеологически I2C - самый простой для этого интерфейс, но, я спросил можно ли на нем реально достичь таких скоростных показателей... ну-ну.. разрулите работу 3+ мастеров на шине и сами поймете "простоту" и латентность.. Нельзя. I2C на 0.5м шлейфе устойчиво работает до 250кГц. Да он и не для этого придуман (не для связи между модулями). именно для связи между модулями/платами он и предназначен.. например аккумуляторы со встроенными контроллерами, tft матрицы.. (это помимо внутриплатного обмена) кстати о матрицах, в старых ЭЛТ и устаревающих TFT мониторах с интерфейсом VGA для идентификации использован DDC - тот же i2c.. длина кабеля ~1.5м да, экранированный, да, скорость невысокая.. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_Pasha 0 25 ноября, 2012 Опубликовано 25 ноября, 2012 · Жалоба Придется правда повозиться с весьма мудреным I2C в STM. Кривой он, а не мудрёный. Есть с SPI вариант такой: -два дифференциалных трансивера как в RS485, два моноканала - один отвечает за передачу/прием клока - второй соответственно для MISO/MOSI Это для высокоскоростной передачи. Договариваться, кто источник кто приемник можно в рамках I2C ------ Сам еще не пробовал, - так, мысли вслух. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Axel 1 26 ноября, 2012 Опубликовано 26 ноября, 2012 · Жалоба именно для связи между модулями/платами он и предназначен.. Вы правы. Я неточно выразился, а имел в виду "не для быстрого обменa". Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
iiv 19 26 ноября, 2012 Опубликовано 26 ноября, 2012 · Жалоба Прошивка. Ответ там стоял: JTAG. Во-первых, всем огромное спасибо всем за разъяснения! Многое понял, сейчас планирую плату. Возникло два глупый вопроса, ответы на который быстро не смог найти в мануалах... Скажите, пожалуйста 1. если у меня только STM32 контроллеры, можно ли как-то по SWIM интерфейсу прошить несколько, организованных в цепочку как и по JTAGу? 2. если я вдруг захочу подсоединить колхоз плисок, atmeg и STM32, достаточно ли мне в этом случае иметь VREF, GND, TCK, TMS, TDO, TDI и могу ли я обойтись без nSRST и nTRST? Спасибо ИИВ Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
