Килоомы там когда сэмплирующая ёмкость на МГц щёлкает. 10пФ на 1МГц собственно 15кОм и будет.
А для измерения раз в секунду на входе ёмкости поди микрофарадные, так что вход АЦП не видно. Но в 15МОм с учётом микроамперных токов утечки входов всё равно верится с трудом.
Там где barrel shifter есть, это обычно подразумевает совсем не 8ми битную разрядность и умножение там будет не медленнее сдвига, а скорее всего даже быстрее так как будет выполнено одной иструкцией с накоплением.
Впрочем и на AVR уножение (деление на константу) 16х16 будет каких-нибудь ~15 тактов, вместо 8 для x>>4. Да, там есть инструкция swap, но мы же не можем рисковать и надеятся на компилятор. А с учётом отсутсвия аппартных циклов и дополнительных шин для складывания/доставания данных из памяти (в отличии от нормальных dsp под такие задачи заточенных) общее быстродействие цикла for(;;i++) y[i]=y[i-1]+(x[i]-y[i-1])>>N; станет процентов на 10 быстрее на AVR, и чуть-чуть медленнее на нормальных архитектурах, ну и ещё и ценой ограничения коэффициентов только степенями 2. Поэтому "оптимизация" довольно сомнительная.
А заменять умножения сдвигами в большинстве случаев довольно сомнительная "оптимизация", которую компилятор и сам сделает https://godbolt.org/z/s8KcrjK3E
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'м и со стороны ПК тупо скопировать туда файл прошивки без каких-либо дополнительных утилит.
Килоомы там когда сэмплирующая ёмкость на МГц щёлкает. 10пФ на 1МГц собственно 15кОм и будет.
А для измерения раз в секунду на входе ёмкости поди микрофарадные, так что вход АЦП не видно. Но в 15МОм с учётом микроамперных токов утечки входов всё равно верится с трудом.
И городить отдельно питание. Китайский же изолятор на ADUM3160 вроде не особо дороже этого "bluepill" стоит.
Там где barrel shifter есть, это обычно подразумевает совсем не 8ми битную разрядность и умножение там будет не медленнее сдвига, а скорее всего даже быстрее так как будет выполнено одной иструкцией с накоплением.
Впрочем и на AVR уножение (деление на константу) 16х16 будет каких-нибудь ~15 тактов, вместо 8 для x>>4. Да, там есть инструкция swap, но мы же не можем рисковать и надеятся на компилятор. А с учётом отсутсвия аппартных циклов и дополнительных шин для складывания/доставания данных из памяти (в отличии от нормальных dsp под такие задачи заточенных) общее быстродействие цикла for(;;i++) y[i]=y[i-1]+(x[i]-y[i-1])>>N; станет процентов на 10 быстрее на AVR, и чуть-чуть медленнее на нормальных архитектурах, ну и ещё и ценой ограничения коэффициентов только степенями 2. Поэтому "оптимизация" довольно сомнительная.
Без умножений.- это CIC фильтры http://www.dsplib.ru/content/cic/cic.html
А заменять умножения сдвигами в большинстве случаев довольно сомнительная "оптимизация", которую компилятор и сам сделает https://godbolt.org/z/s8KcrjK3E
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'м и со стороны ПК тупо скопировать туда файл прошивки без каких-либо дополнительных утилит.