Hunveibin

Извините, непонятно написал. Я имею ввиду - попробуйте в обработчиках прерывания сделать так: HAL_CAN_GetRxMessage(&hcan1, CAN_RX_FIFO0, &RxHeader, RxData); while(HAL_CAN_GetTxMailboxesFreeLevel(&hcan2) == 0); HAL_CAN_AddTxMessage(&hcan2, &RxHeader,RxData,&TxMailbox); Иначе говоря, сначала копируете принятое сообщение в буфер, и потом проверяете в цикле, можно ли отправить сообщение. И когда освободится хоть один мейлбокс, отправляете. Согласитесь, разница по сравнению с первоначальным вариантом есть. Ну и учитывайте, что в общем случае делать такие проверки в обработчиках прерывания - не самая лучшая идея. По первому пункту возражений почти не имею: что-то можно было бы и оптимизировать или даже убрать. Но все же явных косяков не замечал (по сравнению с более ранними версиями). Что касается того, что в холовских функциях вставлено много на первый взгляд лишнего - да, такое тоже есть. Пример этому те же функции работы с интерфейсами через ПДП - куча проверок "включено ли" и "если не включено, включить". С другой стороны, учитывая скорость даже простеньких СТМок, это в большинстве случаев не так критично. Выгода же очевидна - вместо разработки своих библиотек или использования самоделок от неизвестных самоделкиных, конечный пользователь имеет готовое решение от производителя с поддержкой, обновлениями и исправлениями ошибок. Критика в данном случае должна была бы сопровождаться все же и помощью, уж коли Вы хорошо разбираетесь в этой теме. А то так получается как-то не очень красиво. Кроме всего, как такая ситуация - человек жалуется, что у него не работает схема на ОУ. А ему в ответ - рассуждения на тему, как обленились и отупели молодые разработчики. Не могут собрать схему из транзисторов!

Можно предположить, что проблема может быть в функции HAL_CAN_AddTxMessage Точнее, МК просто не успевает отправить сообщения. Попробуйте функцию HAL_CAN_GetTxMailboxesFreeLevel

Ну, он ее удерживать и не будет - плата будет крепится к элементу корпуса. С целью "разгрузки" соединителя можно дополнительно приклеить участок шлейфа каким компаундом - но это крайний случай. Была также идея отказаться от соединителя вообще и паять шлейф на контактные площадки, но посчитали, что это будет не лучшим решением. Ну, задача и стоит как раз подобрать толщину платки под имеющиеся в продаже соединители. Может быть, лучшим будет решение "0,15 на плату - 0,15 на stiffener", т.е. тогда он будет уже играть и некоторую "усиливающую" роль. Впрочем, данных по его механическим свойствам вроде того же предела прочности на растяжение не видел. Под удержанием платы я понимаю то, что соединитель обожмет ее край с выводами так, что она будет в нем держаться. Но не вывалится (если толщина слишком мала) или зажим будет невозможен (когда толщина будет больше допустимой). Что касается механических воздействий, то там есть свои особенности. На плате будет размещен датчик температуры и акселерометр, сама плата будет (как предполагается) крепиться на измеряемом объекте при помощи винтов или клей. Поэтому стоит вопрос еще и как "разгрузить" шлейф от колебаний.

Не совсем понятно - CAN вообще не работает или отваливается только при запуске двигателя? Если первое, проверьте настройки таймингов CAN-интерфейса. Вот вроде неплохой калькулятор: http://www.bittiming.can-wiki.info/ Попробуйте без строчек вида while(HAL_CAN_GetTxMailboxesFreeLevel(&hcan2) == 0);

Стоит задача разработки такой конструкции: обычная печатная плата (модуль-носитель) и подключаемые к нему гибкие печатные платы с датчиком. Последняя будет иметь вид основания с компонентами со шлейфом-отростком. Ранее гибкими печатными платами не занимался, а по сему стоит вопрос - как подобрать соединитель, через который шлейф от гибкой печатки будет соединятся с модулем-носителем? Здесь https://www.pcbway.com/flexible.aspx предлагают толщину до 0,26 мм для 2-х слойной платы (или, суммарная толщина 0,265 мм). Также в опциях заказа есть такой параметр, как Stiffener - как понял, подложка, добавляющая жесткости и увеличивающая толщину. Беглый анализ содержимого диджикея показал, что наиболее распространенные соединители идут под гибкие платы толщиной 0,3 мм. Вопрос - может ли такой соединитель https://www.we-online.com/katalog/datasheet/686116183422.pdf удержать плату, если к ней добавить значение Stiffener в 0,05 мм? Вроде, если ее толщина будет составлять примерно 0,31 мм, это вполне входит в допуск на 0,29..0,34 мм. Также интересует, можно ли на гибкую плату крепить винтовым соединением внутри корпуса?

Прошу помочь разобраться с работой FMC модуля МК STM32F407VE. Необходимо подключить внешнюю память ОЗУ; так как в данном МК шина адреса и данных объединена, для обращения к внешней памяти адрес необходимо демультипликсировать, для чего используется сигнал nADV (nL). Сигнал должен поступать на внешние защелки. Предполагается использовать ОЗУ типа IS61LV25616AL или аналогичную по структуре. Даташит на нее: https://datasheet.lcsc.com/lcsc/1809192221_ISSI-Integrated-Silicon-Solution-IS61LV25616AL-10TL_C16001.pdf Собственно, вопросы такие: 1) В Reference Manual (RM0090) для данного режима временные диаграммы приведены вроде как только для обращения к NOR FLASH. Можно предполагать, что в целом они будут такие же и для PSRAM (RM0090, см. стр. 1547). Однако, не очень понятно, по какому фронту следует защелкивать линию адреса. Предполагаю, что все же по нарастающему – именно за время между спадающим и нарастающим фронтом nADV (nL) сигнала – ADDSET – должны завершиться переходные процессы, а затем FMC модуль считает данные (для режима чтения). Верно ли это, и, соответственно, подойдет ли в качестве защелки микросхема 74HC574 (2 шт.). https://assets.nexperia.com/documents/data-sheet/74HC_HCT574.pdf Смущает, что она довольно медленная: время задержки между входом и выходом может составлять более 200 нсек при напряжении питания 2 В, и 45 нсек при питании 4,5 В. Хотя моя схема будет работать от питания 3,3 В, задержка все равно останется достаточно большой. Может, следует посмотреть что получше? 2) Поскольку шина данных 16-битная, обращение к данным размерностью в 32 бита будет разбито на две этапа (RM0090, см. стр. 1533). Интересует, какие это имеет последствия, кроме увеличения времени доступа к данным по сравнению с временем доступа к данным во внутренней памяти. Также, верно ли, что желательно не делать обращений к внешней памяти из прерываний, а в крайнем случае – использовать инструкцию __DSB()? 3) В мультиплексированном режиме, а также при побайтном обращении линия данных или ее часть находится небольшое время в высокоомном состоянии. Следует ли на всякий случай применять подтяжки к земле/питанию?