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

[rig]

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

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

[=DeaD=]

2Сергей:

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

[Сергей]

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

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

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

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

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

[rig]

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

[=DeaD=]

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

[Сергей]

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

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

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

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

[rig]

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

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

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

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

[Сергей]

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

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

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

[Duhas]

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

[rig]

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

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

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

[Сергей]

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

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

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

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

[=DeaD=]

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

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

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

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

[Сергей]

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

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

[lebaon]

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