roboforum.ru

Конечно можно. Здесь уже приводились ссылки на демо-проекты от TI где подробно расписано как это делается

blindman писал(а):Надо переключаться.

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

Предлагаю:
1. В первой версии протокола тупо фиксировать частоту в обоих модулях и работать по ней.
2. Дальше один из модулей объявляем мастером, второй подмастерьем.
3. Периодически (частоту определим исходя из ответа на вопрос ниже) происходит цикл обмена:
3.1. Мастер кидает запрос в котором выдает свой идентификатор, номер передаваемого пакета, ответ на предыдущую посылку подмастерья, количество байт в посылке, сами байты посылки (если их кол-во >0) и контрольную сумму всей посылки, после чего переходит в режим приёма.
3.2. Подмастерье принимает пакет, проверяет контрольную сумму посылки мастера, если она не битая (проверяет по контрольной сумме), кладёт пришедшие байты в буфер обмена;
3.3. Подмастерье формирует свой пакет такой же как у мастера, если еще есть шанс, что мастер не перешел в режим приёма, ждет.
3.4. Подмастерье отправляет свой пакет мастеру и переходит в режим приёма.

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

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

Вроде всё.

PS: Какое там время переключения между приемом и передачей?

Добавлено спустя 11 минут 40 секунд:
На будущее по поводу смены частоты можно тупой алгоритм накидать или какой-нибудь готовый способ реализовать, но не думаю что в первой версии это надо.

Я начал писать примерно в этом ключе, но сразу закладываю возможность смены частоты. Переключение режимов порядка десятков - сотен микросекунд, сильно зависит от выбранного режима, например включена ли калибровка синтезатора частоты при каждом переходе в режим приема или передачи.

2blindman: А может заглушки пока поставить в те куски когда, которые за смену частоты отвечают? Нафига это реально пока? Может быстрее первую версию без этого сделать, а там уже процесс пойдёт и спокойно добить?

Если готовый код FHSS взять - то еще быстрей пойдет.

Вот кстати проект спектроанализатора на ATmega48 и CC2500
http://www.zero13wireless.net/foro/show ... php?t=1220

и исходники под компилятор ICC, даже скомпилились "сходу" ...

cc2500 и MSP430F2274 - отладочный модуль можно использовать бесплатно на удаленном компьютере.
http://www.techonline.com/product/virtualab/205100815

The eZ430-RF2500 is a complete USB-based MSP430 wireless development tool providing all the hardware and software to evaluate the MSP430F2274 microcontroller and CC2500 2.4-GHz wireless transceiver. The eZ430-RF2500 uses the IAR Embedded Workbench Integrated Development Environment (IDE) or Code Composer Essentials (CCE) to write, download, and debug an application. The new USB debugging interface enables the eZ430-RF2500 to remotely send and receive data from a PC using the MSP430 Application UART.

2EdGull: сегодня буду выкладывать свой код радиоудлинителя уарта. Хекс для меги88 под какой кварц компилировать?

7.3728 МГц

В архиве исходный код и скомпилированная прошивка для ATMega88. Алгоритм - как выше описывал =Dead=.

В обмене участвуют 2 узла, один master, другой slave. Каждый модуль должен иметь уникальный 16-бтный адрес.
После включения, каждый узел должен быть сконфигурирован. Для этого по уарту записываются 6 байт : флаг мастера, адрес этого узла, адрес второго узла, номер канала. Например, выбрали адреса 0xCF5E и 0x356A, 5 канал. В один модуль выдаем последовательность 0x01 0x5E 0xCF 0x6A 0x35 0x05, в другой 0x00 0x6A 0x35 0x5E 0xCF 0x05. После инициализации можно начинать прием/передачу.

Скорость передачи по радио - 100кбит/с. При тестировании один узел был подключен к ПК, с которого передавались данные. На другой стороне выводы RX и TX соединены, таким образом данные возвращаются в ПК. При расположении узлов в непосредственной близости от друг друга (1.5 - 2 м) , в обе стороны передается неперывный поток данных со скоростью 9600 бит/с

вопрос
если мы "на лету" мастер переконфигурим, загрузим для него другой адрес узла и пар-ры, сможем переключиться на другой узел?
или это нужно все узлы выключать и заново включать?

Скорость передачи по радио - 100кбит/с. При тестировании один узел был подключен к ПК, с которого передавались данные. На другой стороне выводы RX и TX соединены, таким образом данные возвращаются в ПК. При расположении узлов в непосредственной близости от друг друга (1.5 - 2 м) , в обе стороны передается неперывный поток данных со скоростью 9600 бит/с

почему такие низкие скоростя?

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

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

EdGull писал(а):почему такие низкие скоростя?

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

ну во-первых предлагаю увеличить скорость передачи по радио до 250кбит/с.

Есть еще помехи и некий процент ошибок передачи, растущий с увеличением расстояния, длины пакета и скорости передачи. У меня пока что на 250 кбит/с не получается достичь приемлемого процента ошибок, при котором реальная скорость прохождения "хороших" пакетов была бы выше чем при 100 кбит/с

а по какому алгоритму ты настравивал регистры СС2500 для подстройки частоты?