Я же говорил, что к одному и тому же пину у меня в коде НИКОГДА нет обращения их РАЗНЫХ потоков.
Это исключено еще на этапе построения проекта.
Поэтому не будет ничего страшного, если кто-то прервет эту строчку с ODR.
В крайнем случае могу использовать CriticalSection, если нужно сохранить строгую последовательность некого пинодрыга, но пока еще с таким я не сталкивался.

ЕМНИП, в компиляторе Hi-Tech для PIC тип char был беззнаковый по умолчанию, но можно было задать знаковый. К спору об int не относится, с ним ясно всем, кроме одного.

Ничего вы не поняли.
В вашем коде две проблемы:
1. Проблема с двухэтапной записью в MODER. Выше уже очень хорошо объяснили, что это нехорошо. Потому что ножка переводится в промежуточное состояние, которое может быть нежелательным. И при возникновении прерывания между двумя записями ножка может остаться в этом состоянии достаточно продолжительное время. Этого может быть достаточно, чтобы что-нибудь сжечь. Это реальная мина, потому что на столе может всё работать, а в продакшене может рвануть.

2. Проблема с неатомарностью операции GPIOA->ODR ^= bit. (Об этом вам пишет juvf). Дело в том, что если такие операции выполняются одновременно из разных потоков (к разным битам одного порта), то возможны сбои. Разжёвывать не буду, гуглите.

ЗЫ. Рано вы взялись за "Чистый код". Надо было сначала основы подтянуть.

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

Вы хотите сказать, что операция обращения к ODR неатомарнае, например, копирование из регистра R2 -> [R3], где R3 хранит адрес ODR-регистра?
Вы точно ничего не путаете?

просто ужос!!!! такие элементарные вещи... вроде разживал все... выделил жирным шрифтом, что при изменении РАЗНЫХ ПИНОВ РАЗНЫХ!!!
ну не видите вы сами... я же вам привел пример... РА15 и РА5

пошагам.... пусть cs будет РА1, а led будет PA4. воспользуемся литералом b. для кратности пусть порт будет 8 бит. изночально в ODR 0b0000'0000
вы в одном поторке выитали ODR, он равен нулю. второй поток прервал первый. второй поток вычитал ODR и добавил туда cs, стало 0b0000'0010. теперь записал это в ODR. Сs стал "1". Вернулись в первый поток... 0b0000'0000 добавили бит светодиода, получили 0b0001'0000 - записали в ODR - всё!!! CS сбросился! Упс!!!

раз вы пишете на RTOS, должны знать про неатомарные операции

БИНГО!!!!

Для класса ты пишешь всякие on/off один раз и они точно будут рабочие. На макросах ты пишешь намного больше и можешь случайно ошибиться:



На радиокоте недавно спрашивали как записать 7 бит заданного байта в PD9, 5 бит в РВ4 и т.д.... Дали парочку ответов, лучший из которых выглядит так:

Шаблонный код мог бы быть таким:

Он понятнее и эффективнее, т.к. никаких проверок в нем нет.


Речь про инит, который уже написан, отлажен и привязан к конкретному пину. Возьмем, для примера, USART. У некоторых популярных мк их по 6 штук, каждому нужно инитить ноги, большинству нужно 3 параметра для каждого пина, у STM32F1 их 2, но там инициализация немного другая... Какая сущность должна всем этим заниматься? Должен ли я для каждого USARTа закопать инициализацию пинов в какой-то общей функции инициализации? Считаю, что не должен, потому делаю так:

Не нравится прописывать пины прямо тут, выносим их куда угодно



Здорово, особенно учитывая, что про бинарные литералы в С++ тебе рассказал именно я

Даже коментировать тут нечего.... Полемика. Ну я же говорю, бинарно мыслите... при чем тут уарт? я вам сказал что макросы ВЕЗДЕ лучше классов/шаблонов?


я бы не так сделал. была подобная задача.

Так глубоко в компилятор я не влезал, щас влез в asm код, который нагенерил компилятор для toggle() ...
Действительно, возможны глюки, надо переписывать!
Вот и баги нашлись
Хотя до сих пор, проблем не было, но это - вопрос времени, нужно обязательно переделать!

Есть идеи, как переделать void toggle() { port->ODR ^= pinMask; }, избежав критических секций?

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

Был тут уже один товарищ с критикой, я ему предложил написать аналог инициализации портов FSMC двумя строками, ты видел ответ? Так и тут... Начинается с того, что задефайнить csOn()/csOff() и прочие максросы проще простого, как и проинитить, а ты покажи полную инициализацию пинов хотя бы пары усартов, тогда будет с чем сравнивать. Имеется в виду количество кода который придется написать для каждого нового усарта в проекте.


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

Сообщение отредактировал Reflector - Apr 20 2017, 08:37

Навскидку...





!!! Извини.... но блин.... это всего лишь ногой дёрнуть!!! ))))))))))))

Можно использовать bit-band для реализации cpl(). У меня так.
(К сожалению, для stm32L0x - не сработает, там нет bin-band для GPIO).

Да и ерунда всё это, на самом деле. Я лично не помню, чтобы где-то использовал cpl(), кроме тестов. Всегда нужно переводить ножку в какое-то определённое состояние.

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

ps ещё програмный меандр выдавать.... можно найти применение cpl-ю

Ага, но только что я приводил пример практически такого-же кода, как не самого эффективного, т.к. там будет проверка.

То же самое, но без лишней инструкции ITE.
ps. Упс, сорри, это совсем не тоже самое, т.к. читает с IDR Но сути это не меняет, меняем IDR на ODR, но код прячем внутри класса.


У F0 ITE нет, там проверки еще более тяжелые.

Сообщение отредактировал Reflector - Apr 20 2017, 09:34

Как вариант ))

Но я предпочитаю более читаемо:


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

Ну тогда bit-band. Есть везде, кроме L0.

ЗЫ. Я там вам ответил про варианты pin.h, возможно вы проглядели (тема растёт очень быстро).