Нескольно простых вопросов о программировании AVR на Си.

[COKPOWEHEU]

А в чем проблема? Для printf ведь нужен колбэк записи char'а, а там уже без разницы, напрямую в железо она писать будет или в буфер. Плюс блокирующей быть перестанет, для реальных применений (не отладки) тоже плюс.

[ARV]

вы код приведите, да и дело с концом. простоту надо увидеть, а не услышать...

[COKPOWEHEU]

Да пожалуйста. Саму обработку UART писал давно, сейчас немного причесал. Даже блокировку прикрутил если очередь переполнилась. Но именно этот код в реальных проектах не проверялся, некоторые опечатки мог пропустить.
Как вы понимаете, pinmacro.h и uart.h не пишутся каждый раз с нуля, а кочуют из проекта в проект.

[Ярослав555]

Спойлер

[uquote="COKPOWEHEU",url="/forum/viewtopic.php?p=4132219#p4132219"]Как вы понимаете, pinmacro.h и uart.h не пишутся каждый раз с нуля, а кочуют из проекта в проект.[/uquote]
я вот в STM32 недавно столкнулся с тем что терминал уже написан, и используется в программе - хочешь ты того или нет. Прошивка состоит из двух частей - твоего кода для первого ядра, и прекомпилированной части для второго ядра. и обе эти прошивки используют один терминал. причем ST неплохо написали - вывод в цвете, префикс где какое ядро выводит сообщение.

[U235]

[uquote="COKPOWEHEU",url="/forum/viewtopic.php?p=4132219#p4132219"]Как вы понимаете, pinmacro.h и uart.h не пишутся каждый раз с нуля, а кочуют из проекта в проект.[/uquote]
На мой взгляд, размещать реализацию функций в заголовочнике uart.h не очень хорошая практика. Если такой заголовочник подключить в разных единицах компиляции - возникнет ошибка линковки из-за нескольких фунций с одинаковыми именами.

[COKPOWEHEU]

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

[ARV]

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

сомнительная ценность...

[COKPOWEHEU]

Да, как я и говорил: код получился проще и не блокирующий. Пока буфера хватает, разумеется - природу не обманешь.

[ARV]

не очень хочется спорить, но как же ваш код ПРОЩЕ, если мой состоит по сути только из функции ввода-вывода символа, которая что у вас, что у меня практически одинаковы, а в вашем еще куча дел с буферами, плюс расход ОЗУ на сам буфер?!

как это может быть проще?


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

[COKPOWEHEU]

как это может быть проще?

Так ведь ее не надо писать каждый раз с нуля. Писать надо фактически только то, что в main.c

в вашем еще куча дел с буферами, плюс расход ОЗУ на сам буфер?!

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

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

Да мало ли. Хотите, можно usb реализовать (а для vusb периодичность poll'а важна). Можно всякие датчики опрашивать. На самом деле не удивительно что возникает проблема с ответом на подобный вопрос: сложно описать плюсы того, что просто работает и не требует лишнего внимания.
К слову, то, что реализацию stdio мне пришлось писать под вас специально, тоже кое о чем говорит. Например, о том, что смысла от stdio в AVR немного.

[ARV]

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

Добавлено after 11 minutes 4 seconds:

Так ведь ее не надо писать каждый раз с нуля.

так и с выводом методом поллинга аналогично. то есть это не аргумент в пользу прерываний.

размениваем память на быстродействие или отклик

тут я бы задумался над ценностью этого отклика и быстродействия - оно на самом деле того стоит?

для vusb периодичность poll'а важна

и при чем тут USART? поллить USB во время работы с USART-ом? так сам бог повелел в USART без прерываний писать, а USB поллить по таймерным прерываниям. и тут, чем меньше прерываний, тем стабильнее поллинг. так что и здесь ваш вариант работы с USART не выглядит предпочтительнее...

реализацию stdio мне пришлось писать под вас специально

специально под меня вы писали свой буфер кольцевой (ну не считать же на самом деле проблемой функцию вывода символа для stdio?!). что лишний раз говорит, что в вашем примере писанины (сиречь - работы) больше...

[COKPOWEHEU]

с моей точки зрения stdio очень даже удачно может применяться в AVR

Чтобы что? Для чего именно вы используете именно форматый вывод вместо обычного?

так и с выводом методом поллинга аналогично. то есть это не аргумент в пользу прерываний.

Откуда вдруг взялся поллинг если вы за задержки агитировали?

тут я бы задумался над ценностью этого отклика и быстродействия - оно на самом деле того стоит?

Далеко не всегда. Но и задачи, где это нужно, бывают.

и при чем тут USART? <...> здесь ваш вариант работы с USART не выглядит предпочтительнее...

Все равно ведь лучше вашего варианта на задержках.

специально под меня вы писали свой буфер кольцевой

Нет, только stdio. Сам-то uart был давным-давно.

[ARV]

Для чего именно вы используете именно форматый вывод вместо обычного?

да практически для всего: printf применяю по максимуму везде, где требуется вывод текста и где нет лимита на размер кода (типа attiny13). намного удобнее и проще, чем городить под каждый случай пирамиду itoa и т.п. даже на LCD1602 через printf делал вывод... но не восхитился - позиций крайне мало, негде развернуться...

Откуда вдруг взялся поллинг если вы за задержки агитировали?

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

Но и задачи, где это нужно, бывают

не спорю, бывают. но само решение от этого проще не становится

Все равно ведь лучше вашего варианта на задержках.

откуда вы взяли задержки?! о них и слова не было... разве что вы превратно поняли "задержку на время вывода строки" - принцип блокирующего вывода printf.

Нет, только stdio

ну, раз вы не пользовались stdio, вам, конечно пришлось писать... я-то тут ни при чем.

[COKPOWEHEU]

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

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

не спорю, бывают. но само решение от этого проще не становится

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

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

откуда вы взяли задержки?! о них и слова не было...

Собственно, из ваших слов и взял.

ну, раз вы не пользовались stdio, вам, конечно пришлось писать... я-то тут ни при чем.

А разве я вас в чем-то обвинял?

[ARV]

не могу не поинтересоваться примером кода реализации stdio без прерываний и с минимальной многозадачностью

только с этим не ко мне: я многозадачность реализую при помощи прерываний не для ввода-вывода ТЕКСТА, а для всяких процессов, в которых человек не участвует. поэтому stdio у меня блокирующий, а вот, например, измерение напряжения, которое по USART я наблюдать хочу - по прерываниям.

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

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

[COKPOWEHEU]

Не обязательно что-то сложное. Я говорил скорее о многозадачном. Вот есть пара фоновых задач плюс терминальный доступ. Как вы с блокирующим вводом-выводом переключать их собираетесь?

[ARV]

Я говорил скорее о многозадачном.

ну вот смотрите, что я по этому поводу думаю.
любую задачу можно решать разными путями, но этап разделения на задачи, скорее всего, быть обязан всегда. задачи делятся на первостепенные и второстепенные. второстепенные - это те, ко времени работы которых особых требований не предъявляется. такими, безусловно, являются все задачи, связанные с взаимодействием с человеком - терминалы, кнопки и т.п. эти задачи всегда что-то делают (по меркам МК) редко и неспеша. эти задачи я стараюсь излишне не усложнять, и выполнять в главном цикле, т.е. главный цикл у меня - это интерфейс пользователя.
первостепенные задачи - это те, которые должны выполняться либо очень быстро, либо так же быстро реагировать на какие-либо изменения окружения, либо должны выполняться четко детерминированно по времени. такие задачи я делаю на прерываниях.
подводя итог: многозадачность в традиционном понимании, т.е. кода есть ряд задач, между которыми происходит переключение, я не применяю (чаще всего), а вот многопоточность (мне кажется, это ближе к тому, что получается) у меня в проектах обычно присутствует.

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

при этом для меня совершенно не страшно, что главный цикл замрет на пару десятков миллисекунд, пока будет printf выводить данные... любая первостепенная задача (читай - прерывание) прервет его работу в нужный момент, сделав своё дело вовремя.

Добавлено after 18 minutes 30 seconds:
с молчаливого позволения уважаемой публики, немного продолжу за свой подход.

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

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

я делал несколько подходов к различным многозадачным ОС для МК: OSA, FreeRTOS и еще куча разных поделок из интернета, включая собственные "менеджеры задач". и каждая попытка кончалась одним и тем же: я не находил оправдания своих усилий в достигаемом результате. мне куда жальче собственную голову, чем ядро МК и потребляемую им энергию. чем меньше я думаю над решением задачи, тем моё решение лучше для меня.

вот один из результатов моего подхода: последний проект Digiscript - плейер эффектов для светодиодных гирлянд. не смотря на достаточную сложность проекта, там все сделано строго на последовательном выполнении задач, включая длительные типа вывода на цепочку WS2912. и синхронизация (для эффектов важны временные интервалы) сделана на тупом цикле ожидания флага. и оно-таки работает, и даже обладает определенной портабельностью! и когда оно работает, кажется, что все делается именно так, как и должно - и многозадачность, параллелизм и т.п. не потребовалось вообще.

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

[oleg110592]

в тему статья DI HALT
http://easyelectronics.ru/avr-uchebnyj- ... gramm.html
http://easyelectronics.ru/avr-uchebnyj- ... ast-2.html

[ARV]

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

[COKPOWEHEU]

я делал несколько подходов к различным многозадачным ОС для МК: OSA, FreeRTOS и еще куча разных поделок из интернета

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