Китайский анализатор, который Вы не пробовали, но не смотря на это не любите, сделает это без лишних движений, достаточно просто указать ему, что данные нужно интерпретировать как I2S.
Совершенно необязательно, это самый примитивный и медленный вариант. Там может быть формирование промежуточного буфера в формате дисплея с последующей его отправкой через DMA. Там может использоваться оконная функция дисплея. Там может использоваться вращение координатной системы дисплея. И тогда вся вот эта "симуляция" теряет все остатки своего смысла
Но даже если все рисуется каким-нить PutPixel - все равно это не симулятор дисплея. Симулятором это было бы если бы прошивка полностью повторяла работу с реальным дисплеем, но выдавала сигналы и данные не на реальный дисплей, а, например, на компьютер через UART или в USB, где программа симулятора дисплея эмулировала бы реакцию дисплея на полученные данные и сигналы. Ну или если Вы хотите отлаживать прошивку прямо на компе - то выдача сигналов и данных в какой-нибудь API симулятора.
А в описанном Вами подходе вообще все бессмысленно. Проще уж прицепить любую графическую библиотеку и рисовать прямо на экране, а не городить вот это всё через тридцать три колена.
Вот именно. Симулятор - это такая штука, которая симулирует поведение чего-либо. То есть "Симулятор Графического Монохромного Дисплея" должен повторять поведение реального дисплея - работать с теми же командами, так же на них реагировать. Но я пока не встречал дисплеев, которые могут закрашивать области командой fprintf(...).
Каким образом ее можно будет ускорить, если в симуляции использовать совершенно другую - абстрактную - библиотеку, после чего для контроллера переписывать все заново с совершенно иным принципом отрисовки?
Ничего не понял. Это потом и в "боевом" микроконтроллере будет генерироваться код .gv? Или он только в симуляции и фактически заменяет какой-нибудь фотошоп, в котором редактируется компоновка экрана? А если так, то о какой отладке вообще идет речь, если потом все равно надо будет все переписывать и отлаживать на реальном микроконтроллере?
Вам принесли 6ти слойную электронную плату прямо с производства. Её ещё ни разу не включали. Обычно в таких случаях 90% вероятность, что в PCB есть какие-то аппаратные баги: короткие замыкания на GND, короткие замыкания на VCC или вовсе непропай пинов MCU.
Срочно менять такое забагованное производство.
Как вы думаете зачем в микроконтроллерах есть функция pull-up/pull-down, если можно просто воспользоваться установкой логического уровня push-pull?
Или не воспринимать слишком серьезно подобные личные оценочные суждения, написанные как непререкаемая истина :) Загрузчик должен стартовать до основной прошивки и передать управление основной программе, либо по какому-либо условию/сигналу принять извне удобным способом новую основную прошивку и записать ее во флэш контроллера. И всё :) Остальные фичи могут быть востребованы, а могут и не быть, зависит от задач и пожеланий :) И методы реализации этих фич так же могут быть разными.
Простейший загрузчик вполне можно уложить и в пару килобайт, а может быть даже и меньше :)
Ни разу не сталкивались с "не представляю зачем они так сделали" при ловле багов в чужих программах? :) Более того, бывает даже "не представляю зачем я это тогда так сделал" :))
Современные микроконтроллеры могут стартовать много как - с заводского загрузчика, с фиксированного адреса RAM, с фиксированного адреса FLASH - все зависит от конфигурации, заданной во фьюзах или определенным подключением специальных выводов. Как правило его конфигурируют на старт из FLASH, где и находится пользовательская прошивка.
Китайский анализатор, который Вы не пробовали, но не смотря на это не любите, сделает это без лишних движений, достаточно просто указать ему, что данные нужно интерпретировать как I2S.
Хотел прокомментировать каждый ляп, но их оказалось слишком много...
Ну может быть имеется в виду, что замену неисправного модуля сможет осуществить сам пользователь, без специальных знаний, инструментов и приборов?
А через пару лет будет "Ну не шмогла я. Ожидания не оправдались, объявляем банкротство, поддержка - всё."...
Упс, сорри :) Предыдущий ответ я писал, будучи уверенным, что отвечаю автору :))
Совершенно необязательно, это самый примитивный и медленный вариант. Там может быть формирование промежуточного буфера в формате дисплея с последующей его отправкой через DMA. Там может использоваться оконная функция дисплея. Там может использоваться вращение координатной системы дисплея. И тогда вся вот эта "симуляция" теряет все остатки своего смысла
Но даже если все рисуется каким-нить PutPixel - все равно это не симулятор дисплея. Симулятором это было бы если бы прошивка полностью повторяла работу с реальным дисплеем, но выдавала сигналы и данные не на реальный дисплей, а, например, на компьютер через UART или в USB, где программа симулятора дисплея эмулировала бы реакцию дисплея на полученные данные и сигналы. Ну или если Вы хотите отлаживать прошивку прямо на компе - то выдача сигналов и данных в какой-нибудь API симулятора.
А в описанном Вами подходе вообще все бессмысленно. Проще уж прицепить любую графическую библиотеку и рисовать прямо на экране, а не городить вот это всё через тридцать три колена.
Вот именно. Симулятор - это такая штука, которая симулирует поведение чего-либо. То есть "Симулятор Графического Монохромного Дисплея" должен повторять поведение реального дисплея - работать с теми же командами, так же на них реагировать. Но я пока не встречал дисплеев, которые могут закрашивать области командой fprintf(...).
Каким образом ее можно будет ускорить, если в симуляции использовать совершенно другую - абстрактную - библиотеку, после чего для контроллера переписывать все заново с совершенно иным принципом отрисовки?
Ничего не понял. Это потом и в "боевом" микроконтроллере будет генерироваться код .gv? Или он только в симуляции и фактически заменяет какой-нибудь фотошоп, в котором редактируется компоновка экрана? А если так, то о какой отладке вообще идет речь, если потом все равно надо будет все переписывать и отлаживать на реальном микроконтроллере?
Срочно менять такое забагованное производство.
Например для выходов open-emitter/open-collector.
Скорее около 50:
Может быть имеется в виду глубина твердой породы, а +10 - это слой пыли? Это объяснило бы резкий рост температуры на глубине выше 0.
Или не воспринимать слишком серьезно подобные личные оценочные суждения, написанные как непререкаемая истина :) Загрузчик должен стартовать до основной прошивки и передать управление основной программе, либо по какому-либо условию/сигналу принять извне удобным способом новую основную прошивку и записать ее во флэш контроллера. И всё :) Остальные фичи могут быть востребованы, а могут и не быть, зависит от задач и пожеланий :) И методы реализации этих фич так же могут быть разными.
Простейший загрузчик вполне можно уложить и в пару килобайт, а может быть даже и меньше :)
Местные животные и растения мутируют, ага.
Ни разу не сталкивались с "не представляю зачем они так сделали" при ловле багов в чужих программах? :) Более того, бывает даже "не представляю зачем я это тогда так сделал" :))
Любая инерциальная система имеет накапливающуюся со временем погрешность. Ее нужно будет регулярно корректировать по достоверным измеренным данным.
Зашел только из-за заголовка "написал свою прошивку с нуля" и в самом же начале увидел резкий разворот на 180° - "с нуля писать не буду" :(
То, что можно зажать, уже перестало быть определяющим фактором :)
Сейчас там с этим все непросто
В Заголовке Слово "Хорошего" Надо Изменить На "Моего".
Современные микроконтроллеры могут стартовать много как - с заводского загрузчика, с фиксированного адреса RAM, с фиксированного адреса FLASH - все зависит от конфигурации, заданной во фьюзах или определенным подключением специальных выводов. Как правило его конфигурируют на старт из FLASH, где и находится пользовательская прошивка.