Судя по виду меди на фотографиях - последовательная шлифовка слой за слоем, а учитывая что медь там 100мкм, а не 18 как обычно, промахнуться довольно сложно.
Датчики влажности (они вроде бы емкостные) имеют нехорошее свойство нанюхаться чего-нибудь и начать показывать "погоду" :) причём необратимо. Просто полежали в комнате даже не особо рядом где какой-то эпоксидкой что-то клеили - всё, пожалуйте бриться, показания просто случайные значения.
Ну и зависимость от температуры при 23 градусах 20.6гр/m^3, при 24 - 21.8. то есть 1 градус ошибки температуры - 6% ошибки влажности.
выхлоп на пару мегабайт получается, для helloworlda с миганием светодиодом ещё можно руками пару регистров переписать, не ошибившись при этом, но вообще так делать не надо. Плюс стуктуры/енумы, в отличии от макросов, частично на компилятор перекладывают проверку типов, и не позволят, например, случайно записать 32 бита куда надо только 16. Если бы ещё язык позволял без костылей анонимные юнионы битовых полей c енумами, не позволяя писать "чужие" значения было бы совсем красиво, но хотя бы так.
там нет такого 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
Судя по виду меди на фотографиях - последовательная шлифовка слой за слоем, а учитывая что медь там 100мкм, а не 18 как обычно, промахнуться довольно сложно.
Знаменитая функция
Q_rsqrtиз Quake III выглядит следующим образом:без оригинальных комментариев как-то немного не то.
Датчики влажности (они вроде бы емкостные) имеют нехорошее свойство нанюхаться чего-нибудь и начать показывать "погоду" :) причём необратимо. Просто полежали в комнате даже не особо рядом где какой-то эпоксидкой что-то клеили - всё, пожалуйте бриться, показания просто случайные значения.
Ну и зависимость от температуры при 23 градусах 20.6гр/m^3, при 24 - 21.8. то есть 1 градус ошибки температуры - 6% ошибки влажности.
развесистой периферии нынче сильно много всякой стало
SVDConv rp2040.svd --generate=header --fields=struct --fields=enum
выхлоп на пару мегабайт получается, для helloworlda с миганием светодиодом ещё можно руками пару регистров переписать, не ошибившись при этом, но вообще так делать не надо. Плюс стуктуры/енумы, в отличии от макросов, частично на компилятор перекладывают проверку типов, и не позволят, например, случайно записать 32 бита куда надо только 16. Если бы ещё язык позволял без костылей анонимные юнионы битовых полей c енумами, не позволяя писать "чужие" значения было бы совсем красиво, но хотя бы так.
#define GPIO_BASE 0x40014000
rp2040.svd всё-таки можно было из SDK и позаимствовать.
С целочисленными множителем вроде бы должно быть лучше чем с дробным
там нет такого 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