STM32 новичку в ARM что к чему

[arkhnchul]

a5021 писал(а):

Если бы ООП в эмбеде имело хоть какую нибудь ценность, все SDK давно были бы на нем.

это еще сильно тормозится сложностью языка по сравнению с C. Напомню, в принципе не так уж давно каждый производитель перестал считать своим священным долгом под каждое семейство контроллеров запилить свой собственный компилятор (и различной степени убогости IDE) и прибить к нему гвоздями свой уникальный SDK. Тогда как человеческих компиляторов C++ существует не так уж много - gcc, clang, icc, msvc, кого еще забыл?

ктсати, вот прям навскидку ST один из весьма активных контрибуторов mbed)

[dosikus]

Ярослав555, не занимайся вы калокубищем, знали бы что в F070 есть аппаратная поддержка модбас. А так похоже вы "велосипеды" ляпаете .
Мурик, ну мы-то знаем какие и как пахнут твои дрова на пуребарсике...

[Ярослав555]

dosikus писал(а):

Ярослав555, не занимайся вы калокубищем, знали бы что в F070 есть аппаратная поддержка модбас. А так похоже вы "велосипеды" ляпаете .

Нет там поддержки модбаса. Там есть аппаратное управление потоком для 485, и только (имеено из-за этого и был выбран даный чип для проекта). Которое я и задействовал - одной галочкой в "калокубе", но легко обойдусь и софтверным, если понадобится. Уже обсуждалось. Модбас это протокол с функциями и пачкой регистров. Покажите мне какой аппаратный блок расшифровывает адрес устройства в посылке, функцию, сам пишет в прикрепленную область памяти если все корректно. Без этого всего об аппаратной поддержке нет смысла говорить.

Добавлено after 5 minutes 41 second:

arkhnchul писал(а):

это еще сильно тормозится сложностью языка по сравнению с C.

Я как-то начал читать подаренную мне книжку Александрески о программировании на основе стратегий Наследование классов отдыхает. Пока что дальше первого раздела не осилил. Мб когда-нибудь таки в отпуск уйду и займусь этим делом.

[dosikus]

Упс, в этих действительно нет. Но это лишь говорит о неверном выборе МК .
На LCSC :
stm32f072cb - $1.7182
stm32f070cb - $2.7735

Уже обсуждалось.

Обсуждалось да не понято. Главное - вычленение пакета а не обработка его.

[Ярослав555]

dosikus писал(а):

Главное - вычленение пакета а не обработка его.

Так это не модбас, это физический уровень обмена. Модбас это протокол второго уровня. Вместо модбаса может быть любой другой - хоть профибас, хоть наш старый проприетарный. Пока МК не будет сам аппаратно разбирать пакет - он модбас не поддерживает.
У меня на плате 070CBT6 распаян.

[dosikus]

Ярослав555, вы тему поверхностно знаете?
Именно физический уровень - определение конца пакета :
RTU -по таймаут в битах , ASCII - по символу
Изучите RM на F072 , там английским по белому написано - аппаратная поддержка модбас.
И еще раз ,уже сделано и работает - захват пакета модбас RTU (uart+DMA) + аппаратный расчет CRC.
Это и есть главное , а разбор самого пакета -это мелочи...

[Ярослав555]

RS485 Driver Enable
The driver enable feature is enabled by setting bit DEM in the USART_CR3 control register.
This allows the user to activate the external transceiver control, through the DE (Driver
Enable) signal. The assertion time is the time between the activation of the DE signal and
the beginning of the START bit. It is programmed using the DEAT [4:0] bit fields in the
USART_CR1 control register. The de-assertion time is the time between the end of the last
stop bit, in a transmitted message, and the de-activation of the DE signal. It is programmed
using the DEDT [4:0] bit fields in the USART_CR1 control register. The polarity of the DE
signal can be configured using the DEP bit in the USART_CR3 control register.
In USART, the DEAT and DEDT are expressed in sample time units (1/8 or 1/16 bit duration,
depending on the oversampling rate).

Ни слова о том что как-то определяется конец пакета.

Спойлер

P.S. недосмотрел что о 072 писали, а не о 070. ОК.

Добавлено after 40 minutes 11 seconds:

dosikus писал(а):

Упс, в этих действительно нет. Но это лишь говорит о неверном выборе МК .
На LCSC :
stm32f072cb - $1.7182
stm32f070cb - $2.7735

У нас 072 раза в полтора дороже 070.
https://imrad.com.ua/ru/stm32f070cbt6
https://imrad.com.ua/ru/stm32f072cbt6

Вложения

070_USART.png

(142.24 KiB) Скачиваний: 283

[Reflector]

Ярослав555 писал(а):

У нас 072 раза в полтора дороже 070.

У китайцев $10.7 десяток, правда F072C8, но это те же самые CB.

[Мурик]

Мурик, ну мы-то знаем какие и как пахнут твои дрова

Ну мы то знаем как несет от досика, считающего своим долгом писать гадости на форуме.

[Ярослав555]

Reflector писал(а):

У китайцев $10.7 десяток, правда F072C8, но это те же самые CB.

С Китая я бы домой себе купил, я бы даже не парился и купил бы 072 здесь подороже. Это же гребаная фирма с бюрократией. Один пытается пару баксов на чипе сэкономить при цене проекта в десятки тысяч, другой будет рассказывать что с Китая мы не можем покупать, потому что так не работаем. Третий сочиняет что мы работаем только под заказ - сначала берем заказ, потом производим РАЗРАБОТКУ и производство. За пару месяцев. Представьте себе.

Добавлено after 8 minutes 24 seconds:
У меня кстати по теме вопрос есть. SPI интерфейс. CPOL задан как низкий - при простое должен быть 0. Но после инита висит как высокий. А после первого обмена уже в простое в низком уровне. В чем может быть проблема? Я подозреваю что по этому поводу у меня первый обмен идет лесом.

Добавлено after 59 minutes 10 seconds:
вышел из ситуации переключив режим в pol=1, pha=1. периферия такое понимает и баг маскируется.

[a5021]

arkhnchul писал(а):

это еще сильно тормозится сложностью языка по сравнению с C.

В ардуине не тормозится, а здесь тормозится? Какой интересный аргумент, однако.

ктсати, вот прям навскидку ST один из весьма активных контрибуторов mbed)

Не смогу похвастаться, что я хорошо знаком с mbed, но единственной библиотекой, которая мне показалось сколь нибудь полезной из всего проекта, оказалась mbedtls. Считайте, что я говорю это нарочно, но в библиотеке не оказалось ни одной строчки на C++.

А теперь об ООП-софтах, составляющих рейтинг "Most Popular Code" на сайте mbed.org:

1. Mbed / OS 2 mbed_blinky
2. mbed official / mbed
3. Blinky LED test for ST Nucleo boards
4. Output a pwm signal.
5. TextLCD library for controlling various LCD panels based on the HD44780 4-bit interface
6. mbed-os-examples / OS 5 mbed-os-example-blinky
7. ST / OS 2 Nucleo_read_analog_value
8. ST / OS 2 Nucleo_printf

По совокупности, светодиодно-мигательная тема лидирует с ошеломительным отрывом и наглядно показывает, насколько и в каких областях ценны все эти mbed-ы и кто их использует.

Добавлено after 28 minutes 37 seconds:

Ярослав555 писал(а):

Ни слова о том что как-то определяется конец пакета.

Все там определяется, начиная с F030, только документация об этом умалчивает. Если же прочесть RM0091, то открывается совершенно иная картина:

27.5.8 Modbus communication using USART

The USART offers basic support for the implementation of Modbus/RTU and Modbus/ASCII
protocols. Modbus/RTU is a half duplex, block transfer protocol. The control part of the
protocol (address recognition, block integrity control and command interpretation) must be
implemented in software.

The USART offers basic support for the end of the block detection, without software
overhead or other resources.

Modbus/RTU

In this mode, the end of one block is recognized by a “silence” (idle line) for more than 2
character times. This function is implemented through the programmable timeout function.
The timeout function and interrupt must be activated, through the RTOEN bit in the
USART_CR2 register and the RTOIE in the USART_CR1 register. The value corresponding
to a timeout of 2 character times (for example 22 x bit duration) must be programmed in the
RTO register. when the receive line is idle for this duration, after the last stop bit is received,
an interrupt is generated, informing the software that the current block reception is
completed.

Modbus/ASCII

In this mode, the end of a block is recognized by a specific (CR/LF) character sequence.
The USART manages this mechanism using the character match function.
By programming the LF ASCII code in the ADD[7:0] field and by activating the character
match interrupt (CMIE=1), the software is informed when a LF has been received and can
check the CR/LF in the DMA buffer

[Ярослав555]

Спасибо за ответ по модбасу.
В понедельник приехали новые чипы (070СВ) - поведение то же (падает на инициализации плл), думаю дело не конкретном экземпляре чипов.
Смотрите какая ситуация по тактовой частоте:
8, 16 - МК работает.
24, 32 - МК отваливается от отладчика на этапе инициализации одной из ножек порта. МК после этого перешивается из среды.
40,48 - МК отваливается на макросе включения PLL. После этого он выходит на связь только под зажатым ресетом.
Как по мне, все это намикает на проблемы с питанием. По мультику все ровно - 3.3В. Как думаете - есть смысл осцилом смотреть? Может быть такое от кривой разводки платы? Все ноги питания и земли подключены, МК обвешан блокирующей керамикой....

[dosikus]

Латентность флеша учтена? Симптомы подходящие.
У меня F0 на 64 стабильно работают...

[Reflector]

dosikus писал(а):

Латентность флеша учтена? Симптомы подходящие.

Не похоже, у него проблемы уже при 24MHz начинаются, для которых 0WS нужен, а у ST все с большим запасом указано, реально с 0 и на 36MHz работает.

[a5021]

Мож VDDA ? PLL от него питается.

[Reflector]

a5021 писал(а):

Мож VDDA ? PLL от него питается.

Может, но на VDDA и сброс завязан, без VDDA обычно не стартует, а тут при 16MHz все нормально.

[Ярослав555]

Я тоже об этом думал. Но на 24 латентность 0 и МК падает на ините жпио. На 32 латентность уже 1, и инит плл проходит успешно, падает также на жпио. Пока что оставлю на 16, а как доберусь до осцила потыкаю в питания.

Добавлено after 1 minute 37 seconds:

Reflector писал(а):

Не похоже, у него проблемы уже при 24MHz начинаются, для которых 0WS нужен, а у ST все с большим запасом указано, реально с 0 и на 36MHz работает.

Как раз таки подходит. PLL у меня запускается на 16,24 и 32. А на 40 уже нет.
До этого проблемы с инитом жпио, но возможно это два разных бага.

Добавлено after 5 minutes 44 seconds:
Я сейчас попытаюсь расписать инит плл, там куб, особо впечатлительных прошу не писать сразу, а посчитать до 100
Смотрите, инит RCC в кубе построен по такому образу - сначала идет конфиг ПЛЛ и его включение в процедуре HAL_RCC_OscConfig(&RCC_OscInitStruct) - менно иам на макросе __HAL_RCC_PLL_ENABLE(); и валится все.
А вот латентность по плану задается уже ПОСЛЕ включения PLL в процедуре HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_1)
Правильно ли я понимаю, что сначала надо ключить буфер и латентность, а уже потом включать PLL. Стоит писать реквест на форум ST?

[Reflector]

Ярослав555 писал(а):

Правильно ли я понимаю, что сначала надо ключить буфер и латентность, а уже потом включать PLL. Стоит писать реквест на форум ST?

Естественно, латентность задается до включения PLL.

[a5021]

Не сочиняйте. __HAL_RCC_PLL_ENABLE() включает PLL, но не переключает тактирование железа от PLL.

[Reflector]

a5021 писал(а):

Не сочиняйте. __HAL_RCC_PLL_ENABLE() включает PLL, но не переключает тактирование железа от PLL.

А, тогда да, без разницы.
Ярослав555, а конденсатор на NRST есть? Резистор нагрузочный там слабенький, включение PLL добавляет помех...