roboforum.ru

delamoure писал(а):"Куча датчиков" etc. - понятие растяжимое. В 40 ... 50 байтов уложитесь?

Это если сильно ужиматься, хотелось бы минимум 2-3Кбайта в секунду иметь. Чтобы не утыкаться в эту границу при разработке и не делать конвеер в МК по выдаче в УАРТ.

delamoure писал(а):По цене темного леса нет. Это информация не для форума.

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

delamoure писал(а):Это какой версии BlueTooth реально реализовать за 30 у.е.?
Готовые модули? Можно несколько ссылок на то, что вы уже применяете.

Такой модуль в робота - http://www.efo.ru/doc/Rainsun/Rainsun.pl?2429 (20$)
И обычный юсб-донг за 10$ в ПК.
Ну обвязка под RoboBus, распаять всё - еще на 5-7$
Итого 35-37$.

Хмм.
Юзайте BlueTooth!

delamoure писал(а):Хмм.
Юзайте BlueTooth!

Блин, ну это неинтересно, никакого соревновательного духа, альтернативных технологий и т.п.

А на Сях уже всё давно выложено на просторах инета...
Заниматься никто не хочет

EdGull писал(а):Заниматься никто не хочет

или дураки как я

Интересно, а кто испытывал все эти чипы на скорость перекачки данных ?

Я тут почитал про свои модули ZigBee, так там написано, что без управления потоком их можно использовать только на низкой скорости 4800\9600 бод.
Иначе переполнение буфера и потеря данных.
И сам я это же заметил, если подавать непрерывно поток данных, то ошибки идут на скорости 9600.
Хотя в ДШ тоже написано, что мол канал радио сам 250кбит, а реально и 9600 с трудом.

EdGull писал(а):А на Сях уже всё давно выложено на просторах инета...
Заниматься никто не хочет

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

я ставлю уарт 115200 и CC2500 на 250кб
и луплю на полной скорости в уарт (смотрите тестовый код)
всё кучеряво, мне очень нравится

delamoure писал(а):

EdGull писал(а):А на Сях уже всё давно выложено на просторах инета...
Заниматься никто не хочет

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

А зачем там многозадачность? Если в системе нет многозадачности - стоит задумаца, почему так сделано.

а логотип для RoboRF еще не рисовали?

А точно, как это упустили? именно с этого надо было начинать - тогда точно все бы давно готово было

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

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

Именно поэтому в Миниботе поставили 2 МК вместо 1, чтоб не переписывать софт

2RoboTok: ИМХО это не панацея. Надо чтобы прошивка отрабатывала приём инфы от центрального МК и выдачу её. Если с выдачей еще более менее понятно (выдаём как время есть), то приём будет либо в никуда уходить, либо на центральном МК будем ждать, когда этот МК будет готов принимать инфу.

у CC2500 огромные буфера и прерываний на каждый чих.