Форум РадиоКот

Изучаю uart, хочу сделать устройство, точнее несколько, будет ГУ которое будет опрашивать, и отправлять им задачи.
В codevision сгенерировал на прием и передачу по прерыванию, с приемом разобрался все ок, с отправкой вроде тоже. Но вот есть одно но, как мне переключать из приема в передачу? перед отправкой и приемом менять значение регистра UCSRB ???

Почитать хотя бы вторую ссылку из яндекса по запросу AVR USART.

http://chipenable.ru/index.php/programm ... ompyuterom

Все разобрался! Тока теперь еще больше вопросов! ГУ будет опрашивать порядка 5 мк, эти 5 мк будут снимать информацию с датчика температуры, датчика влажности, ацп, проверять ножки! Пока еще все задачи не известны! В первую очередь нужно ГУ у которого будет дисплей кнопки,часы, и второе которое будет снимать данные с hc-sr04, третье будет датчик температуры и 2 ацп! Теперь не могу понять, как сделать ГУ, опрос кнопок я делал в таймер, от туда же хотел сделать флаг на начала отправки запроса, и вывод на дисплей, еще опрос часов, как это все реализовать, ведь таймер будет делать прирывание, и uart тоже работа через прерывание, получится что будет таймеры одновременно сработают и т.п. или я не до конца понимаю работу таймера! И тоже самое с мк который будет опрашивать ds18b 20 и по запросу ГУ и будет отправлять ему данные, ведь у ds18b20 после запроса нужно подождать порядка 480 мс, а по uart постоянно что идет, и будет срабатывать прерывание по приему, не получится что это будет мешать опросу да и хотел сделать прерывание и чтобы раз в 1-2 сек опрашивляс? И на ГУ сделать к примеру каждые 10мс или даже меньше отправлять запросу мк, и скажем ждать какое-то время на ответ, и следить если ответ не пришел то записывать ошибку, отправлять другой запрос, потом снова пробывать, если снова ответ не пришел писать ошибку! Я просто боюсь если делать прерывание по переполнение раз в 1мс то не помешает это uart?

dak писал(а):Все разобрался! Тока теперь еще больше вопросов!

- С машинами я договорился, машин не будет! (с) из анекдота


Автор, свои мысли Вы изложили достаточно сумбурно... Вы что - хотите на каждый датчик собственный МК поставить? А смысл?
Например

dak писал(а):третье будет датчик температуры и 2 ацп

Датчик температуры температура - величина достаточно инерционная, её вряд ли есть смысл измерять чаще, чем раз в секунду...
АЦП - сигнал с какого именно устройства будет подан на АЦП?

dak писал(а):второе которое будет снимать данные с hc-sr04

hc-sr04 - где именно стоит? Если коптер, это одно, если радиоуправляемый танк - совсем другое. От скорости объекта зависит требуемая частота опроса hc-sr04. И вполне возможно, что все задачи (температура, АЦП и hc-sr04) получится возложить на один МК.


Вообще, обмен данными между МК по какой среде должен осуществляться? Радиоканал - это одно, связь по проводам - совсем другое.

Что касается обмена данными - лучше сразу разработать какой-то общий протокол обмена.
Например, пакет ответа состоят из девяти байт.
1-й байт - адрес МК, 2-й байт - код команды, 3-й - байт статуса МК, 4-й и 5-й байты - расстояние, измеренное hc-sr04, 6-й и 7-й байты - измеренная температура, 8-й и 9-й байты - CRC.
При этом в 3-ем байте статуса МК, допустим, 0-й и 1-й биты - это состояние пары кнопок (лог.1 - нажаты, лог.0 - отпущены), 3-й бит указывает на актуальность данных, измеренных hc-sr04 - если бит в состоянии лог.0, то с момента последнего запроса не получено нового результата измерения, игнорировать значения 4-го и 5-го байт пакета, если же 3-й бит в сост. лог.1, то есть новые результаты замера расстояния, данные в 4-ом и 5-ом байтах актуальны. Бит 4 в байте статуса аналогично указывает на актуальность значения температуры в 6-ом и 7-ом байтах пакета.
Ну и так далее. Лучше стандартизовать все пакеты хотя бы по длине, байт команды однозначно указывает на тип данных в пакете.
Например, если код команды 0х01, то это ответ на запрос расстояния и температуры, при этом биты байта статуса имеют значения, указанные выше, а если код команды равен 0х02, то это ответ на команду получения данных от АЦП и в байте статуса 0-й и 1-й биты определяют актуальность данных от обоих АЦП, остальные биты не используются. Соответственно, в пакете в этом случае в 4-ом и 5-ом байтах хранится результат оцифровки первого АЦП, а в 6-ом и 7-ом байтах - результат от второго АЦП.
То есть, после получения пакета и проверки его на корректность по коду команды однозначно определяется, как следует интерпретировать данные пакета.

Ну, для начала все. "Переварите" пока это, попробуйте продумать структуру сети устройств Какие датчики к какому МК подключены и т.д.

По поводу опроса термодинамика можно сделать как-то так.
http://easyelectronics.ru/avr-uchebnyj- ... tomat.html
а опрос клавиатуры так http://kit-e.ru/articles/circuit/2007_08_170.php (тут неважно как она подключается), если использовать такой подход то это можно разместить в main, но тогда там не должно быть ни каких delay и циклов ожиданий.

Про UART не совсем понял где проблема, но тут можно сделать временный буфер и в него заносить данные которые надо отправить, а в прерывании по флагу готовности доставать из буфера данные и отправлять в UART, тоже самое можно сделать на прием.

pokk писал(а):можно сделать временный буфер и в него заносить данные которые надо отправить, а в прерывании по флагу готовности доставать из буфера данные и отправлять в UART, тоже самое можно сделать на прием.

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

Alkul писал(а):только так и нужно делать

спорное утверждение

ARV писал(а):

Alkul писал(а):только так и нужно делать

спорное утверждение

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