Comments 29
А возможно ли подключить через JTAG (SWD) на основе FT4232? А то нашел интересный контроллер CH32V307, и та же беда — какие-то идиоты решили, что прошивать его надо исключительно через wch-link либо мега-кривую софтину по UART. Хотя UART бы тоже устроил, если бы хоть протокол обмена известен был.
А возможно ли подключить через JTAG (SWD) на основе FT4232?
Всё та же проблема. Вот прямо взять готовое - скорее всего, нельзя. Сделать поддержку в OpenOCD - можно, только надо время потратить (унифицировать китайский вариант или скопировать загрузчик оттуда в основной, творчески переработав обращения к нему). В коммерческих проектах после фразы про время обычно сразу всё заканчивается. Не любят Заказчики за такое платить. Особенно если находится готовое решение.
Хотя UART бы тоже устроил, если бы хоть протокол обмена известен был.
А любым монитором порта если поглядеть? Вдруг там будет видно, что к чему?
А любым монитором порта если поглядеть? Вдруг там будет видно, что к чему?
Пробовал. Похоже, прошивку на время передачи шифруют или что-то в этом роде. Ни одна последовательность исходной прошивки с потоком байтов не совпадает. Впрочем, какие-то открытые прошивальщики я видел, может и получится оттуда выкусить алгоритм.
Всё та же проблема. Вот прямо взять готовое — скорее всего, нельзя. Сделать поддержку в OpenOCD — можно, только надо время потратить
Понятно. Моих познаний openocd на такое не хватит точно. Значит, буду извращаться другими способами.
off Может быть мимо будут проходить специалисты, которые знают, чем можно дизассемблировать код Mediatek mt7681 (AndeStar™ patented 32-bit RISC-style CPU architecture).
Через этот soc с wifi умный кондиционер общается с облаком. Интересно бы узнать протокол общения.
PS прошивка на отдельной 25q80dv, дамп которой слил.
Может, проще интернет-трафик анализировать? Или он нечитабельно зашифрован?
А у BLE там прям RTOS или какой то свой планировщик? Задачи с приоритетами можно делать?
Похоже, без приоритетов
extern bStatus_t tmos_start_task( tmosTaskID taskID, tmosEvents event, tmosTimer time );
Там есть события (event), сообщения (msg), таймеры. Из того, что вижу - в целом, всё.
Нам доступен только заголовочный файл, так что менять нельзя. Весь стек на это дело сильно завязан. Пользовательский код тоже на taskах построен. Как именно - я глубоко не погружался. Мне показалось, что это - не самый полезный контроллер для BLE, я решил другие поизучать, когда будет время свободное.
Выложить наработки в открытый доступ возможности нет, правильно понимаю?
Поделюсь опытом. С эклипсом не заладилось, уж очень хорошо падал, медленно запускался, ломал весь рабочий процесс. По возможности пытаюсь использовать qt+qbs. Разработчики qbs вроде даже читают/пишут на хабре.
Если делаю шаблонный проект пытаюсь выкладывать. Может кому будет полезен, может разработчики железок заметят и тоже будут выкладывать шаблоны под qbs. Эх мечты.
К сожалению, добра Заказчик на публикацию материалов не дал. К счастью, не так этих материалов и много. Самое главное я на словах изложил.
QT Creator для работы с Cortex M мы рассматривали, когда от нас потребовали проверить, что можно работать через CMake. Попробовали, всё получилось. Тот путь, что мы использовали, требовал слишком много подготовительных действий. Целую инструкцию на экран или два текста выполнить. Может быть, какие-то действия можно было и автоматизировать, не могу точно сказать.
Но каждый использует то, что ему нравится. Всё равно все среды разработки так или иначе завязываются на GDB или LLDB. Они, в свою очередь, могут опираться среди прочего на OpenOCD или J-Link. Поэтому на что опереться - тут показано (скачать китайский OpenOCD и работать через wch-link, либо взять JLINK и поправить ему конфиг). А дальше - всё, что сверху - заработает, кому бы что бы ни нравилось.
Лично мне очень нравится Эклипса. Ко мне она почему-то весьма дружелюбно относится. И в ней максимум всего автоматизировано. Напарник мой всё больше к VS Code тяготеет. Вам, вон Qt Creator нравится, но вот у меня к нему при отладке Виндушных приложений вопросики есть, поэтому я его не жалую и в других местах. Это же замечательно, когда каждый может выбирать что-то своё!
Согласен наличие выбора сред разработок радует. Каждый может выбрать по вкусу и возможностям.
Я пытался продвигать qbs. Статейку даже тут писал, интереса особо не вызывала, железячники народ консервативный. Зато разработчик qbs объяснил мне, что же я сделал в своём проекте)
Да там проект разросся на кучу разных китайских процессоров, даже с разными ядрами (M3 и M4). Плюс кучка прочих опций. Заказчик сказал, что надо делать на CMake. Но я там только сбоку смотрел и при затыках идеи кидал. Делал напарник. Решили, что Qt Creator с этим лучше всего справляется. Он действительно справился на ура.
Ну, начнём с того, что чисто официально этот Qt в России сегодня не скачать
Продолжим вопросом лицензии на использование Qt Creator (хоть и не фреймворка) для коммерческих проектов.
Но повторю... Вот у меня в Qt Creator при отладке под Windows иногда совершенно рабочие функции просто вылетают, если в них поставить точку останова. Пробегаем мимо этой функции - всё работает. Каждый раз приходится с бубном плясать, чтобы найти проблемное место. Причём суть проблемы обычно не ясна. Просто ушаманивать приходится. Чуть иначе проблемную строку перепишешь - начинает работать. Не любит меня Qt Creator, хотя под Windows я в последнее время им часто пользуюсь.
Но на самом деле... Каждый любитель той или иной среды разработки почти всегда может сконвертить в неё проект из другой среды. Производители CH579 любят Кейл, но мы под Эклипсу его быстро преекинули.
не пойму почему под него разработчики микросхем не делают шаблоны.
К слову... Вот я - фанат библиотеки Константина Чижова mcucpp. Ну, и её наследницы Zhele. А вокруг почти никто не может прочувствовать их круть. Я, конечно, удивлён, что никто не хочет их использовать... Но это не мешает мне совать их во все более-менее серьёзные собственные проекты. Мне нравится - я пользуюсь. Другим продвигаю, но к тому, что мало кто фанатеет, отношусь философски. Их проблемы. Я-то пользуюсь...
С окнами давно не имею дела, 10ка была настолько ужасной, что перейти на линукс было проще. Однако у программистов не помню подобных проблем с отладкой под виндой. Под мк всё равно используется связка гдб+опеносд.
Обычно любят то, с чем умеют работать или то с чем умеют работать специалисты, которых смогли нанять. Обращаю внимание, во что вкладывает производитель, в квалификацию сотрудников или в покупку готовых решений. А то был случай, когда пришлось драйвер допиливать, чтобы он стал работать. В том случае была тотальная экономия и на сотрудниках, и на готовых решениях.
Пробежал глазами по Zhele. На вид довольно интересно. Спрошу наверное самый стандартный вопрос, какая разница в ресурсах/производительности относительно реализации на Си?
Попробую предположить, почему подобное мало используют. Железячники очень консервативный народ. Ресурсов на вхождение и освоение нужно в разы больше, чем в голом софте. Переучиваться на плюсы, когда работает на Си, не все хотят (некоторых индивидов приходилось выгонять с ассемблера на си). Ещё любят считать, что разработчик должен сделать схему, плату, написать прошивку и отладить железо, а учиться в свободное от работы время и желательно за свой счёт. Сверху заливаем это
Пробежал глазами по Zhele. На вид довольно интересно. Спрошу наверное самый стандартный вопрос, какая разница в ресурсах/производительности относительно реализации на Си?
Когда я начинал изучать mcucpp, проводил ряд тестов. Во всех случаях, даже при работе с группами битов, разбросанных по разным портам, компиляторы той поры (кажется, дело в 2017-м было, плюс-минус) оптимизировали всё так, лучше чего я бы на ассемблере не сделал. Ну, а драйверы аппаратных блоков там исходно оптимально спроектированы.
Там главная прелесть в шаблонах. Этот шаблон один раз объявил, у тебя появляется имя, к которому можно ссылаться. На чистых сях это можно сделать только через макросы. Но макросы второго или большего уровня - совершенно нечитаемы. И абсолютно не типизированы. Запутаться легко. Шаблоны - и легко понять, и предупредят, если неверно используешь.
Можно строить целые цепочки драйверов. Скажем, ножки GPIO, над ними SPI, над ними - экран, над ним - графическая библиотека. Любой кирпичик можно заменить. Ноги другие выбрать у того же SPI, выбрать другой SPI, заменить SPI на I2C с его ногами и т.п. Цепочки получаются - прелесть. Оптимизация - высшая! Прозрачность кода - все связи в одном месте через typedef прописаны, дальше - по именам внутренним обращения. Все замены - внутри этого заголовочного файла.
Если же хранить какой-то дескриптор в ОЗУ, а не через макросы/шаблоны делать - там процессор каждый раз цепочку от этого дескриптора должен раскручивать, тратя такты. В случае макросов или шаблонов, всё оптимизируется на этапе сборки. Ассемблерные команды сразу к портам лезут, так как их адреса заранее известны, даже через цепочку.
В наше время оптимизаторы в режиме LTO творят чудеса. Можно будет перепроверить, не будет ли всё так же красиво разрулено при вызове цепочки функций, где первая вызвана с константным аргументом. Но как Вы верно заметили, инертность... Когда-то потратил почти месяц, чтобы найти хорошее решение, теперь тратить ещё на перепроверку - лень. Всё ведь и так работает! Но факт того, что оптимизаторы ушли вперёд - я заметил.
Что касается Zhele - я помогал автору оптимизировать работу с USB. Он там в итоге добился двухбуферной схемы, что позволило выжать из USB все соки, но вылезли проблемы, которые мы ловили совместно. Фирменная библиотека от ST этого не позволяет. Причины тут (а тут - продолжение неожиданное). И вообще, работа с USB там классная. А дескрипторы строятся - вообще автоматически. Не то, что в Сишных реализациях. Поправить на Сях - целый процесс. Поменяй данные, поменяй длину. Тьфу!
Да, Qbs замечательная и интересная штукенция, но из за политики Qt в связи с сами знаете какими событиями, много русскоязычных разработчиков приостановили свою работу.
Например, и меня постигла та же идея, и к сожалению, сейчас в Qbs наблюдается застой, коммиты перестали поступать. По факту там остался один Кристиан из Qt Company.
Вот, так не дальновидная политика компании убивает хорошие проекты. У меня сейчас желания нет что то добавлять в Qbs, увы.
А те, кому не нравится QtCreator, могут попробовать VSCode, для которой я написал расширение и пока планирую его поддерживать. ))
В общем, вот такие вот дела, ребятушки.
UDP либа, что в статье упомянута, не из mcucpp случаем?
Простите, а что не так с CMake для работы с микроконтроллерами? Это такой же инструмент для работы как и QBS, который позволяет делать довольно гибкие сборки.
Наврятли CMake лекго заработает, к примеру, с 8051 контроллерами, например тот же Keil, IAR И прочие. Придется писать свой синтаксис для таких тулчейнов. И CMake не предоставит нормальную подсветку заголовков и прочих вещей для таких компиляторов.
Хотя в Qbs это все есть из "коробки".
Кроме того, CMake ничего сам не собирает, ему нужны или Ninja Или Make, но Qbs не требует ничего лишнего и собирает сам. Кроме того, декларативный синтаксис самого Qbs гораздо лучше ложится на любые требования.
Классическая работа с китайскими МК - разработка плавно перетекает в реверс и обратно. Классная статья.
А про цену макеток - ну так это тоже классика жанра. У многих производителей чипов девборды и по сей день часто стоят весьма приличных денег. Это же B2B - деньги компании, кто их считает. Три тысячи рублей за плату и столько же за родной прогер - это ещё по-божески.
Самые дешёвые и доступные девборды почти всегда сделаны не производителем, а третьей стороной - как те же Arduino Nano, или Blue Pill и Black Pill. И только увидев эти решения сам производитель начинает думать о уменьшении цены. Так что если хочется для какого-нибудь странного чипа дешёвую борду, то тут только самому делать. Производитель о популяризации своих изделий среди мелких разрабочиков, для которых между ценой в $20 и $120 есть разница, почти всегда думает в последнюю очередь.
Вообще в китайских железках приятнее всего именно степень интеграции. В одной банке BLE и Ethernet прям с PHY встречается нечасто. Много железок, которые могли бы тягаться на международном уровне - если бы не были сделаны китайцами в Китае.
очень интересно было читать, спасибо. Пока читал постоянно свербила мысль
-Почему такой гениальный ум @EasyLy должен копаться в этом убожестве?
Очень надеюсь, что в прекрасной России будущего миллиарды минпромторга будут идти на проекты российских талантливых инженеров и изобретателей. А дело Валерия Пшеничного будет расследовано.
Всё в порядке, разбирались по заказу от товарища не из нашего ВУЗа, от товарища из Америки (слегка переделанная цитата из фильма "Дежа вю").
Но там была целая цепочка разных контроллеров. Вот тут, например, я описывал, как мы нашли в одном из них аппаратный баг. В другом (GD32F107) нашёлся баг поинтереснее. Его сетевая аппаратура зависает, если длина Ethernet пакета кратна четырём, а используется кольцевой буфер DMA. В фирменных примерах буфер используется связный, с ним такой проблемы не возникает. Но там материалов не на целую статью, поэтому я пока не стал писать, надо с чем-то объединить. В общем, если смотреть на весь объём работ, то там много интересного было. CH579 был быстро обследован, выводы сделаны, быстро Заказчиком отброшен.
Отличная статья, но почему я все время представляю в голове мышей и кактус?
Этот больно умный декомпилятор понимает, что первые два занесения констант 0x57 и 0xa8 не нужны.
Может, у Гидры есть включённая опция антиобфускации?
Контроллер CH579. Начинаем работу и избавляемся от закрытой сетевой библиотеки