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

Что касается атомарности, то это забота не этого класса.

А снабженец закупивший MSP вместо AVR однозначно будет уволен.

Кстати, списки линий поддерживают и манипуляцию отделными битами из списка.
Переводя на пример, который запросил Quasy это будет выглядеть так:


Асм листинг:


Quasy, вы это хотели увидеть?

2 Andy Mozzhevilov
Я говорил про то, что управление конкретными линиями GPIO должно быть только в одном потоке. Иначе вообще странная ситуация складывается - мы пытаемся двумя разными потоками управлять одним и тем же, при этом боимся где-то пересечься. Просто программист, который будет потом разбираться в коде, должен быть в курсе того, что есть такое пересечение потоков.
Кстати, Вы сказали про "приходится настройку портов оборачивать в критические секции", но если это задается вначале программы, то зачем оборачивать в критическую секцию, когда прерывания от периферии еще не разрешены?

Согласен. ИМХО если есть какой-то разделяемый ресур ввода/вывода, то правильно будет ввести сущность "драйвер/менеджер" устройства, и все операции вести через него. Соответственно, вся забота о разделении доступа ложится на этот драйвер

Дык это - для синхронного вывода. Релюхами клацать А если у нас(Вас) случилась такая беда: используется 7 бит для LCD, и надо ж такому случиться - 1wire на последней ноге торчит... Что делать? ванварь-то требует довольно точных временных интервалов...

Значит вы не поняли суть проблемы. Она в том, что для для модификации значения одного бита порта используется команда чтения значения всего порта (8 бит для avr), модификация нужного бита в регистре, и запись 8 бит обратно в порт. То есть модификация 1 бита фактически - это модификация всего порта. Следовательно, если на этом порту есть 2 разных линии, каждая из которых управляется из разных потоков, возможны трудноуловимые баги, обусловленный неатомарными операциями с 8-битным портом. В предыдущем сообщении я написал, как это решается в ARM NXP. Для avr предлагается использовать команды манипуляции отдельными битами (насколько я понял из их мненоники и описания).
А то что вы писали - это управление одной линией из разных потоков (или прерываний и фона) - это другая тема. И такое тоже имеет место быть при необходимости - не надо кричать, что это бред. Например, в фоне выставляется запрос внешнему устройству на каком-то пине, ответ от устройства обрабатывается по прерыванию, в котором в том числе и запрос снимается. Только в этом случае автомат состояния делается общий для такого управления, и там где нужно, изменения состояния автомата оборачиваются в критические секции.


Если это касается main - то не нужно.
На я использую драйвера периферии на С++, где в конструкторе производится инициализация и настройка альтернативных режимов пинов. Все конструкторы закрыты в критические секции, поскольку объекты могут быть созданы не только глобально (конструкторы их будут вызваны до main), но и локально в функции (задаче). В этом случае конструктор будет вызван в месте создания, когда прерывания уже во всю имеют место быть.

Дело не в подводных камнях просто пример совершенно не корректный, скажу более он в принципе не имеет решения.

С нашим устройством связаны биты о маска 0х000F и они должны меняться из одного места. Меняйте любые другие и все будет работать.

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

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

Хорошо, ну а какой смысл вообще оборачивать конструкторы в критические секции? Ну сработало прерывание (не касающееся этой периферии, так как инициализация еще не завершилась), отработали его, вернулись к инициализации и поползли дальше по конструктору, что должно сломаться?
ЗЫ: я не спорю, мне просто интересно

Так смысл абсолютно тот же, что и обсуждается сейчас здесь про неатомарные команды модификации битов порта.
Поясню на примере с ARM NXP.
Eсть регистр ввода-вывода (32 битный). В этом регистре настраиваются 16 линий порта на некоторые альтернативные функции, по 2 бита на пин. То есть, чтобы перенастроить некоторую линию (или группу линий) на другую функцию - нужно:
1. Считать значение IO регистра
2. Модифицировать значение нужным образом.
3. Записать новое значение в IO регистр.
При этом в конкретном драйвере мне нужно (предположим) перенастроить только 2 IO линии из 16-ти, за которые отвечает этот регистр.

Теперь - у меня RTOS с вытеснением (аналогичные рассуждения для прерываний).
В другой задаче у меня так же есть код, который оперирует настройкой линий IO в пределах тех же 16-ти линий того же порта.
Проследите, что будет, если где-то между 1. и 3. произойдет переключение контекста на другую задачу, которая решит также перенастроить линии порта (другие линии, но находящиеся в пределах этих 16-ти).

1a. Считать значение IO регистра
--- контекст a->b
1б. Считать значение IO регистра
2б. Модифицировать значение нужным образом.
3б. Записать новое значение в IO регистр.
--- контекст b->a
2a. Модифицировать значение нужным образом.
3a. Записать новое значение в IO регистр.

В результате операции, выполненные в 1б, 2б, 3б - будут похерены.

ЗЫ: Проблема в том, что подобные баги - трудноуловимы. Их проявление - стечение обстоятельств. То есть как правило - это нечто вроде: "У меня софт прекрасно работает месяц, но потом иногда затыкается обмен данными".
Или: "У меня 1 раз из 100 устройство не включается, но после включения все 99 раз все дальше работает без сбоев".

Для данной конфигурации - да. Остался, кажется, один шаг - заставить Вашу библиотечку разбирать: когда выводить побитно, а когда организовать критическую секцию с "Чтением-Модификацией-Записью". Это, кстати, нужно только для эффективного вывода констант (для переменных вывод побитный, там групповой вывод не работает).
Если интересно, то скажу, что в моем тупом варианте это делается весьма легко: в препроцессоре макрос считает для константы биты на каждом порту, и препроцессор же делает выбор.


... и так для всех портов.

Что для этого потребовалось? Ну, где-то сказать, что ПортА на битовом пространстве, ПортG - нет.
(для ХМЕГИ это означает - сказать на какой виртуальный порт отображен PORTn)
И макрос соорудить для подсчета бит. Это совсем легко.
Негатив такого варианта: для каждой Группы нужен h-файл с макросами для подсчета бит.. Они у меня, собаки, здоровенные получились, но каши не просят

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

Кстати, насчёт пресловутой атомарности.
В msp430 (моём любимом ) с этим никаких проблем.
Зря я волновался.
У него чтение-модификация-запись производится в пределах одной команды, засчёт ортогональной системы команд и адресации.
Вот пример, выцепил из рабочей прошивки.

На порт по адресу 001d накладывается маска 0xffbf, и всё это за одну команду, которая не может быть прервана никаким прерыванием.

Как хорошо иметь компилятор, умеющий без лишнего кода различить, что PORTA |= 0x07 надо делать тремя SBI, а PORTA |= 0x0f с помощью RMW в критической секции.

Меня больше интересует именно групповой вывод для переменных.
Есть у кого нибудь предложеня по дальнейшей оптимизации этой операции? Какие ещё приёмы отображения битов из входного значения в соответствующие биты портов можно придумать? Эффективные приемы для частных случаев?

А так-же какие есть предложения по дальнейшему развитию функционала?
- Отдельная функция для гарантированно атомарного вывода
- Управление подтяжкой линий
- Управление режимами прерываний

Доброго всем времени суток.
В моей библиотеке произошло довольно много изменений:
- поддержка МК Texas Instruments MSP430;
- поддержка STM32;
- поддерживаются компиляторы GCC, IAR, Keil;
- новый подход к конфигурации портов;
- убраны предупреждения компиляторов;
- лучшая оптимизация;
- исправлены ошибки;
- автоматические тесты;
- лиценизия изменена на BSD.

Найти ее можно по старому адресу:
https://github.com/KonstantinChizhov/AvrPro...e/master/mcucpp

Вот это, пожалуй, самое важное :-)
В отличие от, к примеру, портирования на STM32, это самостоятельно сделать возможности никакой не было.

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

Добрый день.
Есть вопрос по С++.
В этом топике выше подымалась тема библиотеки статических классов по управлению портами.
При работе с этой библиотекой возник вопрос.
Можно ли различные списки пинов привести к какой либо ссылке что бы в классе который реализует одинаковую логику но для разных списков использовать просто указатель на список.
Пример чего хочу:

Но ничего не выходит потому что указатель класса B объявлен без списка параметров.
Пока реализовал класс B с шаблоном по списку пинов, но не устраивает что несколько членов-методов которые работают с данными из шаблона дублируются столько раз сколько раз я определяю шаблон.
Есть ли выход из данной ситуации. Или это оптимальное решение.
Все компилирую на IAR.

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

Затраты на вызов одной функции по указателю в худшем случае тактов 8, может и меньше.

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



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

Решил все сделать через указатель на функцию. Огромное спасибо.
Только вопрос в чем разница между кодом как привели Вы:


и кодом который работает аналогично только занимает на 10 байт больше:



И если я передаю в конструктор два указателя на функцию. Как это описать?

Разница в том, что в первом варианте используется инициализация поля _func параметром конструктора, а во втором - _func сначала инициализируется значением по умолчанию, а потом ему присваивается параметр конструктора. В принципе, в данном случае разницы не должно быть никокой, а разница в размерах, видимо из-за того, что оптимизатор чудит.
В с++ надо отличать присваивание и инициализацию, например:

Вариант 1 - инициализация значением по умолчанию потом присваивание.
Вариант 2 - иничиализация копированием (вызов копирующего конструктора).
Вариант 3 - явный вазов конструктора. Наиболее предпочтительный.

to neiver
Добрый день.
Можешь посоветовать как описать набор из n регистров 74HC595(выходы) и 74HC597(входы) для работы с произвольными pin этого набора.
Если в связке будет до 8 регистров или 64 входа/выхода в зависимости от конкретной схемы. В статье описано как работать с одним регистром.
А вот как описать пины для большей разрядности не понятно.
Заранее спасибо.

....
Кажется понял

и объявление из статьи

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

И немного переписать методы DataT Read() и void Write(T value) что бы обновлялись регистры значениями из переменной _currentValue и наоборот.
Но тогда не вижу как можно сделать больше чем 32 пина?

Вобщем-то все правильно. А зачем больше 32 пинов использовать? Два списка по 32 пина и все. Хотя если очень хочется можно и тип uint64_t (он-же unsigned long long), но тогда еще и реализацию спискак линий прийдётся расширять до 64 линий...
Лучше 2 списка по 32 линии.

Можно и два списка по 32. Вопрос не в этом. Обычно на spi все регистры висят последовательно. Как два списка будут работать с одной колбаской из 8-ми регистров?
скажем даже так есть два регистра IN и два OUT. Можно ли описать их двумя списками по 16 бит, но при этом что бы списки по SPI работали каждый со своими регистрами?

С точки зрения оптимальности, выыодить значение в цепочку регистров нужно за один проход. И если 8 регистров включены последовательно, то в любом прийдётся выводить сразу все 64 бита. И соответственно текущее значение хранить в переменной типа uint64_t. Однако, к одному модулю SPI можно подключить несколько цепочек регистров, например, по 4 штуки, разделив их линии защёлкивания данных(ST_CP для 74HC595). Я думаю, что задачу всё-таки нужно свести к 32 битным значениям.

Или уж совсем радикально - массив unsigned int. И ни в чём себе не отказывать :-)

У неграмотных плюсистов.

Попытался адаптировать библиотеку Чижова под STM8. Изменения коснулись только файлов ports.h и atomic.h. Работа с битами в выходном регистре оптимизируется компилятором хорошо, а вот конфигурирование ведет себя так, будто не все известно при компиляции. Это часть класса, связанная с конфигурацией.
В итоге все эти условия так и лезут в кристалл. Что я делаю не так?
Прикрепил весь проект в ИАР. Посмотрите пожалуйста.

В общем всё правильно. При вызове не шаблонной SetConfiguration компилятор не обязан всё инлайнить и вычислять во время компиляции. Для этого лучше использовать шаблонный вариант:

Он гарантированно только три машинных инструкции.
Ну и код можно существенно оптимизировать:


В реализации портов для MSP430 такой прием был использован. MSP430 гораздо ближе по структуре портов к STM8. Можно было взять реализацию их портов за основу, было-бы проще чем кусками брать код из AVR и STM32 портов.Нажмите для просмотра прикрепленного файла