Pull to refresh
26
0.1

User

Send message

Какая блоха 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

да,

однако, после того как на 2040 запустили дум и вот недавно ещё редалёрт на 2350, эмуляция всяких 4/8 битных древностей, типа спектрума целиком в pi pico, выглядит уже не столь впечатляюще.

поскольку тот же Python больше не во младенческом возрасте

наброшу,

Сугубо имхо, но использовать пробел в качестве элемента синтаксиса языка это гораздо большая упоротость чем все вместевзятые: индексация с 1, глобальные переменные, begin/end и т.п.

В качестве встраиваемого скриптового языка в ядро (linux/netbsd) насколько знаю питон или js, пусть и подрезанные, запихать никто даже особо не пытался, а lunatik как-то живёт.

Чуть менее упоротым синтаксисом (тикль вроде заметно старше)? Даже несмотря на все те вещи (~=, then, begin, end, continue) которые в Lua можно было бы сделать и более похожими на С.

Метатаблицами, которые опять же, хоть и несколько неочевидно на первый взгляд, но элегантно позволяют делать много чего.

Довольно аккуратным С api, но тут про tcl мало чего знаю, так что сложно сравнивать.

может не использовать целые числа в качестве названия членов объекта?

чтобы можно было делать маленькие скрипты на JavaScript

Потом кармы в виде сотни тысяч строк яваскрита не боитесь? это выглядит имхо даже хуже.

з.ы чтобы совсем не скучно было надо просто собрать саму Lua в wasm :)

В Математике индексация с 1 не потому что 0 уже был занят типом, скорее в пустое место между первым (1) и последним (-1) можно было что-нибудь воткнуть, размер, например, но путаницы было бы больше при случайном обращении к [[0]] по ошибке.

Осталось только понять зачем это "смещение" от 0 по адресу пытаются использовать для индексации в языках, в которых впринципе такой сущности как "указатель" на какой-то адрес в памяти и соответствующие манипуляции с ними и памятью отсутсвуют как класс.

В Си и языках которые допускают прямую работу с памятью и вообще можно inline assemby - пожалуйста. В верилоге индексация как в паскале хоть и произвольная, но считать биты в байте с единицы никто не будет, т.к. 2^0=1,

wire [7:4] w1;
wire [3:6] w2;

а тот кто массивы 0 индексируемых бит будет объединять в массивы 1 индексированных "слов" видно что очень не любит людей которым это потом после него разгребать придётся :)

там рефлексию человеческую до сих пор не завезли, поэтому через внешние генераторы типа swig или tolua++, которые из хедеров генерят обёртки - вполне.

Есть достаточно 1indexing языков (Julia, Wolfram Mathematica, R, Matlab), где нету реализации массивов как тупо указателя на первый :) элемент и вообще указателей как таковых и соответственно связанной с ними адресной арифметики (сишный вывернутый мехом внутрь index[array] == array[index], и количество ошибок связанных с array[N] для адресации последнего элемента). И эти костыли, которые экономили лишний байт в допотопных языках когда память измерялась в килобайтах и имеющие смысл когда язык недалеко от железа и хотя бы умеет в inline assembly, теперь из-за якобы "обратной совместимости" зачем-то тащат дальше, например в какие-нибудь js и python, труъ "программисты" которых понятия не имеют откуда вообще взялась индексация с 0, а если вдруг с 1 то это ужас-ужас-ужас.

Я вроде достаточно написал кода для взаимодействия Lua<->C, там где индексация вообще получается "смешанной" с разных сторон и это как-то не особо напрягало.

требует больших объемов закрытого кода, из-за чего его практически невозможно реализовать самостоятельно, даже если у вас есть все необходимые спецификации

А они вообще есть? Особенно на всякие интловские ME и амдшные PSP.

Ну то есть coreboot с блобами, а у всяких libre/gnuboot и открытых seabios в списке поддерживаемого оборудования самое новое лет 15 назад с производства снято.

И baremetalный "hello world" (без uefi), чтобы прямо из spi flash, невозможен сегодня на современном х64 железе впринципе? Для какой-нибудь более специфичной железки у которой аппаратная конфигурация заведомо определена раз и навсегда, распаяна и меняться никода не будет.

Вы там в одном варианте на 10ГэВ замахнулись, градиент ускорения в сверхпроводящих резонаторах ~30МэВ/м, длину "компактного" ускорителя можете прикинуть сами.

https://www.xfel.eu/facility/accelerator/index_eng.html

Пучок "короткий" только для ТГц источников, где длина волны под сотню мкм.

А для более коротких волн в длинном пучке электронов на каждый излучающий электрон с какой-то фазой всегда найдётся ещё один такой же, который будет ровно на пол периода излучения отставать и излучать соответственно в противофазе. В результате такого "некогерентного" излучения по статистике складывается поле только от корня из количества электронов.

Чтобы они излучали когерентно надо электронный пучок вдоль длины промодулировать по плотности с периодом излучаемой длины волны чтобы они все излучали в фазе.

Так обычно само получается если пучок достаточно аккуратный, а ондулятор длинный (~1000 периодов), тогда электромагнитные поля от излучения самого пучка добавляют/отнимают у электронов энергию, в результате он сам себя модулирует по интенсивности и вместо корня из количества электронов в складываются уже просто количество электронов без корня, это в поле, по мощности получается пропорционально количеству электронов в квадрате вместо просто количества электронов в пучке. И при зарядах пучка ~наноКулона т.е. количестве электронов ~1e7 разница заметная.

Но резонаторы не делают потому что рентген с длиной волны в десяток кЭв не очень хорошо отражается, для него как бы всё почти прозрачно, разве что только под совсем небольшими углами.

Вместо резонаторов и накопления "излучения" для лучшего его взаимодейтвия с пучком в лазерах на свободных электронах делают seeding, то есть модуляцию оптическим лазером, чтобы потом по этим предварительным "зарубкам" на пучке, пусть и на в 1000 раз большей длине волны, процесс потом SASE начался увереннее.

Есть всякие проекты с резонаторами https://arxiv.org/abs/1903.09317 но насколько знаю никто так и не реализовал нормально.

потому что нужный адрес это &_text_start, а не сам _text_start.

Картинки перерисуйте, электроны отклоняются не вдоль магнитного поля, а поперёк.

1Т поля при 10мм периоде без сверхпроводимости получить не реально.[https://iopscience.iop.org/article/10.1088/1361-6668/acc1a8]

Ондуляторы обычно либо сверхпроводящие, либо из постоянных магнитов, "теплые" электромагнитные почти никто не делает, за редким исключением больших периодов и не очень больших полей (например источники ТГц излучения на ускорителях с большой энергией). Ондулятор с переменным периодом: https://pubs.aip.org/aip/acp/article/2054/1/030024/1023236/Variable-period-undulator-with-tunable

Чтобы получился "лазер" электронный пучок должен быть короче излучаемой длины волны (что как-то работает для ТГц диапазона, но не для 0.01–10 нм) либо очень длинный ондулятор для возникновения SASE и "микробанчинга" пучка собственным излучением.

1
23 ...

Information

Rating
3,484-th
Registered
Activity