Easyelectronics.ru

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

коротко по составу:
smcom - библиотека позволяющая описать железо
smlets - библиотека мессенджинга
smhw - мои конкретные проекты под конкретные платы для примера

smcom сама по себе тоже из двух частей
platform - содержит драйвера под специфичное железо. более менее поддерживаются сейчас stm8s и stm32 F0
наработки по avr тож есть, но семантика файлов не соответствует текущему рефакторингу библиотеки (TODO)

остальные файлы в smcom - надстройки для железа отвязанные от конкретного железа либо для (hwdrv) для какой то внешней переферии
в моих проектах реализована такая уонцепция:
- сначала описывается класс hw-proto.hpp под свое железо используя smcom
- затем описывается application appl-proto.hpp
- после чего пишется main в котором складываются в конечную программу библиотечный node (сейчас работает node-uart.hpp) + hardware + application.
свой такой доморощенный rtos под узкие задачи

из последнего что реализовано - простой мессенжинг с json сообщениями через uart и связкой этих сообщений с MQTT через стандартную прошивку tasmota для esp8266

репозиторий https://github.com/axillent/smletslib

для затравки как обычно blink

stm8s103f3

на D2 светодиод между землей и выходом, режим pushpull
на D3 светодиод между VCC и выходом, режим инверсный (программно)
timer1 взведен на 1 Гц
первый светодиод будет мигать с частотой 1 ГЦ
второй с частотой 1/5 ГЦ
первый аргумент при вызове Run - число морганий. 255 - бесконечность
я эти Blink использую для всяких сигнальных светодиодов.

Прям как по заказу SELEVO топик, на две очень разные платформы (в смысле AVR и STM). Не бывает таких оптимальных, вы будете проигрывать в обоих из-за разницы архитектур. Соберете (каким образом на разных архитектурах) наиболее оптимальные алгоритмы? Так они разные. О общем задумка хорошая, с оптимальной реализацией возможны трудности.

теперь меняем три первые строки и номера портов
получаем blink под stm32f030f4

ктож спорит
универсальность это всегда компромисс
в жертву идет сложный функционал который на бывает кросс-платформенный
тем не менее
на ардуино мне было скучно писать
а на всяких SPL/HAL - грустно
пишу так

во всех проектах для подключения либы достаточно прописать путь для include
для stm32 кроме того нужно добавить в проект startup файл, он стандартный, копия лежит в либе

компиляторы IAR для stm8, stm32 (nuvoton 8051)
и g++ (atmel studio) для avr

Мда, блинк для AVR займет пять строчек (максимум, на некоторых сериях две строчки) ассемблерного кода. Для чего эта портянка?

тоже самое - для тех кому на ардуино скучно, а на ассемблере грустно
blink лишь иллюстрация (это надо объяснять?)
сами по себе они ни кому не нужны, даже на ассемблере

почему? строим кодогенератор и вперёд

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

теперь собственно по проекту.
json?? серьёзно? пусть даже и tiny.
json - это иллюзия универсальности, приводящая в ад.

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

у исходников проблемма с кодировкой. win1251? серёзно? комменарии на русском языке? для кого?
MQTT ?? а это то каким боком и для чего?

в чем его многоплатформенность?


??? для чего, пострайтесь избегать этого.
есть же Enum Classes

откровенно не понимаю целеполагания проекта
если только как набить руку - то ок.

а если задача побыстрому решить проблемму то бери упомянутый protobuffer хочется реальной эффективности, удобства и так чтобы работало даже на STM8 - то тут только AdHoc protocol

PS и не стоить пытаться объять необъятное.

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

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

Из-за разницы архитектур, т.е отличающихся систем машинных команд конкретная реализация алгоритмов (программных решений) на них неизбежно будет отличаться. Первое что пришло на ум - BCD преобразование, где-то около 7 разновидностей. Наиболее оптимальная реализация должна учитывать особенности конкретной архитектуры, например на AVR и MCS-51 оптимальны разные алгоритмы.

прежде чем заниматься подобными "оптимизациями" нужно убедиться в том, что это того стоит.

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

эта дискуссия у нас уже была.


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

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

Я там что-то увидел про nuvoton :)

Возьмем, для примера, F072С8. Там куча таймеров, четыре USART-а, по два SPI/I2C, USB, CAN, ADC, DAC, RTC, CEC, компараторы... В либе из этого всего поддерживается только ADC, USART1 и таймеры, кроме самого полезного 32-х битного TIM2. Причем даже этот USART1 нормально не работает из-за классического бага в классе FIFO.

это старая тема автора не знаю почему он ссылку сам не дал

Расскажите про баг
Отладил со своим кодом много устройств, на баг не наткнулся
Поддержку чего либо пишу по мере использования в каком либо проекте, то что перечисленно я нигде не использовал
Колабарация приветствуется

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

Мало общего осталось, поэтому и не давал ссылку

Допустим во входном буфере один байт, чтобы его забрать вызываем Pop(), внутри есть строка:

Значение data.n загружается в регистр, если в этот момент произойдет прерывание в котором в буфер добавится новый байт, то data.n станет равным 2, но после возврата туда запишется 0, таким образом новые данные потерялись.

какое решение?

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

атомарно это с отключением прерываний?

Да, на F0 только отключение прерываний.