Шаблоны классов работы с пинами и портами (по маске и набору пинов) SILABS EFM32, может кому пригодится Опции

[Nixon]

По мотивам STM32TPL от Anton B. Gusev aka AHTOXA сделал с учетом новых возможностей С++11/14 подобное для EFM32
Особенно интересно получился класс PortPins.

чуток поправил

 efm32lg_gpio.zip ( 3.72 килобайт ) Кол-во скачиваний: 27


Сообщение отредактировал Nixon - Mar 20 2018, 10:00

Причина редактирования: форматирование

[x893]

Порадовала особенно эта строка

enum { MODE0 = X*0x00, MODE1 = X*0x01, MODE2 = X*0x02, MODE3 = X*0x03, MODE4 = X*0x04, MODE5 = X*0x05, MODE6 = X*0x06, MODE7 = X*0x07, MODE8 = X*0x08, MODE9 = X*0x09, MODEA = X*0x0A, MODEB = X*0x0B, MODEC = X*0x0C, MODED = X*0x0D, MODEE = X*0x0E, MODEF = X*0x0F };

ну и остальное смотрел на одном дыхании.

[juvf]

а этот код рабочий? или я не понимаю этот с++14 новомодный....

class Pin {
...
enum { DOUTx = 0x42000000UL + (GPIOx_BASE + offsetof(GPIOxTypeDef, DOUT) - 0x40000000UL) * 32 + pin * 4 };
..}

как это работает? чему DOUTx будет равно для РА5? Я так посчитал
DOUTx = 0x4200_0000 + (0x4000_6000 + 0x1C - 0x4000_0000) * 0x20 + 5 * 4
DOUTx = 0x4200_0000 + 0x601C * 0x20 + 0x14
DOUTx = 0x4200_0000 + 0xС0380 + 0x14
DOUTx = 0x420С_0394

я правильно посчитал?

[Nixon]

а этот код рабочий? или я не понимаю этот с++14 новомодный....

class Pin {
...
enum { DOUTx = 0x42000000UL + (GPIOx_BASE + offsetof(GPIOxTypeDef, DOUT) - 0x40000000UL) * 32 + pin * 4 };
..}

как это работает? чему DOUTx будет равно для РА5? Я так посчитал
DOUTx = 0x4200_0000 + (0x4000_6000 + 0x1C - 0x4000_0000) * 0x20 + 5 * 4
DOUTx = 0x4200_0000 + 0x601C * 0x20 + 0x14
DOUTx = 0x4200_0000 + 0xС0380 + 0x14
DOUTx = 0x420С_0394

я правильно посчитал?

Правильно. BitBanding memory area. Делал для себя, поэтому комментарии почти не писал.

[RadiatoR]

А почему нет?
Если обертка для bb рабочая и эффективная, то не грех выложить.
Лично я попробую.
Спасибо автору.

[Nixon]

По поводу эффективности. IAR 8.22, optimization - medium
Время выполнения на константных параметрах:
PortPins::Mode - 20 + pins тактов
PortPins::Set - 2 * pins тактов
PortPins::Get - 2 + 3*pins тактов

PortMask::Mode - 19 тактов
PortMask::Set - 4 такта
PortMask::Get - 4 такта

[Kabdim]

Исходники всё же лучше выкладывать на гитхаб(или аналоги), нет лицензии.

[juvf]

PortPins::Get - 2 + 3*pins тактов

не торт. 16 пинов 50 тактов. Если в лоб вычитать ODR 1-3 такта. Но в коде писать удобней. Плата за удобство.

А сколько тактов Pin::Get()?

[Forger]

По поводу эффективности.

Цифры действительно неплохие ... для поклонников ногодрыга

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

Потому, имхо, применение той или иной обертки (не только для пинов) должно быть предельно очевидным, ознозначным и тривиальным. Т.е. читаемым должен прежде всего быть код, а не сама библиотека.
В данном случае такое обилие способов применения мне лично кажется избыточным (судя по приведенным примерам), ну, главный "недостаток" - повышенные требования к компилятору: C++11/14.

В целом, пример интересный и полезный, ну, хотя бы в образовательных целях

[Nixon]

не торт. 16 пинов 50 тактов. Если в лоб вычитать ODR 1-3 такта. Но в коде писать удобней. Плата за удобство.

А сколько тактов Pin::Get()?

Согласен, потому и использую для широких портов PortMask. Там все побыстрее будет. Но бывает что нужно красиво использовать неширокую шину с разбросанными пинами.
Pin практически не отличим от PortPins на один пин. Можно и убрать этот класс.
По поводу вычитки напрямую - вы не забывайте что PortPins еще и правильно мапит нужный пин в нужный бит. А это тоже затраты.

Цифры действительно неплохие ... для поклонников ногодрыга

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

Потому, имхо, применение той или иной обертки (не только для пинов) должно быть предельно очевидным, ознозначным и тривиальным. Т.е. читаемым должен прежде всего быть код, а не сама библиотека.
В данном случае такое обилие способов применения мне лично кажется избыточным (судя по приведенным примерам), ну, главный "недостаток" - повышенные требования к компилятору: C++11/14.

В целом, пример интересный и полезный, ну, хотя бы в образовательных целях

1. Скорость настройки портов бывает важна - например при двунаправленных шинах. Согласен, это редкое применение, но бывает
2. Иногда после чтения (или перед записью) пинов нужно делать кучу преобразований (битовых манипуляций), тут это делается автоматически
3. Необходимый размер RAM для данной обертки 1 байт на экземпляр класса (или 0 байт для работы со статическими методами). Размер ROM действительно велик (по сравнению с требованиями к RAM), из-за сплошного inline, но для большинства камней действительно не критичен

А по поводу компилятора - а кто сейчас для ARM не делает поддержку С++11/14? Последним был IAR и то уже исправился.
В целом я с вами согласен - это чисто образовательный пример, но с практическим значением
Хотел бы заметить что многие вещи, ранее невозможные (или приводящие к большой избыточности кода) на 11/14 делаются не в пример легче и удобнее.

[juvf]

Pin практически не отличим

вроде как 3 такта должен быть. ну это мож на стм32.

Пример интересный.... я бы не полез смотеть сырц, если бы в описании видел

IV. Check pin state:
* Var = PA5::Get() //return int: 0 when RESET, 1 when SET
* Var = pa5.Get() or
* VAR = pa5;

вроде как логично 0 это 0, а 1 это 1, но вдруг вы возвращяете для порта РА5 значение (1<<5)? Такое тоже бывает. А может возвращаете RESET или SET, true или false, LOW или HI. Но так вы пишете для себя....

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

c11 щя все поддерживают. IAR, gcc. Про кеил не знаю, может там его нет. вроде как 7 лет прошло.

[Nixon]

вроде как 3 такта должен быть. ну это мож на стм32.

Пример интересный.... я бы не полез смотеть сырц, если бы в описании видел
вроде как логично 0 это 0, а 1 это 1, но вдруг вы возвращяете для порта РА5 значение (1<<5)? Такое тоже бывает. А может возвращаете RESET или SET, true или false, LOW или HI. Но так вы пишете для себя....

Для Pin и PortPins производится приведение считываемых данных к их реальному размеру. Т.е. для Pin вернется или 0 или 1, но никак не 1<<5

[Forger]

Про кеил не знаю, может там его нет. вроде как 7 лет прошло.

У кейла С++11/14 держит ARM компилятор v6, но он делает заметно бОльший код, чем старый компилятор v5 (по крайней мере в моих проектах).
старый v5 лишь частично поддерживает C++11

[juvf]

Для Pin и PortPins производится приведение считываемых данных к их реальному размеру. Т.е. для Pin вернется или 0 или 1, но никак не 1<<5

Это вы знаете, так как вы знаете, что так и куда приводиться. Вы знаете что там BitBanding. у того же АНТОХА

* V. Check pin state:
* if (PA5::Signalled()) // returns non-zero if pin input = active state (H for PA5)

возвращает ноль и НЕ НОЛЬ, а не ноль может быть и 1<<5. Ни куда не надо лезть, из шапки всё понятно.

Если писать для людей (да и для себя. т.к. сможете забыть), то уж лучше уже в шапке чиркнуть возвращаемое значение. Хотел сразу про это сказать, но у вас код "для себя". ))

[Forger]

например при двунаправленных шинах

Да это - ногодрыг в чистом виде! Такое, имхо, лучше делать через прямое обращение к портам без всяких оберток и классов, разумеется, в ущерб читаемости.
Но такие случаи обычно связаны с очень медленными (например, 1-wire) интерфейсами, где суперскорость не имеет значения. Поэтому ни что не мешает использовать даже толстые обертки.
Лишь бы код был предельно простой, лаконичный и читаемый, а вся эта "срамота" скрыта в недрах библиотеки/обертки.

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

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

Надуманная "проблема" или я не пойму о чем речь. Приведите пример ))

Хотел бы заметить что многие вещи, ранее невозможные (или приводящие к большой избыточности кода) на 11/14 делаются не в пример легче и удобнее.

А вот этот момент просвятите, пожалуйста, по-подробнее, разумеется, в применении к нашей области (МК)
Если возможно, то конкретные ситуации, где это действительно оказалось полезным.

[Nixon]

Это вы знаете, так как вы знаете, что так и куда приводиться. Вы знаете что там BitBanding. у того же АНТОХА
возвращает ноль и НЕ НОЛЬ, а не ноль может быть и 1<<5. Ни куда не надо лезть, из шапки всё понятно.

Если писать для людей (да и для себя. т.к. сможете забыть), то уж лучше уже в шапке чиркнуть возвращаемое значение. Хотел сразу про это сказать, но у вас код "для себя". ))

Согласен, задокументировал плохо. Переделаю.

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

"Широкая" параллельная шина для связи например с FPGA

Надуманная "проблема" или я не пойму о чем речь. Приведите пример ))

Пример - есть параллельная 4-битная шина висящая на пинах 1(bit0), 11(bit1), 12(bit2) и 5(bit3) (ну получилось так при разводке). Необходимо записать на шину определенное число. Сколько операций займут у вас битовые манипуляции?

А вот этот момент просвятите, пожалуйста, по-подробнее, разумеется, в применении к нашей области (МК)
Если возможно, то конкретные ситуации, где это действительно оказалось полезным.

Пожалуйста. Мне например очень помогает нормальная поддержка constexpr. Это помогает резко экономить RAM, которого никогда не хватает. Или инитить что-либо. Например

Код

struct S {
  int a;
  int b;
  int c;
};
constexpr S R[] = {{0,1,2}, {3,4,5}, {6,7,8}};
constexpr int sum ( void ) {
  int temp = 0;
  for (int i = 0; i < sizeof(R)/sizeof(S); i++) temp += R.b;
  return temp;
}
const int summa = sum();
int array[summa];

создание массива на этапе компиляции, размер которого зависит от суммы всех R.b. Причем размер R не играет значения. Пример абсолютно абстрактный.
Очень приятная фишка variadic template - помогает КРАСИВО и БЫСТРО делать например делегаты и списки типов.
Я уж молчу про битовые литералы

P.S. Забыл сказать - динамическое выделение памяти у нас на работе запрещено внутренним регламентом.

[Forger]

"Широкая" параллельная шина для связи например с FPGA

А нафига тут параллельная программная (соотв. медленная) шина, если вполне достаточно аппаратного SPI или чего-то подобного?
Или схемотехник решил поиздеваться над программистами или разработчик под FPGA еще не научился применять готовые модули популярных послед. шин?

Пример - есть параллельная 4-битная шина висящая на пинах 1(bit0), 11(bit1), 12(bit2) и 5(bit3) (ну получилось так при разводке).

Самое первое, что приходит в голову - выгнать такого схемотехника. Я серьезно! За подобные костыли программисты устраивают "темную" такому схемотехнику ))
А пока временно сделать программную заглушку, написанную чуть ли не АСМе. Конечно, если, требуется суперскорость и речь идет, например, про программный QuadSPI ( )

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

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

Мне например очень помогает нормальная поддержка constexpr.

Любопытно ... но не очень убедительно: получается некая экономия на "копейках", вынуждающая думать где ставить constexpr или оставить банальный const

Очень приятная фишка variadic template - помогает КРАСИВО и БЫСТРО делать например делегаты и списки типов.

Познавательно! Без делегатов связать незнакомые и изолированные друг от друга модули никак не получается. Поэтому использую делегаты (своего рода система signal/slot в Qt).
Впрочем, я использую делегаты всего лишь 4 видов, шаблоны которых вмещаются в одном крохотном hpp файлике (если интересно, приведу содержимое).

Код

class DelegateVoidVoid
template<typename OutType> class DelegateTypeVoid
template<typename InType> class DelegateVoidType
template<typename OutType, typename InType> class Delegate

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

Однако, сейчас существует очень много стороннего и полезного кода, который как минимум без C++11 уже не собирается.
Поэтому, хочешь или не хочешь, но придется переходить на более свежий компилятор.

Я уж молчу про битовые литералы

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

P.S. Забыл сказать - динамическое выделение памяти у нас на работе запрещено внутренним регламентом.

Ну, это само собой! Впрочем, к данной теме это не имеет отношения ))

[Сергей Борщ]

А нафига тут параллельная программная (соотв. медленная) шина, если вполне достаточно аппаратного SPI или чего-то подобного?

А какая вам лично разница? Ну вот понадобилась.

Самое первое, что приходит в голову - выгнать такого схемотехника. Я серьезно!

Или просто не давать советы "космического масштаба и космической же глупости"

[juvf]

Самое первое, что приходит в голову - выгнать такого схемотехника. Я серьезно!

Если у вас ПП формата А4, 8 слоёв, корпус 144 ногий, кортекс-М4, и из обвеса питание + светодиод - то конечно да, нужно трассировку сделать "удобную" для прогера.
А если у вас ПП с почтовую марку, 2 слоя (а иной раз 1), и деталюшки друг на друге, да ещё для экономии класс ПП 3..... тут не до удобств программисту. Трассировку делают, чтоб хоть как то влезло и заработало.
А бывают случаи когда все порты заняты.... остались свободные 1(bit0), 11(bit1), 12(bit2) и 5(bit3) - туда нужно шину подтянуть.

Про ногодрыг - сплошь и рядом. Даже аппаратный SPI не всегда с аппаратным CS работает, приходится ногой дрыгать. Управление RS-485 на STM32F* программное (кстати, на STM32L есть аппаратное управление уартом).
1-wire... вроде да, медленная шина, неча тут тики на ногодрыге считать, но когда процессор работает на 1МГц, то тут приходится "на спичках экономить".

Опять же.... паралельная шина для управлени ЖК экранос с знакосентезатором, даже если вы 8 бит повесите полностью на один порт, то R/W, RS, E все равно ногодрыгом.

Если нужна суперскорость, то нужно переделывать схему и плату, а не заниматься дрочевом с битовыми манипуляциями

Приходит заказчик, и говорит "Из этого куска шкуры любой может сделать шапку. А можно из этого сделать СЕМЬ шапок?". Это я к тому, что на шустром дорогом контроллере тебе школота всё что угодно слепит на занятиях радиокружка (на ПП А4 со 144 ногами). А чтоб быть конкурентным, сделай на ПП с почтовую марку на процессоре в 20 ног.

дрочевом с битовыми манипуляциями - это чей-то хлеб ))

[Forger]

дрочевом с битовыми манипуляциями - это чей-то хлеб ))

Ну, да, компилятор C++11/14 и его новые фичи тут как раз кстати, без них ведь никак
А как появится в доступе более свежий компилятор, и он тоже станет "необходим" для ногодрыга.


Конечно, согласен, много изделий, где просто никак не обойтись без ногодрыга. Более того скажу, что это - вполне типичная ситуация.
Но она реализуется в виде простейшей программной прослойки (обертки/класса и т.п.), которая закрывает (изолирует) вынужденную кривизну аппаратного решения от другого нормального кода.
А как и на чем она реализована воообще не принципиально. Такой код один раз отлаживают и успешно забывают.

Или просто не давать советы "космического масштаба и космической же глупости"

Nixon выше привел лишь гипотетические (мифические) примеры.
Или вы увидели в этих "примерах" что-то свое очень знакомое?