Note, however, that the maximum input clock frequency for burst operations which cross page boundaries is 84 MHz
То есть вроде позволяют всё-таки читать непрерывно, но на пониженной частоте (вместо 144МГц), видимо дополнительно кэшируя внутри, чтобы впихнуть открытие/закрытие страниц и рефреши.
Большинство psramов просто зацикливают burst внутри страницы.
На большие объёмы оно уже обычно PSRAM, т.е. внутри sdram который всю "динамику" прячет, а наружу выглядит как обычная асинхронная память. Но там надо аккуратно, могут быть некие грабли с непрерывной выдачей данных, и ограничением непрерывного чтения только в пределах страницы. "видеоданные" возможно придётся по строкам по границам страниц выравнивать.
В качестве компромиса между ram и flash ещё spi eepromы есть, с количеством циклов перезаписи получше. Ну и fram ещё но там на такие размеры цены уже негуманные.
как вариант на попробовать можно ещё ft232h (ft2232h), там в режиме mpsse вроде можно 30МГц непрерывный однобитовый поток с ПК организовать, и заодно gpio дрыгать для hvsync.
однобитный 1440*2560 это 460кБ влезет даже во внутреннюю память rp2350, который наружу может на 150МГц DDR, т.е. на 300МГц выплюнуть через HSTX, заодно сигналы синхронизации сформировать.
Я от какого-то то-ли 4-го то ли 5-го айфона пытался ковырять сенсор, вроде бы 5642. чтобы из него хоть как-то достать пожатую картинку в каком угодно низком разрешении/качестве, но через какой-нибудь "медленный" интерфейс, а не как положено. Но документация в виде каких-то скриншотов pdfa с китайского сайта и замечательные аппноуты омнивижена в виде нескольких страниц портянок вида i2cwrite(0xaabb, 0xcc); для инициализации различных режимов без описаний, одолеть не смог. Подозреваю что за прошедшие лет 10 лучше с документацией не стало, а совсем наоборот.
Вы имеете в виду именно с MIPI DSI интерфейсом или экраны вообще?
Вообще, если посмотреть вокруг есть довольно большое дисплеев которым и раз в секунду обновляться-то не особо надо. И вполне можно было бы обойтись любым мелким микроконтроллером без гигабитных трансиверов и соответствующих потоков видеоданных.
Ну и физически, особенно oled какой-нибудь, с чего бы отдельный пиксель после включения через сколько-то мс вдруг забыл своё значение яркости, что его надо обязательно N раз в секунду обновлять надо следующим кадром.
больше в low power с lvcmos уровнями (которые из говна и палок на чём угодно изобразить можно) вроде не умеет. Для большего нужны отдельные гигабитные трансиверы, которые не везде есть.
Но довольно большое количество различных дисплеев которые в режиме "фоторамки" отображают статичные картинки которые можно хоть секунду обновлять.
Да и гонять данные через low power камеры/дисплеи вроде обычно не умеют ну или делают вид что не умеют, это опять же про качество и доступность документации.
Хватает сенсоров изображений с jpeg энкодером на борту, да и на дисплеях далеко не всегда надо обязательно 140fps отображать. И для первого и для второго с некоторой натяжкой хватило бы и lowpower режима с его 10МБит/с и любого дохлого МК без гигабитных интерфейсов. Но вот некая огороженность и отсутсвие человеческой документации раздражает.
Да, но только возможности эти довольно ограничены, и если надо что-нибудь лишь чуть сложнее чем просто отображение циферки на экране, геморроя сразу вылезет гораздо больше.
Например измеряемое напряжение будет от какого-нибудь датчика, которым на какой-нибудь подвижке ездить надо, или поворачивать, или греть и смотреть зависимость от температуры.
Хотя казалось бы просто ещё пару команд (тех же scpi) отправить подвижке/нагревателю и опросить его статус.
но сразу же всё упрётся ограниченность языка этого конфиг файла и лютые костыли для обхода этого.
Имхо проще самому на любом скриптовом языке сделать простые обёртки для чтения различных измерительных устройств, чем пытаться приколхозить к какому-то чужому гую, ещё и без исходников.
А чтобы потом не поток циферок в консоли разглядывать, он в несколько строчек заворачивается в gnuplot для отображения графиков на лету.
И в совсем запущенных случаях если это кому-то на сторону для использования отдать надо примитивный гуй с полями ввода всяких параметров тоже в пару строк добавляется что-нибудь вроде https://www.tecgraf.puc-rio.br/iup/en/dlg/iupgetparam.html
Насколько знаю никто текстовый формат непосредственно в железку передавать не будет. Не исключаю что всегда возможно найдутся альтернативно одарённые, но если посмотреть на встроенные бутромы различных МК все обычно городят свой примитивный протокол (бинарный!) с указанием адреса/размера и контрольной суммы куда что писать во внутреннюю (и не очень) память.
Есть даже некие попытки как-то стандартизовать это, например, мелкомягкий .UF2 (в rp2040)
А весь описанный функционал можно спокойно перенести внутрь МК, а со стороны ПК "идеальным loaderом" становится консольная команда copy.
Если используется usb, со стороны МК в бутлоадере прикинуться mass storage'м и со стороны ПК тупо скопировать туда файл прошивки без каких-либо дополнительных утилит.
Ну да, конечно не абсолютно равномерно в 2pi, но анод обычно вроде просто плоскость под 45 градусов к пучку, и "восьмёрка" во все стороны сделает 2pi по одной оси.
В реальных рентгеновских аппаратах мощности трубки могут измеряться в кВт, и там обычно проблемы и ограничения из-за того что вольфрамовые аноды не выдерживают и плавятся, и вполне существуют трубки с вращаюшимися анодами, чтобы размазать прилетающую с электронами мощность на большую площадь.
Ну и на условную флюорографию, если правильно помню, надо, очень грубо говоря, 1милирентген дозы получить, т.е. 10мкЗв или 10мкДж/кг, что равно 1мДж поглощённого ионизирующего излучения на 100кг тушку.
Если теперь учесть эффективность преобразования собственно электронов в рентген, учесть что светит он во все стороны 2пи стерадиан, а не только на фотографируемого, да и поглощается тоже не особо, в основном насквозь пролетает, то там как бы не кДж потратить надо чтобы хотя бы флюорографию сделать. Что не сказать, что очень уж много, в пальчиковой батарейке на порядок больше запасено. Но добывать столько механически трением или из пьезо зажигалки - так себе идея.
Note, however, that the maximum input clock frequency for burst operations which cross page boundaries is 84 MHz
То есть вроде позволяют всё-таки читать непрерывно, но на пониженной частоте (вместо 144МГц), видимо дополнительно кэшируя внутри, чтобы впихнуть открытие/закрытие страниц и рефреши.
Большинство psramов просто зацикливают burst внутри страницы.
tcc main.c -luser32
main.exe: 3584 bytes
На большие объёмы оно уже обычно PSRAM, т.е. внутри sdram который всю "динамику" прячет, а наружу выглядит как обычная асинхронная память. Но там надо аккуратно, могут быть некие грабли с непрерывной выдачей данных, и ограничением непрерывного чтения только в пределах страницы. "видеоданные" возможно придётся по строкам по границам страниц выравнивать.
В качестве компромиса между ram и flash ещё spi eepromы есть, с количеством циклов перезаписи получше. Ну и fram ещё но там на такие размеры цены уже негуманные.
как вариант на попробовать можно ещё ft232h (ft2232h), там в режиме mpsse вроде можно 30МГц непрерывный однобитовый поток с ПК организовать, и заодно gpio дрыгать для hvsync.
однобитный 1440*2560 это 460кБ влезет даже во внутреннюю память rp2350, который наружу может на 150МГц DDR, т.е. на 300МГц выплюнуть через HSTX, заодно сигналы синхронизации сформировать.
применяли бы их в своих проектах?Я от какого-то то-ли 4-го то ли 5-го айфона пытался ковырять сенсор, вроде бы 5642. чтобы из него хоть как-то достать пожатую картинку в каком угодно низком разрешении/качестве, но через какой-нибудь "медленный" интерфейс, а не как положено. Но документация в виде каких-то скриншотов pdfa с китайского сайта и замечательные аппноуты омнивижена в виде нескольких страниц портянок вида i2cwrite(0xaabb, 0xcc); для инициализации различных режимов без описаний, одолеть не смог. Подозреваю что за прошедшие лет 10 лучше с документацией не стало, а совсем наоборот.
Вы имеете в виду именно с MIPI DSI интерфейсом или экраны вообще?Вообще, если посмотреть вокруг есть довольно большое дисплеев которым и раз в секунду обновляться-то не особо надо. И вполне можно было бы обойтись любым мелким микроконтроллером без гигабитных трансиверов и соответствующих потоков видеоданных.
Ну и физически, особенно oled какой-нибудь, с чего бы отдельный пиксель после включения через сколько-то мс вдруг забыл своё значение яркости, что его надо обязательно N раз в секунду обновлять надо следующим кадром.
Вам хватает или имеется в виду, что их довольно-таки много?ну не то что бы прям много, но некторые есть, OV56xx которые в каких-то старых айфонах использовались и как запчасти стоили прям копейки.
10 МБит/с мало.больше в low power с lvcmos уровнями (которые из говна и палок на чём угодно изобразить можно) вроде не умеет. Для большего нужны отдельные гигабитные трансиверы, которые не везде есть.
Но довольно большое количество различных дисплеев которые в режиме "фоторамки" отображают статичные картинки которые можно хоть секунду обновлять.
Да и гонять данные через low power камеры/дисплеи вроде обычно не умеют ну или делают вид что не умеют, это опять же про качество и доступность документации.
Хватает сенсоров изображений с jpeg энкодером на борту, да и на дисплеях далеко не всегда надо обязательно 140fps отображать. И для первого и для второго с некоторой натяжкой хватило бы и lowpower режима с его 10МБит/с и любого дохлого МК без гигабитных интерфейсов. Но вот некая огороженность и отсутсвие человеческой документации раздражает.
да, только я со временем вообще всё в lua перенёс.
и сами "драйвера" устройств стали проще, и логику работы приятнее описывать, чем на bash.
мало того, в 95% случаев простого самописца без какого-либо гуя, который тупо в текстовый csv файл значения непрерывно пишет более чем достаточно.
но easimonenko про альтернативы спрашивал.
Да, но только возможности эти довольно ограничены, и если надо что-нибудь лишь чуть сложнее чем просто отображение циферки на экране, геморроя сразу вылезет гораздо больше.
Например измеряемое напряжение будет от какого-нибудь датчика, которым на какой-нибудь подвижке ездить надо, или поворачивать, или греть и смотреть зависимость от температуры.
Хотя казалось бы просто ещё пару команд (тех же scpi) отправить подвижке/нагревателю и опросить его статус.
но сразу же всё упрётся ограниченность языка этого конфиг файла и лютые костыли для обхода этого.
Имхо проще самому на любом скриптовом языке сделать простые обёртки для чтения различных измерительных устройств, чем пытаться приколхозить к какому-то чужому гую, ещё и без исходников.
https://github.com/pavel212/uffi/blob/master/example/hp3458a.lua
А чтобы потом не поток циферок в консоли разглядывать, он в несколько строчек заворачивается в gnuplot для отображения графиков на лету.
И в совсем запущенных случаях если это кому-то на сторону для использования отдать надо примитивный гуй с полями ввода всяких параметров тоже в пару строк добавляется что-нибудь вроде https://www.tecgraf.puc-rio.br/iup/en/dlg/iupgetparam.html
https://kevincuzner.com/2018/06/28/building-a-usb-bootloader-for-an-stm32/ - 8кБ
https://github.com/sfyip/STM32F103_MSD_BOOTLOADER - 13кБ
у rp2040 bootrom 16кБ
а если по вот этому основательно напильником пройтись
https://github.com/adafruit/tinyuf2
упихать думаю возможно
Какая
блохаSD? КакойзаяцSPI? Почему HEX?Насколько знаю никто текстовый формат непосредственно в железку передавать не будет. Не исключаю что всегда возможно найдутся альтернативно одарённые, но если посмотреть на встроенные бутромы различных МК все обычно городят свой примитивный протокол (бинарный!) с указанием адреса/размера и контрольной суммы куда что писать во внутреннюю (и не очень) память.
Есть даже некие попытки как-то стандартизовать это, например, мелкомягкий .UF2 (в rp2040)
А весь описанный функционал можно спокойно перенести внутрь МК, а со стороны ПК "идеальным loaderом" становится консольная команда copy.
Но зачем?
Если используется usb, со стороны МК в бутлоадере прикинуться mass storage'м и со стороны ПК тупо скопировать туда файл прошивки без каких-либо дополнительных утилит.
Так как скорость передачи данных для отображения не особо критична, spi можно и в однопроводной превратить RC цепочками.
Ну да, конечно не абсолютно равномерно в 2pi, но анод обычно вроде просто плоскость под 45 градусов к пучку, и "восьмёрка" во все стороны сделает 2pi по одной оси.
Мощности всё равно не те.
В реальных рентгеновских аппаратах мощности трубки могут измеряться в кВт, и там обычно проблемы и ограничения из-за того что вольфрамовые аноды не выдерживают и плавятся, и вполне существуют трубки с вращаюшимися анодами, чтобы размазать прилетающую с электронами мощность на большую площадь.
Ну и на условную флюорографию, если правильно помню, надо, очень грубо говоря, 1милирентген дозы получить, т.е. 10мкЗв или 10мкДж/кг, что равно 1мДж поглощённого ионизирующего излучения на 100кг тушку.
Если теперь учесть эффективность преобразования собственно электронов в рентген, учесть что светит он во все стороны 2пи стерадиан, а не только на фотографируемого, да и поглощается тоже не особо, в основном насквозь пролетает, то там как бы не кДж потратить надо чтобы хотя бы флюорографию сделать. Что не сказать, что очень уж много, в пальчиковой батарейке на порядок больше запасено. Но добывать столько механически трением или из пьезо зажигалки - так себе идея.
Ему там psramа на qspi можно донавесить. 8-16МБайт для 386 хватит
собственно red alert так и запустили: https://hackaday.com/2025/04/06/command-and-conquer-ported-to-the-pi-pico-2/
это для dooma внутренними 256к обошлись, https://kilograham.github.io/rp2040-doom/speed_and_ram.html