Теоретически предел магнитной индукции материала NdFeB ~ 1,6 Тл"; Пять (~5 Тл) - это, мягко говоря, несколько больше.
1.6Т остаточной намагниченности внутри магнита не ограничивают этим значением поля которые можно создать снаружи от магнита, например свернув его в цилиндр или сферу Халлбаха. Там коэрцитивная сила является ограничением чтобы магнит сам себя не размагнитил.
Производительность при этом выросла с единиц МФлопс до ТФлопс. Какое безобразие! Можно современному процессору зажать частоту до такого же потребления в пару Вт и всё равно будет порядка на 3 быстрее чем 486. Статическое потребление тоже слегка подросло с увеличением количества транзисторов, но оно как раз более тонким тех. процессом почти скомпенсировалось, учитывая во сколько раз выросло количество транзисторов.
Килоомы там когда сэмплирующая ёмкость на МГц щёлкает. 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
https://github.com/scmrtos/scmrtos-doc/tree/master/pdf
1.6Т остаточной намагниченности внутри магнита не ограничивают этим значением поля которые можно создать снаружи от магнита, например свернув его в цилиндр или сферу Халлбаха. Там коэрцитивная сила является ограничением чтобы магнит сам себя не размагнитил.
Вот как раз 5Т при комнатной температуре https://cerncourier.com/a/record-breaking-magnet-has-five-tesla-field/ правда в зазоре 0.15мм всего
Производительность при этом выросла с единиц МФлопс до ТФлопс. Какое безобразие! Можно современному процессору зажать частоту до такого же потребления в пару Вт и всё равно будет порядка на 3 быстрее чем 486. Статическое потребление тоже слегка подросло с увеличением количества транзисторов, но оно как раз более тонким тех. процессом почти скомпенсировалось, учитывая во сколько раз выросло количество транзисторов.
Килоомы там когда сэмплирующая ёмкость на МГц щёлкает. 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