там нет такого backpressure как у ULPI, только RX клоки 125МГц - выход под которые надо засинхронизироваться с забиранием данных. И даже несовпадение RX(выход) и TX(вход) клоков внутри phy вроде как просто дополнительно буферизируется (правда как именно если вдруг TX клоки медленнее - не очень понимаю). Наружу это никак не вылазит и никому не мешает.
Клок не совсем "от нас", там у 1000Base-T вроде всегда один мастер другой слэйв и клок вообще может и с другой стороны езернетного провода приходить. Но если его на 4 поделить и обратно в PLL pico на 4 помножить, и полярность по ходу нигде не потерять, то может и получится. Ну а на 125х3=375МГц можно и просто "wait 1 pin" вставить и по нему дальше данные читать. Но для начала попробую номинальные 125МГц без "разгона".
Там для ~40 МБ/с есть готовые мосты ft232h, правда чем попало прикинуться не получится.
А для ~400МБ/с есть ft601, но там ног даже у rp2350b не сильно много останется для чего-то ещё помимо usb.
А чтобы просто пропихнуть побольше данных в ПК возможно проще всего через HSTX -> DVI -> MS2130 USB capture. 640x480x60x3 = 55МБ/с. там вроде YUV компрессию научились отключать, ну либо 16бит на пиксель и 36МБ/с. теоретически даже есть обратный медленный канал передачи через EDID.
з.ы. а я аж на PIO-GMII замахнулся. Если 125МГц клоки с phy получится засинхронизировать так чтобы из PIO просто непрерывно данные читать/писать каждый такт не по внешнему клоку, а по внутреннему.
Сгенерированный файл презентации может потребовать не только картинку/видео, а например какие-нибудь данные для интерактивного графика, тогда через input выбирать файл придётся на каждом слайде в режиме "презентации". Просто положить их рядом с file://presentaion.html нормально не получится, ну разве что только если обернуть их в js:
export const binaryData = new Uint8Array([12,244,87,...]);
И собственно "редактор" не обязательно вырезать из сгенерированной "release" презентации, можно и оставить в "debug" версии.
ну просто картинки/видео показать пожалуй всё-таки откроет, но грабли там местами есть:
Loading images from a local file:// path into a <canvas> element to extract data (e.g., via toDataURL) is blocked by browser CORS security policies and cannot be bypassed using HTML attributes like crossorigin="anonymous"
При открытии .html через file://, а не от сервера через https:// у браузеров нынче может быть несколько иное мнение по поводу открытия других, рядом лежащих файлов. Так что решение с упаковкой в один html - более чем адвекватное.
Они все, внезапно, обращаются к драйверам видеокарты, где для компиляции шейдеров внутри спрятан какой-нибудь условный clang, мегабайт так на 50 если не больше
И даже труЪ-олдскульные в int 10h mode 13h под ДОС, опять же получается читеры, не сами с видеокартой общаются через i/o, а обращаются к bios, чтобы он её за них сконфигурировал и отмапил видеопамять в А000.
В зависимости от степени "оригинальности" там пожалуй когда-то были и нотпады не то что без всяких co-pilot'ов, но возможно даже и без richedit, с тупо стандартным контролом CreateWindow("edit", ... ) из user32.dll
с отсутсвием в убогих МК barrel shifterов вот это вот 0xB4>>x будет ужОс во что скомпилировано(циклы с побитовым сдвигом), проще 16байт флэша на полную таблицу потратить.
int delta(bool a, bool b){
static bool pa=0, pb=0;
bool pos = a^pb, neg = b^pa, moved = pos^neg;
pa=a; pb=b;
return (moved&pos) - (moved&neg);
}
Нынче в любом МК за <1$ есть АЦП, достаточный для прямой оцифровки всех ДВ станций точного времени 50, 66, 77кГц разом. И дури по вычислительной мощности более чем достаточно и для фильтров и выделения несущей и для демодуляции посылок с временем, в цифре. Даже усилитель можно взять вообще тупо единственный инструментальный ОУ с 1нВ/rtHz шумами.
Калибровать линейность АЦП прямо китайским блоком питания, без дополнительно измерения напряжения хотя бы каким-нибудь китайским же мультиметром с тем же последовательным портом - замечательная идея. Что ж там за АЦП такой - 8ми битный самопальный "двойного интегрирования" на RC цепочке, таймере и IO МК?
С целочисленными множителем вроде бы должно быть лучше чем с дробным
там нет такого backpressure как у ULPI, только RX клоки 125МГц - выход под которые надо засинхронизироваться с забиранием данных. И даже несовпадение RX(выход) и TX(вход) клоков внутри phy вроде как просто дополнительно буферизируется (правда как именно если вдруг TX клоки медленнее - не очень понимаю). Наружу это никак не вылазит и никому не мешает.
Клок не совсем "от нас", там у 1000Base-T вроде всегда один мастер другой слэйв и клок вообще может и с другой стороны езернетного провода приходить. Но если его на 4 поделить и обратно в PLL pico на 4 помножить, и полярность по ходу нигде не потерять, то может и получится. Ну а на 125х3=375МГц можно и просто "wait 1 pin" вставить и по нему дальше данные читать. Но для начала попробую номинальные 125МГц без "разгона".
Там для ~40 МБ/с есть готовые мосты ft232h, правда чем попало прикинуться не получится.
А для ~400МБ/с есть ft601, но там ног даже у rp2350b не сильно много останется для чего-то ещё помимо usb.
А чтобы просто пропихнуть побольше данных в ПК возможно проще всего через HSTX -> DVI -> MS2130 USB capture. 640x480x60x3 = 55МБ/с. там вроде YUV компрессию научились отключать, ну либо 16бит на пиксель и 36МБ/с. теоретически даже есть обратный медленный канал передачи через EDID.
з.ы. а я аж на PIO-GMII замахнулся. Если 125МГц клоки с phy получится засинхронизировать так чтобы из PIO просто непрерывно данные читать/писать каждый такт не по внешнему клоку, а по внутреннему.
при большом желании из PIO можно пожалуй ULPI изобразить для внешнего hispeed phy.
а там вроде бы местами usb не совсем полноценный, CDC внутри аппаратно гвоздями прибито?
Нет, не решаемая, в том смысле что если надо вот это вот делать == не работает.
Чем упаковка внутрь html так хуже этих замечательных костылей?
з.ы. С каким-нибудь, например, safari что делать? или в любом "мобильном" браузере?
Сгенерированный файл презентации может потребовать не только картинку/видео, а например какие-нибудь данные для интерактивного графика, тогда через input выбирать файл придётся на каждом слайде в режиме "презентации". Просто положить их рядом с file://presentaion.html нормально не получится, ну разве что только если обернуть их в js:
export const binaryData = new Uint8Array([12,244,87,...]);
И собственно "редактор" не обязательно вырезать из сгенерированной "release" презентации, можно и оставить в "debug" версии.
ну просто картинки/видео показать пожалуй всё-таки откроет, но грабли там местами есть:
Loading images from a local
file://path into a<canvas>element to extract data (e.g., viatoDataURL) is blocked by browser CORS security policies and cannot be bypassed using HTML attributes likecrossorigin="anonymous"При открытии .html через file://, а не от сервера через https:// у браузеров нынче может быть несколько иное мнение по поводу открытия других, рядом лежащих файлов. Так что решение с упаковкой в один html - более чем адвекватное.
Они все, внезапно, обращаются к драйверам видеокарты, где для компиляции шейдеров внутри спрятан какой-нибудь условный clang, мегабайт так на 50 если не больше
И даже труЪ-олдскульные в int 10h mode 13h под ДОС, опять же получается читеры, не сами с видеокартой общаются через i/o, а обращаются к bios, чтобы он её за них сконфигурировал и отмапил видеопамять в А000.
в 3.11/95/98, потом позволили увеличивать
https://en.wikipedia.org/wiki/Windows_Notepad#Limitations
В зависимости от степени "оригинальности" там пожалуй когда-то были и нотпады не то что без всяких co-pilot'ов, но возможно даже и без richedit, с тупо стандартным контролом CreateWindow("edit", ... ) из user32.dll
можно и без richedit https://www.catch22.net/tuts/neatpad/neatpad-overview/
не 2кБ конечно, но не сказать что сильно жирнее.
гуй там страшненький конечно и местами прям бесит, но не настолько всё плохо.
OpenFOAM тоже выглядит больно для совсем простых вещей.
з.ы. в вольфрамовскую математику FEM уже довольно давно завезли.
https://reference.wolfram.com/language/PDEModels/tutorial/StructuralMechanics/ModelCollection/3DPrintedMechanicalDesign.html
так это ведь не я решил в lookup таблицы засунуть то что парой xorов вычисляется, да ещё и упаковать побитово
с отсутсвием в убогих МК barrel shifterов вот это вот 0xB4>>x будет ужОс во что скомпилировано(циклы с побитовым сдвигом), проще 16байт флэша на полную таблицу потратить.
>распространенность деталей
Нынче в любом МК за <1$ есть АЦП, достаточный для прямой оцифровки всех ДВ станций точного времени 50, 66, 77кГц разом. И дури по вычислительной мощности более чем достаточно и для фильтров и выделения несущей и для демодуляции посылок с временем, в цифре. Даже усилитель можно взять вообще тупо единственный инструментальный ОУ с 1нВ/rtHz шумами.
а не вот это вот всё из рассыпухи
ещё бы с фапч, который за несущую цепляться умеет, а-ля GNSS Disciplined Oscillator, только из говна и палок.
Калибровать линейность АЦП прямо китайским блоком питания, без дополнительно измерения напряжения хотя бы каким-нибудь китайским же мультиметром с тем же последовательным портом - замечательная идея. Что ж там за АЦП такой - 8ми битный самопальный "двойного интегрирования" на RC цепочке, таймере и IO МК?