Вот программы для семинара 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, говорят, не работает

Сообщение отредактировал Огурцов - Dec 28 2015, 13:15

Почитал 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... Первое очень избыточно. Второе как то расточительно в смысле времени процессора.