roboforum.ru

Технический форум по робототехнике.

Проект "RoboRF" - открытый недорогой радиоканал для роботов

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

Re: Проект "RoboRF" - открытый недорогой радиоканал для роботов

Сообщение RoboTok » 22 янв 2009, 17:52

Огромные - это сколько ?
Аватара пользователя
RoboTok
 
Сообщения: 1060
Зарегистрирован: 04 фев 2008, 13:18
Откуда: Москва
прог. языки: PHP

Re: Проект "RoboRF" - открытый недорогой радиоканал для роботов

Сообщение =DeaD= » 22 янв 2009, 17:55

EdGull писал(а):у CC2500 огромные буфера и прерываний на каждый чих.

Вопрос не в этом, при отправке инфы с головного МК на АТМега88 СС2500 вообще побоку будет.
Проект [[Open Robotics]] - Универсальные модули для построения роботов
Аватара пользователя
=DeaD=
 
Сообщения: 24218
Зарегистрирован: 06 окт 2004, 18:01
Откуда: Ебург
прог. языки: C++ / PHP / 1C
ФИО: Антон Ботов

Сообщение delamoure » 22 янв 2009, 18:01

RoboTok писал(а):Огромные - это сколько ?

"Data buffering with separate 64-byte receive and transmit FIFOs".
Два буфера по 64 байта.

http://focus.ti.com/docs/prod/folders/print/cc2500.html
Не ищите сложностей в простом.
Аватара пользователя
delamoure
 
Сообщения: 15
Зарегистрирован: 01 дек 2008, 03:52
Откуда: Днепропетровск
прог. языки: C, asm, Delphi

Re:

Сообщение Сергей » 22 янв 2009, 23:53

delamoure писал(а):2Сергей.
Задуматься стоит. Что я и сделал - читайте выше.

А теперь расскажите мне каким образом вы реализуете в одном устройстве, скажем, работу с внешним АЦП, обслуживание символьного ЖКИ, обслуживание клавиатурной матрицы, работу по UART etc.
Или работу с той-же RoboBus. Если будете ожидать, скажем, готовность вашего радиомодема? И все процессы замрут. Гениально!
Исходники от ti являются только примерами. Для более-менее нагруженных задач они не подойдут.

А зачем мне все это пихать в одно устройство? Я делаю модули, с определенными протоколами, никакой многозадачности не нужно в модулях вовсе. Соединяю с хорошим камнем на котором стоит нормальная ОС, и управляю.
Ну а во-вторых - существуют прерывания, по прерыванию я могу обслужить UART, получив команду я читаю АЦП, символьный ЖКИ вообще банально управляеца, клавиатура - тоже через прерывания ( если хотите сложнее - сделайте вложенные прерывания ) и не нужно городить многозадачности
Сергей
 
Сообщения: 3744
Зарегистрирован: 29 дек 2004, 23:15
Откуда: Санкт-Петербург
прог. языки: C, C++, C#, Asm
ФИО: Кашликов Сергей

Re: Проект "RoboRF" - открытый недорогой радиоканал для роботов

Сообщение delamoure » 23 янв 2009, 00:50

Сергей, можно и микроскопом гвозди забивать, кому как удобнее :D
Речь изначально шла об исходниках от ti. Очень надеюсь, что вы с ними знакомы и я не трачу время попусту.
Так вот, чего в них хватает, так это циклов ожидания событий.
И, как бы вы не строили свою систему, перед MCU, обслуживающим радиомодем, будет минимум две основные задачи:
работа с модемом и работа, цитирую, с "определенным протоколом". Никакие прерывания не решат эти две задачи в РЕАЛЬНОМ времени, если тело программы будет висеть в цикле. И на запрос состояния вашему мощному камню ответа не придет. Как у блондинки: или придет, или не придет.
Около года назад мне пришлось написать свои драйвера к CC именно по этой причине.
Удачи!
З.Ы. Может мы по разному понимаем термин "многозадачность"?
Последний раз редактировалось delamoure 23 янв 2009, 01:04, всего редактировалось 2 раз(а).
Не ищите сложностей в простом.
Аватара пользователя
delamoure
 
Сообщения: 15
Зарегистрирован: 01 дек 2008, 03:52
Откуда: Днепропетровск
прог. языки: C, asm, Delphi

Re: Проект "RoboRF" - открытый недорогой радиоканал для роботов

Сообщение Сергей » 23 янв 2009, 01:00

О_о похоже спорить бесполезно. Удачи :D
Сергей
 
Сообщения: 3744
Зарегистрирован: 29 дек 2004, 23:15
Откуда: Санкт-Петербург
прог. языки: C, C++, C#, Asm
ФИО: Кашликов Сергей

Re: Re:

Сообщение =DeaD= » 23 янв 2009, 09:44

Наверное речь об экономической эффективности решений просто...
Проект [[Open Robotics]] - Универсальные модули для построения роботов
Аватара пользователя
=DeaD=
 
Сообщения: 24218
Зарегистрирован: 06 окт 2004, 18:01
Откуда: Ебург
прог. языки: C++ / PHP / 1C
ФИО: Антон Ботов

Re: Проект "RoboRF" - открытый недорогой радиоканал для роботов

Сообщение boez » 29 янв 2009, 14:57

Хотел это сообщение написать в ответ galex1981 в тему cc2500 для минибота, потом решил что ему место тут.

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

Для начала было бы неплохо определиться с протоколом общения, а для этого - с задачами, которые перед этим общением стоят. Первая задача у нас - радиоудлиннитель уарта, от нее и отталкиваемся, не забывая про расширяемость. Основная идея - минимум добавлений к коду тупого радиоудлиннителя и максимум пользы от этих добавлений.

Думаю что очень неплохо, если бы мухи от котлет протокол от кода, работающего с чипом был отдельно. Тогда можно будет при большом желании заменить чип на другой (а то и на ИК, как тут в другой теме обсуждается), не переделывая протокол.

Интерфейс на границе раздела "протокол/драйвер чипа" мне кажется разумным сделать на уровне приема-передачи пакетов. То есть, протокол может передать драйверу произвольный пакет для передачи в физическую среду и принять от драйвера полученный им из среды пакет. Верификацию пакета (по контрольной сумме или еще как) можно возложить как на драйвер (а он - может и на чип), так и на протокол. А вот вопросы адресации - наверное на протокол. То есть наш протокол будет выполнять все или часть функций канального уровня и все функции сетевого и транспортного уровней. Ориентируемся на стек TCP/IP, правда стараясь его упростить так, что может и родная мама не узнает, зато в кило кода на АВР влезет :)

Сетевой уровень может быть аналогом Wi-Fi (схема обмена такая: 1:"хочу передать пакет" - 2:"фиг с тобой, передавай" - 1:"собсно пакет" - 2:"ок, принял"). Все пакеты, кроме пакета с данными - короткие, канал сильно не нагрузят. Адреса можно какие-то коротенькие, хоть в байт размером - вряд ли нам понадобится больше 256 ботов на одном канале :). Про проблему скрытых узлов пока забываем, как про нее забыли в вайфае. В одной комнате скрытых узлов у нас не будет.

Разводить чудеса с маршрутизацией и ретрансляцией думаю не стоит, не наш случай. Соответственно, нафиг идут мак-адреса отдельно от сетевых. Есть просто адрес бота и все. Динамическую раздачу адресов нужно иметь в виду, заманчивая штука, но на первом этапе не обязательна.

Транспортный уровень - это протоколы-аналоги TCP и UDP. Понятие порта тоже полезно, разве что нам наверное 256 портов хватит с головой. Можно даже зафиксировать "стандартные" номера портов, как это сделано в TCP/IP (80 - www и т.п.). К примеру, порты 1-5 - уарты, выше там раскидать прямой доступ к сенсорам и моторам, еще выше - свободные номера для любых применений. Из TCP выкидываем нафиг окна, контроль потока, собственно оставляем только повторы передачи (а подтверждения приема у нас есть с сетевого уровня). Склейку пакетов тоже нафиг. Собсно у нас UDP и TCP только этими повторами и будут отличаться.

Интерфейсы к приложению можно обсудить. Первым наверняка будет просто реализация последовательного канала (уартозаменитель). А дальше - потихоньку другие применения.

Просто, если сделать тупой уартозаменитель без адресов - то мы потом натолкнемся на трудности с несколькими ботами. А кода писать почти столько же. Поскольку контроль доставки - нужен. Повторы - нужны. Добавляем к этому всего 4 байта в заголовок (адрес и порт источика и назначения) и совсем немножко кода для их формирования и проверки (в вырожденном простейшем варианте - просто заполение этих полей фиксированными значениями на передаче и сравнение на приеме). И вроде бы вырисовывается удобная масштабируемая система. Хочется тупой радиоудлиннитель уарта? Пожалуйста, скомпилили прошивки для двух платок (к компу и боту) с двумя жестко зашитыми адресами и портами, залили - и все работает прозрачно для компа и бота. Хочется с одного компа общаться с несколькими ботами? Пожалуйста, на ботах та же прошивка, на комповой платке - прозрачный пакетный шлюз, на самом компе - реализация протокола, встроенная в управляющую прогу. Хочется несколько параллельных потоков к одному боту? Не вопрос, причем такую реализацию уже будет делать кто-то другой, кому это понадобится, ее не надо делать сразу :)

Лично я собираюсь написать реализацию подобного протокола для минибота и платы переходника, когда они приедут - а они уже выехали :) Но пока они доедут - можно обсудить сам протокол. И скоординировать действия. Если я напишу реализацию на Си (она будет годиться для АВР и для ПК), а кто-то наваяет совместимую реализацию на баскоме - будет здорово.

Конструктивная критика - приветствуется! Если идея заинтересовала - могу попробовать набросать черновичок спецификации протокола (какие конкретно форматы пакетов, адреса, порты, флаги подтверждения доставки и повторов и т.п.).
boez
 
Сообщения: 1981
Зарегистрирован: 27 авг 2008, 10:45
Откуда: Харьков
прог. языки: С/С++

Re: Проект "RoboRF" - открытый недорогой радиоканал для роботов

Сообщение blindman » 29 янв 2009, 15:19

Давай более-менее формальную спецификацию, с разбивкой по уровням, обсудим.
Проект [[Open Robotics]] - универсальные модули для построения роботов
Модули Open Robotics можно приобрести в магазине shop.roboforum.ru

Day OFF? You must be pulling my leg! Stop making humor before someone sees you, fool!

Аватара пользователя
blindman
 
Сообщения: 4130
Зарегистрирован: 29 апр 2008, 21:15
Откуда: Хабаровск
прог. языки: C,C++,Assembler,PHP,Javascript,Ruby, SPIN,Java(?)
ФИО: Андрей Юрьевич

Re: Проект "RoboRF" - открытый недорогой радиоканал для роботов

Сообщение EdGull » 29 янв 2009, 15:22

boez мне нравится :good:
Аватара пользователя
EdGull
 
Сообщения: 10211
Зарегистрирован: 28 дек 2004, 20:33
Откуда: Тольятти
Skype: Ed_Gull
прог. языки: Bascom AVR Basic
ФИО: Гуль Эдуард Викторович

Re: Проект "RoboRF" - открытый недорогой радиоканал для роботов

Сообщение frig » 29 янв 2009, 15:23

boez, а чего не взять тот самый TCP/IP (о котором я уже уши форуму прожужжал) и не использовать его ограниченно? Ну тоже ведь самое получается. Не нужна тебе фрагментация - не трогай флаги. игнорируй. и т.д.

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

я бы вообще разрабатывал только физический и канальный уровни, оставляя выше все тот же TCP/IP пускай и используемый частично и ограничено для экономии ресурсов. но опять же с другой стороны останется совместимость и возможность прозрачно работать через различные среды передачи не трогая все остальное.
frig
 
Сообщения: 1640
Зарегистрирован: 12 фев 2007, 12:25
Откуда: Днепр

Re: Проект "RoboRF" - открытый недорогой радиоканал для роботов

Сообщение galex1981 » 29 янв 2009, 15:39

boez, спасибо за отличную идею реализации :good:. Давай на bascome я ее и буду пытаться ;)
if(!Operate) Read(pDatasheet);
Аватара пользователя
galex1981
 
Сообщения: 4362
Зарегистрирован: 04 дек 2008, 22:44
Откуда: Камышин
Skype: galk-aleksandr1
прог. языки: Kotlin, Java, C, C++, Assm, BasCom, VB, php
ФИО: Галкин Александр Владимирович

Re: Проект "RoboRF" - открытый недорогой радиоканал для роботов

Сообщение boez » 29 янв 2009, 15:40

frig писал(а):boez, а чего не взять тот самый TCP/IP (о котором я уже уши форуму прожужжал) и не использовать его ограниченно? Ну тоже ведь самое получается. Не нужна тебе фрагментация - не трогай флаги. игнорируй. и т.д.


ОЗУ полный TCP/IP требует неслабо - вот в чем проблема. Да и 60 байт заголовка на пакет - многовато, при полезных данных в несколько байт. У нас не такой жирный канал связи. Я предлагал всего 4, ну может 5-6 :). То есть конечно uIP в минимальной конфигурации в атмегу8 наверное влезет (написано "несколько сотен байт") - но нужно ли нам это? Вот конверсию этого протокола в полный TCP/IP рассмотреть можно.
boez
 
Сообщения: 1981
Зарегистрирован: 27 авг 2008, 10:45
Откуда: Харьков
прог. языки: С/С++

Re: Проект "RoboRF" - открытый недорогой радиоканал для роботов

Сообщение frig » 29 янв 2009, 15:46

ОЗУ полный TCP/IP требует неслабо - вот в чем проблема.


а нам и не надо полный. пока что...
Да и 60 байт заголовка на пакет - многовато, при полезных данных в несколько байт.

почему 60?

То есть конечно uIP в минимальной конфигурации в атмегу8 наверное влезет (написано "несколько сотен байт") - но нужно ли нам это?


его тоже можно обрезать, но совместимость останется.

Вот конверсию этого протокола в полный TCP/IP рассмотреть можно.


как бы не пришлось полностью все переписывать потом. зачем?
frig
 
Сообщения: 1640
Зарегистрирован: 12 фев 2007, 12:25
Откуда: Днепр

Re: Проект "RoboRF" - открытый недорогой радиоканал для роботов

Сообщение blindman » 29 янв 2009, 15:54

frig писал(а):а нам и не надо полный. пока что...

Я думаю, что и вряд ли надо будет. Для связи ботов между собой и ПК более чем достаточно простого протокола, с недорогой аппаратурой. Для чего нужен полноценный TCP/IP?
Проект [[Open Robotics]] - универсальные модули для построения роботов
Модули Open Robotics можно приобрести в магазине shop.roboforum.ru

Day OFF? You must be pulling my leg! Stop making humor before someone sees you, fool!

Аватара пользователя
blindman
 
Сообщения: 4130
Зарегистрирован: 29 апр 2008, 21:15
Откуда: Хабаровск
прог. языки: C,C++,Assembler,PHP,Javascript,Ruby, SPIN,Java(?)
ФИО: Андрей Юрьевич

Пред.След.

Вернуться в Коммуникации

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 0

cron