Реализация моста PC -> SPI на attiny2313, Главные вопросы прошивка и прога на PC Опции

[max_2980]

Собственно возникает потребность порулить регистрами разных схем и хочется это делать культурно из окошка выньдос клацая мышой.
Погуглив наткнулся на схему такого старого программатора как AVR910

Только думаю вместо транзюков поставить max232(в компе есть COM порт) или китайский свисток USB <-> RS232
Некий чел на своей странице приводит исходники зашивки
www.serasidis.gr/circuits/avr_isp/avr_isp.htm
Думаю взять это за основу, очень похоже на то что мне нужно.
Собственно SPI бывают разные, для определенности конкретные эпюты сигналов (скорость особа не важна)


Контроллеры раньше не пользовал, так что вопрос к корифееям.
Может кто покажет короткую дорогу бегинеру.
Собственно вероятно зашивку придется модифицировать, чо-как?
Нужно писать свою прогу с кнопочками которая будет рулить контроллером через COM порт, это вообще без понятия как?
Полагаю что это стандартная задачка и спецам вероятно это как два пальца об асфальт (наверно многие с этим сталкивались).
Может кто поделится своими примерами реализаций.

Сообщение отредактировал max_2980 - Feb 4 2015, 22:31

[Xenia]

Да у меня у самого была сначала хотелка на USB, но подумал что будет совсем сложно для такого чайника как я USB программить (надеюсь с 232-м будете легче).
Но на всякий случай думаю оставить вилку в которую можно будет воткнуть китайский свисток аля FT232 (вместо max232)
типа такого www.aliexpress.com/item/1-pcs-USB-To-RS232-TTL-Auto-imported-Converter-Module-Converter-Adapter-For-Arduino-Worldwide-FreeShipping/1361575381.html

Что-то мне ваша задача становится всё непонятнее и непонятнее . Ведь если вы взялись курочить входную часть ("транзюки" на max232 заменять или вообще "китайский свисток" ставить), то зачем зубами цепляетесь за tiny2313? Ведь тогда вас фактически ничего с ней не связывает. А цены у tiny2313 и mega8 примерно одинаковые (порой mega8 даже дешевле стоит). А если вы у китайцев уже что-то заказали (так и не поняла с ваших слов, что это было), то уже ни о какой-переделке и речи быть не может. Хотя высказались вы на этот счет настолько невнятно, что получилось, что вы голую ATtiny2313 из Китая заказали ("будет тинька, китайцы видимо уже запаковали и отправили в дальний путь"), когда ей в России цена 100 руб в розницу.

В ситуации, когда вы толком не пишите, что именно заказали в Китае, то обсуждать это невозможно. А если же вы сами что-то паять надумали, то жесткая привязка к tiny2313 выглядит нелепо.

Mega8 выглядит презентабельнее, чем tiny2313, не только потому, что у нее больше памяти (обоих типов), но и тем, что у нее SPI поддержан аппаратно. Т.е. кладешь в регистр SPI-данных передаваемый байт ("SPDR=байт") и ждешь когда в регистре статуса (SPSR) появится бит завершения передачи. Ну, еще есть регистр режима (SPCR), где можно желаемую частоту передачи установить, полярность и порядок передачи бит. Т.е. тут и программировать нечего, т.к. всё предельно элементарно.

А у tiny2313 (как и у прочих tiny), насколько помню, ничего такого нет. Я, кстати, сама когда-то писала SPI-интерфейс между как раз этой tiny2313 и двумя штуками АЦП AD7714 (у них связь по SPI). Там мне это ногодыгом пришлось на ассемблере писать. Сама-то программа у меня на Си была написана, а функцию эмуляции SPI на ассемблере писала для того, чтобы задержки по тактам нужные выставить. Понятно, что ни о какой универсальности тут и речи быть не может, когда мне пришлось подгонять скорость обмена под тактовую частоту МК (1.8432 МГц у tiny2313, и 2.4576 МГц у АЦП, чтобы последний с гарантией успевал принять строб). А к tiny2313 я была привязана тем, что вся конструкция питалась от линий RS232 и других источников питания не было. Вот и пришлось экономить (tiny более экономичная, чем mega).

Но вы-то не привязаны к питанию от RS232, поскольку можете запитаться от девайса. И это совершенно правильное решение, если заранее не знаете, 5-вольтвый будет девайс, 3.3-вольтовый и того меньше. А раз так, то зачем вам tiny2313 со всеми неудобствами, сопряженными с ее выбором?

А по поводу уровней сам соображаю. Хотся универсальности. А дабы никто никому не грел защитные диоды логично питать контроллер от питания ведомого девайса, а если ведомый с низким питаловом то есть вероятность что моей тиньке не хватит.
Тогда нужно ставить что-то из разряда преобразователей 74LVC244A, TXB0108PWR, ADG3300 с отдельным питаловом. А их где-то брать надо и они еще денег стоят, а жаба как всегда душит.

Верно, преобразование уровней не нужно, если питание схемы берется от девайса. А уж тем более, когда его напряжение питания заранее неизвестно.

Между тем, проблемы, которые я вижу, далеко выходят за рамки железа. Ведь SPI-интерфейс "синхронный". И хотя у него три провода (отдельно на прием и передачу), но прием и передача осуществляются одновременно. Т.е. вы не можете принять по своему PC/SPI-мосту требуемое число байт, не передав точно такое же число байт в девайс. Поэтому прием у вас всегда будет выглядеть, как эхо от передачи, которое в отличие от истинного эха, будет звучать иначе, чем передача.

Пошли дальше. Реальные устройства (например, АЦП, которые очень часто делают с SPI-интерфейсом) требуют соблюдения определенного протокола, подразумевающего серию обменов с задержкой. Например, чтобы прочесть данные из АЦП, ему сперва следует послать посылку с требованием того, что от него требуется (это либо содержимое регистров установок или готовые данные). Нужную посылку формируем и отравляем - это обычно 1-2 байта. Затем выдерживаем паузу для того, чтобы АЦП "осознал", что от него требуют, и успел приготовиться к передаче. После это передают какую-нибудь фигню типа 0xFF, прислушиваясь исключительно к ответному эху. И соответственно, столько раз, сколько байт ответной информации ожидается. В случае если пауза окажется недостаточной, то первый байт ответа может оказаться лажей, а дальше нарушиться синхронизация, т.к. в следующий раз АЦП не воспримет команду, а станет передавать тот байт, который не успел передать в прошлый раз. Но может случиться беда и в том случае, если пауза затянется, тогда АЦП может решить, что произошел сбой по таймауту и прекратить передачу данных (а точнее - передавать вместо них муру).

Во многих случаях при работе с АЦП используют дополнительную линию сброса/синхронизации (ее роль обычно выполняет chip selесt). В таких случаях желательно озаботиться тем, чтобы у PC/SPI-моста тоже такой провод был и им можно было программно дергать.

Всё это выливается в то, что PC/SPI-мост, пригодный для реальных задач, должен выглядеть не как поток, а как процедура, состоящая из нескольких шагов:
Шаг 1 - перевод линии CS (chip select) в положение, включающее у девайса слух.
Шаг 2 - передача K-байт команды, эхо от которой игнорируется.
Шаг 3 - временная задержка.
Шаг 4 - передача N-байт чепухи, эхо от которой передается в PC, как ответ девайса.
Шаг 5 - перевод линии CS (chip select) в положение, отключающее к девайса слух.
Если линия CS не используется, то шаги 1 и 5 удалять из протокола не требуется, т.к. тогда они ничему не мешают.
При этом очень желательно, чтобы посылка от PC к PC/SPI-мосту представляла собой готовую структуру данных, содержащую все байта команды и указание величины задержки между окончанием передачи команды и началом приема ответа. Сам ответ, чаще всего, тоже приходится паковать в структуру с заголовком, т.к. во многобайтных ответах бывает трудно разобраться, который из байт первый.

Сейчас я намекнула лишь на некоторые трудности, возникающие, когда девайсом является АЦП. А если это ... SD-карта?! Даже страшно себе представить последствия, если сделать PC/SPI-мост по-простецки.

Вот всё оно как-то так выглядит , если относиться к этому делу серьезно и рассчитывать на практическую пользу от конструкции.