Комментарии 22
Зачем было снимать плату индикации, как я понимаю чисто сервисную, и затем городить её аналог на микроконтроллере, чтобы не пищало? Если достаточно было сдублировать сигналы идущие на нее на вход своего анализатора/логгера?
Насколько помню, плата индикации занимала много места, и очень хотелось от неё избавиться, чтобы больше места осталось для Raspberri Pi. Потом захотели более аккуратный адаптер RS-485 и желательно свой, в виде shield'a, как на картинке. Покупные мезонинные адаптеры для Pi чем-то не устраивали Заказчика. Заодно решили окончательно избавиться от писка. А так совершенно согласен, если бы знали заранее, что программными методами окончательно не избавимся, то логичнее было бы плату индикации оставить.
>дешевый китайский логический анализатор
это пиратский клон реально существующего анализатора от Saleae, оригинал стоит от $500, то что у вас - втыкать в важные устройства немного опасно. тоже самое можно сказать о софте который с ним идёт.
У Заказчика в итоге сгорел сам анализатор, и не один. Подозреваю, что он на горячую куда-то подключал. У меня ни разу не сгорал, часто пользовался, особенно при отладке программ для микроконтроллеров. Но они очень дешевые и легко купить. Программу скачивали с официального сайта Saleae Logic.
Поддерживаю, у самого есть отладка на CY7C68013A, использовал её с Saleale Logiс, но как-то не зашло, в итоге перешел на PulseView (sigrok) - ничуть не хуже.
Также был опыт использования Kingst LA1010 (сейчас стоит 3.4кР, ранее стоил примерно 2кР), с их софтом - у него больше частота дискретизации, до 100МГц, и 16 полноценных каналов. Софт родной китайский в целом нормальный, но иногда вис намертво при подключении анализатора или запуске анализа, так и не понял, в чем дело.
В целом, для большинства проектов вполне хватает и самого простого анализатора, очень сильно выручал много раз.
Например, была задача отреверсить протокол подключения датчиков и моторов к детскому конструктору WeDo 2, чтобы непрофессионалу можно было удобно проверять большое количество периферии, просто подключая её к разъему, и тыкая кнопочку (среди периферии есть датчик наклона на гироскопе, датчик расстояния на ИК-датчике отражения и мотор, надо было наглядно показывать, что работает ОК). Протокол там простецкий, на базе UART, просто меняется часть данных в посылке - можно было даже USB-UART + терминалом отреверсить, но проще и безопаснее сначала проверить, что там точно UART, а не I2C, например.
К сожалению, дальше прототипа дело не пошло, ковид усилился, денег в компании стало мало, проект (а потом и весь инженерный отдел) заморозили:(
Примерно так это должно было выглядеть - недоделанная плата.
Выглядит очень хорошо. И информация по 100МГц полезная, спасибо, иногда 24МГц не хватает, а 100МГц обычно дороже стоят. По нашим разработкам ковид тоже ударил, заказчиков несколько месяцев почти не было, был только заказ для отображения панорамы гидролокатора корейского. Потом хоть заказчики опять появились, например разрабатывали сеть очистителей воздуха на Raspberry Pi с управлением в том числе со смартфона, настройки таймеров озонатора и УФ ламп и т.п. Можно сказать, интернет вещей. Протоколы MQTT, сервер, сайт и т.д. :
Устройства - это очистители воздуха, для ковида востребованы были, особенно год и два назад. Надолго работы хватило. Хотя технические решения были простые.
Спасибо!
По поводу ЛА - насколько я помню, он не может выдавать эти 100МГц при использовании всех каналов, а только при использовании двух или трех из всех. Если использовать все каналы, ЧД падает до 16 МГц или около того, надо смотреть описание. На практике не приходилось доходить до таких частот, поэтому не могу точно сказать, насколько правда. Но один неоспоримый плюс есть - в комплекте просто великолепный USB-A->USB-B кабель, очень гибкий и мягкий, не утягивает ЛА за собой. Брали, кстати, анализатор в оф. магазине на Алике.
Про очистители воздуха - да, в родном городе (Новосибирск) есть компания, которая занимается производством умных бризеров и подобного, несмотря на их цены, покупатели у них есть, а во время ковида стало ещё больше.
А у вас прямо полноценный промышленный интернет вещей выходит, судя по схеме. Если не секрет, как реализовали OTA-обновление на таком масштабе? Отдельным приложением на одноплатнике? При таком количестве устройств без OTA любой баг это ужас просто.
Кстати, не рассматривали ли OrangePi как альтернативу Raspberry? Был с ними опыт работы, в целом, прикольная штука, но конечно, и комьюнити меньше, и доков иногда совсем нет, но цена намного ниже, а версии, которым уже лет 5+ (OrangePi PC) вполне стабильно работают.
Для обновления программ ( ОТА ) организовали SSH туннель к каждой Pi. С Orange Pi мы сталкивались по двум работам, например этой весной с Orange Pi C4. Заказ был по портированию программы с GUI с Raspberry. Включая видеоплеер. Что не понравилось - под полноценную Linux c X server нет видеодрайверов, графические приложения работают очень медленно. Есть видеодрайвер под версию только с консолью. Существующие видеоплееры все с нюансами, ни один под нашу задачу не подошел. Железо в Orange Pi отличное, но c поддержкой производителем драйверами проблема. Мои личные впечатления. Всё с Orange решаемо, но долго и мучительно.
Круто! Но это только проверка имеющейся периферии? Новые дополнительные модули, наверное, сложно будет подружить с контроллером и родным софтом типа WeDo 2.0 LEGO® Education.
И ещё, может знаете живые сообщества по WeDo/Boost/Spike?
Да, это только проверка.
На самом деле чаще всего ломаются моторы, из огромной горы моторов и датчиков (думаю, штук по 80+ было датчиков, а моторов больше сотни, докупали запасные), датчиков поломанных было всего пара-тройка, а вот моторов десятка четыре, практически везде проблемы с кабелем, так как дети как только нвд ними не издеваются:( причем многие моторы были далеко не первый раз на починке.
Чтобы можно было кому угодно поручить проверку моторов, изначально сделал несколько простых тестеров, тупо H-мост на двух парах N+P мосфетов, AO4606, кажется, на скрине выше они в SO-8 корпусе. Управление там обычным слайдером, завтра попробую найти фотку или плату.
Этого в принципе хватало, но потом возникла идея сделать более навороченное устройство для внутренних нужд организации. Легально его продавать вряд ли бы вышло, это для EV3 есть и схемы, и SDK, а для WeDo ничего нет, все закрыто и проприетарно, но пользы было бы много. Ну и дальше случилось то, что случилось, собственно.
Я разбирал дохлые модули и датчики, в датчиках стояли stm8, тогда еще дешманские, а вот насчет блока я не помню, кажется, там стоял EFM32, но могу путать, если надо, могу поискать фото платы, может быть остались.
Как я и говорил выше, никаких доков и SDK найти не удалось, но возможно, если попросить вендора, то он поделится.
Можно попробовать закостылить датчик, сэмулировав один из тех, что в наборе, то есть отправлять свои данные, которые блок будет принимать за данные от родного датчика, но практической пользы от этого, на мой взгляд, мало.
Китайцы отреверсили протоколы и успешно продают копии WeDo 2.0.
По поводу кастомных датчиков/моторов для WeDo/Boost/Spike, имхо, интерес есть. Но может действительно, проще перейти на Ev3. Энтузиасты на ютубе выкладывают разные интересные поделки, комбинируя одинаковые или разные наборы. На мой взгляд, всё упирается в развитые сообщества и методические материалы. В подавляющем большинстве школ преподавание идёт по готовым схемам и возможностям одного конкретного набора. Хотя Lego и декларирует, что наоборот нужно развивать фантазию учеников, чтобы они самостоятельно придумывали новые собственные схемы.
Да, мы, кстати, покупали на ТаоБао коннекторы и кабели к WeDo 2.0, взамен поломанных, так что судя по всему, китайцы просекли фишку:)
Кастомные датчики - ну, в теории, это всё можно сделать, но WeDo в этом плане сильно ограничен, так как работает только с компом/планшетом, и портов всего два. Насчет остальных не знаю. EV3 дороже раза в полтора, если правильно помню, но там полноценный Linux, и железо позволяет сделать почти всё, что захочется, либо купить что-то кастомное у других энтузиастов.
Методику конечно надо развивать, чтобы дети могли использовать разные наборы и собирать что-то свое, если им просто изначально показать, какие есть проверенные решения, и дать теорию, то они очень бодро начинают конструировать вполне неплохих роботов, и чем больше собирают, тем лучше получается. На самом деле на EV3 можно делать и инженерные прототипы какой-нибудь механики, чисто проверить концепцию, будет ли работать или нет.
Ещё есть Lego Technic, но я не слежу, возможно, их уже не выпускают. Там тоже есть где разгуляться, но скорее с точки зрения железа, потому что всё же NXT с EV3 дают бОльшие возможности для программирования.
По поводу сообществ, к сожалению, не подскажу. По Ev3/NXT их раньше было очень много разной степени открытости, по WeDo в основном это детские проекты, а со spike/boost работать особо не довелось, пару раз только мельком их видел.
Огромное спасибо за статью, очень интересно было читать!
Сам одно время занимался и разработкой электроники, и реверсом, и одноплатниками, но с существенно более низкой квалификацией, так как в компании, где работал, не было нормального разделения обязанностей, и приходилось всем делать всё (мои обязанности, например - разработка и изготовление схемотехники и плат, программирование МК/одноплатников, закупка компонентов, работа на станке).
С одной стороны, embedded - это круто, с другой стороны - очень сильно распыляешься, и в итоге страдают навыки.
С нетерпением жду рассказов про другие проекты, очень мало подобных материалов в интернете.
Спасибо за добрые слова! Совершенно с Вами согласен, когда касается реальной электроники, часто приходится становится универсалом. Тут есть и плюсы, начинаешь видеть всю систему целиком, от закупки комплектующих, приборов, изготовления "железа" до программного обеспечения. Можно переложить часть функций с электроники на программы и наоборот. И легче поставить задачу узкому специалисту-профессионалу при необходимости. Для Интернета вещей такое тоже важно, там ещё и серверная часть, сайт, вопросы поддержки всей системы и т.п. Буду писать ещё статьи, исходя из личного опыта.
Да, согласен, в этом же и суть эмбеддед:)
Но всё же для сложных и больших проектов чаще всего недостаточно одного профессионала в эмбеддед, особенно, если там и сети, и механика, и электроника, и Linux. В любом случае где-то да просядут знания, и решение может быть неоптимальным. Возможно, в таком случае проще будет как раз привлечь разово специалиста, чтобы потом не пожалеть.
Очень жду продолжения!
Согласен с Вами. Написал продолжение . Написал про программу с интерфейсом пользователя для этого торгового автомата.
Интересная статья, благодарю за труд. Много работы наверное было проделано...)
Спасибо. Долгое время занимался разработкой протоколов сопряжения, использованием уже готовых. Когда корабельное АСУ своего изделия разрабатывал. Поэтому "взлом" такого протокола особого труда не составил, разработчики даже контрольную сумму поленились вставить. Был ещё интересный "взлом", тоже RS-485, но нужно было "вклиниться" в поток данных, добавляя нажатия кнопок. Причина - состояния торгового автомата ( температуры в разных точках, счетчики циклов очистки, и многое другое ) находились глубоко в сервисном меню. Поэтому надо было имитировать нажатия кнопок, войти в меню и собрать все данные и отослать как телеметрию. Плюс возможность "вручную" с сайта нажимать кнопки, наблюдая за текстом на индикаторе 16x2 на сайте же. И состояние лампочек на панеле автомата:
Огоньки на картинке - это индикаторы режимов, текущего состояния в большинстве случаев. Такое вмешательство называется "Человек - посредине", Man-In-The-Middle. Иногда основная плата обнаруживала, что есть задержки в ответах и начинала мигать лампочкой аварии. Но побороли в итоге.
Мне кажется у вас есть материал для продолжения статей, пишите ещё. Будет интересно почитать.
Спасибо! Написал ещё статью про программу отображения для гидроакустической станции. Для меня это тоже близкая тема, похожие программы, только посложнее, разрабатывал для экспортных корабельных комплексов РЭП. Ещё в планах написать подробнее про свой опыт в части Интернета вещей для промышленного оборудования. В результате пришли к варианту, который не зависит от иностранных проприетарных решений и достаточно простой.
От взлома протокола в старом «железе» до разработки программ