roboforum.ru

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

Вопрос не в этом, при отправке инфы с головного МК на АТМега88 СС2500 вообще побоку будет.

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

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

А зачем мне все это пихать в одно устройство? Я делаю модули, с определенными протоколами, никакой многозадачности не нужно в модулях вовсе. Соединяю с хорошим камнем на котором стоит нормальная ОС, и управляю.
Ну а во-вторых - существуют прерывания, по прерыванию я могу обслужить UART, получив команду я читаю АЦП, символьный ЖКИ вообще банально управляеца, клавиатура - тоже через прерывания ( если хотите сложнее - сделайте вложенные прерывания ) и не нужно городить многозадачности

О_о похоже спорить бесполезно. Удачи

Хотел это сообщение написать в ответ 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 мне нравится

boez, спасибо за отличную идею реализации . Давай на bascome я ее и буду пытаться

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

а нам и не надо полный. пока что...

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

почему 60?

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

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

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

как бы не пришлось полностью все переписывать потом. зачем?