Сергей Борщ

В пульте нет PD. И раньше от этой же зарядки этот пульт прекрасно заряжался. Просто не повезло.

Понятно. Это, наверное, ключевой момент. Это вряд ли. До этого же все нормально заряжалось. Уточнил - зарядка была воткнута в роземку, кабель валялся, то есть ее не перетыкали из одного устройства в другое. Значит, просто такт совпало. Может статикой выбили. Спасибо.

Прошу прощения за вопрос не по теме. Принесли в ремонт ("тыжпрограммист") пульт ДУ от телевизора. Пульт без батареек, на борту суперконденсаторы, солнечная батарея и разъем USB type-C для зарядки (задействованы только контакты земли, VBUS и СС1, СС2 (резисторы на землю). Анамнез: долго лежал под подушкой, после доставания на свет не работал, подключили зарядку - зарядку не берет. Диагноз: пробой 5-вольтового трансила на VBUS. Вопрос: если блок питания был воткнут во что-то, с кем он договорился, скажем, о питании напряжением 20 В и потом его быстро отключили от того устройства и переткнули в пульт ДУ, продолжать выдавать эти 20 В уже в пульт ДУ?

Во-первых надо понимать, что переменные редактора связей (линкера) и переменные программы это несколько разные вещи. Редактор связей работает с адресами и все, что он может предоставить программе - это адрес какого-либо объекта. То есть в Си-программе это будет значение указателя на объект и надо будет сделать явное приведение типа: extern int _Min_Heap_Size; // <- вместо int тут может быть любой тип (кроме void). size_t Min_Heap_size = (size_t)&_Min_Heap_Size; Можно воспользоваться тем фактом, что имя массива неявно приводится к указателю на его первый элемент: extern int _Min_Heap_Size[]; // <- вместо int тут может быть любой тип (кроме void). size_t Min_Heap_size = (size_t)_Min_Heap_Size;

Ситуация 1: Настраиваю SPI на работу с ПДП (RXDMAEN = 1, TXDMAEN = 1). Заряжаю один канал ПДП на прием n байтов из SPI (пишу n в >NDTR, пишу все кроме EN в DMAx_SyCR). Запускаю этот канал (DMAx_SyCR.EN = 1). Заряжаю второй канал ПДП на передачу N байтов в SPI. все работает, можно повторять сколько угодно раз. Ситуация 2: Передаю m байтов через этот же SPI вручную, записью в TXDR (SPIx->SR.RXPLVL увеличивается с каждым принятым байтом). Вычитываю m принятых байтов из FIFO вручную, чтением RXDR (SPIx->SR.RXPLVL уменьшается с каждым вычитанным байтом до нуля). Заряжаю один канал ПДП на прием n байтов из SPI (пишу n в >NDTR, пишу все кроме EN в DMAx_SyCR). * передачи еще не было, RXPLVL. RXWNE, RXP, DXP в SPIx->SR равны 0 Запускаю этот канал (DMAx_SyCR.EN = 1). и вот в этот момент происходит пересылка через ПДП одного байта (байт всегда равен нулю, не зависит от содержимого UDRDR). Предполагаю, что на шаге 2, несмотря на вычитывание всех байтов, не снимается запрос ПДП. В F0x, F7x этот код работал без нареканий. Если перед шагом 1 сбросить RXDMAEN, a после шага 2 взвести - все тоже работает. Мало ли, может кому пригодится.

Обернуть в структуру-шаблон, в котором CRC есть. И уже этот шаблон инстанцировать в union со всеми возможными вариантами кадров. Или этот SendMessage засунуть в структуру, а после него разместить резервирование места под CRC. Все равно вы CRC считаете пробегаясь указателем по сырым байтам. В конце этот указатель указывает в нужное место, куда класть CRC. А в структуре он нужен только для наглядности и резервирования места, все равно вы явно с этим полем никогда не работаете - так и отразить это в комментарии к полю структуры. Ничего более другого в голову не приходит.

Я структурой описываю заголовок данных, от него наследую структуры данных. При приеме привожу приемный буфер к типу generic_data (фактически - голый заголовок), по нему определяю тип пакета и тогда уже привожу к типу конкретного пакета и обрабатываю соответствующим образом. А обрамление кадра (при необходимости) описываю шаблоном, параметром которого является структура данных. В этом же шаблоне размещаю и CRC (чисто для визуализации). По факту при передаче CRC считаю на лету и вставляю приведением указателя в конце расчета. Или прямым запихиванием в передатчик.

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

К кристаллу никто паяться и не собирается. Я же написал в первом сообщении - вместо него будет корпусной транзистор. Судя по всему это болезнь данных модулей и целый на разборке стоит как полмашины.

Ну да, так и было сделано. Проволочка оторвалась от кристалла.

Какой клей порекомендуете? Сколько ни брал всяких "проводящих" клеев на али - ни один ни капли проводимости не показал. Что тут странного? Очень часто такие попадаются.

Блок управления топливным насосом. Плата керамическая, с серым площадкам были приварены выводы бескорпусного транзистора, один из них отломался от транзистора. Транзистор будет корпусной, но чем припаяться к этой площадке? Пробовал обычный оловянно-свинцовый припой с флюсом NC-559 - один вывод к крупной площадке припаялся, а второй к мелкой площадке - вообще никак, нет даже немеков на залуживание площадки. Какие еще могут быть варианты? Припой с серебром поможет?

Проверил - та же фигня. К контуру платы привязывается, к User.comments и User.graphics - нет

Можно запустить ПДП в цикличестком режиме и когда АЦП закончит преобразование первой половины буфера - в прерывании HTIF быстренько обработать его. ПДП в это время будет заполнять вторую половину буфера, которую обработать в прерывании TCIF пока ПДП заполняет первую. И так по кругу. Там не так много обработки, можно обрабатывать постоянно (без задействования EXTI).

У меня там есть snap to graphics, его можно поставить Always.