Вот программы для семинара ST.

Апликация STM32Cube и лабораторные работы с инструкциями как пользоваться.
https://www.dropbox.com/sh/eqim95c9s2sspqn/...8vSdRW4P3a?dl=0

За час можно склепать простой проект, а потом использовать сгенерированный код для развития проекта. Лицензию на IAR IDE дадут на короткое время, но если выбрат' при генерации проекта toolchain SW4STM32, то можно обойтись бесплатными инструментами.

Из платных поддерживаются:
EWARM
MDK-ARM V4
MDK-ARM V5
TrueStudio

Видео инструкции:

https://www.youtube.com/watch?v=PqsgSVbgfBs

под кокос видео сделайте, pls

Это не мое видео Сам только начал. Изучаю и делюсь.

За полдня удалось поднять "фундамент" для простенького проекта на STM32F103C8T6, но потом все наглухо уперлось в нестабильную работу I2C1... То работает, то глухо HAL (polling mode) подвисает на 10 секунд при любой операции с шиной и вываливает потом ошибку HAL_TIMEOUT. На шине пока всего один EEPROM.. Вот и в раздумьях я, а оно вообще у Cube работоспособно?

Этого ни кто не знает, так глубоко там все упрятано - лучше spl
Кстати i2c у 103, говорят, не работает

Почитал Errata... Похоже нашел "мой" случай. "Порадовался"...

2.13.7 I2C analog filter may provide wrong value, locking BUSY flag and preventing master mode entry

Description
The I2C analog filters embedded in the I2C I/Os may be tied to low level, whereas SCL and SDA lines are kept at high level. This can occur after an MCU power-on reset, or during ESD stress. Consequently, the I2C BUSY flag is set, and the I2C cannot enter master mode (START condition cannot be sent). The I2C BUSY flag cannot be cleared by the SWRST control bit, nor by a peripheral or a system reset. BUSY bit is cleared under reset, but it is set high again as soon as the reset is released, because the analog filter output is still at low level. This issue occurs randomly.

Воркараунд предложен но какой то сильно заморочанный.

А насчет отказа от I2c - сложновато это. В планах были на шине EEPROM для калибровок, плюс 16-битный ADC и пара экстендеров вынесенных на другую плату с ВЧ делами. Тянуть туда SPI нереально.

Так как раз это обсуждаем - поставьте там ещё камень и общайтесь по uart

Я довольно долго бился с их примером HAL I2C. В итоге всё стало работать стабильно после понижения частоты до 80 кГц. Кроме того, читаю и пишу кусками не менее 4 байт. Не разобрался, почему при меньших кусках возникают упомянутые Вами подвисания .

Это видимо не тот случай (еще один баг, другой). У меня при некоторых включениях I2C вообще не запускается. Вываливается в постоянное ожидание флага готовности I2C при первом же обращении к функциям HAL. Но если запустился - работает.

А я опять повторю, что не видел еще ни одного МК со стабильным аппаратным I2C.
Для редкой и медленной работы (при включении чего прочитать-записать или еще когда), пригоден софтовый вариант- работает годами и не зависает и еррат не имеет. Еще софтовый вариант хорош тем, что к ногам не привязан, на любых двух удобных(свободных) пинах может быть сделан.

Я думаю, речь шла не об SPI, а об SPL

А они ещё и дма обещают - вообще не понимаю как

Полностью согласен, софтовый имеет больше приимуществ, заметил это еще с аврок, где код инициализации и приема-передачи аппаратного был больше, чем мой, софтовый

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



Только в случае линейной передачи с автоинкрементом.

Там уже ничего не поставить. Этот ВЧ модуль уже существует и кроме I2C вариантов нет. Сейчас думаю что правильнее - забить на STM32 и поставить "обкатанный" LPC1758 или все же сделать bit banging... Первое очень избыточно. Второе как то расточительно в смысле времени процессора.

поставьте здесь, хоть мегу в ногодрыге

Стесняюсь спросить - резисторы подтягивающие на линиях есть?

Не первый день замужем.
Логический анализатор (Zeroplus LAP-C) подцеплен к шине - нет никаких глитчей при рестарте, стабильно в единице и SCL и SDA. Посмотрел осциллографом уровень (думал просаживает что то) - нет, 3.3 вольта есть, как положено.

Было бы так - не стали бы с кубами водиться

Обращаюсь ко всем, у кого не работает аппаратный I2C. Вы прочитали руководство, документацию по ошибкам, настроили все регистры, и - не работает?? Шайтан помешал?

Ардуринщики мануалы не читают. Они "скетчи" в интернете ищут.
О каком руководстве можно спрашивать в теме о всякой гадости вроде HAL/SPL/Qube?

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

Надо признать, что пока если что и приведет к фиаско, то не куб, а банальная глючность конкретного камня. К чести ST расписанная в errata (до чтения которой дошло только после того как грабли сделали свое черное дело).

Ну, это у Вас еще везуха сплошная, если уже что-то спроектировано-смонтировано и как-то работает, а в еррату еще и не заглядывали.
Я обычно еррату читаю раньше чем основную документацию, на этапе выбора МК под задачу. Бывает, ее чтение переворачивает все с ног на голову.

Куб хорош для понимания, в чем накосячил при написании собственной работы с периферией.

Я, к примеру, долго не понимал, почему у меня не работает SPI - не принимает данные и все тут. В кубе работает, а в моем проекте - нет.
Оказалось, SCK обязательно должен быть выведен на ногу. Хоть мне он и не нужен (эмуляция 1-wire).

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

Так тут особый случай. Поделка штучная, под рукой был модуль китайский, хорошо встающий в макетку - и решил посмотреть, как оно пойдет, если к вопросу подойти "с другой стороны".

Если честно - то это вообще первый в жизни STM32 с которым я связался. До этого были игрища с NXP/Freescale/TI а до серии из 32-битников доходили только NXP.

куб убивает spl , а кубовские исходники никто не выкладывает, ибо и так никому не нужны

LPC1758/LPC1778/LPC1788/OMAP-L137/....

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

Присоединюсь... На 1758 и 1768 тысячи изделий "в поле", I2C используется интенсивно (расширители и I2C слейвы на базе пиков 16-х) - проблем нет. Правда там и не кубоподобное на низком уровне, а честно выстраданное бессонными ночами.

PS: Упоминавшийся на прошлой странице воркараунд из STшной Errata помог. Ровно на 2 минуты помог. Крутилось в цикле тупо вычитывая здоровый кусок EEPROM в буфер, и встало опять, в то же состояние с 10-сек таймаутом и возвратом с кодом HAL_BUSY.

Изучая сякие SPL и HAL к сабжу, и собственно, сабжи, пришел к выводу, что использовать из них можно только заголовочники (.h). И то с наятгом.
Так как никакой универсальности в плане работы с периферией они не несут. Так, к примеру, у 32F1 и 32F0 разная по возможностям периферия.
Тот же USART, SPI. И, написав код под F0, на F1 его запустить уже не получится. И HALы с КУБами никак не помогут.

удивил OMAP: вообще в еррате нет упоминания I2C. Или это чудо или пациента просто еще недообследовали (ревизия документа-2011 год)
для LPC - упомянута только одна ошибка в реализации I2C, вроде бы обходится без особых танцев с бубном, так что тоже годится.
спасибо, буду знать.

И там будут свои метаглюки. Независимые ни от чего

Гиперкуб

Я этот куб даже обновить нормально не могу. Лучше новую версию скачать и переустановить.

метакуб круче, чем гипер, ибо абстрагирует все от всего

Может и недообследовали, но у меня на OMAP на I2C висит FRAM, в которую непрерывно пишутся логи работы, так что обмен довольно интенсивный и никаких проблем в его работе я не заметил.
Для LPC еррату не смотрел, так как на баги вроде не наступал (хотя может и наступил, но не понял что это баг). В любом случае на LPC1758 и LPC1788 у нас тоже наверное уже тысячи устройств у заказчиков работают в режиме 24часа и если-б там были проблемы, мне бы уже плешь насквозь проели . :-)

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

I2C у STM32F103C8 я для себя списал в утиль по результатам. Условно считаем что его нет, потому как бубна в комплекте с чипом не дают, а свой приносить для камлания вокруг их I2C модуля - много чести. SPI работает вроде устойчиво с кубовским драйвером. Поделка ради которой я решил попробовать STM32 и куб уже задышала на LPC1758. Но я слегка "подточил" свои библиотечки для LPC чтобы приблизить форматы передачи параметров к кубовским и без больших правок использовать код который накропал за время игрищ с кубом, вреда от этого никакого а польза когда то может быть.

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

Точно!!!!!

Это программная эмуляция имеющейся в МК периферии - убогая идея. Ногодрыг - это тяжёлое наследие АВР и иже с ними.
400кГц (обычная частота для I2C) даст 800кГц прерываний! Это угробит производительность даже самого жирного МК на бессмысленное дёрганье ножками.
А ведь бывает нужно на несколько разных интерфейсов I2C повесить устройства. Вот тут и появляются чудо-проекты, когда МК с несколько сот МГц тактовой едва хватает для опроса пары датчиков.
Видно все Ваши задачи заключаются в моргании несколькими лампочками, тогда да - чем ещё загружать CPU?

именно для этого и нужен десяток ядер в каждом камне

Точно! Даёшь каждому I2C-девайсу по ядру!

Очень часто нужно изредка что-то там поделать с I2C. Подождать 20 мкс - не проблема.
А если интенсивный обмен, то прерывание на каждый байт - тоже не сахар.

Никогда не использовал прерывания для i2c. По-моему это бред полный, ибо интерфейс синхронизируемый самим контроллером, можно делать обычные delay().

ЗЫ. Это я про мастер режим, разумеется, слейв - тут только аппаратный блок, придется изучать все ераты и пр.. К счастью, пока нужды в нем не было

и автоматом решается вопрос с маппингом и ерратами
10 уартов или 10 езернетов - пожалуйста

Обычные delay() допустимы только для однозадачной среды, в многозадачной среде они убъют все задачи приоритетом ниже той, в которой работает такой драйвер.
В нормально реализованном драйвере, работающем с аппаратной периферией, как раз наоборот - обмен по интерфейсам (с использованием прерываний и DMA) освобождает процессор для менее приоритетных задач
(в которых кстати тоже может идти обмен по другому интерфейсу, времянки которого не будут сбиваться более приоритетными задачами).
Опять приходим к тому, что в более-менее сложном ПО будет скорей всего многозадачная среда, а однозадачная среда - что-то простое типа моргания лампочками.

В многозадачной среде есть необычные delay(), которые в момент отдыха данной задачи отдают управление менее приоритетной задаче.

I2C не сильно-то нагруженный интерфейс, чаще всего, пару байт переслать раз в минуту/час. Это не SPI/I2S/Ethernet/CAN, которые чаще всего загружены "по полной".

Такие delay задают задержку в количестве тактов таймера планировщика задач, который имеет частоты обычно не более единиц кГц. I2C на такой задержке будет ну очень медленный.

У меня задачи переключаются с частотой 10000 раз в сек - это вполне нормальная скорость. I2C не для передачи изображений же используется

А Вы откуда знаете?
Мы в некоторых изделиях используем матричные ЖКИ висящие на I2C. А также FRAM-память на I2C размером в 32кБ.
В других изделиях есть ADE78xx работающая по I2C непрерывным потоком на макс. скорости.
Если Вы думаете, что I2C используется только для передачи пары байт и никаких других применений нет, то зачем в новых МК ввели I2C с SCL до 1МГц?

PS: Имхо - тактировать шедулер 10кГц можно конечно, но по-моему многовато - много накладных расходов на переключение задач. У меня обычно максимум 1кГц или меньше.