ARM, RISC-V контроллеры

У UART протокола нет, но ... его можно сделать! Непосредственно с ADUC7026 дела не имела, но работа UART на всех МК реализована примерно одинаково. Физически обмен по интерфейсу UART предельно прост - кидаешь байты один за другим в регистр данных (COMTX), а получатель с той стороны (обычно персональный компьютер) будет получать их в том же порядке, в котором они были посланы. Т.е. UART, с точки зрения программиста, - простой байтовый обмен. Существуют определенного рода предварительные настройки, которые должны произвести обе стороны (ADUC7026 и компьютер), например, настроиться на одинаковую частоту передачи и условиться об использовании дополнительных сигнальных линий. Но эти настройки производятся не в процессе обмена, а определяются выбором самого программиста на том этапе разработки, когда он решает на какой скорости будет работать передача. Помня только о том, что с увеличением скорости падает надежность связи и снижается ее дальность (ограничение в длине проводов). Технически установить скорость передачи приходится всего один раз, при запуске устройства. А сам акт передачи предельно примитивен - кидаем байты в регистр COMTX. Тут только одно правило надо соблюсти – проверить, что прошлый байт уже ушел и COMTX освободился. Обычно это проверяется проверкой соответствующего бита (THRE) в регистре статуса (COMSTA0). Как в том бите единичка появится, значит, предыдущий байт уже отправлен и можно "толкать" следующий. На языке C это выглядит так: while( !(COMSTA0 & 0x020)); // ждем появление бита THRE COMTX = новый_байт; // толкаем очередной байт В практических конструкциях появления бита готовности не ждут (чтобы не тормозить работу МК), а настраивают прерывание по готовности этого бита. Например, я использую кольцевой 256-байтный буфер, а который заталкиваю требующие отправления байты, не задумываясь о готовности UART к отправке, а система прерываний настроена так, что при готовности к отправке очередной байт автоматически берется из этого буфера. Но если вы новичок, то пока используйте самый простой способ отправки с предожиданием, как в только что приведенном примере. Теперь по проводу протокола. Пересылка байт в каком-то протоколе не нуждается, но если вы собрались пересылать какие-то сообщения, то вам придется сочинить ДЛЯ СЕБЯ какой-то протокол, чтобы отличать одну посылку от другой. Ведь запихнуть все данные в один байт вам не удастся, а, следовательно, посылки у вас будут многобайтные. И вот тут-то и надо предусмотреть какой-то способ различать в непрерывном байтовом потоке отдельные посылки. Только не надейтесь здесь на свои знания арифметики. Если у вас посылка размером в 5 байт, то это вовсе не значит, что 1000001-ый байт тоже окажется началом посылки. Будьте готовы тому, что любой байт из потока может пропасть, а прием начаться не сначала посылки, а с любого места. Поэтому позаботьтесь заранее, придумав такую структуру посылок, чтобы в них потом можно было разобраться. Например, если вы выдаете данные с текстовом виде, то символ конца строки позволит вам отличать одну посылку от другой. Если же данные требуется посылать более плотно, в бинарном формате, то стоит задуматься о каких либо разделителях, которые нельзя было бы спутать с байтами данных. Тут все зависит от вашей фантазии и здравого смысла. Помните, что расшифровывать посылки придется не чужому дяде, а вам самому. Т.е. при передаче вы пакуете эти посылки, а при получении их распаковываете. Если же вы будете посылать данные неупакованными, а россыпью, то потом не можете эту россыпь собрать, т.к. запутаетесь, какой у вас байт первый, а какой второй. Ведь на отправленном байте нет этикетки, к чему он относится.