roboforum.ru

Значит понадобился такой девайс для баловства разного рода. Уже есть ряд готовых девайсов таких как [[Шлюз-контроллер GATE-A8D8M2]] или Контроллер SC18IM700 шины I2C с UART-интерфейсом. Но они работают только в режиме Мастера, что мне не подходит. Поэтому написал протокол(если можно так сказать), естественно за основы брал уже имеющиеся. И проверил работоспособность в Протеусе, ну конечно нужные еще полевые испытания, но это после того как будет плата готова.

Применение:
Допустим у меня ARM7 может работать только в режиме Мастера, но мне потребовалось чтобы к нему можно было обращаца как к Слейву. Поэтому я упрощаю себе задачу, просто подключив переходник на свободный uart, тем самым давай возможность получать "входящие"

Значит что за переходник:
- ATMega8 ( либо делать на ATMega8L либо и то и то )
- 4MHz
- два выхода - на twi и uart
А больше и не нужно, можно еще светодиоды включить для отображения наличия питания и передачи данных.
Плата еще не разведена, что будет сделано после окончательной разборки с протоколом.
Предполагаеца, что это будет все запаяно в smd и tqfp корпусах, и иметь маленькие размеры.

Вот сам протокол

Отправить данные
[ W | Addr | Nb | Data | P ], где
W - означает запись в шину TWI,
Addr - адрес устройства на шине,
Nb - сколько байт нужно передать устройству,
Data - байты данных,
P - стоповый байт.

Чтение данных
[ R | Addr | Nb | P ], где
R - означает прочитать данные из устройства на шине по адресу Addr,
Nb - сколько байт нужно принять.

Записать данные в буффер переходника
Записываем данные в буффер, а когда переходник входит в режим SlaveTransmitter, он передает вызывающему адресу данные из буффера, если их нет в нем то возвращает ноль.
[ B | Nb | Data | P ], где
B - означает что нужно поместить данные в буффер,
Nb - сколко данных нужно туда поместить.

А вот список возможных приходящих пакетов:
Получили данные
[ W | Nb | Data | P ], где
W - означает, что нам адресовали данные,
Nb - сколько байт нам адресовали,
Data - байты данных,
P - стоповый байт.

Получили данные, ответ на отправленный запрос [ R | Addr | Nb | P ]
[ T | Nb | Data | P ], где
T - означает, что нам удалось прочитать данные с нужного нам устройства
Nb - сколько байт мы сумели прочитать.

Получили ошибку
[ E ], где
E - означает что произошла ошибка. Предполагаеца также ввести коды ошибок, тогда пакет будет выглядеть так
[ E | Code ]

Здесь реализуеца работа переходника и в Slave и в Master режимах, насколько это возможно и насколько я это себе представляю.
Жду предложения и критику..

2Сергей:

Я вообще слегка не врубился, как можно слэйв I2C шлюзом куда-то сделать? Там ведь, когда я что-то читаю мастером, - мне сразу ответ должны дать, как это реализовать то через чужие протоколы? Или переходник будет... как бы это помягче сказать... не совсем полноценным I2C-слэйвом?

скажем так, спи я еще не пробовал заодно и разберемся, если что поправите.
шлюз работает на прием и передачу. это понятно.
ошибки возможны при приеме/передаче?

А, то есть ты пытаешься сделать тоже такой переходник?)
Ошибки возможны везде. По TWI ошибки маловероятны. По UART возможны ошибки, но реализовать качественную передачу данных, чтобы при этом елси проскользнул один байт в передаче, не было неразберихи.

Я еще предлагаю ввести проверочный пакет типа [ C ], где
C - означает, что мы хотим проверить, завершилась ли предыдущая операция. Если нет ответа то посылаем до тех пор пока не будет получен ответ.
Или какнибудь так..

=Dead= писал(а):Ну то есть я понял правильно - это не совсем полноценный слэйв, часть запросов он не сможет правильно отрабатывать... я просто думал на эту тему и мне показалось, что это принципиально не решается...

Это не идеальный вариант, но хоть чтото..
Какие запросы он не сможет обрабатывать? Имеешь ввиду ПОВСТАРТ и тп?

Дак тут проблемы то нет особой, это же i2c, тут все аппаратно,а работу с i2c можешь посмотреть в AVRLib.
У тебя немного не то. У меня вот такая структура
[ Device(has only UART) ] [ Мой переходник ] <- i2c bus....i2c net.

ЗЫ а вот проблемы с потерей данных, когда они идут от Device до Переходника по uart - возможны. Использование контрольной суммы возможно впринципе, но не решает задачу. Допустим потеряли один байт, пришло не 5 байт а 4 байта, переходник ждет еще один байт, а его и не будет.. вот такое возможно

Добавлено спустя 11 минут 23 секунды:
У меня на каждый девайс по переходнику, объединяем их в сеть, а дальше протокол i2c все делает. Естественно здесь мастер инициирует передачу данных, а остальные ждут когда шина освободица.. Мы говорим немного о разных вещах

схожу ознакомлюсь пожалуй
Шина I2C и как её использовать (включая спецификацию)
http://www.gaw.ru/html.cgi/txt/interface/iic/index.htm

Сергей писал(а):У меня на каждый девайс по переходнику, объединяем их в сеть, а дальше протокол i2c все делает. Естественно здесь мастер инициирует передачу данных, а остальные ждут когда шина освободица.. Мы говорим немного о разных вещах

интересно, переходников то несколько, а кто же мастер?
[ Device(has only UART) ] [ Мой переходник ] <- i2c bus....i2c net.<-> [Device тут мастер?]

Сергей писал(а):А, то есть ты пытаешься сделать тоже такой переходник?)

Нет, но обдумывал варианты

Сергей писал(а):Это не идеальный вариант, но хоть чтото..
Какие запросы он не сможет обрабатывать? Имеешь ввиду ПОВСТАРТ и тп?

Ну я так и понял, я ж не говорю что всё пропало, говорю что не полноценный слэйв, у меня ж не было в целях закидать тухлыми помидорами, я скорее себя проверил запросы это не будет обрабатывать типа запись+чтение в одном запросе, и придётся вводить временные интервалы, чтобы знать, когда точно можно будет прочитать ответ на свой запрос.

так ты же говорил, что переходник можно переключить в режим мастера!
тогда и можно будет такие запросы слать