Comments 23
К тому же сомнительно, чтобы RC-генератор мог в тепличных условиях уйти настолько, чтобы появились битовые ошибки в UART. Да и в «боевых» условиях тоже.
Если ошибки происходят уже «на столе», значит в консерватории точно что-то не в порядке.Я это тоже понимаю, поэтому и пытался разобраться в периодически возникающей проблеме, вместо того, чтобы махнуть рукой и сказать «и так сойдет».
А битовые ошибки иногда могу возникать при высокой скорости работы UART. А уж «в боевых» условиях от различных электромагнитных помех при коммутации силовых цепей — и подавно.
На дешёвых платах с STM32F401CCU6 от WeAct, где установлен кварц на 25 МГц, регулярно наблюдалась проблема с нерабочим DFU — по симптомам похоже, что частота HSI отклонялась от паспортного значения 8 МГц настолько, что при попытке определения частоты внешнего кварца (для которого встроенная реализация DFU поддерживает автоопределение в диапазоне от 4 до 26 МГц с шагом 1 МГц) эта частота определялась неправильно — как 24 или 26 МГц (для чего достаточно отклонения частоты HSI примерно на 2%). В последних версиях документа AN2606 “STM32 microcontroller system memory boot mode” по этому поводу даже появилось примечание о том, что для надёжной работы DFU желательно использовать кварц с более низкой частотой (например, 8 МГц) — в этом случае ошибочное определение частоты произойдёт при заметно более значительном отклонении частоты HSI (более 6%), вероятность чего значительно меньше.
Зачем использовать такой странный кварц — 11.0592 МГц?Чтобы при установке стандартных скоростей (115200, 9600 и т.д.), получать их целочисленным делением.
Делится PCLK2 или PCLK1, в зависимости от канала UART.
Например первый попавшийся даташит для STM32F1**
Only USART1 is clocked with PCLK2 (72 MHz max). Other USARTs are clocked with
PCLK1 (36 MHz max).
72 MHz дает нулевую погрешность на 115200 и более низких скоростях.
Ну или первый попавшийся даташит по STM32F4**
Only USART1 and USART6 are clocked with PCLK2. Other USARTs are clocked with PCLK1. Refer to the device datasheets for the maximum values for PCLK1 and PCLK2
У тебя на скриншоте PCLK2 70.77888, что дает большую погрешность.
А вообще вам скорее всего повезло с отсутствием проблем или же в прошивке был что-то ещё. Обычно на производстве конечного устройства производится калибровка встроенных кварцев по одному стабильному внешнему, и это значение загружается куда-то в регистры при старте устройства. Дополнительно можно, а иногда и необходимо, реализовать адаптивную перекалибровку в процессе работы устройства, например — раз в несколько минут, при больших и частых отклонениях температуры.
Зачем использовать такой странный кварц — 11.0592 МГц?
возможно рядом стоит какой-то потребитель конкретно этой частоты или её производных.
у нас например стоит 12.288 МГц, потому что где-то рядом от нее тактируется блок АЦП (2.048 МГц).
Данный генератор проходит калибровку на заводе и производитель гарантирует точность в 1% при температуре 25 градусов Цельсияи этого должно хватать, возможно у Вас мало стоп-битов?
А потом, это же нужно будет делать для каждого устройства и для каждой серии микроконтроллера!
Если использовать все возможности, то кубик вам не поможет, там этого просто нет.
А если использовать Middleware, то параметров для настройки будет еще больше.
Вот с I2C реально засада. Одно время времени не хватало на разобраться с расчетом TIMING регистра, пользовался кубиком для расчета этого числа. Пока анализатором не увидел что на шине вместо 400кГц внезапно 330 кГц. Акселерометр оказался не привередливым, работал нормально. При разборе полетов, оказалось все просто: кубик знать не знает про емкость шины на плате, да и номиналы резисторов в расчете не участвуют. При ручном расчете, это можно скомпенсировать и получить правильную диаграмму.
Так что даже для настройки периферии, пользовать кубик ну такое себе удовольствие. Опять же, неужели когда новое устройство делают, то старый код обнуляют и пишут все с чистого листа? Да после первого ж проекта появляется более\менее приличный набор сниппетов кода, который гуляет потом по проектам.
В одном проекте светодиод и входная цепь были на одном пине. Так её для опроса приходилось каждый раз переконфигурировать на вход, проверять нажатие кнопки, и опять устанавливать как выход.
А с I2C вообще беда. Периодически пропадала связь не понятно почему. В результате нашел в errate про этот косяк, который так же приходится обходить вручную. (2.13.7 I2C analog filter may provide wrong value, locking BUSY. STM32F10xx8 STM32F10xxB Errata sheet)
Пока анализатором не увидел что на шине вместо 400кГц внезапно 330 кГц. Акселерометр оказался не привередливым, работал нормально. При разборе полетов, оказалось все просто: кубик знать не знает про емкость шины на плате, да и номиналы резисторов в расчете не участвуют.
Эээ… А как емкость шины и номиналы резисторов могут повлиять на частоту тактирования?
Не спроста же для скоростей выше 400к обычно используется токовый драйвер для быстрого фронта. у того же stm на борту 25мА источник есть для режима F+ (до 1МГц), правда не понятно как его запустить то корректно.
По поводу микроконтроллеров — была история с дорогущим ноутбуком для программирования siemens symantec, у которого был встроенный контроллер для закачки программы в микроконтроллер через COM порт. Который сгорел, когда его подключали, не выключив питание. Потому что в 99 случаях это делать можно без последствий, но в 1 случае из 100 устройства бывают подключены к разным розеткам с разными фазами. И привет.
История одной ошибки