Comments 194
Круто! Спасибо, что поделились :)
В программировании микроконтроллеров до того, как вы дойдете до всяких так алгоритмов и структур данных пройдет год, а то и два колупания с электропитанием, макетированием, тактированием, прерываниями и прочим. А проблемы отсутствия всяческого Link(а) в программировании микроконтроллеров и вовсе красной нитью прошивают всю мою карьеру. Особенно в случае беспроводных интерфейсов.
Сочувствую.
Замечу из своего опыта, что до программирования любого микроконтроллера(SoC) и разработки алгоритмов , особенно в случае беспроводных интерфейсов, который выполнен в виде китайского модуля (ESP,NRF,TLINK,STM,Ti и др) обычно проходит не более 5 дней (время на изучение документации на новый чип) и 1 дня (припаять провода для подключения к ПК и установить IDE на Eclipse).
И весь недельный тест с логами внутри накрывается медным тазом... Пришлось поднимать на устройстве NVRAM и черный ящик в SD карту, чтобы писать логи в энергонезависимую память.
Странно, что кому-то вообще пришла в голову идея хранить недельные логи в RAM...
Именно. Всегда когда надо тестировать больше пары часов в ход идет одноплатник, либо пишущий на свою флешку, либо если тест долгий и есть интернет, сразу по mqtt на сервер что бы можно было в реальном времени мониторить. + в одноплатник сразу программатор засунуть можно
А ещё странно что это за логи такие что аж недельный объём помещается в ОЗУ микроконтроллера...
Оказалось, что ему просто лень было посмотреть, что написано на корпусе микросхемы
Или кому-то другому было лень написать программисту ТЗ или хотя бы записку, где указать тип контроллера
весь случай со статикой это не баг - это стыд и позор для организации, особенное если она ориентирована на разработку электроники. многие из нас конечно же так делают, но это настолько ССЗБ что слов нет
Ещё баг под названием ub+мало опыта есть
Мои два самых смешных случая связаны с тем, что я давно сижу под линуксом, а народ в основном под виндой. Случай первый. Нужно было написать некоторую не особо хитрую программку для STM8S (8-битный микроконтроллер от ST Microelectronix) Я писал на SDCC, у заказчика был IAR Embedded Workbench. У меня всё работает, и у заказчика прошитый мой бинарный файл тоже прекрасно работает. Но при попытке заказчика собрать прошивку из исходников, работать перестает. Выяснилось, что SDCC нумерует прерывания с нуля (как вроде оно и логично !), а IAR с единицы (почему спрашивается ???). Когда это поправили, всё заработало.
Случай второй. Нужно было сделать некий довольно хитрый проект на FPGA ice40 от Lattice (я писал об одной интересной задачке, связанной с этим проектом https://habr.com/ru/articles/485786/ ). На версии icecube2 под линукс всё собирается нормально и всё работает. На версии под винду у заказчика, прошивка собирается, но не работает. Слава богу удалось продемонстрировать это заказчику. Очевидно в версии под винду были баги, а под линукс - нет. Удивительно как такое вообще может быть. У них что, под разные системы различная кодовая база ??? Кстати после следующего обновления, под винду тоже стало собираться нормально.
Так ведь даже переход между разными версиями винды - уже проблемы. Ставил недавно банальную ардуину иде. Сначала поставил на 7 - проект не компилится, то одна ошибка вылезет, то другая, то третья. Помучался, надоело. Накатил 10-ку, проект скомпилился без проблем. Одна и та же версия ардуины, одни и те же библиотеки, один и тот же проект.
Никто не обещал что оно будет работать на Win7
на win7 есть много внутренних ограничений, весьма неожиданных. проблемы с кирилическими именами папок это давно классика. а вот что в win7 ограничена длина строчки в командной строке - это уже неявный момент который легко приведет к странным ошибкам. так же регулярно используются утилиты писаные на python, новые версии на win7 которого уже не работают (без хитростей) и ошибки будут вообще из другой области.
Так ведь это, по сути, не проблема винды, все остальное на ней работает. Сама иде на ней работает, простейшие скетчи работают. Просто кто-то написал несовместимый код, а другой кто-то это не проверил.
Про питон вы верно сказали, проблема была именно с ним (esptool).
Где esptool, и где проект не компилится, то одна ошибка вылезет, то другая, то третья (ц)
так нет такого обязательства писать код совместимый со старыми виндами (95,98,XP,7,8). MS ввела новые api которых в 7ке просто нет, компиляторы их используют по умолчанию, чтобы обеспечить совместимость нужны доп. телодвижения, на что разработчикам лень и некогда. и как бы никто не виноват, и вообще можно использовать не самые новые версии софта, либо костылить. либо мигрировать. под linux тоже кстати есть такие истории.
Ну, как это? Если для ide заявляется совместимость, то и для библиотек должна быть совместимость. Иначе какой смысл в ide в отрыве от библиотек? Тем более, что ардуина позиционирует себя для начинающих разработчиков, а значит все должно работать из коробки, без лишних телодвижений и, тем более, колдунства 80lvl.
Ну, или хотя бы просто написали что такая-то версия не совместима, установите вот такую. Так ведь нет, там ошибка вывалилась вообще хз какая и только вдумчивое гугление навело на мысль о версиях по.
для библиотек должна быть совместимость
Тут наверное вопрос к авторам BSP для 8266.
только вдумчивое гугление навело на мысль о версиях по
opensource, ага ;)
именно так. гарантий то никто не дает, все as is
Arduino IDE с ванильной ардуиной - да, успешно.
Там даже Reset разведён куда надо и контроллер переключается в режим прошивки как надо.
А вот с подражателями уже куча вопросов - или надо успевать в момент заливки переводить в режим программирования (поленились резет куда надо вывести) или компиляторы внешние не очень корректные или внешние тулзы (питон для esptool)
так нет такого обязательства писать код совместимый со старыми виндами (95,98,XP,7,8). MS ввела новые api которых в 7ке просто нет
Graceful degradation? Не слышали!
Я писал на SDCC, у заказчика был IAR Embedded
А зачем? Пусть SDCC у себя настраивают. Смысл поддерживать разные компиляторы, если это не крупный opensorce проект, где каждый свой велосипед собирает. Да даже версии компиляторов и флаги компиляции должны быть теми же самыми, что бы исключить странные баги.
Или наоборот, развернуть IAR у себя. SDCC само по себе странное изделие.
IAR платный, SDCC - нет, для большинства задач 8биток его более чем достаточно.
IAR платный
Ну вы же деньги на этом зарабатываете. Использовать разные тулчейны у себя и у заказчика - ну, немного странно.
IAR платный
Однако! (ц)
Ради экономии 3кевро можно и пострадать немного ;)
Жаба. Жаба never changes.
Именно поэтому во времена авр основным методом отладки был тяжелый пристальный взгляд.
И UART-CLI
https://habr.com/ru/articles/694408/
Я перепутывал разьем usb - поставил перевернутым. Причем плата уровня ардуино нано, три с половиной детальки. В - внимательность. Так что теперь перед заказом откладываю проект на пару дней, потом делаю ревью, и только после отдаю в работу.
#12 - у нас как то на тестовом стенде перезагрузилась коробка с текущим релизом, кто то заметил это в отчёте и завёл инцидент. Проверяли билды, повторяли тесты -всё ок. Отложили. Через месяц перезагрузилась соседняя на другом релизе и ревизии платы, и снова никаких результатов расследования. На третий раз заметили, что все перезагрузки имели разные аптаймы - что то вроде 43 дня, 37 и 28, и это коррелировало с тремя ревизиями плат под тестированием, которые отличались моделями процессоров.
Ну а дальше стало понятно - какой то watchdog. Посчитав тики, выяснили какой из процессоров не сбрасывает таймер, и нашли баг.
Удивительным оказалось то, что этот код существовал с первого релиза, но воспроизвёлся баг только когда в тестовой лабе появились коробки, которые тестировались вдолгую. Не было ни одной жалобы от покупателей - они перезагружали коробки сами чаще, или просто не замечали перезагрузки.
Удивительным оказалось то, что этот код существовал с первого релиза, но воспроизвёлся баг только когда в тестовой лабе появились коробки, которые тестировались вдолгую.
Не вы первые, не вы последние...
Из недавнего - развели плату с новым (для нас) Ethernet PHY, на прием пакетов работает на передачу нет. Смотрим осциллографом - пакеты уходят, с виду более шумные чем приходящие. Сравниваем с референсными схемами - там аналоговое питание отделено от обычных 3.3V индуктивностью, слабо верится что это может влиять но других идей уже просто не осталось. Развели заново чтоб точно по рекомендациям, конденсаторы на том расстоянии на каком должны быть, земля общая питание раздельно, не работает. Все знакомые электроники говорят "вы зря Ethernet осциллографом смотрите, оно должно просто само заработать".
Так и вышло. На схеме были перепутаны ножки TXD2 и TXD3.
Вот поэтому я и рекомендую всегда строить таблицу проводов в google spreadsheet. Для каждой схемотехники.
https://habr.com/ru/articles/716596/
Да, верно) ethernet - довольно таки устойчивая к помехам и несогласованности технология. Я когда на кабельном работал, лазил по чердакам, каких только скруток на езернет кабелях не встречал) и, по видимому, все работало.
С езернетом может быть такой прикол: неправильно обжаты пары. Например, tx+ оказался в одной кабельной паре, а tx- в другой. Это может даже как то работать, линк поднимется, простейший кабельный тестер подвоха не увидит, но будет сильно глючить.
Наблюдал странное для меня: лан двух компьютеров был просто запараллелен. Проводки рыжей и зелёной пар были соответственно аккуратно скручены. Оба компьютера под вин10 виделись в сети, про интернет не знаю, видел как с них, с каждого, распечатывали документы.
Мне казалось что так работать не должно. Но вот железный факт меня удивил.
(в стародревние времена делал хаб на три компьютера на резисторах - работало)
1) Переходили на новый МК. При подключении RTC модуля, контроллер начал падать в Hard fault. При этом, код до этого модуля и близко не доходил, падая в другой rtos задаче.
Выяснился интересный момент. Если чуть поменять код местами: if внутри case вынести до switch-а, то все снова начинает работать.
Проблема в итоге решилась, после исправления сопроцессора.
2) Не баг, а фича. Поймал коллизию CRC32 при изменении одного бита. Массив uint8_t [ < 0x20'0000].
Случайно не на stm32 проблема с RTC?
Была такая проблема на L433, но в HardFault сваливался немедленно после старта, исключительно с вставленной батарейкой RTC. Заключили, вроде бы, что она наводит помехи на NRST и вообще на половину периферии прямо сквозь камень)
По крайней мере, симптоматика была такая.
день убил на ковыряние в прошивке, поиск косяков, почему вчера работало а сегодня перестало... в конце дня посмотрел через лупу - у микросхемы нога недопаяна
У меня был случай , когда с производства принесли плату, а там микроконтроллер 144 пин вообще держался на трёх угловых пинах. Можно было металлическую линейку под QFP144 засунуть.
Если это был некий отечественный микроконтроллер в некоем импортозамещенном мониторе, то оно при этом могло даже нормально работать...
Монтажник прихватил чип за крайние ножки, собрался пропаивать - но тут его отвлекли. Вернулся, посмотрел, что чип стоит на плате и пошёл паять следующие компоненты. Это вообще классика. Не отвлекайте монтажников, пока они работают, а монтажники - не отвлекайтесь, пока полностью не пропаяете компонент.
Помнится какой-то адаптер для JTAG'а прислали из головного офиса, позволял воткнуть два разных типа риббон-кабеля, а на выходе получить уже обычный разъем.
И тут он вдруг перестал работать... прозваниваем - между точками 1-2 звенит, между точками 2-3 звенит... а вот 1-3 не звенит... оказалось в точке 2 контакт отвалился. Когда прозванивали естественно прижимали и всё работало.
Недавно проверял связь с ПК по RS485 с одним промышленным контроллером, ни в какую не было линка. Расковырял компаунд над чипом-трансивером, протыкал всё осциллографом с его стороны, вроде на обеих линиях сигнал видать, rx/tx переключается. Когда мозг начал покидать чат под конец рабочего дня, решил перебрать невероятные варианты. В итоге нашёл что соединительный проводок 10 см от адаптера до контроллера по одной из линий в обрыве, а с виду целый был.
Наши схемотехники тоже один раз выдали. Трансивер Ethernet соединялся с микроконтроллером по параллельной шине - 16 ног для данных и 13 для адреса. И пинг вроде есть, но со связью как-то всё коряво. И все руками разводят, на программиста пальцами показывают, чтоб у себя косяк искал. Оказалось что на одну из ног адресной шины по ошибке засадили светодиод линка.
Недавно проверял связь с ПК по RS485 с одним промышленным контроллером, ни в какую не было линка.
Я когда-то давно одним из первых нарвался на известную проблему с поддельными чипами USB to serial. Ну, это где обозленный производитель написал драйвера, которые вроде работали, но через каждые N байтов вставляли в поток данных текст "это подделка".
А кто нынче таким грешит не подскажете?
А кто нынче таким грешит не подскажете?
Нынче не знаю, а тогда это был Prolific. Потом его примеру последовал FTDI, который вообще окирпичивал поддельные чипы, хотя и не фатально.
сейчас пролифик тупо не работает, прямо в имени устройства пишет мол у вас чип древний идите вы отсюдова. Причём, я так понимаю они уже даже не пытаются различать оригиналы и не оригиналы. Довольно скотское поведение конечно. Только силабсы вроде бы адекватные остались
хотя и не фатально
Смотря для кого не фатально. Если поставили партию девайсов (необязательно промэлектроника, мало ли что за железка, которая к ПК подрубается и работает себе) клиентам, а через полгода после обновления драйвера они массово отлетели, то ситуация аховая. И убытки от отзыва этих аппаратов на перепайку чипов понесёт не FTDI и не поставщик, который впарил контрафакт, а те, кто произвёл и продал.
Не фатально для чипа. Можно откатиться на предыдущую версию драйвера и восстановить пид.
Ага. У нас так однажды клиент (розничная сеть) закупили партию дисплеев покупателя (это такие обычно 2-4 строчные штуки, показывающие покупателю последнюю позицию, стоимость и общую сумму) с USB интерфейсом на поддельных FTDI чипах. К вечеру первого дня внедрения этого барахла N-ое количество было успешно окирпичено и я до ночи искал причину, а потом писал инструкцию как это оживлять. Не знаю выкинули ли эту партию или мучались дальше, но в момент обнаружения было крайне не приятно столкнуться с этим.
Это кто был? У меня FTDI так навеки оказались в чёрном списке вендоров, когда в обновлении драйверов стали окирпичивать чипы, определившиеся как поддельные. Просто перезаписывала PID на 0000, и для оживления надо было танцевать с бубном. Везде после этого перешёл на CP2102.
Бывает такое) в старом пикаде, когда переносишь кусок схемы из старого проекта в новый, нетлист так же переносится, с теми же номерами соединений. И может так случиться, что номера некоторых соединений из старой схемы совпадают с номерами в новой. Визуально это никак не видно и ошибок в схеме нет. А вот на трассировке платы это вылезает, и там действительно, светодиод может приконнектится к шине данных, силовая линия из источника питания - к ножке проца, и т.д. абсолютный рандом) приходилось очень внимательно проверять разводку плат за печатниками.
Невнимательно читал документацию на кварц: картинка выше - не посадочное место, а вид со стороны контактов. Нужно отзеркалить.
Заводили дополнительный eth на джетсоне через pcie. Взяли референсный дизайн. Единственная особенность eth (realtek) и джетсон сидели на разных платах и соединялись плоским шлейфом. Все завелось кроме eth. Причем eth завелся, но как-то по-особенному. как будто с неинициализированным флешем (там обычно лежат всякие настройки). Запускал сам, но в железо не лез (уверяли, что все собрали правильно). Не завелось. И поставщиками писали, прислали кучу утилит для инициализации. Проверяли шлейф тыщу раз. И по форумам писал. Отложил в сторону. Потом решили таки добить.
Достал этот бутерброд и начал по старинке все проверять. Подал питание и начал везде его проверять. Оказалось, что на шлейфе питания нет. Начал рассматривать шлейф и разъемы. И оказалось, что на материнке стоит двухсторонний разъем, а на плате с реалтеком односторонний. Воткнули шлейф вверх ногами. Перевернул шлейф и сразу же получил свой гигабит.
Получил еще одну прививку от доверия другим людям и их уверениям в своей безошибочности.
У меня было в Протеусе все работает, в железе глючит и перезагружается. Оказалось забыл отключить внешнее прерывание, нога висела в воздухе и генерила огромное количество прерываний.
Не про микроконтроллеры, но тоже про "загадочные прерывания".
В ZX Spectrum можно было использовать свой обработчик прерывания от таймера (других источников прерываний там не было). Для этого надо было загрузить старшие 8 бит адреса, в котором лежит адрес обработчика в регистр процессора I, а младшие 8 бит Z80 брал с шины. В норме там должно было быть #FF, но на шайтан-клонах могло прилететь что угодно. Поэтому обработчик приходилось размещать по адресу #XYXY (с одинаковым младшим и старшим байтом), а под таблицу прерываний отдавать 257 байт и заполнять их этими самыми #XY.
В норме там должно было быть #FF, но на шайтан-клонах могло прилететь что угодно.
Как раз в оригинальном спектруме и могло прилететь что угодно, а в клонах бывало и #FF
Assuming that the databus contains a "random" number in range of 00h..FFh upon IRQs, it requires a table with 101h bytes at [I*100h+0..100h]. On the Spectrum 128 and up the databus seems to be stable FFh, needing only a 2 bytes at [I*100h+FFh..100h].
В ZX Spectrum можно было использовать свой обработчик прерывания от таймера (других источников прерываний там не было).
Бешеный SysTick таймер. Работам с многоядерным микроконтроллером FC7300F8MDT. Запускаю по очереди первое, второе, третье ядра CPU (ARM-Cortex-М7). С удивлением для себя обнаруживаю, что Heartbeat LED сначала мигает на частоте 1Hz, потом 2Hz и 3Hz соответственно. UpTime время системы тоже бежит в 3 раза быстрее. Не порядок.
Сначала подумал, что системная частота поменялась. Вывожу ClockOut на улицу. Прикладываю электрод осциллографа. Всё нормально 300MHz/8=37,5MHz.
Потом подумал, что пред-делители таймеров не те. Смотрю в CLI пред делители всех трёх SysTick таймеров. Настройки всех трёх SysTick таймеров одинаковые.
Вызываю в консоль HAL функции чтения системных частотных рельс (SCG_GetScgClockFreq и CSC0_GetCSC0ClockFreq)и всё тоже корректно, как до так и после инициализации SysTick таймеров.
Спустя несколько часов чисто в порядке бреда отключаю системные таймеры на Core1 Core2 и смотрю отладчиком в Ozone, что происходит. Частота Heartbeat LED вдруг нормализовалась.
Оказалось, что у всех трех таймеров была одна и та же функция для обработчика прерываний SysTick_Handler. Вот она и вызывается в три раза быстрее чем надо. Все три ядра вызывали одну и ту же функцию прерываний SysTick_Handler. В результате решил SysTick оставить только на Core0. А Core1 и Core2 работают без SysTick. Таким образом UpTime стал высчитываться корректно.
Тоже вспомнилось. Делал одну железку, там были драйверы моторов. Собрали, запустили - всё работает, шаговики крутятся, всё ездит. Но всплыла проблема - после нескольких десятков прогонов координаты уходят. Причём происходит этакий циклический сдвиг, если сделать запусков так сто, то оно вернётся на место. Явно как будто программная ошибка. Очень долго ковырял прошивку, поменял библиотеку для работы с драйверами, жгуты проводов все заменил на экранированные. И опять не работает.
А всё оказалось банально и просто - оказалось, что при слишком маленькой длительности импульса (какая стояла по умолчанию в той библиотеке) драйвер может пропускать шаги, причём крайне незначительно (может, один процент от числа всех импульсов игнорировался). А в сочетании с механикой, которая была у меня, он может это делать вот так вот необычно, что напоминает программный баг (как будто погрешность при непонятно откуда взявшемся округлении или что-то вроде этого). Увеличил длительность вдвое, и всё ожило.
оказалось, что при слишком маленькой длительности импульса (какая стояла по умолчанию в той библиотеке) драйвер может пропускать шаги
У меня с той турелью был даже обратный эффект.
Из-за ненадежного разъёма между MCU и платой с драйвером drv8711 наоборот из-за дребезга на линии STEP получались лишние шаги.
В результате ось каждый раз уезжала дальше на 3-5%.
Это проблема у всех шаговых двигателей
А ещё шаговые двигатели свистят во время работы. И тоже не ясно как бороться с шумом.
Частота ШИМ, я на своих драйверах иногда за 120 кГц выводил, чтобы вообще не было слышно, но это не всем доступно. Ну и если делать глубокий microstep - то и при движении ничего особо не шумит.
если делать глубокий microstep - то
На глубоком microstep момент силы низкий. А у нас турель была 80 кг на валу.
Очень сильно зависит как от двигателя, от его железа, так и от алгоритмов, у меня особо заметных потерь по моменту не было, но скорее всего сошлись и частоты и возможности железа. Можно поиграться с формированием ШИМ и перейти вообще к ЧИМ, но тогда можно опять попасть в звуковой диапазон. Да, ваш случай сложный.
Моторное "железо" - не грелось ли? Или фильтры были?
Очень полезная статья. Особенно с точки зрения поиска. Например если вбить в поисковой строке "Программатор не видит target по SWD", то можно будет получить вполне вменяемый ответ на решение проблемы. Также описание проблем сможет направить пуско-наладчика в нужном направлении. Баги довольно интересные, конечно.
Ух, какая отличная статья. Поделюсь частью своего набора:
1.Разъем USB-B. После смены поставщика ( ну разъемы то похожие, по мнению снабружов) стали наблюдаться интересные явления: некоторые платы не определялись компьютером. Оказалось, что на новых разъемах контакты расположены ближе к задней крышке. Итог, припой образует мениск и образуется замыкание ножек на корпус. Там + шина c USB и одна из шин данных.
2.Тоже из раздела схемотехники. Много лет заказывали печатные платы. Посадочные площадки под штыревые разъемы всегда были металлизированы с обоих сторон и в отверстии тоже была металлизация. В последней партии приехали платы, а в отверстии металлизации нет. Оказалось, сменили изготовителя печатных плат, и он сделал в точности, как в герберах.
3.При переходе с камня STM32 на GD32 ( была черная полоса в заказах, нужно было делать продукцию, а обходных путей на ST, как и подделок не было) обнаружилось следующее: АЦП на GD32 не работает, хотя прошивка ранее работала на всех STM32. Детальное "курение" даташитов результата не дало. Ну одинаково было у них. Решилось все банальным уменьшением частоты опроса АЦП.
2. Но ведь в Gerber не указывается (и даже нет возможности) наличие металлизации в отверстиях. Это в бланке заказа платы указывается. Да, интересный у вас поставщик. А с переходными отверстиями он справился успешно? Или проволочки пришлось впаивать?
Металлизация переходных отверстий сделана правильно. На плате есть другие разъемы, в них тоже металлизация есть, все нормально. Видимо ранее тоже в сгенерированных файлах было отсутствие металлизации в конкретных отверстиях, но производитель сделал по своему. А сейчас просто решили сделать все по правильному.
Вроде бы, все что касается отверстий описывается в файле сверловки. А герберы да, только слои описывают. Сколько слоев, столько и герберов.
В сверловке указывается. А она с гербером идёт.
АЦП на GD32 не работает, хотя прошивка ранее работала на всех STM32. Детальное "курение" даташитов результата не дало.
Скорее бы вернулись STM и прочие заслуживающие доверия вендоры. Надоело тратить время на "курение" даташитов и поиск граблей во всякой китайщине.
Не люблю ардуинки идеологически, а после этого случая особенно. Достался как то раз чужой код и встала задача дописать в него команду на ребут. Ну, дело известное - включаем wdt, зацикливаемся, после ребута выключаем wdt. Не работает. Точнее ребутится-то плата хорошо, даже слишком, а если точнее - то циклически и бесконечно. Смотрели в код тремя парами глаз, выводили отладочные сигналы и трогали их осциллографом - ну вот не выходит из ребута и все тут. Оказалось, что для выключения wdt AVR требует установки битов в регистр в течении какого то количества тактов после старта программы (могу быть не точен за давностью лет, но там действительно был довольно небольшой допуск по времени). Ну а ардуинья библиотека банально не успевала это сделать. Переписали вручную эту часть - всё прекрасно заработало. Мораль - не верьте высокоуровневым библиотекам и читайте референс мануалы на контроллер.
Я так писал прогу для управления газоразрядным индикатором с самосканированием (такой эпичный аппарат как ПИУ-2). Оказалось, ардуино с "медленными" digitalWrite не укладывается в тайминги сканирования индикатора (там текстовый дисплей из семи рядов точек, надо успевать выставлять на ножках вертикальную линию из семи точек, когда схема управления даёт сигнал на это) и текст разъезжался. Поменял на "быструю" работу с портами, и всё заработало.
Не так давно с этим же бодался. Насколько я понял, там дело не во времени, а в том, что биты в регистре нужно выставлять по отдельности, а не одной командой. То есть, нужно сделать в точности в той последовательности, как написано в даташите, шаг влево, шаг вправо - работать как надо не будет. Это достаточно не очевидный момень, так как обычно биты можно ставить/убирать в любом порядке, хоть скопом, хоть по отдельности.
Сейчас открыл RM, нашел это место, вот так там было:
The sequence for clearing WDE and changing time-out configuration is as follows:
In the same operation, write a logic one to the watchdog change enable bit (WDCE) and WDE. A logic one must be written to WDE regardless of the previous value of the WDE bit.
Within the next four clock cycles, write the WDE and watchdog prescaler bits (WDP) as desired, but with the WDCE bit cleared. This must be done in one operation.
Сначала разрешаем изменения, а потом быстро их вносим, пока оно не запретилось обратно. 4 такта для библиотечной функции оказывается слишком мало
Да, три года назад такое же с avr32uc3a столкнулся. Доставщиеся в наследство старые проекты на mplab.x.ide мигрировал. Всё красиво на C, а десяток строк - смена осциллятора на asm. Переписал на C - не работает. Оказалось, что даже со всеми оптимизациями не успевает, оставил старый код, но как-то не очень. Удручало, что гуглишь форумы, а ссылки на 404 ведут
А ещё есть такое: для того, чтоб не тянуть кучу проводов от кнопок, решили на кнопки поставить резисторы с разным сопротивлением, а микроконтроллер в установке взависимости от сопротивления понимал какую именно кнопку нажали. Между пультом и установкой получилось всего 2 провода. Красотииища! Все довольны. Но со временем контакт в кнопках стал хреновым, и кнопки стали определяться некорректно. Пришлось переделать кучу пультов, вставить микроконтроллер в каждый, и проводов стало 3. Теперь опять все довольны. Но столько головной боли было.
В каком-то мониторе (LG, кажется) видел такое решение с аналоговым выходом. И случилась та же история - контакты в кнопках окислились (их с самого момента производства монитора толком никто не нажимал) и регулировать параметры стало невозможно.
Такое решение вообще довольно распространено. У многих автомобилей кнопки на руле так обрабатываются.
Такое решение применяется в большинстве телеков и мониторов. Ну, кроме тех, наверное, где кнопки на самой плате стоят.
Есть комнатные пульты регуляторов для отопления, там 3 провода - земля, температура помещения с потенциометра, и выбор режима - с переключателя сделанного на дискретном потенциометре
Надо делать диапазон АЦП на срабатывание. Типа кнопка ентер от 45 до 52 срабатывает, ескейп от 80 до 87
«У каждой проблемы есть простое, лёгкое, неправильное решение» ©
Решение нормальное. Если у нажатой кнопки сопротивление измеряется в килоомах - она и в цифровом режиме будет работать странно.
Если у нажатой кнопки сопротивление измеряется в килоомах - она и в цифровом режиме будет работать странно.
Если.
Тут чаще бывают не килоомы, а сотни ом. Что аккурат хватает для залезания в диапазон для другой кнопки. Из-за этого начинаются глюки, когда, например, на мониторе пытаешься открыть меню, а вместо этого меняется яркость.
Мы даже для миллисекундных таймеров используем uint64. А использовать 32-битный счётчик для микросекундного таймера это вообще смелое решение.
По-моему наоборот хорошее - лучше сразу корректно обрабатывать переполнение, чем оно выстрелит один раз на объекте а до того не поймается никем.
Сразу видно опытного разработчика!
На самом деле смотря на каком контроллере всё происходит. Вот у нас сейчас переделка старого проекта на древнем техасовском DSP. И там, конечно, никаких 64-битных переменных не используем. Там используем 32-битный миллисекундный таймер и учитываем переполнение. А был вообще 16-битный счётчик, который тикал раз в 10-миллисекунд.
Зачастую спасает банальная замена if(Ticks()>OldTick){... на if( (Ticks()-OldTick)> ...)
положили SWD длиной 90 см и нет Link(а) с MCU
Что, в принципе, вполне ожидаемо при метровой длине. У нас как-то разработку блока SPI заказали, и потом заказчики жаловались на нестабильную работу на частоте 25 МГц. Оказалось, они SPI по многометровому кабелю, проложенному внутри своего "изделия", запускали.
Я в таком случае конвертировал spi в lvds, lvds в линию, а потом обратная конвертация. LVDS - согласованная диффпара, как в эзернете, ее можно тянуть достаточно далеко. Главное - если тянуть далеко, надо снижать скорость, чтобы фронты не сильно разбегались.
вот непонятно почему автор не снизил скорость а полез в потроха. SWD, если медленно, может и метры взять.
Скорость и так была на минимуме. Килогерцы
я понимаю что укоротить кабель это быстрое решение.
но для килогерцев Slip-ring не должен быть помехой. возможно в нем причина. хорошо бы там осциллографом глянуть. либо он сломан, либо какая либо прокладка транспортировочная не снята, либо неучтенные утечки/подтяжки.
если SWD корректно реализован в схемотехнике, то метры ему не страшны.
не в тему багов на железках, но про баги
помню самые эпик баги на одном из линуксов) ставишь дистрибутив и черный екран и всегда разное решение ) не во всех версиях и не каждое время, с чем-то связано, но наблюдал часто) еще смешные баги в Киберпанке помню когда игра вышла люди делали нарезки о своих багах, на какойто момент помню поймал себя на мысли, что это прикольно, но долго на багах не вывезешь, сейчас наверно большинство багов пофикшено )
Всё родное...
"Есть контакт, где не должен, отсутствует, где нужен". Мое любимое: на логанализаторе ничего, тычешь мультиметром - всё, как должно быть. Оказалось, плохо припаял питание на сдвиговом регистре, и когда проверял мультиком - нога дожималась и всё работало.
"О нужности курилки и документации". То монтажник не то запаяет, то произойдёт рассинхрон бома и схемы.
"О внимательности и даташитах": когда поленился читать раздел на периферию целиком, надеясь, что тут изменений в логике не будет. Медитировал над кодом, потом пошел на крайние меры - почитал ДШ. Оказалось, что для включения ШИМ на advanced таймере нужно установить бит, которого нет на остальных.
Самые Эпичные Баги при Программировании Микроконтроллеров
Вас Тоже Покусали Британские Газетчики, Пищущие Все Слова В Заголовках С Заглавной?
Этот баг называется «Мусор между разъёмами».
«Электротехника — это наука о контактах, а вернее — об их отсутствии.» ©
Этот баг называется: «толстые пальцы».
Вот прям интересно: и зачем человечество изобрело пинцеты?..
Загрузчик, к слову, писал коллега из другого дивизиона.
Вот что бывает, когда спортсменов (или военных) заставляют софт писать!
Вас Тоже Покусали Британские Газетчики, Пищущие Все Слова В Заголовках С Заглавной?
Нет. У меня просто диплом британского университета.
Ну так Вы больше не в Британии, поэтому выдыхайте уже!
P.S. Стало лучше, но "Микроконтроллер" по-прежнему с заглавной — это фамилия, что ли?
«Электротехника — это наука о контактах, а вернее — об их отсутствии.» ©
«Возможны всего два варианта: либо присутствие отсутствия контакта, либо отсутствие его присутствия» ©
На объекте пропала связь от контроллера RS-482 до ПК, вся разводка идёт под потолком через все помещение. Приговорили преобразователь интерфейсов, но после замены ничего не заработало. Почесывая затылок пошёл попить чаю и увидел доп.блок системы через который проходил сигнал. На этом то блоке как раз и была наполовину выдрана фишка, которой там не должно быть( возможность есть, но только при подключении дополнительного оборудования, на комп по схеме идёт напрямую от контроллера). Баг называется монтаж не по схеме и невнимательность. Скорее всего монтажники сэкономили таким образом пару десятков метров кабеля.
Потух пульт системы селекторной связи. Не видит его система. Берут из зипа второй, ставят - фик, тоже не видится. Блок питания, перезагрузки... А с утра "Очень Важный Селектор".
Спрашиваю - что делали? -Ничего. Все работало, но вдруг перестало. Продолжаю пытать, признаются что переделывали кроссировки. И тут меня осеняет, вспоминаю как 10 или даже 12 лет назад запускали систему, и я не мог оживить пульт после переноса его в другую комнату. Вся проблема в том (и тогда и сейчас) что пульт управлялся по rs485 и при перекроссировке путали А и В жилы. В общем через 3 минуты пульт завелся.
Напоминает, как у нас был комп, где интернет работал только у мужчин. Оказалось, перебили кабель под полом, мужчины его весом до контакта прожимали, а девушки все стройные)
Сколько крови попили эти А и Б по первой. Особенно когда на одном объекте Мокса на другом другой дешевый преобразователь.
Всегда считал что преобразователь USB-485 от "производителя" лучше чем "с Али". Но вот "Болид" смогла переубедить: их преобразователи могли нормально работать на одном ноутбуке и не работать на другом. Причём зависимость марка\винда\погода\меркурий так и не смогли установить.
На удивление самой стабильной заменой стал "свисток" с "Алика" - 3 штуки за 150р.
Теперь и не переживаешь что где-то оставил, и несколько объектов посещать стало проще.
{если Болидовцы это читают, наши коллективные лучи гнева - вам! Даже у недорогих приборов типа Гранит на плате есть micro-usb(!) для программирования, а вы зажопились сделать хотя-бы PLS гребёнку для подключения, крутим провода отвёрткой!}
В давнем проекте на AT91SAM7S256 написали прошивку, протестировали, всё отлично работало, девайс пошёл в массы, и тут от некоторых пользователей начали прилетать похожие жалобы «периодически намертво зависает при включении». Сделали возврат, получили свои коробки обратно, стали гонять - действительно, виснут. Меняем МК - не виснут, паяем «плохой» МК в нашу рабочую плату - виснет и тут, дело в МК. Попробовали изучить под JTAG-отладчиком - а он в состоянии этого зависания даже не подключается. Делаем «reset and halt» - подключается, ставим break на main и запускаем - труп. Трассируем стартовый код - умирает на включении PLL. Внимательно смотрим исходник (типовой стартовый код из Keil, копировали не задумываясь, «это ж Keil, а мы - юнцы зелёные»), заглядывая в мануал, и видим непотребство - одной записью в регистр и включается PLL, и осуществляется переключение на него (т.е. не то что не ждут готовности PLL, а ну прямо вообще одной операцией и запуск, и переключение). Вставляем ожидание готовности PLL, сразу всё начинает работать как надо. Дальше - обновление бутлоадера, где получилось и замены/возвраты, где нет.
«Однако если же USB вилку аккуратно выдвинуть всего только на полдлины, то так питание поступает! Оказывается был просто бракованный разъём гнезда для USB-A»
На Micro USB сталкивался с таким поведением несколько раз. Но чтобы на огромном USB-A - ни разу, даже на очень бюджетных кабелях.
Еще одно вспомнил. Купил как-то давно на али десяток stm32f437, которые с криптой. Удивился, чего оно так дешево - десяток за обычную цену пары. Но халява же! Штук шесть завелись отлично. Остальные, когда передаешь что-то по usb, почти сразу глухо висли. Сначала думал баг в коде, но нет - обнаружилось, что зависание происходит, если пакет 64 байта. Меньше - всё ок... Потом еще ловил F103 с нерабочим SPI - после инициализации любого из оных начинали нагреваться и висли. Да, китайцы собирают брак, не прошедший тестирование, и продают - будте осторожнее с халявой.
Как-то был проект, где использовали Raspberry Pi с российским адаптером USB-to-RS485, сделанным по всем правилам. У заказчика внезапно перестало работать и перезагрузка не помогала.
Позже выяснилось, что у "правильный" адаптер при загрузке Linux должен быть вытащен из гнезда и вставлен обратно после загрузки. Тогда всё работает. В следующем проекте использовали купленный на AliExpress в 7 раз дешевле (брал для домашних проектов). Работал идеально - хоть сколько перезагружай.
Схемотехник новичок первый раз разводил плату для управления BLDC мотором с датчиками холла. От провели длинные дороги через всю плату к фазам двигателя (он небольшой). Я начал отлаживать датчики холла, кручу руками вал - четкий сигнал. Запускаем с питанием - мотор дергается, не крутит, на датчиках шум. Мне имеют мозг, типа сделай программный фильтр на датчиках. Ковырялся несколько дней (сам был не опытен). Потом думаю погляжу ка я на линию питания МК, а там при запуске мотора просто шум дичайший, конечно МК в перезагрузку уходит 50 раз в секунду. Переделали плату, фазные дороги сделали короткими и разнесли подальше от сигнальных и питания МК, заработало как часы.
Случай после которого я вообще психанул на весь embedded. Контроллер не помню какой, но какой то Atmel 32 бит с Ethernet Phy. Задача поднять веб сервер, TCP сервер, UART и делать простые действия. Собрал проект в Harmony. Работает отлично, но спустя время зависает. Может зависнуть через 10 минут, может через 10 часов, может через 4 часа. Ковырялся чуть ли не месяц, пробовал разные аллокаторы памяти, думал может из фрагментации памяти ломается. Плюнул, снес проект и собрал с нуля заново. Перестал зависать, так и не понял почему.
Опять BLDC. Собрали плату для управления. уже опытные, собаку на моторах съели. На тестовом моторе работает как часы. Подключаем к мотору заказчика - дергает, еле крутит, ток повышенный. Репу чесали долго. Вешаем осциллограф на датчики холла - сигналы сильно кривые. Очевидно установка датчиков холла неправильна. Переделывали несколько раз, проверяли, считали углы - все равно кривые сигналы. Решили проверить магниты на валу. Нам показывают чертеж - да вот жеж все ровно. По факту оказалось что вал с магнитами сильно перекошен.
МК EFR32. На отладочной плате прошивка работает, на плате заказчика - не дышит. Оказалось на отладке есть дополнительный внешний тактовый генератор низкой частоты, а у заказчика его нет. Решение: в настройках проекта переключил на внутренний генератор.
схемотехник придумал питание пустить через монтажные стойки на плате, а земля полигоном по всей плате. Конечно когда стойку прикрутили коротнуло.
Проблемы тактирования, питания, перемкнутых контактов уже настолько тривиальные что проверяются в первую очередь когда плату собрали и первый раз прошили.
схемотехник придумал питание пустить через монтажные стойки
Какое неочевидное решение)
Плюнул, снес проект и собрал с нуля заново. Перестал зависать, так и не понял почему.
Место (которое на диске) было прОклятое!
По факту оказалось что вал с магнитами сильно перекошен.
Забыли применить передовую технологию «сварка взрывом» «сборка трезвым»?
Модуль FSC-BT1026С не может выдавать I2S семплы чаще чем 48kHz.
А техописание модуля утверждает, что он может выдавать сэмплы вплоть до 192 кГц:
FSC-BT1026x provides a standard I²S/PCM interface capable of operating at up to a 192 kHz sample rate.
Видимо, дело не в частоте, а в ее кратности: Supports 8, 16, 32, 44.1, 48, 96, 192 kHz sample rates.
Еще одна возможная причина — несоблюдение Table 5: Digital audio interface slave timing. Потому и переключение в master помогло.
забыли вообще даже подать на микроконтроллер электропитание!
В современных EDA существует множество правил для проверки дизайна плат. Почему не пользуетесь? )
зависает при прыжке из загрузчика в приложение. При пошаговой отладке всё стартует отлично.
Непонятно, почему работало при отладке?
Программисты порой как туземцы какие-то вообще не понимают с чем работают.
Это относится не только к программистам, а к большинству представителей любой профессии, увы.
Пришлось либо отрубать аппаратный FPU ( -mfloat-abi=soft ), либо включать сопроцессоры FPU.
Неудивительно: компиляторы пишут люди; людям свойственно ошибаться.
Оказывается, при инициализации CAN вызываются прерывания, на которые нет обработчика.
По правилам хорошего тона, принято в неиспользуемых векторах прерывания помещать безусловный jump по адресу с функцией, которая выставляет где-нибудь в оперативке флаг наподобие unused_int_detected. Тогда проблему можно быстро обнаружить при отладке. Также полезно поместить аналогичный jump в конце таблицы прерываний, если это допустимо по карте памяти.
Недавно встретили баг, на новой версии компилятора.
Прошивка просто висла при прыжке в функцию, логи нормально помочь не смогли, полезли программатором, оказалось что компилятор новой версии генерировал инструкцию LDRD, для того что бы вытащить uint64_t. Который у нас находился по невыравненному адресу. А ядрышко так не умеет :)
STM32F437
Компилятор старой версии генерировал просто 2х LDR.
Как-то возился с проектом на Arduino.При питании от прошивочного кабеля все отлично, при запитке от качественного БП 5В перезагрузки,кривая работа АЦП. Копал железо,копал софт, но вот вообще даже не мог представить,что на свежекупленном стандартном f-f проводке ,через который шло питание чисто для Arduino, будет падать от двух вольт.
Баг с номером 11 явно не решен.
11--Загадочные прерывания.
У ARM ар поводу этого есть отдельная errata. Этот баг исправляют не так.
Вообще странно читать от разработчика под ARM-ы столько перечислений багов и ничего про баги связанные с шинами и кэшировнаием.
Видимо потому что эти баги так и остались нерешенными.
Кстати было бы интереснее прочитать про баги которые так и остались в коде и их заткнули заплатками.
Самые жуткие нерешаемые баги обычно связаны с дефицитом RAM в микронтроолерах из-за чего приходится химичить с опенсорсами, которые писали под линукс, но портировали на микроконтроллеры. Например, ничего нельзя поделать с фрагментацией кучи.
Из недавнего. Досталась мне по наследству плата. Которая по легенде мелкосерийная, и даже неоднократно отгружались заказчикам. Только вот глядя в квартусе на "код" понимаю, что оно вероятно не могло работать. А при включении оказалось, что диод по питанию впаян неправильно - то есть впаян согласно документации, но по сути не так, питания на плату не поступает. Кварцы (а их 4шт) не на те частоты что надо. Жтаг разведен зеркально. И много другое.
Наткнулся на вот такую подборку: STM32 gotchas Что-то неочевидно, а что-то было найдено до включения в эррату.
Статься супер!
Коллеги, подскажите где искать работу по программированию микроконтроллеров на удалёнке для стажёра/джуниора? Не могу себя выше оценивать, настоящие и крупные проекты не видел и не занимался ими, сейчас работаю в другом направлении айтишного мира. Лично для себя и на заказ делаю несложные платки и пишу код под stmки и атмеги. Пытался искать на hh.ru, но там вакансий кот наплакал, либо требования заоблачные
работу по программированию микроконтроллеров на удалёнке
Благодарю за оценку текста.
Однако, чтобы в принципе делать embedded software нужен физический доступ к многочисленному и разнообразному калейдоскопу всяческого промышленного оборудования.
Монтажные мастерские, программируемый блок питания, осциллограф, логический анализатор, DMM, микроскоп, тепловизор, векторный антенный анализатор.
Это главное и основное отличие программирования-микроконтроллеров от, например,
того же Web программирования.
Едва ли вообще можно эффективно работать в роли embedded удаленно.
Это как удаленно от плиты готовить еду, удаленно красить стены, строить дом или
удаленно работать воспитателем в детском саду.
Программист МК - это профессия производственная и тут нужно физические первостепенное воздействие на прототип или изделие.
В YADRO есть стажировки на embedded вакансии, удаленка очень сильно развита, сам успешно работаю из Владивостока.
О, так так. Ситуаций таких много, уже и не вспомнишь навскидку, но что-то отложилось
Во многих ситуациях - Очень удаленная отладка. Прям пол страны
1. В один из дней МК в отладчике ведёт себя странно и рестартует после случайного времени работы. Прошивка большая, от другого прибора, юарта нет, всякое может быть. Думаю, потом разберусь, сейчас свою часть запущу и начну копать. На следующий день плата не шьётся. MassErase не срабатывает, но блоки трутся. Вспоминаю, что недавно на этой плате убили ПЛИС, подав высокое напряжение, начинаю копать в эту сторону - прошу коллег посмотреть потребление. На эту просьбу поднимают ток и плата перестает подхватываться отладчиком. Ну, думаю, сгорела. Потом они решили ещё покрутить и плата заработала без проблем.
Ответ убил:
"У тебя просто сейчас источник говеный, нормальные кончились". Источник стоит теперь другой
2. Простейшая связка - i2c датчик, два резистора и МК. Ну не видит его, хоть ты тресни, на АСК не отвечает. Прошу перепроверить схему подключения. Ответ:
"Да там проверять нечего, все как надо, ну ладно, глянем"
Оказалась классика - плюс и минус у датчика перепутаны
3. Поворотное устройство. Стоят модные tmc2209(не модули, а на общей плате) и ШД с редуктором 1:50/100. Должно пальцы ломать, но что-то прям вяленькие, еле тянут. И каких только токов-режимов я не перепробовал - ну, не тянут. Уже смирился - может подделка попалась. В один день было чуть больше времени и желания разобраться. Оказалось, vref был посажен на землю.. Отпаял резистор, переконфигурировал и потянуло
4. Этот же проект. Простой баг. Раз на раз работают концевики оптические - в один день нормально, в другой не очень и сильно "мажут". Оказалось ток светика оптопары находился на границе включения. И, иногда, просто было солнечно
5. Самодельное реле с датчиком тока. Показания тока "плавают". В реле без тока то показывают ток, то нет - зависит от устройства. Просят посмотреть, что-то придумать в ПО для компенсации. К слову, этим проектом уже 3 до меня занимались. Посмотрел на датчик тока - а это датчик на Холле прям рядом с эм-реле..
5. Была доп. плата расширения, которая занималась управлением всякими дополнительными устройствами. Подключалась по i2c в режиме slave к сложной системе i2c расширителей. Данных к этой плате каталось много. На столе работает отлично. На готовом изделии в первый же день в 4 часа ночи перезагрузка по wd. Оказалось, что иногда, (очень редко) в эту же линию одновременно с Большим Устройством стучался мастер управления питанием и на I2C случался мультместеринг
6. В одном из устройств внезапно начались страшные глюки консоли. Был Uart и Rx и tx линии выходили на корпус. Один раз просто кто-то решил, что хорошо бы, если бы были линии data скрученные..
7. Даже вспоминать страшно сколько (на заре карьеры) крови выпила у меня enc28j60, которую решили заложить в проекте, т.к. "её постоянно используют в модулях для ардуинок"
8. Сжёг девайс, т.к. по совершенно одинаковым разъемам подавалось 12В и сотни постоянки
9. Приносят коррбку плат - "ой, не прошивается, не работает, наверное прошивка, проверь". Плата без признаков жизни или смерти (изначально разработана без единого светодиода). Подключил, прошил, не работает. Начал копать схему. Оказалось - в новых(пару лет назад) схемах была добавлена ошибка с расположением диода на питании (защита от обратного включения). И кто-то новенький просто был не в курсе этой фичи
Даже вспоминать страшно сколько (на заре карьеры) крови выпила у меня enc28j60, которую решили заложить в проекте, т.к. "её постоянно используют в модулях для ардуинок"
Аж ностальгия взяла. В далёком седьмом классе делал проект блока реле с управлением с компа (и вроде ещё какими-то фишками). Вот там была ардуино и этот модуль на ENC28J60. Ух сколько моей крови было тогда им выпито... К слову, в итоге с ним так и не запустилось, перешёл на Wiznet W5100.
Сжёг девайс, т.к. по совершенно одинаковым разъемам подавалось 12В и сотни постоянки
А вот и пример. Это шнурок от платёжного терминала Lipman Nurit с уникальной израильской технологией "RS-232-over-USB". Да, вместо USBшного питания там 12 В, а вместо D+ и D- обычные RX и TX (c уровнями в 9 В).
Авторам таких переходников отдельный котел в аду заготовлен, без терморегулятора.
У Ingenico ещё был кабель RS-232, где зачем-то на другой конец бахнули тоже miniUSB (ну хоть 12 В питания не пустили). Вообще, несколько лет с такими девайсами, и приучаешься, что:
8P8C - это не всегда сеть. Я бы даже сказал, зачастую вообще не сеть. (пример - практически любой девайс с RS-232, где в качестве порта не DB9)
По HDMI можно пускать RS-232. (VeriFone VX670, VX680, NewPOS 8110)
По USB может идти 24 В, причём без каких-то протоколов типа PD, а просто напрямую. И по линиям данных. (какая-то китайская настольная лампа)
USB можно пускать вообще по каким-то адовым разъёмам типа ШР или РС. (электроника на ЖД/метро)
Если в кабеле питания красный и чёрный провод, не стоит преждевременно думать, какой провод куда. (ну, это каждый из нас видел)
И это далеко не всё.
RS-232, где зачем-то на другой конец бахнули тоже miniUSB
Разблокировано воспоминание (;
На одном из девайсов-коробочек (с линуксом внутри) был на панели USB разъем в который опасно было втыкать флешки. Там было 24В питание и 485RS по Data. Не знаю, пошло ли в серию)
Вот ещё из вспомнившегося:
DB9, DB25 и DHS15 за пределами компьютерной техники практически никогда не COM/LPT/VGA. Я бы даже сказал, уже поднадоели личности, называющие DB9 "COM-портом". (также всякое промоборудование)
Эти же самые разъёмы в компьютерной технике порой тоже не то, чем они кажутся. Или таки то, но с заведомо перепутанной распиновкой. (бесперебойники APC)
3,5 мм - это зачастую не аудио. И даже не питание, как в некоторых китайских девайсах, а вообще неведомая лажа. (денежный ящик в древних кассах)
Разъём ATX 12V может служить для того же, что и в обычном компе, но быть с перепутанной полярностью (питание Apple Power Mac)
Чувствую, тут на отдельный пост хватит. В духе "Худшие схемотехнические решения по части интерфейсов".
3,5 мм - это зачастую не аудио. И даже не питание, как в некоторых китайских девайсах, а вообще неведомая лажа.
Мы на прошлой работе Audio Jack 3,5 мм использовали для CAN.
По поводу (8) - обязательно очень внимательно проверяю устройства и блоки питания с простым круглым штеккером 5,5-2,5. Очень редко, но попадается плюс не в центре, а на наружной обойме. Чаще попадалось на японской аппаратуре.
В Debug прошивка работает, в Release - нет. Думалось и проверялось разное, дошло до пресловутого "мрачного разглядывания дизассемблерного листинга". И тут вообще стало жутко.
В дебаге по некой формуле рассчитывается значение и кладётся в переменную. В релизе - какие-то ошметки от предвычислений, и на этом всё.
Переменная для обмена с соседним ядром, данную кладёт одно, проверяет содержимое - другое.
В объявлении потеряли volatile, релиз "оптимизировал" код сохранение "не используемого" значения, и половину его вычисления. Какие-то ошметки вычислений в скобках при этом почему-то остались.
"Оказалось ток светика оптопары находился на границе включения. И, иногда, просто было солнечно "
Вот это прямо хорошо.
Встречал ещё более фееричное - когда блик от вращ. детале не опытном стенде триггерил оптический концевик.
Самые Эпичные Баги при Программировании Микроконтроллеров