Именно так. На входе ставим малошумящий операционник, экранирование сигналов от помех коаксальным кабелем, сигнальные линии на внутренних слоях и прочие премудрости.
У этих людей одна мотивация - доить фонды. А с приходом ИИ сейчас появилась еще одна - затянуть ИИ как можно больше и глубже, чтобы опять же - доить. Вбуханное в эту тему с ума сшедшее бабло изговняколо абслютно всё.
Это самый настоящий заговор! Кучка п#$%ров под предводительством Canonical пытается убить X11 (Xorg) и внедрить Rust везде где только можно. Но по факту у них ничего не выходит. Более 50% пользователей Linux всё еще используют Xorg, а многие переходят на Xlibre и отказываются от Wayland. Нужно сопротивляться всеми силами этому наплыву идиотии и отказываться от дистрибутивов которые пытаются похоронить X11, навязать убогие технологии, заменить отработанные веками решения на "новое и модное".
Прискорбно сознавать, что Базальт со своим ALT вошел в их круг. Буду сносить ALT везде.
В данный момент (мне 44 года) мне строительство своего Desktop ни разу не интересно.
Мне в этом году будет 50, но причем тут возраст ? Я не занимаюсь "строительством своего Desktop", просто установил FreeBSD и ряд требуемых мне пакетов. У меня даже дети используют FreeBSD на ноутах.
Про встроенный ЦАП не скажу, так как использовал внешний (SPI), но на АЦП у меня получалось как раз 0,1-0,15%. Учтите, что на MIK32 опорное напряжение АЦП - 1,2 В.
Код из EEPROM исполняется на частоте 32 МГц без задержек.
Я реализовывал датчик магнитного расходомера на MIK32 - ШИМ возбуждения катушки, опрос АПЦ, рассчет основного параметра и выдача его по 4-20 мА и одновременно по RS-485/ModbusRTU. Точности АЦП достаточно, хотя там есть нелинейности снизу и сверху. Весь код вмещался в EEPROM.
То при компиляции Вы получите универсальный код для инициализации всех таймеров, даже если Вы используете всего лишь один из них. И такого балласта и в HAL, и в библах Arduino предостаточно.
Ну и я всегда включаю Link-Time Optimization (-flto).
Вы всё таки посмотрите в настройки драйвера эмулятора COM порта (FTDI), там раньше были разные опции, в том числе размеры буферов. Увеличение размера буфера давало увеличение CPS. Но это было более 15-ти лет назад и на Win 7. :-)
Разработчик ожидает определенную производительность и не получает её из-за тонны лишнего кода под капотом ардуиновских функций. Это я к тому, что тем , кто перерос Arduino, следует слезать и с Arduino IDE.
Именно так. Из-за универсальности кода ардуиновсих библиотек в них содержится масса лишнего, что просто поедает драгоценную EEPROM и SRAM этого крохотного МК, и ко тому же, делает код медленнее. Так, что тут либо резать код библиотек #ifdef-ами, либо отказываться от Arduino IDE и писать всё самому используя только то, что требуется.
Попробовал пропатчить openFPGALoader - с наскоку ничего не вышло. Но, я посмотрел какой CPS при загрузке во Flash (SPIFI) дает родной mik32_upload.py через OpenOCD на наших изделия:
SPIFI writing successfully completed!
[02:26:32] Wrote 315904 bytes in 45.05 seconds (effective 6.8 kbyte/s)
6.8 КБ/сек это конечно далеко от желаемого, но всё же не 0.9 КБ/сек как у Вас. Что-то где-то у Вас требует подкрутки. Моё подозрение падает на Вашу винду и "слабоватый" драйвер, не позволяющий выполнять "bit banging" с хорошей скоростью. Попробуйте подкрутить размеры I/O буферов в насройках драйвера FTDI, если таковые еще там остались. У меня на ноуте FreeBSD.
Направление верное. У MIK32 есть два 32-х битных 4-х канальных ШИМ таймера с загрузкой из ПДП (DMA), Теоретически, это может дать хорошее многолосное звучание.
LinuxKPI - да. Всё остальное - нет.
Погрешность конечно же описана, но есть нюанс. ;-) Читайте мою прошлогоднюю статью пор MIK32.
Именно так. На входе ставим малошумящий операционник, экранирование сигналов от помех коаксальным кабелем, сигнальные линии на внутренних слоях и прочие премудрости.
Срочно поменять местами!
А что, разве в мире open source есть что-то, что написано не на коленке Васей (Джоном) ? ;-)
Что в том пакете - не спрашивайте. Docker я на дух не переношу, сама идея мне претит.
А каких именно примеров Вам требуется ? Их есть у меня.
Лучше на Xlibre, там много чего исправлено как раз в части стабильности.
Кто нибудь напишет прослойку что-то типа xwayland но наоборот, если уже не написал.
У этих людей одна мотивация - доить фонды. А с приходом ИИ сейчас появилась еще одна - затянуть ИИ как можно больше и глубже, чтобы опять же - доить. Вбуханное в эту тему с ума сшедшее бабло изговняколо абслютно всё.
Поддерживаю! GNOME и KDE - в топку.
Это самый настоящий заговор! Кучка п#$%ров под предводительством Canonical пытается убить X11 (Xorg) и внедрить Rust везде где только можно. Но по факту у них ничего не выходит. Более 50% пользователей Linux всё еще используют Xorg, а многие переходят на Xlibre и отказываются от Wayland. Нужно сопротивляться всеми силами этому наплыву идиотии и отказываться от дистрибутивов которые пытаются похоронить X11, навязать убогие технологии, заменить отработанные веками решения на "новое и модное".
Прискорбно сознавать, что Базальт со своим ALT вошел в их круг. Буду сносить ALT везде.
Мне в этом году будет 50, но причем тут возраст ? Я не занимаюсь "строительством своего Desktop", просто установил FreeBSD и ряд требуемых мне пакетов. У меня даже дети используют FreeBSD на ноутах.
Про встроенный ЦАП не скажу, так как использовал внешний (SPI), но на АЦП у меня получалось как раз 0,1-0,15%. Учтите, что на MIK32 опорное напряжение АЦП - 1,2 В.
Код из EEPROM исполняется на частоте 32 МГц без задержек.
Мой совет - держитесь от Wayland подальше и не будет у Вас ничего падать при просмотре видео.
Сижу на Xlibre под FreeBSD с оболочкой Xfce4. Никогда такого не было, чтобы "зависла" система, упала оболочка или Firefox.
Я реализовывал датчик магнитного расходомера на MIK32 - ШИМ возбуждения катушки, опрос АПЦ, рассчет основного параметра и выдача его по 4-20 мА и одновременно по RS-485/ModbusRTU. Точности АЦП достаточно, хотя там есть нелинейности снизу и сверху. Весь код вмещался в EEPROM.
Это зависит о того, как написан код. Если в коде библиотеки есть что-то типа:
mik32-hal/peripherals/Source/mik32_hal_timer32.c
То при компиляции Вы получите универсальный код для инициализации всех таймеров, даже если Вы используете всего лишь один из них. И такого балласта и в HAL, и в библах Arduino предостаточно.
Ну и я всегда включаю Link-Time Optimization (
-flto).Вы всё таки посмотрите в настройки драйвера эмулятора COM порта (FTDI), там раньше были разные опции, в том числе размеры буферов. Увеличение размера буфера давало увеличение CPS. Но это было более 15-ти лет назад и на Win 7. :-)
Именно так. Из-за универсальности кода ардуиновсих библиотек в них содержится масса лишнего, что просто поедает драгоценную EEPROM и SRAM этого крохотного МК, и ко тому же, делает код медленнее. Так, что тут либо резать код библиотек #ifdef-ами, либо отказываться от Arduino IDE и писать всё самому используя только то, что требуется.
Попробовал пропатчить openFPGALoader - с наскоку ничего не вышло. Но, я посмотрел какой CPS при загрузке во Flash (SPIFI) дает родной mik32_upload.py через OpenOCD на наших изделия:
6.8 КБ/сек это конечно далеко от желаемого, но всё же не 0.9 КБ/сек как у Вас. Что-то где-то у Вас требует подкрутки. Моё подозрение падает на Вашу винду и "слабоватый" драйвер, не позволяющий выполнять "bit banging" с хорошей скоростью. Попробуйте подкрутить размеры I/O буферов в насройках драйвера FTDI, если таковые еще там остались. У меня на ноуте FreeBSD.
PS:
Направление верное. У MIK32 есть два 32-х битных 4-х канальных ШИМ таймера с загрузкой из ПДП (DMA), Теоретически, это может дать хорошее многолосное звучание.