STM32 I2C

А это точно не в Development надо писать?

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

Хм, может электронику в отдельный раздел надо выделить...

Что я делаю не так?

Изобретаешь велосипед.

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

И вообще поглядел бы для начала на исходники HAL.

Тот же opencm3 I2C умеет весьма условно. По крайней мере тогда, когда я его тыкал. Там нормальная поддержка (точнее вроде работающий пример в репозитории) была только для серии STM32F3. HAL, насколько я помню, достаточно низкоуровневый. Та же отправка пакета по I2C это куча вызовов функций в правильной последовательности. И вообще мой велосипед мне кажется куда более удобным, чем существующие аналоги. Например, я могу написать так:

STM32::GPIOPad usart1tx(STM32::GPIOA, STM32::GPIO9, GPIOPad::Mode::ALTFN);
STM32::GPIOPad usart1rx(STM32::GPIOA, STM32::GPIO10, GPIOPad::Mode::INPUT);
STM32::GPIOPad i2c1scl(STM32::GPIOB, STM32::GPIO6, GPIOPad::Mode::ALTFN, GPIOPad::PuPdMode::NONE, GPIOPad::DriverMode::OPENDRAIN);
STM32::GPIOPad i2c1sda(STM32::GPIOB, STM32::GPIO7, GPIOPad::Mode::ALTFN, GPIOPad::PuPdMode::NONE, GPIOPad::DriverMode::OPENDRAIN);
STM32::GPIOPad led(STM32::GPIOC, STM32::GPIO13, GPIOPad::Mode::OUTPUT);

STM32::USART usart1(STM32::USART1, 64, 64, 115200);
STM32::I2C i2c1(STM32::I2C1, 400000);
STM32::USBD usb(&usbDeviceDescr, usbConfigs);

...

while (true) {
    led.toggle();
    Thread::delay(500);
}

...

usart1.printf("Counter = %i\r\n", counter);

А сам по себе HAL я смотрел. Вроде более-менее повторил алгоритм.

Хм. Если хочеца удобства, то есть ещё libmaple это аля-ардуино. Но в тулчейне для стмок на первом месте должно стоять не удобство, а возможности.

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

Если так хочешь классы, то лучше сделай обёртку HAL, но и это не особо необходимо.

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

У STM32 есть тонкости в реализации приёма/передачи блоков длиной 1 и 2 байта. Вот тут хорошая либа, где всё сделано аккуратно, и довольно подробно комментировано.

Ну ладно, удачи! Но, честно, не вижу особого смысла в этой затеи, хы.

А что с проектом? В логах вижу: 31 августа переписана вообще вся история!

warning: no common commits
From git://github.com/KivApple/controllerFramework
 + 82fdacf...521aeb7 master     -> origin/master  (forced update)
First, rewinding head to replay your work on top of it...
Applying: Initial commit
Applying: Initial commit
Using index info to reconstruct a base tree...
.git/rebase-apply/patch:67: trailing whitespace.
PROJECT_NUMBER         = 
.git/rebase-apply/patch:73: trailing whitespace.
PROJECT_BRIEF          = 
.git/rebase-apply/patch:80: trailing whitespace.
PROJECT_LOGO           = 
.git/rebase-apply/patch:191: trailing whitespace.
STRIP_FROM_PATH        = 
.git/rebase-apply/patch:200: trailing whitespace.
STRIP_FROM_INC_PATH    = 
warning: squelched 186 whitespace errors
warning: 191 lines add whitespace errors.
Falling back to patching base and 3-way merge...
Auto-merging .gitignore
CONFLICT (add/add): Merge conflict in .gitignore
error: Failed to merge in the changes.
Patch failed at 0002 Initial commit
The copy of the patch that failed is found in: .git/rebase-apply/patch

When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase --abort".

А теперь https://github.com/KivApple/ControllerFramework удалён.

Понял, что сделал всё криво и косо и разочаровался в проекте. В настоящий момент продумываю более адекватную структуру.

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

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

Сейчас я работаю над новой реализацией.

Во-первых, там будет модифицированный C вместо C++ (который должен транслироваться в валидный plain C и быть совместимым с sdcc, arm-none-eabi-gcc и т. д.). Он будет поддерживать классы (без множественного наследования) и асинхронное программирование (при этом обычная функция будет прозрачно разворачиваться в машину состояний).

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