Comments 72
Микроконтроллер поставляется в упаковке, которой позавидуют китайцы с AliExpress.
Вы, судя по высказыванию, никогда не заказывали микроконтроллеры не на AliExpress.
UFO just landed and posted this here
Ну китайцы-китайцу рознь, некоторые могут и просто LQFP россыпью в зиплок насыпать ))
А так вроде на фотках можно сказать практически стандартная упаковка для всех кто занимается электроникой, штатная подложка от производителя, пакетик силикагеля, индикатор влажности и все это в вакуумный антистатический пакет, а поролон сверху уже по вкусу )
А так вроде на фотках можно сказать практически стандартная упаковка для всех кто занимается электроникой, штатная подложка от производителя, пакетик силикагеля, индикатор влажности и все это в вакуумный антистатический пакет, а поролон сверху уже по вкусу )
Могу показать партию из Маузера с загнутыми ногами. Штук 20 контроллеров испоганили. Деньги вернули…
Эта упоротая упаковка говорит только о том, что на российских предприятиях электронной проиышленности мало что изменилось с советских времен. Во всяком случае именно в упаковке. Я помню точно такие коробки и фольгу для микросхем еще в 80-м году :/
Не на предприятиях, а в ГОСТах, которым они обязаны соответствовать. Уж кого странно упрекать в советскости, так это «Миландр», начавший разработку микросхем уже в 21 веке.
Я их не упрекаю, я только вспоминаю былое ;)
Упаковка реально не изменилась за 40 лет.
В любом случае, кривая коробка из картона низкого качества не делает им чести и косвенно показывает их уровень и объёмы производства.
Упаковка реально не изменилась за 40 лет.
В любом случае, кривая коробка из картона низкого качества не делает им чести и косвенно показывает их уровень и объёмы производства.
Я склонен полагать, что вы придаете излишнее значение весьма мелким факторам. У меня подобная упаковка конечно вызвала бы улыбку, но вряд ли это что-то говорит об их уровне. Об объемах — может быть, хотя это и без коробок ясно.
Театр начинается с вешалки, а товар с упаковки.
Поскольку у них не товар (в смысле не нацелен на рынок imho), то их нормальная упаковка не волнует.
В общем, меня их продукция, технологический уровень, цели и задачи и не интересуют. Я не собирался и не собираюсь глубоко копать ;)
Всем добра!
Поскольку у них не товар (в смысле не нацелен на рынок imho), то их нормальная упаковка не волнует.
В общем, меня их продукция, технологический уровень, цели и задачи и не интересуют. Я не собирался и не собираюсь глубоко копать ;)
Всем добра!
Опять же — вы преувеличиваете. Были в свое время такие оптроны — АОТ110 — так они на полном серьезе были конкурентны в ряде применений, продавались на каждом углу и в больших количествах (в свое время). И поставлялись с завода при этом в таких же убогих картонных коробках, и никого это не волновало.
Для сравнения — прекрасные оптроны 6N137, шедшие по жизни в треях, и по жизни с мятыми ногами, а какой там корпус и как потом эти ноги исправлять — это вы сами в интернете можете подивиться. К автоматической установке они после этого были непригодны. Хотя может это нам так «везло», потому что почти всегда они были от одного производителя.
Для сравнения — прекрасные оптроны 6N137, шедшие по жизни в треях, и по жизни с мятыми ногами, а какой там корпус и как потом эти ноги исправлять — это вы сами в интернете можете подивиться. К автоматической установке они после этого были непригодны. Хотя может это нам так «везло», потому что почти всегда они были от одного производителя.
Западные производители ориентированы на автоматическую установку компонента на плату. Поэтому детали поставляются или на ленте, или на кассете (tray). Главное в этих системах то, что их легко открывать — лента сматывается с катушки, плёнка на ленте отрывается машиной, стопка кассет раскрывается человеком или роботом одним движением. Все компоненты находятся более-менее на месте, чтобы их можно было захватить по центру.
Защита от статики осуществляется самим носителем (слабо проводит ток). Кассеты и катушки с боящимися статики компонентами помещают в пакеты из фольги, иногда пакеты кассет опрессовывают вакуумом. Этого достаточно.
Более того, герметичная упаковка требуется для защиты от влаги. Если слегка отсыревшую деталь при пайке быстро нагреть до +300 градусов, она немножко взорвётся. Если упаковка нарушена, детали перед установкой надо сушить много часов при определённой температуре. Даже пассивные элементы, не особо боящиеся статики, поставляются в заваренных пластиковых пакетах, иногда с поглотителем влаги внутри.
Защита от статики осуществляется самим носителем (слабо проводит ток). Кассеты и катушки с боящимися статики компонентами помещают в пакеты из фольги, иногда пакеты кассет опрессовывают вакуумом. Этого достаточно.
Более того, герметичная упаковка требуется для защиты от влаги. Если слегка отсыревшую деталь при пайке быстро нагреть до +300 градусов, она немножко взорвётся. Если упаковка нарушена, детали перед установкой надо сушить много часов при определённой температуре. Даже пассивные элементы, не особо боящиеся статики, поставляются в заваренных пластиковых пакетах, иногда с поглотителем влаги внутри.
хоть и в документации сказано, что поддерживает SWD интерфейс, но как и куда что подключать упомянуть забыли
Это же Миландр. У них многое так в документации.
Видимо после перепрошивки линии порта JTAG-A переопределяются на другое функциональное назначение, хотя в программе порт B на котором находится JTAG-A даже не инициализировался. Разбираться в этом не хотелось, так как есть еще и JTAG-B.
Напоминает подход к решению проблемы классического ардуинщика.
Прерывание передатчика работает по фронту, а не по уровню сигнала. В случае, если модуль и прерывания от него разрешены до осуществления записи данных в буфер FIFO передатчика, прерывание не формируется. Прерывание возникает только при опустошении буфера FIFO.
Опустошение буфера FIFO передатчика не гарантирует передачу последнего байта наружу в линию, это же Миландр.
Опустошение буфера FIFO передатчика не гарантирует передачу последнего байта наружу в линию, это же Миландр.Отнюдь не являюсь проповедником импортозамещения, но Миландр здесь ничем не отличается от других: опустошение FIFO буфера означает лишь то, что последний байт данных поступил в сдвиговый регистр трансмиттера, а вовсе не выплюнут в линию.
Плюсую, как минимум на STM32 в точности так же, сам баг ловил )
У STM32, помимо прерывания TXE, есть прерывание TC, которое надо разрешать только при передаче последнего байта посылки и тогда оно как раз и будет соответствовать моменту окончания передачи данных в линию. Именно так и рекомендуется делать в официальной документации STM AN3070
На волне импотрозамещения портировал на сабж ChibiOS для одного выставочного проекта. Так вот UART точно такой же как у NXP. Драйвер подошел как родной.
Прерывание передатчика работает по фронту, а не по уровню сигнала. В случае, если модуль и прерывания от него разрешены до осуществления записи данных в буфер FIFO передатчика, прерывание не формируется. Прерывание возникает только при опустошении буфера FIFO.
Ох как по больному-то месту вы прошлись сейчас!
У нас были постоянные проблемы с преобразованием UART'a в 485, потому что преобразователь нужно переключать в режим приема только после того, как на линию будет отправлен последний байт целиком.
Но в Миландре нет прерывания «передача завершена», только «буфер передатчика пуст». Для события «передача завершена» есть только флаг.
Если проверять флаг, то можно не успеть и переключиться на прием слишком поздно, когда другое устройство на шине уже начало что-то передавать — слишком позднее переключение отрезает от этой посылки кусочек бита.
Вопрос
Возможно, стоить пилить пост про то, как мы эту ситуацию в итоге разрулили?
Самое обидное, что Миландр не собирается переделывать периферию (по большей части) и этот UART так и будет переезжать в новые процы :(
Еще более странно, что ни в одном зарубежном МК я с такой ситуацией не сталкивался, везде было прерывание по событию «передача завершена». А в миландре — нету.
При этом, у НИИЭТ тоже есть МК на ядре ARM Cortex (К1921ВК01Т), и в тамошнем UART'e тоже нет такого прерывания. Совпадение? Или по Зеленограду кочует один и тот же UART?
Запилите пост — это достаточно серьезная проблема. Я например не выключаю приемник и принимаю собственное эхо.
Если проверять флаг, то можно не успеть и переключиться на прием слишком поздно, когда другое устройство на шине уже начало что-то передавать — слишком позднее переключение отрезает от этой посылки кусочек бита.
Я на это дело подвесил таймер(знаем размер и скорость порта) и уже в прерывании таймера проверяю флаг. Этим же таймером формирую таймауты на RS485.
Таймеры наше все. Особенно, когда нужна универсальная либа 485, которая без особых переделок будет работать на разных семействах.
В прерывании «фифо пуст» взводим таймерок и уже в прерывании по таймеру переключаем с передачи на прием. Приоритет для таймера можно максимальный поставить, ибо обработчик короткий. Да, костыль, но что делать. Отсутствие прерывания по концу передачи совсем не редкость.
В прерывании «фифо пуст» взводим таймерок и уже в прерывании по таймеру переключаем с передачи на прием. Приоритет для таймера можно максимальный поставить, ибо обработчик короткий. Да, костыль, но что делать. Отсутствие прерывания по концу передачи совсем не редкость.
Но Миландр в Зеленограде, а НИИЭТ в Воронеже)
Впрочем, это может не мешать кочевать одному и тому же UART.
Впрочем, это может не мешать кочевать одному и тому же UART.
Все уже придумано за нас
if (isr & UART_MIS_TXMIS)
{
if (u->FR & UART_FR_TXFE)
{
osalSysLockFromISR();
msg_t b = sdRequestDataI(sdp);
osalSysUnlockFromISR();
if (b >= Q_OK) {
u->DR = b;
}
}
/* Physical transmission end.*/
if ((u->FR & UART_FR_BUSY) != UART_FR_BUSY)
{
osalSysLockFromISR();
if (oqIsEmptyI(&sdp->oqueue))
chnAddFlagsI(sdp, CHN_TRANSMISSION_END);
osalSysUnlockFromISR();
u->IMSC &= ~UART_IMSC_TXIM;
}
}
{
if (u->FR & UART_FR_TXFE)
{
osalSysLockFromISR();
msg_t b = sdRequestDataI(sdp);
osalSysUnlockFromISR();
if (b >= Q_OK) {
u->DR = b;
}
}
/* Physical transmission end.*/
if ((u->FR & UART_FR_BUSY) != UART_FR_BUSY)
{
osalSysLockFromISR();
if (oqIsEmptyI(&sdp->oqueue))
chnAddFlagsI(sdp, CHN_TRANSMISSION_END);
osalSysUnlockFromISR();
u->IMSC &= ~UART_IMSC_TXIM;
}
}
Самое обидное, что Миландр не собирается переделывать периферию (по большей части) и этот UART так и будет переезжать в новые процы :(
Это им не выгодно. И разработчик мог уйти в другую контору. Я так столкнулся с одним поделием Миландра. А в целом изделия Миланда — это боль. Хорошо, что UART не выпилили из МК, как в свое время они поступили с CAN-ом в одном из серии на ядре ARM.
Обидно, что они не переделывают периферию даже в своих инициативных работах (в смысле в тех, которые без заказчика).
В целом, боль, конечно, но я вынужден признать, что в России — это лучший производитель микроконтроллеров.
В целом, боль, конечно, но я вынужден признать, что в России — это лучший производитель микроконтроллеров.
И что особенно хорошо — они все-таки меняются в лучшую сторону, пусть и не быстро. Недавно глянул еррату на один из их МК — е-мое, она появилась обновилась! Я причем даже содержанием был реально удивлен, чесслово. Мне как бы параллельно оно, я импортозамещением не скован, но вот за тех, кто скован, я как-то порадовался, ведь эта еррата будет им вполне полезна. Особенно если учесть, что кажется все просмотренные мной баги по их утверждению пофиксены в последней версии (и это не похоже на случай, когда «и еще миллион багов просто пока не описан»).
Не знаю, о каком именно чипе вы говорите, но, допустим, у 1986ВЕ1T все еще есть неисправленные ошибки в эррате.
Например,
«0011 Ошибка системного таймера
Статус
Будет исправлена только в случае замены ядра.»
Или «0014 Возникновение Hard Fault в режиме run time при отображении
содержимого периферии
Статус
Исследование.»
Плюс есть некоторое количество не столь фатальных ошибок, а, скорее, неприятных моментов. В эррате про них не пишут, на форуме на вопросы отмалчиваются.
Ну и основная документация страдает от некоторой эээммм скажем так недосказанности :).
Например,
«0011 Ошибка системного таймера
Статус
Будет исправлена только в случае замены ядра.»
Или «0014 Возникновение Hard Fault в режиме run time при отображении
содержимого периферии
Статус
Исследование.»
Плюс есть некоторое количество не столь фатальных ошибок, а, скорее, неприятных моментов. В эррате про них не пишут, на форуме на вопросы отмалчиваются.
Ну и основная документация страдает от некоторой эээммм скажем так недосказанности :).
Ну, я не буду утверждать, что там все шоколадно, особенно в части «досказанности», меня радует сам факт развития.
По поводу отсутствующих в еррате ошибок — ну это тоже обычная в общем-то проблема, она у всех некрупных производителей встречается. Имел аналогичный опыт с продукцией тайваньской RDC — и ничо, жили как-то.
По поводу приведенных вами примеров: ну, 0014 я бы вообще не принимал близко к сердцу (характер у меня такой), вот 0011 уже хуже и, к сожалению, тяжело ловится в рантайме, представляю, как пригорало у нашедших. Впрочем — а сколько еще подобного живет у более именитых производителей, но не поймано? Из своего опыта скажу, что большая еррата лучше, чем маленькая (если только речь не про Интел).
По поводу отсутствующих в еррате ошибок — ну это тоже обычная в общем-то проблема, она у всех некрупных производителей встречается. Имел аналогичный опыт с продукцией тайваньской RDC — и ничо, жили как-то.
По поводу приведенных вами примеров: ну, 0014 я бы вообще не принимал близко к сердцу (характер у меня такой), вот 0011 уже хуже и, к сожалению, тяжело ловится в рантайме, представляю, как пригорало у нашедших. Впрочем — а сколько еще подобного живет у более именитых производителей, но не поймано? Из своего опыта скажу, что большая еррата лучше, чем маленькая (если только речь не про Интел).
При этом, у НИИЭТ тоже есть МК на ядре ARM Cortex (К1921ВК01Т), и в тамошнем UART'e тоже нет такого прерывания. Совпадение? Или по Зеленограду кочует один и тот же UART?
Достаточно одного взгляда на карту регистров, чтобы понять, что это один и тот же IP :)
Однако, в последних камнях НИИЭТ прерывание «передача завершена» появилось.
А можете пару примеров таких камней привести? Или они не на Cortex'e?
Вот в этой теме на форуме есть ссылки на рабочие версии описаний и некоторая другая информация.
Ребята, а в чем проблема? Вот есть мной нежно любимый TL16C550, коих кажется в мире работает сейчас не меньше, чем Миландр всех микросхем выпустил. И там, как щас помню, есть только THRE (прерывание по опустошению буфера передатчика), и ничего — жили нормально, RS-485 работал, как-то вот вертелось это все с применением одного из двух простых решений.
Вот что меня удивляет в российской электронике
Так ведь это тип корпуса, корпус «импортный» — буква тоже «импортная». Всё логично.
Такой «вывих» встречается и в ГОСТах, например название корпуса русскими буквами, а варианты — латиницей.
Меня удивляет то что они один и тот же кристалл упаковывают в разные корпуса, и при этом четко отказываются упаковывать данный кристалл в корпус LQFP144, тем самым кастрируют много периферии…
Видимо после перепрошивки линии порта JTAG-A переопределяются на другое функциональное назначение, хотя в программе порт B на котором находится JTAG-A даже не инициализировался. Разбираться в этом не хотелось, так как есть еще и JTAG-B.
В файле MDR32F9Qx_config.h выберите #define USE_JTAG_A
Косяк с отвалом JTAG\SWD при «прикосновении» к его порту — просто феерическая боль, через которую обязан пройти каждый, начинающий работу с мк Миландр. Они даже как бы намекают на проблему присутствием второго порта JTAG. Стоит отметить, что библиотеки, в принципе, сносные. Если появится желание поднять USB CDC — после долгих мучений и исследований форума Миландра всплывет прикол с define-ом, который надо прописать, чтоб он работал полноценно.
Сделали бы поддержку Arduino, был бы интерес со стороны энтузиастов. А так только для профессионального использования МК.
С чего бы «энтузиаст» добровольно выбрал более дорогой и хуже документированный контроллер, если над ним, в отличие от некоторых «профессионалов», не стоит демон «импортозамещения»? И потом, разработчик-любитель («энтузиаст») — вовсе не синоним слова «чайник». Почему бы ему не воспользоваться человеческими системами разработки, а не Arduino IDE?
Чем больше выбор железа, тем в целом лучше для экосистемы. Что касается «импортозамещения», то энтузиаст здесь чем отличается от профи? завтра запретят ввоз Atmel и ST, и дальше что? мультивибратор на КТ315? :)
завтра запретят ввоз Atmel и ST, и дальше что? мультивибратор на КТ315? :)Если дойдет до такого маразма, то можно только догадываться, что еще запретят из областей, отличных от электроники. Боюсь, что в такой ситуации количество любителей помигать светодиодом, на чем бы это не строилось, резко поубавится, т.к. они будут заняты решением более насущных проблем. Что касается профессиональных разработчиков, то на чем прикажут, на том и будут строить мультивибраторы — может на КТ315, а может и на МП39, или даже на 6Н2П.
А может стоит расти из ардуинщиков в профессионалы?
Может, но Arduino снижает порог входа в технологию, нужно начинать с чего-то простого чтобы потом расти дальше.
Arduino снижает порог входа в технологию
Возможно. Но есть один важный нюанс, что большинство комьюнити ардуинщиков состоит из не профессионалов, профессионалам ардуино не интересна. И как следствие приводит к росту не грамотных. Есть живой пример и не один.
В эпоху отсутствия ардуино, как-то входили в технологию программирования микроконтроллерных и микропроцессорных встраиваемых систем.
Проблема ровно в том, что подавляющее большинство ардуинщиков не хочет расти дальше, а хочет клепать на Ардуино все и вся, включая вещи для автоэлектроники, промышленной техники, медицины и т.д. и т.п. И вот это надо жёстко пресекать, а то люди потом электроды от Ардуино к голове без гальванической развязки подключают и продают это задорого.
Спасибо за статью… мало что то стало сейчас на хабре специалистов по железу… :(
- Есть и у кого нибудь возможность протестировать рабочий температурный диапазон у этого кристалла ?? -40/ +85 C он потянет ?? В авто электронике его использовать можно ?
- Ардуино совместимый контроллер из него сделать можно ?
Есть и у кого нибудь возможность протестировать рабочий температурный диапазон у этого кристалла ?? -40/ +85 C он потянет ?Если Вы не доверяете данным из этикетки производителя, заверенные печатью его службы контроля качества, то, наверное, следует присмотреться к продукции более надежного на Ваш взгляд производителя, а не просить «кого нибудь» проверить данный параметр. Кстати, если Вы не доверяете данным производителя, то почему только приведенному рабочему диапазону температур, а другие заявленные характеристики у Вас не вызывают сомнения?
Ардуино совместимый контроллер из него сделать можно ?Это как то не гармонирует с Вашим же первым вопросом.
1886ВЕ3У при минус 60 °С работает.
мало что то стало сейчас на хабре специалистов по железу…
Специалистов хватает, просто им некогда писать статьи.
Это очень плохо и печально. Нормального железячного коммьюнити нет, и получается, что даже те самые профессионалы, у которых нет времени писать, в итоге тоже закисают в своих местечковых болотах, не говоря уже о том, что новичкам не у кого учиться. А потом новички вырастают и проектируют чипы криво, потому что не знают, что можно было по-другому.
Есть и у кого нибудь возможность протестировать рабочий температурный диапазон у этого кристалла ?? -40/ +85 C он потянет ?? В авто электронике его использовать можно ?
Кристаллы у данной серии едины, в пластик корпусируется в Китае, в золото у нас в стране. Вам остается только правильно выбрать исполнение.
Ардуино совместимый контроллер из него сделать можно ?
Можно. Только кому оно нужно?
Cмотря какой грейд вам нужен.
AEC-Q100
в металле — работает, жрёт мало,
термовакуумные испытания держит…
термовакуумные испытания держит…
Del, ошибся веткой из-за глюка мобильной версии (
Поделитесь пожалуйста проектом с разводкой платы под МК.
Делюсь, проект и схема по ссылке.
Кто-нибудь,
1. Проясните, пожалуйста, про интервалы. В документации с сайта modbus.org сказано:
Насколько я понимаю, в FreeModbus используется только t3.5, соответственно, в основанных на нём портах — тоже. Во всяком случае, в виденных мной. Но почему? Ведь теоретически может получиться, что межсимвольный интервал будет, скажем, t1.6, и тогда придётся «браковать» фреймы, хотя данные в них корректны.
2. Проверьте, пожалуйста, работу с Coils на «правильном» железе, т.е которому доверяете на ~100%. Насколько я помню и понимаю, в FreeModbus 1.5 (1.6, вроде, не отличается) она некорректно реализована, т.е. не соответствует документации с сайта modbus.org. Хочу получить независимое подтверждение/опровержение.
1. Проясните, пожалуйста, про интервалы. В документации с сайта modbus.org сказано:
In RTU mode, message frames are separated by a silent interval of at least 3.5 character times.
…
If a silent interval of more than 1.5 character times occurs between two characters, the message frame is declared incomplete and should be discarded by the receiver.
Насколько я понимаю, в FreeModbus используется только t3.5, соответственно, в основанных на нём портах — тоже. Во всяком случае, в виденных мной. Но почему? Ведь теоретически может получиться, что межсимвольный интервал будет, скажем, t1.6, и тогда придётся «браковать» фреймы, хотя данные в них корректны.
2. Проверьте, пожалуйста, работу с Coils на «правильном» железе, т.е которому доверяете на ~100%. Насколько я помню и понимаю, в FreeModbus 1.5 (1.6, вроде, не отличается) она некорректно реализована, т.е. не соответствует документации с сайта modbus.org. Хочу получить независимое подтверждение/опровержение.
1. По спецификации отправитель должен быть уверен что самый большой интервал между байтами одной посылки 1,5Т, а получатель что все байты которые разделены интервалом менее или равным 1,5Т являются байтами одной посылки. Когда байты разделены более чем 3,5Т то это последний байт предыдущей посылки и следом первый байт новой.
Причина таких интервалов в том что Т отправителя может отличаться от Т получателя, но 1.5Т отправителя всегда будут меньше 3,5Т получателя. Это можно трактовать как: «Будьте либеральны к тому что принимаете, и консервативны к тому что отправляете».
На практике интервал 1,5Т не используют, так многие слейв устройства из-за неправильно расставленных приоритетов прерываний, (обычно modbus имеет самый низкий приоритет) могут прерывать передачу и на большие интервалы, и не контролируют этот параметр. Собственно это не имеет смысла так как новая посылка должна начаться с интервала в 3,5Т, и если интервал превышает 3,5Т то предыдущая и следующая посылка будут отброшены по проверке контрольной суммы.
Думаю для большей поддержки разнообразных устройств все и отступают от контроля этого интервала.
Причина таких интервалов в том что Т отправителя может отличаться от Т получателя, но 1.5Т отправителя всегда будут меньше 3,5Т получателя. Это можно трактовать как: «Будьте либеральны к тому что принимаете, и консервативны к тому что отправляете».
На практике интервал 1,5Т не используют, так многие слейв устройства из-за неправильно расставленных приоритетов прерываний, (обычно modbus имеет самый низкий приоритет) могут прерывать передачу и на большие интервалы, и не контролируют этот параметр. Собственно это не имеет смысла так как новая посылка должна начаться с интервала в 3,5Т, и если интервал превышает 3,5Т то предыдущая и следующая посылка будут отброшены по проверке контрольной суммы.
Думаю для большей поддержки разнообразных устройств все и отступают от контроля этого интервала.
Sign up to leave a comment.
Modbus на российском микроконтроллере К1986ВЕ92QI