Sergey_Aleksandrovi4

//функция работающая в прерывани от последовательного порта void modbus_usart_5(void) { static unsigned char rx_flag=0; static unsigned char tx_flag=0; // static short unsigned int rx_reg; static long unsigned int usart_sr_my=0; static long unsigned int usart_rdr_my=0; rx_flag=0; tx_flag=0; if((UART5->ISR & USART_ISR_PE) != 0){//по ошибке паритета UART5->ICR |= USART_ICR_PECF; } if((UART5->ISR & USART_ISR_FE) != 0){//по ошибке кадрирования UART5->ICR |= USART_ICR_FECF; } if((UART5->ISR & USART_ISR_NE) != 0){//по шуму в посылке UART5->ICR |= USART_ICR_NCF; } if((UART5->ISR & USART_ISR_ORE) != 0){//принятые данные не успели прочитать UART5->ICR |= USART_ICR_ORECF; } if((UART5->ISR & USART_ISR_IDLE) != 0){//на линии долго ничего нет //выставляется при обычном обмене UART5->ICR |= USART_ICR_IDLECF; } if((UART5->ISR & USART_ISR_LBDF) != 0){//на линии длинный логический ноль UART5->ICR |= USART_ICR_LBDCF ; } if((UART5->ISR & USART_ISR_RTOF) != 0){//тайм аут по приему UART5->ICR |= USART_ICR_RTOCF ; } if((UART5->ISR & USART_ISR_EOBF) != 0){//конец блока - при работе со смарт картами //выставляется при обычном обмене UART5->ICR |= USART_ICR_EOBCF ; } if((UART5->ISR & USART_ISR_BUSY) != 0){// идет прием байта - флаг выставляется и сбрасывается аппаратно //UART5->ICR = USART_ICR_EOBCF ; __NOP();// } if((UART5->ISR & USART_ISR_CTSIF) != 0){// CTS interrupt flag - флаг выставляется и сбрасывается аппаратно UART5->ICR |= USART_ICR_CTSCF ; __NOP();// } if((UART5->ISR & USART_ISR_CTS) != 0){// CTS flag - флаг выставляется и сбрасывается аппаратно //UART5->ICR = USART_ICR_EOBCF ; __NOP();// } if((UART5->ISR & USART_ISR_ABRE) != 0){// Auto-Baud Rate Error - флаг выставляется и сбрасывается аппаратно UART5->CR3 |= USART_RQR_ABRRQ ; __NOP();// } if((UART5->ISR & USART_ISR_CMF) != 0){// Character Match Flag - флаг выставляется аппаратно UART5->ICR |= USART_ICR_CMCF ; //выставляется при обычном обмене __NOP();// } if((UART5->ISR & USART_ISR_SBKF) != 0){// Send Break Flag - флаг выставляется программно и сбрасывается аппаратно //UART5->ICR = USART_ICR_EOBCF ; __NOP();// } if((UART5->ISR & USART_ISR_RWU) != 0){// Receive Wake Up from mute mode Flag - флаг выставляется и сбрасывается аппаратно //UART5->ICR = USART_ICR_EOBCF ; //выставляется при обычном обмене __NOP();// } if((UART5->ISR & USART_ISR_WUF) != 0){// Wake Up from stop mode Flag - флаг выставляется аппаратно UART5->ICR |= USART_ICR_WUCF ; //выставляется при обычном обмене __NOP();// } if((UART5->ISR & USART_ISR_TEACK) != 0){// Transmit Enable Acknowledge Flag - флаг выставляется и сбрасывается аппаратно //UART5->ICR = USART_ICR_EOBCF ; //выставляется при обычном обмене __NOP();// } if((UART5->ISR & USART_ISR_REACK) != 0){// Receive Enable Acknowledge Flag - флаг выставляется и сбрасывается аппаратно //UART5->ICR = USART_ICR_EOBCF ; __NOP();// } usart_sr_my = UART5->ISR; usart_rdr_my = UART5->RDR;//прочитали байт и при этом //должен был сбросится флаг прерывания RXNE if((usart_sr_my & USART_ISR_TXE) != 0){//по передаче //данные передались в сдвиговый регистр //UART5->ISR &= ~USART_SR_TC; // UART5->ICR |= USART_ICR_TCCF ;//сбросим флаг UART5->RQR |= USART_RQR_TXFRQ ;//сбросим USART_SR_TXE // tx_flag=1; __nop(); } if((usart_sr_my & USART_ISR_TC) != 0){//по передаче //данные передались из сдвигового регистра //UART5->ISR &= ~USART_SR_TC; UART5->ICR |= USART_ICR_TCCF ;//сбросим флаг // UART5->RQR |= USART_RQR_TXFRQ ;//сбросим USART_SR_TXE tx_flag=1; } if((usart_sr_my & USART_ISR_RXNE) != 0){//по приему rx_flag=1; //UART5->SR &= ~USART_SR_RXNE; UART5->RQR |= USART_RQR_RXFRQ;//**сбросим флаг RXNE явно //rx_reg = UART5->RDR;//прочитали байт //rx_reg = (UART5->DR);//прочитали байт } if(tx_flag==1){//по передаче tx_flag=0; ... }//по передаче if(rx_flag==1){//по приему rx_flag=0; ... }//по приему // заремарим сброс - вдруг какое то прерывание возникает повторно UART5->ICR = 0xFFFF;//сбросим все флаги UART5->ICR |= USART_ICR_PECF; UART5->ICR |= USART_ICR_FECF; UART5->ICR |= USART_ICR_NCF; UART5->ICR |= USART_ICR_ORECF; UART5->ICR |= USART_ICR_IDLECF; UART5->ICR |= USART_ICR_LBDCF ; UART5->ICR |= USART_ICR_RTOCF ; } @firstvald 1. Покажите код внутри тела условного оператора if(rx_flag==1) скрытое под многоточием 2. Проверьте логическим анализатором/осциллографом частоту вызова функции modbus_usart_5() во время сбоя перед сваливанием в hardfault PS Это не мой код, я причесал портянку firstvald выложенную на 6 странице топика. Не задавайте мне вопросов по поводу этого ужаса)

Ещё не предлагали вариант с т.н. "иммерсионной жидкостью" в которой майнеры криптовалют свои видеокарты купали? Как пример OCTAVA COOLANT. По-видимому такое же минеральное масло, наподобие трансформаторного. Но ни разу не слышал (хотя и не особо интересовался), чтобы у майнеров из-за работы в среде этого масла деградировали электронные компоненты.

Ну собственно тему можно на этом закрывать, больше, чем инженеры из TI, тут вряд ли кто-то расскажет) Читайте, выбирайте наиболее подходящий для себя вариант защиты. К слову, существуют стабилизаторы со встроенной защитой от обратного тока. В качестве примера (сам никогда их не использовал) https://www.nisshinbo-microdevices.co.jp/en/faq/004.html

Быстрее в 3 раза без лишних телодвижений: выбрасываете из тела цикла абсолютно ненужный nop, включаете хотя бы самую лёгкую оптимизацию. Вместо портянки из 6 инструкций/итерацию Оптимизиция -O0 void TEST(unsigned int FG2) { while(FG2--){__NOP();} } 080002cc: nop 080002ce: ldr r3, [r7, #4] 080002d0: subs r2, r3, #1 080002d2: str r2, [r7, #4] 080002d4: cmp r3, #0 080002d6: bne.n 0x80002cc <TEST+16> получаете 2 инструкции/итерацию Оптимизиция -O1 void TEST(unsigned int FG2) { while (--FG2); } 08000260: subs r0, #1 08000262: bne.n 0x8000260 <TEST+6> Выхлоп из GCC, но IAR на таких тривиальных вещах должен выдавать аналогичный результат

@Arlleex По прошествии 3х лет с открытия этой темы, удалось достигнуть желаемого? Состоялся переход с Си на C++?

Приём называется "stack painting" (окраска стека). Анализировать % использования стека можно не только в отладчике, но и программно. Бывает полезно при длительном тестовом прогоне оборудования.

Совсем забыл поставить точку в этом вопросе. Эксперимент прошёл успешно. По-колхозному: без делителя и последовательного резистора, кинул провод напрямую с генератора (вывод МК) на OSC_IN чипа. Ничего не сгорело, чип исправно тактировался внешним источником. Единственное, не проконтролировал энергопотребление.

Благодарю за ответы. По поводу чипа: секрета особого нет, как и нет смысла про него рассказывать. Вопрос концептуальный. О таком делителе речь? Не пойму идею. C1 отрежет постоянную составляющую меандра, C2 завалит фронты. Я думал о резистивном делителе, но, как заметил Plain, при питании от одного источника это будет излишним. Полистал даташиты на ночь глядя, наткнулся на АЦП от TI. Разрешают тактировать и так, и эдак без каких-либо настроек в регистрах АЦП. Резистор 50 Ом, как понимаю, от "звона" отражённого сигнала (вроде бы эти резисторы непосредственно у выхода источника сигнала рекомендуют ставить, а не со стороны приёмника). В общем, как приедут запасные чипы (чтобы без "железа" не остаться), проведу эксперимент, отпишусь о результатах.

Здравствуйте. Работаю с микросхемой, требующей для тактирования внешний кварцевый резонатор. По-классике: выводы OSC_IN, OSC_OUT, кварц и два нагрузочных конденсатора на землю. Есть желание затактировать её от внешнего генератора. По аналогии с микроконтроллерами STM32 и AVR, где допускается как использование резонатора, так и внешнего синхро-сигнала. Однако, в документации на чип нет ни слова про такую возможность. Более того, в МК при работе от внешнего генератора требуется вручную указывать в соответствующих регистрах опцию "работа от внешнего генератора": Fuse-биты CKSELx в AVR или бит RCC_CR_HSEBYP в STM32. В моей микросхеме таких настроек нет. Предполагаю, что в большинстве случаев внутренний генератор построен по схеме Пирса, и от подачи внешнего прямоугольного сигнала ему поплохеть не должно. Но опять-таки, смущает необходимость явно указывать о факте внешнего тактирования в МК. Самый простой вариант - подпаяться к чипу и проверить. Но, может кто-нибудь здесь поделится мыслями по поводу затеи. PS С производителем чипа связался, но ответа нет уже 3 неделю.

В силовые цепи блоков питания телевизоров иногда устанавливают предохранители :) Внутри блоков питания ЗУ для телефонов их редко можно увидеть. Максимум Fuse Trace (печатный проводник) Кто-то фото внутренностей обсуждаемой розетки выложил. Есть там защиты от перенапряжения, от КЗ? Не силён в силовой электронике, не буду ничего комментировать. Ко всему прочему пластик корпуса может быть горючим. Плюс традиционный "китайский" монтаж (цитата из отзыва) Я бы не оставлял это устройство работать в непрерывном режиме 24/7.

@slanted спасибо, впервые узнал про преобразование типов при предупреждении "implicit declaration". По поведению точно оно: тип int в AVR 16-битный, возвращается через регистры r24:r25. И один из способов проверки int-величины на 0 может осуществляться как раз с помощью команды or r24, r25. Ваш совет помог, но не сразу. Все инклуды были прописаны, предупреждение об implicit declaration не было, перекомпиляция не убирала ошибку. Однако после того, как выполнил Clean Solution и полностью пересобрал проект - картина изменилась. Все проверки bool-результатов выполняются посредством правильной команды and r24, r24 (хотя я так и не понял почему не используют tst или cpi) Спасибо за помощь и за ликбез.

Здравствуйте. Снова я со своими AVR-ками. Пишу загрузчик в gcc (Atmel Studio 7). Отладил алгоритм в основной секции ROM при -Og оптимизации, перенёс в область загрузчика, но ужал по код по размеру: оптимизация -Os. Посыпались глюки. Стал разбираться. Возвращаемые функциями bool-результаты в ряде случаев всегда интерпретируются вызывающим кодом как true. Копнул глубже. Функции возвращают bool-результат через регистр r24 т.к. тип bool однобайтный: объявлен как unsigned char проверил это с помощью sizeof(bool)==1. В asm-листинге вижу как функции заносят корректное значение в r24 перед выходом, пока всё отлично. НО в вызывающем коде проверка bool-результатов на true/false производится 2 экзотическими способами: 1) and r24, r24 2) or r24, r25 Второй вариант и создаёт ошибку, т.к. в r25 зачастую лежит мусор отличный от нуля. В паре мест я видел что перед вызовом функции r25 обнуляется, но обычно - нет, и кроме того через r25 в функцию передаётся аргумент. Я изрядно позабыл avr-asm, но вроде бы логично было использовать специально-предназначенные cpi r24, 0 или tst r24. Ладно, возможно чего-то не понимаю. Нашёл пока лишь единственный способ побороть этот глюк - добавил ассемблерные вставки перед возвратом false. Но это лютые костыли кмк. asm volatile ("clr r25" ::: "memory"); Может быть кто сталкивался с подобным поведением компилятора и знает более элегантные пути обхода? Допускаю, что сам мог где-то в опциях компилятора не указать какой-нибудь волшебный gcc-шный ключ.

Вы слишком высоко оценили мои способности :D Линуксовый мир мне чужд, на банальную сборку одного лишь libiconv по инструкции ушла большая часть рабочего дня. И дело ещё в другом. Все эти исходники должны компилироваться на "ванильных" сборках Atmel Studio. Т.е. если разработчик после меня захочет что-то поправить в коде, то он просто скачает и установит дистрибутив студии с сайта и откроет в ней мой проект, а не будет рвать на себе волосы в надежде собрать рабочий тулчейн из исходников. Было бы дело в одной лишь dll библиотеке, её можно бы было положить в репозиторий с проектом и написать readme как и куда её подключать. По этой же причине отказался от идеи что-либо править руками в make-файле, пусть автоматически генерируется по настройкам из GUI студии. Поэтому буду писать поддержку юникода. По флэш-памяти у меня, грубо говоря, ограничений нет.

Конкретно с этим процессором не работал, но, вспоминая опыт годичной давности - никакой "магии" при управлении ADAU с внешнего МК не было. Описание регистров должно быть в даташите, I2C тоже вполне тривиальный интерфейс. Sigma Studio с отладчиком (у меня был недорогой китайский клон с aliexpress) крайне полезна тем, что управляя через графический интерфейс можно видеть какие биты в каких регистрах затрагиваются, там окошко с консольным "выхлопом" есть. Документация их мне крайне не понравилась. Да и много очень настроек, в голове не удержать. А вот через Sigma Studio отлаживаться было гораздо проще. Даже на их форуме EngineerZone в одной из тем посвящённых ADAU инженер от AD рекомендовал устанавливать этот пакет чтобы в полной мере прочувствовать все особенности чипа.

Тоже малоприменимо, спасибо за совет. У меня в устройстве GUI в которое потребовалось добавить поддержку нескольких языков. Хочется видеть в исходниках именно текст в том виде, в котором он выводится на экран. Если строковые константы будут записаны "крякозябрами" или через подобные литералы, то управлять и модифицировать проект в дальнейшем будет проблематично. Разве что оставлять после каждой строки комментарий в человекочитаемом виде. Но это на потом, если с юникодом не получится.