vlad_new

Вы сначала выясните сколько ESP32 вообще реально потребляет в спящем режиме, а потом наноамперы вычислять будите. Вот у моего друга ничего не вышло с батарейкой на ESP32. Слишком много кушает когда спит. В результате что то там сделал на обычной ESP с батарейкой. Даже что то там по WiFi передаёт раз в минуту или 10 минут ( не помню ). На счёт энкодоров, то тут то же засада. Вон у меня куча их валяется новых и уже не работают ( застыла смазка, почернели контакты и т.д.). Оптика нужна, но она кушать будет. Так что с батарейкой надо как то дёргать им питание. Да даже обычные энкодоры, пока им 10кОм и 0,1мкФ не поставишь, нормально работать не будут. Про оксидную плёнку что нибудь слышали? Вот ваши наноамперы сразу выльются в мА.

Ищите где Вы забыли volatile объявить глобальные переменные. Именно при включении оптимизации оно и выстреливает.

Потому что у него на этой скорости "ERROR" выдаёт. Остаётся питание. Попробуйте поставить конденсатор микрофарад на 1000-4700. Иногда помогает, особенно кто пытается запитаться по USB от ноута. Ещё нужно убедится, что в конце у вас 0x0D0A передаётся. Попробуйте только 0x0D передать. Если покупали на алиэкспрес, то вероятность брака почти 100%.

Судя по таблице, в группе из 4 бит, NVIC_IRQChannelSubPriority должен быть равен 0. The table below gives the allowed values of the pre-emption priority and subpriority according to the Priority Grouping configuration performed by NVIC_PriorityGroupConfig function ============================================================================================================================ NVIC_PriorityGroup | NVIC_IRQChannelPreemptionPriority | NVIC_IRQChannelSubPriority | Description ============================================================================================================================ NVIC_PriorityGroup_0 | 0 | 0-15 | 0 bits for pre-emption priority | | | 4 bits for subpriority ---------------------------------------------------------------------------------------------------------------------------- NVIC_PriorityGroup_1 | 0-1 | 0-7 | 1 bits for pre-emption priority | | | 3 bits for subpriority ---------------------------------------------------------------------------------------------------------------------------- NVIC_PriorityGroup_2 | 0-3 | 0-3 | 2 bits for pre-emption priority | | | 2 bits for subpriority ---------------------------------------------------------------------------------------------------------------------------- NVIC_PriorityGroup_3 | 0-7 | 0-1 | 3 bits for pre-emption priority | | | 1 bits for subpriority ---------------------------------------------------------------------------------------------------------------------------- NVIC_PriorityGroup_4 | 0-15 | 0 | 4 bits for pre-emption priority | | | 0 bits for subpriority ============================================================================================================================

Ну во первых флаг LBD - это не обязательно LIN. Например я его использую как флаг начала пакета. Во вторых странно, что у вас не выставляется флаг FE. Хотя он не на что и не влияет. В третьих флаг OVR заслуживает отдельного внимания, поскольку ( как я понял в некоторых камнях ) он блокирует дальнейший приём. В мэнуале как то странно написано, что сбросить его можно чтением приемника ??? и/или ??? чтением регистра SR (вроде). Поэтому при приёме байта сначала вычитываем RX и SR в каие нибудь переменные, а потом уже занимаемся всем остальным. Правда во время обработки приема байта, флаг OVR опять может установиться ( от разного там дребезга в контактах ). Ситуация редкая, но я уже с этим сталкивался (приёмник просто намертво виснет, хотя казалось бы, что ранее флаг OVR был сброшен). Вообщем написав уже с не один десяток разных обработчиков пакетов, везде вылезало что то своё и до всего приходилось докапываться самому.

От кого шифруемся? http://www.break-ic.com :)

Смотрим еррату! Option byte loading can fail if MSI frequency is greater than 8 MHz Description The option byte loading operation can fail if the MSI clock is ON with a frequency equal or greater than 8 MHz before performing an option byte loading by setting OBL_LAUNCH bit in the FLASH _CR register. Some options and engineering bytes values can be corrupted. Workaround If MSI is ON at a frequency equal or higher than 8MHz, It is mandatory to reduce MSI frequency to 4 MHz or less before launching the Option Byte loading operation by setting the OBL_LAUNCH bit in the FLASH_CR register. Ну и т.д. :)

А разве не надо сбрасывать флаг в любой ситуации. Иначе есть вероятность, что Вы при выходе из прерывания снова в него будете влетать до бесконечности. Не знаю что там библиотеках индюшка понаписал, но я это делаю просто вот так: EXTI->PR|=(1<<12); // clear pending interrupt PA12 __ISB(); ...

SWD.

Ну собственно вот. Можно и самодельный и штатный JLINK доработать самому. 2 мГц тянет. Ещё есть вариант купить штатный STLINK IsoI ( он с опторазвязкой ) и воспользоваться утилитой с сайта сиджера, которая перепрошивает его в JLINK. У меня есть такой. Всё норм работает. Правда не знаю работает ли при этом полный JTAG. Ну если надо могу проверить.

Вот вычитал, что в STM32F412xxx штатный загрузчик может грузить по CAN2 , PB5, PB13. Для всех типов корпусов. ( п. 3.16 Boot modes ).

Для начала запустите STM32-STLINK utility. Он должен увидеть ваш stm. А уже потом переходите к кейлу. Убедитесь, что в кейле в debug -> utility установлен ваш Jlink и внутри выбран нужный тип роцесора из таблицы.

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

Как уже было замечено ранее, всё дело в последовательности. Там вы работаете не напрямую с физическими регистрами, а с теневыми. Сейчас уже точно не помню, но вроде реальные данные, переписываются из теневых регистров только после записи секунд в них. С чтением проблем вроде не было. Но и там то же читать надо 2 раза, что бы не напороться на секундный переход. Причем при использовании библиотек, убедитесь, что там верная последовательность (ошибок в библиотеках хватает). Читаем в такой последовательности: RTC_GetTime(RTC_Format_BCD, &RTC_TimeStructure); // Get the current Time RTC_GetDate(RTC_Format_BCD, &RTC_DateStructure); // Get the current Date Пишем в такой: PWR_BackupAccessCmd(ENABLE); // BKP ENABLE RTC_SetDate(RTC_Format_BCD, &RTC_DateStructure); // Init Date RTC_SetTime(RTC_Format_BCD, &RTC_TimeStructure); // Init Time PWR_BackupAccessCmd(DISABLE); // BKP DISABLE Или я не уловил суть вопроса?

На счет подвисания. Все они виснут. Вопрос при каких условиях это происходит. На счет ланки, могу сказать, что в домашних условиях, она редко виснет. У меня она работает уже лет 5. Но она очень помехо не защищенная. Если рядом с ethernet кабелем создать даже небольшую помеху, то она сразу перестает работать. В 90% помогает обычный импульс сброса на её лапку. типа: if(read_PHY(0)==0), то сбрасываем её. К стате, зависнуть может даже от включения холодильника ( если проводка в доме неважная). В промышленных вариантах использую DP83848. Она на порядок более помехо защищенная. Вот как то так.

При смене камня, часто меняется и размер стека.

в ф4, да и во всех других стм-ах есть би директ режим в уартах. я пользую этот режим. прекрасно работает по 1 проводу. Если надо именно ок. то тут уже всё что нужно было сказано.

Я не раз нарывался на проблеммы с оптимизатором в кейле. много всего было всего не упомниш. вот один пример: есть массив глобальный волятивный. Делаем какие то действия с массивом. После этого разрешаем прерывание и ждём флага окончания изменения данных в массиве. Так вот 1 элемент массива с оптимизатором не менялся. Почему то кейл заганял его в регистр и после обновления массива в прерывании, 1 элемент брал из этого же регистра. это было в версии 4.2 В версии 4.5 уже это было исправлено. Так же попадались примерчики кейловские, например с USB, которые работали только без оптимизатора. Так что смотрите ассемблер и поймёте что не так.

С незаземлённым компом и не развязанным осциллографом всегда будут проьлеммы. ещё и камни дознуть периодически будут. Выхода 2. Заземлить всё хотя бы на батарею отопления если нету нормальной земли. 2 вариант отвязать проэкт от всего этого безобразия. Я сделал себе опторазвязку на программатор и запитал осциллограф через трансформатор. Все стало прекрасно. Конечно 1 способ правильней, но мне по работе, приходится работать в разных местах и часто земли просто нет. К стате ткнитесь осциллографом куда нибудь на плату и постучите пинцетиком по земле этой платы и вы увидите выбросы под 100 вольт :)

Ну на счет "все" - это смотря что надо. Лично мне нужны были ещё nlocalm[], lhost_name[], own_hw_adr[]. А так же мне пришлось подправить файл конфигурации Net_Config.c, поскольку там некоторые переменные были объявлены как константы, а мне их надо было менять. К примеру мне нужна была индикация наличия соединения по DHCP. Долго пришлось ковыряться. В результате получилась такая ф-ция: void dhcp_check(void){ if((*(unsigned int)&localm)!=0) LED_DHCP_ON; } Поскольку библиотека постоянно меняется от версии к версии, то и варианты её использования то же могут отличатся. Я пользую 4.73 и как там в 5.xx не знаю.

стек увеличивай. с 200 байтами работать не будет. хотя бы 2 кило отведиди.

уже известно: STM32F756 :)

Сталкивался с подобным. Помогло отключение, щас точно не помню, какого то буфера в камне. Вроде бы префеч ( ну или как его там ).

У меня то же не вышло работать с обоими флагами. Использую только флаг приема, поскольку он то же выставляется после передачи байта.

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