Jump to content

    
Sign in to follow this  
Tarbal

Легкий старт для STM32 проекта

Recommended Posts

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

 

Апликация STM32Cube и лабораторные работы с инструкциями как пользоваться.

https://www.dropbox.com/sh/eqim95c9s2sspqn/...8vSdRW4P3a?dl=0

 

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

 

Из платных поддерживаются:

EWARM

MDK-ARM V4

MDK-ARM V5

TrueStudio

Share this post


Link to post
Share on other sites
За час можно склепать простой проект, а потом использовать сгенерированный код для развития проекта.

 

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

Share this post


Link to post
Share on other sites
Этого ни кто не знает, так глубоко там все упрятано - лучше 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 нереально.

Share this post


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

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

Share this post


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

 

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

Share this post


Link to post
Share on other sites

А я опять повторю, что не видел еще ни одного МК со стабильным аппаратным I2C. :)

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

Share this post


Link to post
Share on other sites
пригоден софтовый вариант- работает годами и не зависает и еррат не имеет. Еще софтовый вариант хорош тем, что к ногам не привязан, на любых двух удобных(свободных) пинах может быть сделан.

 

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

 

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

 

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

 

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

Share this post


Link to post
Share on other sites
Так как раз это обсуждаем - поставьте там ещё камень и общайтесь по uart

 

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this