Чип очень ограниченный в возможносиях потому и дешевый. Нет SDIO, не имеет Flash памяти, медленный USB, весь такой защищенный, но криптоакселератора нет. Все говорит о том что чип заточен под жёсткую бизнес модель привязки к архитектуре. Т.е. кто-то пишет библиотеки и потом полностью закрывает их от юзеров в Secure domain. Те же эмуляторщики ретро игр наконец получат защиту своего IP. (если научатся) Отсюда и такое внимание в доке к защите бутлодера.
Ардуинщики кто зарабытывает на аппаратных расширениях, теперь смогут переквалифицироваться и еще зрабатывать продавая залоченные, но частично отрытые чипы.
Понимаете, я такие смотрю по диагонали. Но вот сейчас заметил что в статье на осциллограмме размах сигнала больше вольта. Был бы он меньше этой стати неверняка не было бы. Автор все же не фантаст.
Стандартная фишка. В Советском Союзе её знал любой АОН-щик. АОН-ы как раз работали с однобитовым сигналом. Спектр сигнала не сильно меняется если его квантовать в однобитовый. Если чувствительности цифрового входа маловато, то можно добавить на вход еще шум с другого выхода. Это будет дитеринг. Его тоже в АОН-ах применяли. Чуток фантазии и не за дорого можно ADPCM соорудить.
А GPT подкинул еще один вариант:
RC-цепь и измерение времени заряда: Создайте простую RC-цепь и используйте функцию измерения времени микроконтроллера для определения напряжения на конденсаторе. Это позволит получить цифровое представление аналогового сигнала без АЦП.
Посматриваю канал https://www.youtube.com/@AltiumAcademy Там толковые советы попадаются. Вот один из них всегда соблюдаю. Если плата часто бывает в руках персонала, габаритная, извлекается, переносится в течении эксплуатациия, ставится в непонятные места, то по контуру делаю обводную дорожку или полигон. Это уводит статику от пальцев и разъемов мимо микросхем на плате. Еще припомнил момент. Когда ставим микросхемы с микропотреблением или есть линии на плате с высоким импедансом (линии кварцев, и прочие тактирующие линии) надо думать о фотоэлектическом эффекте. На ярком свете процессоры, кодеки и т.д. просто могут не запуститься. Подозреваю свойства текстолита или маски тут имеют значение, и сама прозрачность корпусов микросхем. Кстати, еще есть байка про гелий, выделяемый медицинскими аппаратами, и его влияние на MEMS-ы, т.е. всякие микросхемы акселерометроы и гироскопов.
Словом разработка плат - это тема похожая на программирование, новые компоненты - новые неизведанные баги. Можно сделать все по импедансам, но интерфес будет глючить из-за блуждающих токов, потому что в чипе есть какая-то кривизна. И исправляется только кардинальной сменой схемотехники или жесткими ограничениями на условия применения. Поэтому как и в программировании в трассирвке всегда нужно еще думать и учитывать будущий тюнинг. В частности стараться чтобы все сигналы где нибудь да выходили на внешние слои. Хтоя бы в виде глухих переходных.
Командная строка - удел слабых архаичных архитектур. В сильных архитектурах используют командные приложения с GUI и голосовым вводом. Сейчас даже дешевые Wi-Fi extender-ы выполняют голосовые команды для управления сетевыми настройками. Учебные проекты однозначно должны поддерживать взаимодействие с AI и IoT. Для AI нужны нужны хорошие объемы RAM, для IoT тоже нужно больше RAM чем в RP2350/54 . Вывод - RP2350/54 не для базы учебного проекта, это просто экстендеры для их базы на Raspberry Pi 5. Потому у RP2xxx и нет графического движка.
Наличие же интерфейса HSTX для реализации DVI и HDMI говорит, что да, для эмуляторов ретрокомпьютеров RP235x годен, но не более.
Не, ошибся. Там оказывается все есть в виде Raspberry Pi Pico SDK. Там же и RTOS, WiFi, BLE, USB. Единственно нет графического движка. Но сам чип слабый, даже RP2350 будет все еще сильно слабее лидеров от ST, Renesas, NXP.
Плату с микронтроллером сделать гораздо легче чем фреймворк с осью, middleware и драйверами. Поэтому по уму выбирают сначала ось с фреймворком, а потом берут то железо под которое она портировна. Так проще и быстрее. Под Raspberry Pi Pico пока не видно нигде полноценных фреймворков.
Т.е. индексов гораздо больше чем 2000, если нельзя выделить даже 24 КБ RAM ? Ну и понимаете же, что один трек не показатель. Может в это время на небе было видно 24 спутника. А такое счастье не всегда и везде.
Статья прекрасный образец того насколько ChatGPT изъясняется лучше и понятней человека.
Какой размер у электрона?
Размер электрона — вопрос, связанный с квантовой механикой и физикой элементарных частиц. В классическом смысле, размер объекта определяется его физическими границами, но электрон является фундаментальной частицей, у которой нет внутренней структуры, как, например, у атомов.
Современная наука рассматривает электрон как точечную частицу без измеримого радиуса. В экспериментальных исследованиях, включая исследования по рассеянию частиц, ученые не обнаружили какого-либо внутреннего размера электрона. Радиус электрона, называемый классическим радиусом электрона, который теоретически может быть вычислен, составляет около 2.82×10−152.82 \times 10^{-15}2.82×10−15 метра, но это не физический размер, а параметр, используемый в расчетах электромагнитного взаимодействия.
Таким образом, можно сказать, что у электрона нет четко определенного размера в традиционном понимании, и он рассматривается как точечный объект с размером, близким к нулю.
А человек даст много воды, попытается пографоманствовать, термины будет объяснять терминами и потеряет нить изложеня под конец.
Как то сомнительно что GNSS работает с точностью до метров в таком бюджетном решении. Стоило ли прилагать усилия по уменьшению времени расчета , если сами показания GNSS скачут в пределах десятков метров? Про ресурсы RAM микроконтроллера занятые этим алгоритмом ничего не сказано. ChatGPT говорит, что на 2000 индексов надо будет 24 КБ RAM. Правда ли это, и сколько индексов реально у вас?
Пока не попадается код, который кто-то с мелким шрифтом писал под 150 символов в строку.
В редкаторах экран довольно динамический. Его отъедают со всех сторон вспомогательные панели. Но так обычный экран у меня это где-то 50 на 200 символов. Максимум 80 на 300. И подозреваю что таким он стал не потому что я так захотел, а потому что это такой экран авторов большинства сторонних сорсов кторые я использую. Они в соотвествии с таким экраном делают средний размер своих функций и файлов.
Тип enum в языке C может быть неудобен при отладке по следующим причинам:
Отображение значений: При отладке компиляторы и отладчики часто отображают значения перечислений как целые числа, а не как имена констант. Это делает сложным быстрое понимание текущего значения переменной типа enum, поскольку нужно помнить соответствие между числовым значением и его символическим именем.
Отсутствие строгой типизации: В языке C типы enum фактически являются целыми числами. Это значит, что переменной типа enum можно присвоить любое значение, которое подходит по размеру, даже если оно не соответствует ни одному из значений в перечислении. Это может привести к ошибкам, которые сложно отловить, особенно если вы не подозреваете, что переменной может быть присвоено "неправильное" значение.
Сложность трассировки значений: Если в программе используется множество значений enum, а переменные этого типа изменяются в разных частях кода, отладка может стать затруднительной из-за необходимости постоянного отслеживания, какие значения и где используются.
Нет явной поддержки в некоторых отладчиках: Некоторые отладчики имеют ограниченную поддержку типов enum, что может привести к необходимости вручную проверять соответствие числового значения и его текстового представления.
Эти факторы делают использование enum в C менее удобным в процессе отладки по сравнению с языками, где перечисления являются более строгими типами, как, например, в C++ или C#.
Перечисления требуют введения нового типа. Новый тип тогда должен быть объявлен по всему простанству исходников в том числе и в сторонних, если с этим перечислением обращаться туда. Надо править кучу хидеров. Т.е. появление нового перечисления вызовет каскад рефакторнга гораздо большего чем введение просто целочисленной переменной. Ну и зачем лишний рефакторинг только потому что кто-то там когда-то сделал кучу ошибок при назначении констант? Может он в notepad-е программировал.
Битовые поля вызыват постоянную головную боль с пониманием точной позиции где они стоят. Ну и зачем еще лишняя боль? Да, в компактных протоколах битовые поля применяют. Но все меньше есть потребности в компактных протоколах.
Думаю на это влияет размер и тип шрифта принятый в редакторе автора исходников. В давние времена исходники были маленькие, окна редактора узкие, а шрифты большие. И так появился CamelCase и до сих пор рулит в софте под PC. Потому что отрефакторить этот стиль в snake_case уже нет возможности. А в современном embedded рулит snake_case. Шрифты меньше, окна больше. Экономить на длине имен нет смысла. При мелком шрифте snake_case гораздо читабельней.
В принципе большинство правил правильные. Остальные, подозреваю, взяты из другой организации или придуманы автором чтобы разогреть тему. Битовые поля, юнионы и перечисления стараюсь не использовать. И это потому что что они мешают отладке. Вообще все языковые конструкции что мешают отладке идут побоку. Отладка важнее удобства и всякого синтаксического сахара. Попадись мне автор в сотрудники я бы ему еще правил накидал. Например, запретил бы писать несколько операторов в одну строку (потому что неудобно ставить брекпоинты). Все if тоже запретил бы писать без скобок (про той же причине). Запретил бы макросы с вычислениями (потому что отладчик не заходит в макросы и там нельзя проставить брекпоинт). Запретил бы тернарные операторы (опять из-за брекпоинтов ). Запретил бы большие буквы в переменных (потому что так принято в уважаемых сторонних проектах ). Заголовки функций, да должны быть по шаблону. (потому что память подводит, а что делает функция надо быстро вспомнить, а нормальные редакторы шапку формирую автоматом). Да, комментарии везде ставлю такие //, это, во-первых, чтобы не лазить мышкой в конец текстового блока чтобы написать */ , а во-вторых комментарии типа // лучше выделяются в тексте при отладке, где может быть не виден конец комментария из-за узкого окна.
Но сам я конечно не сильно все это соблюдаю, обычно все это рефакторится постфактум. Главное правило - рефакторить сорсы при малейшем подозрении на неудобства восприятия и отладки.
Тут недавно столкнулся с сорсами от Infineon. Там во всех условиях в конструкциях if сначала стоит константа, а потом переменная. Досталось видимо с той эпохи динозавров, когда == могли спутать с = . Но раздражает дико. Не поленился и в их либах везде исправил, потому что эти сорсы предстояло отлаживать. А в процессе отладки ничего не должно раздражать.
Судя по оглавлению, про социально-экономические вопросы мало дано информации. Т.е. что законно реверсить, что не законно. В каких случая окупается реверс, а в каких нет. Например лучше ли реверсить уже клоны от реверсеров или прямо оригиналы. Есть ли подробные разборы реальных случаев и пользы от них?
По мне такие книги надо бесплатно раздавать как учебники в ВУЗ-ах
И я вполне согласен. Мне как недизайнеру все те цвета как серый. Тем более после того как она повалялаь там по кустам.
Все эти статьи про ИИ всегда грешат пару моментами. Во-первых, они устаревают уже как только их начали писать. Во-вторых, раз ИИ вероятностный так давайте не по одному ответу от него, а по паре сотен, и приводите статистику.
Еще подозреваю прикол в том что ИИ может создать индивидуальный пузырь вокруг каждого юзера, покруче чем гугл своими шортсами.
Чип очень ограниченный в возможносиях потому и дешевый.
Нет SDIO, не имеет Flash памяти, медленный USB, весь такой защищенный, но криптоакселератора нет.
Все говорит о том что чип заточен под жёсткую бизнес модель привязки к архитектуре.
Т.е. кто-то пишет библиотеки и потом полностью закрывает их от юзеров в Secure domain.
Те же эмуляторщики ретро игр наконец получат защиту своего IP. (если научатся)
Отсюда и такое внимание в доке к защите бутлодера.
Ардуинщики кто зарабытывает на аппаратных расширениях, теперь смогут переквалифицироваться и еще зрабатывать продавая залоченные, но частично отрытые чипы.
Понимаете, я такие смотрю по диагонали. Но вот сейчас заметил что в статье на осциллограмме размах сигнала больше вольта. Был бы он меньше этой стати неверняка не было бы. Автор все же не фантаст.
Стандартная фишка. В Советском Союзе её знал любой АОН-щик. АОН-ы как раз работали с однобитовым сигналом. Спектр сигнала не сильно меняется если его квантовать в однобитовый.
Если чувствительности цифрового входа маловато, то можно добавить на вход еще шум с другого выхода. Это будет дитеринг. Его тоже в АОН-ах применяли.
Чуток фантазии и не за дорого можно ADPCM соорудить.
А GPT подкинул еще один вариант:
Вот тут таймер более умно будет применен.
Посматриваю канал https://www.youtube.com/@AltiumAcademy
Там толковые советы попадаются.
Вот один из них всегда соблюдаю. Если плата часто бывает в руках персонала, габаритная, извлекается, переносится в течении эксплуатациия, ставится в непонятные места, то по контуру делаю обводную дорожку или полигон. Это уводит статику от пальцев и разъемов мимо микросхем на плате.
Еще припомнил момент. Когда ставим микросхемы с микропотреблением или есть линии на плате с высоким импедансом (линии кварцев, и прочие тактирующие линии) надо думать о фотоэлектическом эффекте. На ярком свете процессоры, кодеки и т.д. просто могут не запуститься. Подозреваю свойства текстолита или маски тут имеют значение, и сама прозрачность корпусов микросхем.
Кстати, еще есть байка про гелий, выделяемый медицинскими аппаратами, и его влияние на MEMS-ы, т.е. всякие микросхемы акселерометроы и гироскопов.
Словом разработка плат - это тема похожая на программирование, новые компоненты - новые неизведанные баги. Можно сделать все по импедансам, но интерфес будет глючить из-за блуждающих токов, потому что в чипе есть какая-то кривизна. И исправляется только кардинальной сменой схемотехники или жесткими ограничениями на условия применения.
Поэтому как и в программировании в трассирвке всегда нужно еще думать и учитывать будущий тюнинг. В частности стараться чтобы все сигналы где нибудь да выходили на внешние слои. Хтоя бы в виде глухих переходных.
Командная строка - удел слабых архаичных архитектур. В сильных архитектурах используют командные приложения с GUI и голосовым вводом.
Сейчас даже дешевые Wi-Fi extender-ы выполняют голосовые команды для управления сетевыми настройками. Учебные проекты однозначно должны поддерживать взаимодействие с AI и IoT.
Для AI нужны нужны хорошие объемы RAM, для IoT тоже нужно больше RAM чем в RP2350/54 .
Вывод - RP2350/54 не для базы учебного проекта, это просто экстендеры для их базы на Raspberry Pi 5. Потому у RP2xxx и нет графического движка.
Наличие же интерфейса HSTX для реализации DVI и HDMI говорит, что да, для эмуляторов ретрокомпьютеров RP235x годен, но не более.
Не, ошибся.
Там оказывается все есть в виде Raspberry Pi Pico SDK. Там же и RTOS, WiFi, BLE, USB.
Единственно нет графического движка.
Но сам чип слабый, даже RP2350 будет все еще сильно слабее лидеров от ST, Renesas, NXP.
Плату с микронтроллером сделать гораздо легче чем фреймворк с осью, middleware и драйверами. Поэтому по уму выбирают сначала ось с фреймворком, а потом берут то железо под которое она портировна. Так проще и быстрее.
Под Raspberry Pi Pico пока не видно нигде полноценных фреймворков.
Т.е. индексов гораздо больше чем 2000, если нельзя выделить даже 24 КБ RAM ?
Ну и понимаете же, что один трек не показатель. Может в это время на небе было видно 24 спутника. А такое счастье не всегда и везде.
Статья прекрасный образец того насколько ChatGPT изъясняется лучше и понятней человека.
А человек даст много воды, попытается пографоманствовать, термины будет объяснять терминами и потеряет нить изложеня под конец.
Как то сомнительно что GNSS работает с точностью до метров в таком бюджетном решении.
Стоило ли прилагать усилия по уменьшению времени расчета , если сами показания GNSS скачут в пределах десятков метров?
Про ресурсы RAM микроконтроллера занятые этим алгоритмом ничего не сказано.
ChatGPT говорит, что на 2000 индексов надо будет 24 КБ RAM. Правда ли это, и сколько индексов реально у вас?
В редкаторах экран довольно динамический. Его отъедают со всех сторон вспомогательные панели. Но так обычный экран у меня это где-то 50 на 200 символов. Максимум 80 на 300.
И подозреваю что таким он стал не потому что я так захотел, а потому что это такой экран авторов большинства сторонних сорсов кторые я использую. Они в соотвествии с таким экраном делают средний размер своих функций и файлов.
Вот вам 31 способ отладки:
JTAG
SWD (Serial Wire Debug)
UART Debugging
SPI/I2C Debugging
GDB (GNU Debugger)
OpenOCD
Trace Debugging
printf Debugging
In-Circuit Emulator (ICE)
Logic Analyzer
Oscilloscope
Boundary Scan
Hardware Breakpoints
Software Breakpoints
Watchpoints
Memory Monitoring
Peripheral Registers Inspection
Firmware Logging
Event Tracing
Code Coverage Analysis
Static Code Analysis
Unit Testing
Integration Testing
Simulation Tools
Bootloader Debugging
Crash Dumps/Memory Dumps
Fuzz Testing
Fault Injection Testing
Power Analysis
Electromagnetic Interference (EMI) Testing
Hardware-in-the-Loop (HIL) Testing
Привет от ChatGPT!
Ну такие вещи даже ChatGPT знает:
Про технологии отладки тут. Но там, конечо, не все технологии.
Перечисления требуют введения нового типа. Новый тип тогда должен быть объявлен по всему простанству исходников в том числе и в сторонних, если с этим перечислением обращаться туда. Надо править кучу хидеров. Т.е. появление нового перечисления вызовет каскад рефакторнга гораздо большего чем введение просто целочисленной переменной. Ну и зачем лишний рефакторинг только потому что кто-то там когда-то сделал кучу ошибок при назначении констант? Может он в notepad-е программировал.
Битовые поля вызыват постоянную головную боль с пониманием точной позиции где они стоят. Ну и зачем еще лишняя боль? Да, в компактных протоколах битовые поля применяют. Но все меньше есть потребности в компактных протоколах.
Думаю на это влияет размер и тип шрифта принятый в редакторе автора исходников.
В давние времена исходники были маленькие, окна редактора узкие, а шрифты большие. И так появился CamelCase и до сих пор рулит в софте под PC. Потому что отрефакторить этот стиль в snake_case уже нет возможности.
А в современном embedded рулит snake_case. Шрифты меньше, окна больше. Экономить на длине имен нет смысла. При мелком шрифте snake_case гораздо читабельней.
В принципе большинство правил правильные.
Остальные, подозреваю, взяты из другой организации или придуманы автором чтобы разогреть тему.
Битовые поля, юнионы и перечисления стараюсь не использовать. И это потому что что они мешают отладке. Вообще все языковые конструкции что мешают отладке идут побоку.
Отладка важнее удобства и всякого синтаксического сахара.
Попадись мне автор в сотрудники я бы ему еще правил накидал.
Например, запретил бы писать несколько операторов в одну строку (потому что неудобно ставить брекпоинты). Все if тоже запретил бы писать без скобок (про той же причине). Запретил бы макросы с вычислениями (потому что отладчик не заходит в макросы и там нельзя проставить брекпоинт). Запретил бы тернарные операторы (опять из-за брекпоинтов ). Запретил бы большие буквы в переменных (потому что так принято в уважаемых сторонних проектах ). Заголовки функций, да должны быть по шаблону. (потому что память подводит, а что делает функция надо быстро вспомнить, а нормальные редакторы шапку формирую автоматом).
Да, комментарии везде ставлю такие //, это, во-первых, чтобы не лазить мышкой в конец текстового блока чтобы написать */ , а во-вторых комментарии типа // лучше выделяются в тексте при отладке, где может быть не виден конец комментария из-за узкого окна.
Но сам я конечно не сильно все это соблюдаю, обычно все это рефакторится постфактум.
Главное правило - рефакторить сорсы при малейшем подозрении на неудобства восприятия и отладки.
Тут недавно столкнулся с сорсами от Infineon. Там во всех условиях в конструкциях if сначала стоит константа, а потом переменная. Досталось видимо с той эпохи динозавров, когда == могли спутать с = . Но раздражает дико. Не поленился и в их либах везде исправил, потому что эти сорсы предстояло отлаживать. А в процессе отладки ничего не должно раздражать.
Судя по оглавлению, про социально-экономические вопросы мало дано информации.
Т.е. что законно реверсить, что не законно. В каких случая окупается реверс, а в каких нет.
Например лучше ли реверсить уже клоны от реверсеров или прямо оригиналы.
Есть ли подробные разборы реальных случаев и пользы от них?
По мне такие книги надо бесплатно раздавать как учебники в ВУЗ-ах
Статью не читал, но поиск показывает что в ней нет слов FIFO или фифо.
Странно как это можно проигнорить касаясь темы DMA.
ChatGPT 4o прямо сейчас:
И я вполне согласен. Мне как недизайнеру все те цвета как серый. Тем более после того как она повалялаь там по кустам.
Все эти статьи про ИИ всегда грешат пару моментами. Во-первых, они устаревают уже как только их начали писать. Во-вторых, раз ИИ вероятностный так давайте не по одному ответу от него, а по паре сотен, и приводите статистику.
Еще подозреваю прикол в том что ИИ может создать индивидуальный пузырь вокруг каждого юзера, покруче чем гугл своими шортсами.