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 режимах, насколько это возможно и насколько я это себе представляю.
Жду предложения и критику..

я счас бьюсь со следующим
1 когда посылаю данные на приемник - последний не знает что передача идет к нему, следовательно если передача не корректна то и ошибку он не выдаст.
2 ошибка появляется не во всех приемниках одновременно - ктото принял правильно/ктото нет.
3 для устранения такой ситуации ввожу обязательное подтверждение пеердачи.
причем пока 2 варианта с подтверждением и без.
3,1 первый важная команда - требуется обязательный ответ приемника(ведомого). передатчик (ведущий) добивается ответа повтором передачи цать раз, если неудачно бросает это дело.
3,2 команда подтверждения приема - если передатчик (ведущий) не получил подтверждения то все хорошо, иначе снова получает ответ на последнюю команду (от ведомого) с п 3,1
стороны приемник и передатчик постоянно меняются местами, поэтому надо както определиться ведущий ведомый чтоли.

Добавлено спустя 1 минуту:
хотя может на проводах ошибок не будет или будет немного, по радиоканалу их прилично получается.

2Сергей:

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

=Dead=, честно, я не очень понял тебя.
Когда ты посылаешь данные не обязательно получать ответ как это сделано у твоего шлюза.
Переходник может принимать данные, передавать их после этого девайсу по UART
Переходник может быть "прочитан" (то есть режим SlaveTransmitter), данные берутся из буффера.
Переходник может сам выступать в роли Мастера, мы можем отправить по адресу данные, мы можем прочитать данные по адресу..

Добавлено спустя 3 минуты 37 секунд:

rig писал(а):я счас бьюсь со следующим
1 когда посылаю данные на приемник - последний не знает что передача идет к нему, следовательно если передача не корректна то и ошибку он не выдаст.
2 ошибка появляется не во всех приемниках одновременно - ктото принял правильно/ктото нет.
3 для устранения такой ситуации ввожу обязательное подтверждение пеердачи.
причем пока 2 варианта с подтверждением и без.
3,1 первый важная команда - требуется обязательный ответ приемника(ведомого). передатчик (ведущий) добивается ответа повтором передачи цать раз, если неудачно бросает это дело.
3,2 команда подтверждения приема - если передатчик (ведущий) не получил подтверждения то все хорошо, иначе снова получает ответ на последнюю команду (от ведомого) с п 3,1
стороны приемник и передатчик постоянно меняются местами, поэтому надо както определиться ведущий ведомый чтоли.

Добавлено спустя 1 минуту:
хотя может на проводах ошибок не будет или будет немного, по радиоканалу их прилично получается.

Ты извини, канешн, твой порыв мыслей великолепен, но я не понял над чем ты "бьешься", кто такой приемник, от кого куда передача идет и тп.
Давай тогда уж по порядку и по конкретней

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

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

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

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

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

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

нет, я не переходник делаю, я гоняю по радиоканалу данные используя ЮСАРТ и дешовые приемо/передающие модули.
тут получается почти тоже что и СПИ, можно адресовать конкретному устройству.
в общем проблемы похожи. Данные не всегда доходят правильно.

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

по простому суммирую все байты и результат пишу в последний байт посылки. это чтото на тему контрльной суммы. Это не самое страшное.

Добавлено спустя 4 минуты 38 секунд:
самое интеерсное начинается когда три девайса в моем случае начинают посылать друг другу данные. Собственно они равноправны между собой. наверно от сюда все проблемы.
у тебя мастер иницирует передачу и обмен? или возможен слейвом.

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

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

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

ну если девайсина с уартом не своя, и кодить ее в области протокола обмена не получится, можно дать возможность переходнику ресетить етот девайс при косяках в передаче... если же сво девайсина, то перехдник подождам n времени, ругается ей что ты мне не все отдала... отсылай мол все занава... мне кажется тут особых проблем не будет... главное не навертеть лишнего в протоколах обмена... и определеиться то должен девайс уметь со стороны и2ц

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

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

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

Мастером может выступать по необходимости любой девайс

Добавлено спустя 1 минуту 57 секунд:

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

Практически все реализовано в AVRLib, на языке Си.

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

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

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

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

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

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

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