Касательно отрубания информационных линий, многие дешманские китайские провода вообще не содержат линий данных. Или провода с магнитным разъемом, там по фото разъёма сразу видно, есть там данные или нет.
Нотификации без подтверждения это само собой, но там на более нижнем уровне (LL) все равно стороны обязательно чередуются и каждый следующий пакет подтверждат предыдущий (битами SN и NESN).
Скорость прошивки nRF52 может быть низкой не из за BLE, а из за внутреннего флеша, там же есть задержки при сохранении страниц.
Но признаю, используя все фичи BLE на обоих микроконтроллерах (2M Phy, Data length extension), в этой же статье была достигнута скорость 1371 Кбит/с (170 КБ/с) при теоретическом пределе в 1400.
Это вероятно специально настроенные железки, где все включено и тюнингованно. И iOS, и Андроид, насколько я знаю, имеют ограничения на Connection interval и не используют этот интервал полностью, что сильно ограничивает производительность BLE.
Нашел вот такую статью, где на 1М Phy выжали 478 Кбит/с (60КБ/с) при теоретическом лимите в 660 КБит/с, но оба девайса - микроконтроллеры nrf52 со вручную настроенными тайминигами. Для сравнения практический пример: когда андроид-приложение nRF Connect заливает прошивку на тот же микроконтроллер nRF52, скорость выходит около 5Кб/с.
Да и честная скорость уж точно не 2к, наушники же прекрасно передают звук, как через пропритарные кодеки поверх BLE, так и используя кодеки BLE.
Вы про BLE Audio с телефона на наушники? Если честно, еще не держал таких в руках, но думаю, что там OS подкручивает параметры BLE так, как не доступно простому приложению.
Мегабит в BLE это низкоуровневая скорость передачи одного пакета. Ради Low Energy между пакетами вставлена куча пауз, полудуплексность, подтвеждение каждого пакета, в итоге от мегабита остаётся от силы пара кбайт/с, в лучшем случае - несколько десятков кбайт/с, если устройства поддерживают все последние стандарты и разрешают приложениям выставлять минимальные тайминги
Думаю, имеется в виду, что сам по себе USB-C ничего из этого не гарантирует. Вполне может оказаться, что в конкретном девайсе с USB-C работает только USB 2.0 и 5V2A. Все эти вкусности требуют нового стандарта USB, а стандарт уже требует новый разъем.
Открывать все подряд порты потенциально вредная идея, мало ли что устройства будут делать при подключении. Ардуино и подобные платы, например, перезагружается.
Лучше привязаться к VID/PID (как минимум это сократит количество устройств, подвергающихся подключению), а ещё лучше заменить в прошивке название устройства, серийный номер, на что-то свое уникальное, привязываться к этому. В RP2040 нативный USB, должен позволять такое.
Ну я тоже не очень знаком с номенклатурой; вот то, что часто в ESP32 модули ставят (т.е. относительно недорогое): APS6404L, LY68L6400, ESP-PSRAM64H. Вроде это все 64Мбит, должно с запасом хватить. По идее, флэш кроме числа перезаписей должна быть еще заметно медленнее, чем RAM, особенно на запись
Недостаточно просто подавать видеосигнал. Следует записать нужные значения в регистры драйвера экрана
А откуда конвертер RGB-MIPI или HDMI-MIPI берет эти данные? МК присылает по упомянутому в статье SPI?
Почитать про то, как делать такой реверс - очень интересно, для саморазвития. Но для хобби-поделок я бы взял экран, с которым меньше всего геморроя (так что как найти такой экран, тоже интересно)
Тема таких экранов меня заинтересовала, когда я купил фотополимерный принтер и узнал, что даже принтеры начального уровня имеют FPGA для отправки данных в экран. Появился вопрос, а нельзя ли вместо свзяки MCU+FPGA с глючными закрытыми прошивками использовать одноплатник типа малины/апельсинки, и выводить картинку как на обычный дисплей... Но в целом, эта идея выглядит сильно больше, чем у меня есть знаний и свободного времени.
Получается, произвольный DSI экран можно подключить к конвертеру и пускать RGB данные? Я когда-то слегка изучал тему подключения CSI камер к RPi, и, насколько я понял, у камер регистры конфигурации свои у каждого производителя, и для официально поддерживаемых RPi камер чуть ли не свои блобы в дистрибутиве зашиты. С экранами нет такой шляпы?
Ни разу не олимпиадный программист, но по идее, для решения таких задач давно придуманы специальные структуры данных, типа дерева интервалов . Это если вам таких проверок много надо делать. Если же проверка одна, то какая-то переусложненная реализация вышла, в духе "Hello world в кровавом ентерпрайзе".
Ну для USB-PD для этого данные не нужны, только линии CC1/CC2. Вроде другие быстрые стандарты тоже не через линию данных работают.
Касательно отрубания информационных линий, многие дешманские китайские провода вообще не содержат линий данных. Или провода с магнитным разъемом, там по фото разъёма сразу видно, есть там данные или нет.
А чем вайфай лучше с точки зрения переезда?
А что потом программисты делали с вашим файлом Figma? Я так понимаю, это в основном инструмент для веба и мобайла, а какой воркфлоу для ембеддеда?
Нотификации без подтверждения это само собой, но там на более нижнем уровне (LL) все равно стороны обязательно чередуются и каждый следующий пакет подтверждат предыдущий (битами SN и NESN).
Да, наверное вы правы
Но признаю, используя все фичи BLE на обоих микроконтроллерах (2M Phy, Data length extension), в этой же статье была достигнута скорость 1371 Кбит/с (170 КБ/с) при теоретическом пределе в 1400.
Это вероятно специально настроенные железки, где все включено и тюнингованно. И iOS, и Андроид, насколько я знаю, имеют ограничения на Connection interval и не используют этот интервал полностью, что сильно ограничивает производительность BLE.
Нашел вот такую статью, где на 1М Phy выжали 478 Кбит/с (60КБ/с) при теоретическом лимите в 660 КБит/с, но оба девайса - микроконтроллеры nrf52 со вручную настроенными тайминигами. Для сравнения практический пример: когда андроид-приложение nRF Connect заливает прошивку на тот же микроконтроллер nRF52, скорость выходит около 5Кб/с.
Вы про BLE Audio с телефона на наушники? Если честно, еще не держал таких в руках, но думаю, что там OS подкручивает параметры BLE так, как не доступно простому приложению.
Мегабит в BLE это низкоуровневая скорость передачи одного пакета. Ради Low Energy между пакетами вставлена куча пауз, полудуплексность, подтвеждение каждого пакета, в итоге от мегабита остаётся от силы пара кбайт/с, в лучшем случае - несколько десятков кбайт/с, если устройства поддерживают все последние стандарты и разрешают приложениям выставлять минимальные тайминги
Думаю, имеется в виду, что сам по себе USB-C ничего из этого не гарантирует. Вполне может оказаться, что в конкретном девайсе с USB-C работает только USB 2.0 и 5V2A. Все эти вкусности требуют нового стандарта USB, а стандарт уже требует новый разъем.
Датчики холла токовые не рассматривали?
Открывать все подряд порты потенциально вредная идея, мало ли что устройства будут делать при подключении. Ардуино и подобные платы, например, перезагружается.
Лучше привязаться к VID/PID (как минимум это сократит количество устройств, подвергающихся подключению), а ещё лучше заменить в прошивке название устройства, серийный номер, на что-то свое уникальное, привязываться к этому. В RP2040 нативный USB, должен позволять такое.
Можете ссылок кинуть? А то там ещё разобраться надо, кто профильный, а кто - диванный.
Firefox, вестимо.
Ну я тоже не очень знаком с номенклатурой; вот то, что часто в ESP32 модули ставят (т.е. относительно недорогое): APS6404L, LY68L6400, ESP-PSRAM64H. Вроде это все 64Мбит, должно с запасом хватить. По идее, флэш кроме числа перезаписей должна быть еще заметно медленнее, чем RAM, особенно на запись
Спасибо!
А как понять, сколько линий нужно дисплею? Я находил фото платы от своего принтера, там сильно больше дифпар, чем 3 или 4.
Скрытый текст
Может, все же SPI RAM использовать для хранения экранного буфера? Использовать для этого флэш как-то звучит,.. неправильно.
А откуда конвертер RGB-MIPI или HDMI-MIPI берет эти данные? МК присылает по упомянутому в статье SPI?
Почитать про то, как делать такой реверс - очень интересно, для саморазвития. Но для хобби-поделок я бы взял экран, с которым меньше всего геморроя (так что как найти такой экран, тоже интересно)
Тема таких экранов меня заинтересовала, когда я купил фотополимерный принтер и узнал, что даже принтеры начального уровня имеют FPGA для отправки данных в экран. Появился вопрос, а нельзя ли вместо свзяки MCU+FPGA с глючными закрытыми прошивками использовать одноплатник типа малины/апельсинки, и выводить картинку как на обычный дисплей... Но в целом, эта идея выглядит сильно больше, чем у меня есть знаний и свободного времени.
Получается, произвольный DSI экран можно подключить к конвертеру и пускать RGB данные? Я когда-то слегка изучал тему подключения CSI камер к RPi, и, насколько я понял, у камер регистры конфигурации свои у каждого производителя, и для официально поддерживаемых RPi камер чуть ли не свои блобы в дистрибутиве зашиты. С экранами нет такой шляпы?
Ни разу не олимпиадный программист, но по идее, для решения таких задач давно придуманы специальные структуры данных, типа дерева интервалов . Это если вам таких проверок много надо делать. Если же проверка одна, то какая-то переусложненная реализация вышла, в духе "Hello world в кровавом ентерпрайзе".
Очень интересно, я бы почитал подробностей!