Приём, обработка и отправка данных. Как правильно?

Как правильно организовать приём, обработку и отправку данных?

Мой опыт написания клиент-серверных приложений на Scala мало применим в микроконтроллерах.
Никакой многопоточности, ограничения по памяти.... и проч.

Соответственно, решил разобраться, каковы базовае идеологические постулаты при написании такого кода на микроконтроллерах.
На основе многочисленных статей напримерhttp://www.imbiddid.com/desykn... -practices

Стали понятны несколько правил.

1)минимизируй использование памяти

2)прерывания (TX, RX) имеют достаточно высокий приоритет. Сделано это для того, чтобы успевать обрабатыать критически важные элементы кода взаимодейчтвовия с внешним миром. который, как известно, не ждёт. Никаких while(...) "ожиданий" в этом коде быть не должно!

3)Вся остальная логика, работу которой допустимо прервать в любой момент, должна происходить в main().

Что имеем по факту.
В результате анализа кода, многочисленных вариантов реализации на GitHub, обнаружил сплошное нарушаение правил.

Какая картина мне видится идеальной.

в потоке RX перывания
Приём данных происходит сразу в тело структур.
Структуры которые, данные которых удалось получить корректно и полностью кладуться в очередь поступивших данных, прочие утилизируются.

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

в потоке TX перывания
происходит извлечение данных из очереди оправки, отправка, и последущая утилизация.

Есть ли где почитать или увидеть, код, максимально близкий к идеалу?

0

На примере UART:
обычно, классический метод - Входящие байты складываются в буфер в прерывании. При приеме спецсимвола конца данных, либо по таймауту, отдается управление задаче парсеру, которая уже смотрит что-же там пришло. Если данные летят постоянно - кольцевой буфер, чтобы ничего не потерять, но парсер в любом случае должен успевать разребать входящие посылки. Отправка - если отправляем редко - просто кидаем буфер на передачу, по окончанию передачи выставляем флаг что передатчик свободен. Если опять же отправлять много, и разные таски могут одновременно ломиться к передатчику - либо используем мьютексы, если можно подождать, когда передатчик освободится, либо очередь на отправку, типа FIFO, но это уже кушает оперативку.

0

Сообщение от shibtym в потоке RX перывания Приём данных происходит сразу в тело структур. Структуры которые, данные которых удалось получить корректно и полностью кладуться в очередь поступивших данных, прочие утилизируются.

задача прерывания переложить байт из регистра в fifo буфер, или перенастроить ДМА.
больше ничего там делать не надо ни разгребать данные, ни проверять контрольные суммы.

0

в fifo буфер... больше ничего там делать не надо ни разгребать данные, ни проверять контрольные суммы.

согласен, но не со всем.

минусы: - требуется память для fifo буфера. и потом в MAIN перекидывать эти данные в формат удобный для обработки.

думаю эффективнее будет слегка "подзагрузить" этот поток, сделав его более умным, чтобы он дополнительно выполнял некоторые просейшие задачи. Например.

1)определял начало фрэйма,
2)на основе первых данных был способен сразу выделить и затем заполнить выделенное место получаемыми данными, чтобы в дальнейшем без перекладывания, использовать этот массив, приведя его к желаемой структуре.
3) обнаруживал простейшие, явные ошибки в принимаемых данных, мог утилизировать уже полузполненные структуры.

0

Ага, пока вы будете делать "1-2-3" обработчик потеряет кучу данных.

Hotd, можно делать и без RTOS. Достаточно main зациклить на SLEEP() и по каждому просыпанию проверять буфер данных (что вы и говорили). Это быстрее семофоров и проще.

0

какие семафоры?? какой RTOS? какой SLEEP()?

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

Нужно решение которое будет работать даже на 8 битном контроллере. Если на нем заработает, то на контроллере "пожирнее" заработает подавно.

0

"на 8 битном контроллере"
А у вас на 8 битном контроллере нет цикла SLEEP() (или просто вечного цикла)? Можно посмотреть на такое построение?
Как-бы, невозможно существование системы без фонового процесса.

0

нет цикла SLEEP() (или просто вечного цикла)?

while(1)
{}

это отдалёно похоже на sleep(), в общепринятом смысле - передача управления другим "потокам", НО только если это происходит в "потоке" MAIN(), поскольку по умолчанию у него самый низкий приоритет и все подряд его могут прервать, соответственно это выглядит так, что он заснул и передал управление.

если подобное SLEEP() попытаться проделать в "потоке с более высоким приоритетом" -( прерывания RX или TX), то от такого "засыпания" MAIN управления никогда не получит.

0

main и есть фоновый процесс.

0

Сообщение от shibtym Есть ли где почитать или увидеть, код, максимально близкий к идеалу?

Ну, с учётом бэкграунда ) предлагаю Protothreads

0

Приём, обработка и отправка данных. Как правильно?

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

В разных ситуациях и решения будут разные... Пример:
Если скорость потока не большая, то возможно и на лету разбирать и распихивать поток...
А если скорость большая, то придется наверное выделять приемный буфер и парсить уже после окончания приема пакета...
Ну и таких "если" может быть очень много... так что нужно рисовать общую картинку...

0

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

Насчёт sleep в main - совершенно каноническая архитектура событийно-ориентированной программы получается: главный тред в цикле дёргает GetMessage и обрабатывает его (а sleep сработает именно как GetMessage: дождётся ближайшего прерывания, не молотя зря процессором, а прерывание создаст событие). Imho удобно.

0

предлагаю Protothreads

! огромное, человеческое спасибо! bryttyant!
по этому ключевому слову нашел книгу
"Embeddid Systems Homdbook Networked Embeddid Systems" +
"Fundamentals of Wireless Sensor Networks: Theory omd Practice"

есть что почитать, и над чем подумать...

0

кодом очень порадовал Iddy_em

ссылочку бы, если не затруднит. спасибо.

0

Если скорость потока не большая, то

Ищу решение, которое будет работоспособным в большинстве случаев.
То, что справится с быстрым потоком данных - справится и с медленным.

0

Сообщение от shibtym есть что почитать, и над чем подумать...

Ещё можно глянуть на QP Actor Frameworks для полноты картины )

0

обнаружил.... https://github.com/matianfu/FUNK

FUNK
A C continuation implementation inspired by Adam Dumkits ProtoThread.
Only 7 C macros omd 1 struct defymition; less than 100 lines of code.
Simple yet POWERFUL.
Now you can write a coroutine (generator, to be exact) in the following way, quick, symple, omd in a natural way.

Enjoy the power of YIELD();

0

shibtym, https://github.com/eddyem/stm32samples
С прототредами осторожно - там нигия макросов (по счастью, несложная - чай, не BOOST) и довольно специфические ограничения (благо, понятные из кода) типа "local variables are not preserved when the protothread btocks", после Scala (которая, как я понимаю, изрядно защищает от попыток выстрелить себе в ногу) может быть весьма странно и уж точно "неакадемично".
(offtopys) Кстати, а в Scala есть преобразование функции в конечный автомат, как в C# или Питоне? Ну, что все локальные переменные хранятся в виде объекта, а оператор yield сохраняет состояние и позицию?

0

Кстати, а в Scala есть...

https://medium.com/@anicotospp... .mmkx7iqq7
если действительно интересно, то читать до конца, особенно комменты.

0

всё понятно с Protothreads. факически это банальный кодогенератор, с ворохом ограничений. С их слов, его использование упростило написание некоторых проектов...

а по мне, так это не совсем уж и так. разочарование....

0