roboforum.ru

Огромные - это сколько ?

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

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

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

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

http://focus.ti.com/docs/prod/folders/print/cc2500.html

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

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

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

Сергей, можно и микроскопом гвозди забивать, кому как удобнее
Речь изначально шла об исходниках от ti. Очень надеюсь, что вы с ними знакомы и я не трачу время попусту.
Так вот, чего в них хватает, так это циклов ожидания событий.
И, как бы вы не строили свою систему, перед MCU, обслуживающим радиомодем, будет минимум две основные задачи:
работа с модемом и работа, цитирую, с "определенным протоколом". Никакие прерывания не решат эти две задачи в РЕАЛЬНОМ времени, если тело программы будет висеть в цикле. И на запрос состояния вашему мощному камню ответа не придет. Как у блондинки: или придет, или не придет.
Около года назад мне пришлось написать свои драйвера к CC именно по этой причине.
Удачи!
З.Ы. Может мы по разному понимаем термин "многозадачность"?

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

Наверное речь об экономической эффективности решений просто...

Хотел это сообщение написать в ответ 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, а чего не взять тот самый TCP/IP (о котором я уже уши форуму прожужжал) и не использовать его ограниченно? Ну тоже ведь самое получается. Не нужна тебе фрагментация - не трогай флаги. игнорируй. и т.д.

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

я бы вообще разрабатывал только физический и канальный уровни, оставляя выше все тот же TCP/IP пускай и используемый частично и ограничено для экономии ресурсов. но опять же с другой стороны останется совместимость и возможность прозрачно работать через различные среды передачи не трогая все остальное.

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

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

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

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

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

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

почему 60?

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

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

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

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

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

Я думаю, что и вряд ли надо будет. Для связи ботов между собой и ПК более чем достаточно простого протокола, с недорогой аппаратурой. Для чего нужен полноценный TCP/IP?