даже для 8086 есть варианты с передачей через регистры, но это лишь некие соглашения.
никто же не мешает упороться и для вызова своей функции, например, выделить где-нибудь память, сложить туда аргументы и адрес возврата, а указатель положить по какому-нибудь абсолютному адресу 0xDEADBEEF не задействуя для этого ни регистры ни стэк.
попадались usb2com с кривыми драйверами, которые например при физическом выдёргивании шнурка без закрытия порта стабильно вызывали у виндов синий экран.
ну а положив каким-нибудь таким образом сначала виртуалку и проброс устройства можно затем и за хоста взяться :)
без относительно виртуалки у хоста же ведь тот же кривой драйвер для этого устройства.
так всё равно ж оно обернуто в пару каких-нибудь функций вроде put_pixel и swap_buffer для тех кто выше.
а будет там внутри fprintf, просто запись в буфер или прямо в дисплей висящий на внешней шине и отмапленный в общее адресное пространство, или вообще вызов egavga.bgi :)) не столь принципиально.
Склеивать вместе идентификаторы чтобы потом их пытаться разобрать не самая замечательная идея, хотя бы пробелы вместо умножения (как в вольфрамовской математике).
Так-то есть ffi от luajit, и alien который lua обёртка для libffi, вполне себе кроссплатформенные.
Я слишком туп оказался чтобы их под виндами с lua54 собрать, пришлось пилить своё :)
Там "платформеннозависимого" кода не сильно много (собственно всё вынесено в win64.c), только пара функций, которые ассембленый код с учётом calling convention генерят, в них только порядок запихивания аргументов в стэк/регистры поменять, а остальное dlsym/GetProcAddress и mprotect/VirtualProtect только названиями отличаются, может когда-нибудь руки дойдут.
Суть в том, что файл, который управляет сборкой проектов для Zig - это файл с кодом на языке Zig
пожалуй на любом языке можно вызвать компилятор как внешнюю программу и сделать тем самым свою систему собрки с нескучными обоями, выглядит только это обычно довольно страшненько по сравнению даже с просто шелл скриптами.
Потому что это дополнительная и совершенно не нужная здесь сущность, для побитового перебора достаточно чтобы слэйвы просто сравнивали присланный ID со своим как число на больше/меньше.
Оборудование какого производителя использует 32 бит на адрес в 485 ?
Нормальные производители таким онанизмом заниматься не будут, сделают нормальный способ задать 7-8битный адрес устройству
но приходилось как-то изобретать подобный велосипед для подключения кучи однотипных устройств по 485, для которых совсем не хотелось руками раздавать каждому логические адреса на шине (джамперами / в еепром), но у которых есть уникальный chip ID в МК, 64битный, по которому их можно различать, и, просканировав шину мастером при старте, раздать им соответствующие логические 128 адресов для последующей адресации на шине. некий убогий аналог dhcp для rs485.
собственно для 1wire всё уже давно придумано.
а слэйвам для этого надо только две команды:
1) отозваться хоть как-то, если присланный мастером ID больше чем собственный и плевать на коллизии, наличие просто стартового бита в ответе означает что на шине кто-то есть. и без дополнительного дергания IO.
2) получить свой логический однобайтный адрес и в дальнейшем перестать отзываться на запросы с ID, чтобы не мешать остальным.
Если вычислить DFT, обнулить высокие частоты и вычислить обратное DFT, то не меняется фаза тех низкочастотных гармоник, которые мы оставили.
Умножение в частотной области (на ступеньку с занулением определённых частот) == свёртка во временной, ровно то что КИХ фильтры и делают без преобразования туда обратно.
Фаза и так не портится, ФЧХ абсолютна линейна и соответствует просто задержке на половину длины фильра.
Ваше "скользящее среднее" просто надо считать не от X[i]..X[i+N] а от X[i-N/2] до X[i+N/2], и внезапно ничего никуда смещаться не будет.
acuuracy grade это абсолютная ошибка вообще, в основном масштаба, на длине 1м, то есть целиком линейка может оказаться 1.000001м или 0.999999м вместо 1.0, там стекло какое-то специальное с <0.1ppm/C коэффициентом расширения.
а период да 2мкм, и аккуратно измеряя амплитуду синуса/косинуса, при вычислении их арктангенса умудряются получить субнм разрешение, с ошибкой интерполяции (локальная нелинейность) в единицы нм, и длина волны тут ни при чём.
и как он интересно отличит поле от магнита на оси от поля магнита который кто-то просто рядом сбоку положил, отчего "ноль" на несколько градусов уедет?
нормальные оптические энкодеры рисуют на стекле какой-нибудь фотолитографией, там линейные разрешения в нанометры, ну в десяток нм можно получить. но и ценник соответствующий
оптический энкодер из говна и палок (TCUT1350)
тоже 0.1 градуса даёт, но после нормальной индивидуальной калибровки, очень уж чувствительный к аккуратности позиционирования.
https://en.wikipedia.org/wiki/X86_calling_conventions#List_of_x86_calling_conventions
даже для 8086 есть варианты с передачей через регистры, но это лишь некие соглашения.
никто же не мешает упороться и для вызова своей функции, например, выделить где-нибудь память, сложить туда аргументы и адрес возврата, а указатель положить по какому-нибудь абсолютному адресу 0xDEADBEEF не задействуя для этого ни регистры ни стэк.
попадались usb2com с кривыми драйверами, которые например при физическом выдёргивании шнурка без закрытия порта стабильно вызывали у виндов синий экран.
ну а положив каким-нибудь таким образом сначала виртуалку и проброс устройства можно затем и за хоста взяться :)
без относительно виртуалки у хоста же ведь тот же кривой драйвер для этого устройства.
хабр съел тэг <sarcasm>
у меня вот местами есть W7 и яваскрипта там тоже нет.
а окошко можно и спрятать
а что не питон? или VBA?
.bat файл может сделать себе
del "%~f0"ft232h
не буду спорить,
возможно автор свою очередную графическую библиотеку изобретает, вместе с таким вот странным велосипедом для "отладки" этого на ПК
так всё равно ж оно обернуто в пару каких-нибудь функций вроде put_pixel и swap_buffer для тех кто выше.
а будет там внутри fprintf, просто запись в буфер или прямо в дисплей висящий на внешней шине и отмапленный в общее адресное пространство, или вообще вызов egavga.bgi :)) не столь принципиально.
так-то заголовок не самый сложный, только разрешение по горизонтали должно быть кратно 4, чтобы без padding. вроде бы так:
int s = 54+w*h*3;
char header[54] = {'B', 'M', s, s>>8, s>>16, s>>24, 0, 0, 0, 0, 54, 0, 0, 0, 40, 0, 0, 0, w, w>>8, w>>16, w>>24, h, h>>8, h>>16, h>>24, 1, 0, 24, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}; дальше w*h*3 байт данных пикселей
а можно через popen открыть gnuplot, сказать ему
fprintf(f, "set view map\n");
fprintf(f, "splot '-' matrix with image\n");
потом данные и e\ne\n в конце
вылезет окошко с пикселями https://gnuplot.sourceforge.net/demo/heatmaps.html
Мне кажется, что это немного другой жанрда по коду точно такой же парсер (из книги Страуструпа), который 90% занимает, ВМ там в последних 50 строчках.
только раширенный немного добавлением типов, указателей и циклов/условных переходов до такой степени, чтобы мог сам себя собрать.
console.log(new ExpressionCalc('ab=3; a=1; b=2; x=pi/3; abcos(x)').calc()); //1.0
console.log(new ExpressionCalc('a=1; b=2; x=pi/3; ab=3; abcos(x)').calc()); //1.5
Склеивать вместе идентификаторы чтобы потом их пытаться разобрать не самая замечательная идея, хотя бы пробелы вместо умножения (как в вольфрамовской математике).
https://github.com/rswier/c4/blob/master/c4.c
не совсем js конечно, но зато с компиляцией в байткод стэковой виртуальной машины и даже возможностью самосборки.
немного допилить, чтобы wasm байткод на выходе генерил, потом самособрать и засунуть в браузер.
Так-то есть ffi от luajit, и alien который lua обёртка для libffi, вполне себе кроссплатформенные.
Я слишком туп оказался чтобы их под виндами с lua54 собрать, пришлось пилить своё :)
Там "платформеннозависимого" кода не сильно много (собственно всё вынесено в win64.c), только пара функций, которые ассембленый код с учётом calling convention генерят, в них только порядок запихивания аргументов в стэк/регистры поменять, а остальное dlsym/GetProcAddress и mprotect/VirtualProtect только названиями отличаются, может когда-нибудь руки дойдут.
ну да, надо бы конечно,
а этот опциональный заголовок он вообще может быть разного размера? ну кроме 0 и 176 байт, когда из него EXPORT_DIRECTORY и берётся
Суть в том, что файл, который управляет сборкой проектов для Zig - это файл с кодом на языке Zig
пожалуй на любом языке можно вызвать компилятор как внешнюю программу и сделать тем самым свою систему собрки с нескучными обоями, выглядит только это обычно довольно страшненько по сравнению даже с просто шелл скриптами.
https://github.com/tsoding/nobuild
Там даже таких слов как маска нет.
Потому что это дополнительная и совершенно не нужная здесь сущность, для побитового перебора достаточно чтобы слэйвы просто сравнивали присланный ID со своим как число на больше/меньше.
Оборудование какого производителя использует 32 бит на адрес в 485 ?
Нормальные производители таким онанизмом заниматься не будут, сделают нормальный способ задать 7-8битный адрес устройству
но приходилось как-то изобретать подобный велосипед для подключения кучи однотипных устройств по 485, для которых совсем не хотелось руками раздавать каждому логические адреса на шине (джамперами / в еепром), но у которых есть уникальный chip ID в МК, 64битный, по которому их можно различать, и, просканировав шину мастером при старте, раздать им соответствующие логические 128 адресов для последующей адресации на шине. некий убогий аналог dhcp для rs485.
собственно для 1wire всё уже давно придумано.
а слэйвам для этого надо только две команды:
1) отозваться хоть как-то, если присланный мастером ID больше чем собственный и плевать на коллизии, наличие просто стартового бита в ответе означает что на шине кто-то есть. и без дополнительного дергания IO.
2) получить свой логический однобайтный адрес и в дальнейшем перестать отзываться на запросы с ID, чтобы не мешать остальным.
дальше бинарый поиск.
а для этого есть автокорреляция,
и затем гражданин Герцель для DFT с одним умножением на отсчёт, без тригонометрии.
Если вычислить DFT, обнулить высокие частоты и вычислить обратное DFT, то не меняется фаза тех низкочастотных гармоник, которые мы оставили.
Умножение в частотной области (на ступеньку с занулением определённых частот) == свёртка во временной, ровно то что КИХ фильтры и делают без преобразования туда обратно.
Фаза и так не портится, ФЧХ абсолютна линейна и соответствует просто задержке на половину длины фильра.
Ваше "скользящее среднее" просто надо считать не от X[i]..X[i+N] а от X[i-N/2] до X[i+N/2], и внезапно ничего никуда смещаться не будет.
acuuracy grade это абсолютная ошибка вообще, в основном масштаба, на длине 1м, то есть целиком линейка может оказаться 1.000001м или 0.999999м вместо 1.0, там стекло какое-то специальное с <0.1ppm/C коэффициентом расширения.
а период да 2мкм, и аккуратно измеряя амплитуду синуса/косинуса, при вычислении их арктангенса умудряются получить субнм разрешение, с ошибкой интерполяции (локальная нелинейность) в единицы нм, и длина волны тут ни при чём.
https://www.heidenhain.com/products/linear-encoders/exposed/lip-200
диффракция тут никак не мешает ещё пока.
период ~мкм, интерполяцией вытягивают нанометры.
у линеек с периодом 20мкм разрешение 20нм. т.е. если sin/cos хотя бы с 10разрядами оцифровать разрешение и получается на три порядка меньше периода.
причем 20мкм линейки даже не на стекле, на фольге какой-то печатают, с обратной стороны клеевой слой, как скоч, куда надо просто лепится.
в даташите там нелинейность в 1 градус.
и как он интересно отличит поле от магнита на оси от поля магнита который кто-то просто рядом сбоку положил, отчего "ноль" на несколько градусов уедет?
нормальные оптические энкодеры рисуют на стекле какой-нибудь фотолитографией, там линейные разрешения в нанометры, ну в десяток нм можно получить. но и ценник соответствующий
тоже 0.1 градуса даёт, но после нормальной индивидуальной калибровки, очень уж чувствительный к аккуратности позиционирования.