Шероховатости Linux

Поддерживаю! GNOME и KDE - в топку.

Шероховатости Linux

Ну и как подальше от него держаться? ;)))))

Это самый настоящий заговор! Кучка п#$%ров под предводительством 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 МГц без задержек.

Шероховатости Linux

Мой совет - держитесь от Wayland подальше и не будет у Вас ничего падать при просмотре видео.

Сижу на Xlibre под FreeBSD с оболочкой Xfce4. Никогда такого не было, чтобы "зависла" система, упала оболочка или Firefox.

Плохое яблоко на русской Ардуине

Я реализовывал датчик магнитного расходомера на MIK32 - ШИМ возбуждения катушки, опрос АПЦ, рассчет основного параметра и выдача его по 4-20 мА и одновременно по RS-485/ModbusRTU. Точности АЦП достаточно, хотя там есть нелинейности снизу и сверху. Весь код вмещался в EEPROM.

Плохое яблоко на русской Ардуине

Компилятор не так уж плохо выкидывает всё ненужное

Это зависит о того, как написан код. Если в коде библиотеки есть что-то типа:

mik32-hal/peripherals/Source/mik32_hal_timer32.c

__attribute__((weak)) void HAL_TIMER32_MspInit(TIMER32_HandleTypeDef* htimer32)
{
    GPIO_InitTypeDef GPIO_InitStruct = {0};


    if (htimer32->Instance == TIMER32_0)
    {
        __HAL_PCC_TIMER32_0_CLK_ENABLE();
    }

    if (htimer32->Instance == TIMER32_1)
    {
        __HAL_PCC_TIMER32_1_CLK_ENABLE();
        if (htimer32->Clock.Source == TIMER32_SOURCE_TX_PAD)
        {
            GPIO_InitStruct.Pin = GPIO_PIN_4;
            GPIO_InitStruct.Mode = HAL_GPIO_MODE_TIMER_SERIAL;
            GPIO_InitStruct.Pull = HAL_GPIO_PULL_NONE;
            HAL_GPIO_Init(GPIO_0, &GPIO_InitStruct);
        }
    }

    if (htimer32->Instance == TIMER32_2)
    {
        __HAL_PCC_TIMER32_2_CLK_ENABLE();
        if (htimer32->Clock.Source == TIMER32_SOURCE_TX_PAD)
        {
            GPIO_InitStruct.Pin = GPIO_PIN_4;
            GPIO_InitStruct.Mode = HAL_GPIO_MODE_TIMER_SERIAL;
            GPIO_InitStruct.Pull = HAL_GPIO_PULL_NONE;
            HAL_GPIO_Init(GPIO_1, &GPIO_InitStruct);
        }
    }
}

То при компиляции Вы получите универсальный код для инициализации всех таймеров, даже если Вы используете всего лишь один из них. И такого балласта и в 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.

PS:

% openocd -V
Open On-Chip Debugger 0.12.0

Плохое яблоко на русской Ардуине

Направление верное. У MIK32 есть два 32-х битных 4-х канальных ШИМ таймера с загрузкой из ПДП (DMA), Теоретически, это может дать хорошее многолосное звучание.

Плохое яблоко на русской Ардуине

На самом деле MIK32 ни чуть не более геморройней чем изделия серии ATMega. Есть своя ниша. Миросхема производится полностью в России. Очень простая и понятная архитектура. Программировать его приятно и легко если всё пишешь сам, а не занимаешься борьбой с чужими глюками и недоработками типа Arduino IDE. Некто Vladimir Zaytsev написал к MIK32 набор однофайловых (.h) HAL библиотек - очень удобно, рекомендую.

Плохое яблоко на русской Ардуине

Ну, как говорится, с почином!

Существует альтернативный загрузчик ex_loader_2 от fabmicro.

Это не наш код, а какого-то парня по имени Vladimir Zaytsev. Я всего лишь выложил его на Gitflic. Но рад, что кому-то это могло помочь. :-)

Загрузка в NOR flash (SPIFI) через OpenOCD действительно жутко медленная и это сильно достает когда прошивка становится большой. Хочу попробовать через OpenFPGALoader, эта утилита может писать/читать QSPI Flash через JTAG.

Кристалл микроконтроллера MIK32 «Амур»

А какой у АО "Микрон" логотип на кристаллах ? Есть примеры ?

Нейросети против открытого кода: Malus автоматизировал легальный обход лицензий

Ну что-ж, пожелаем еще больше удачи этим жертвам счастливцам автоматизации.

Нейросети против открытого кода: Malus автоматизировал легальный обход лицензий

del

Нейросети против открытого кода: Malus автоматизировал легальный обход лицензий

Миллиард тестов тоже машина напишет ?

Нейросети против открытого кода: Malus автоматизировал легальный обход лицензий

Простите, а кто будет проверять те миллиарды строк кода которые нагенерировала машина ? Или уважаемый Нолан полагает, что в сгенерированном его болванчиком коде совершенно нет ошибок, неприятных артефактов и прочих дыр в безопасности ? Чтож, пожелаем успехов его клиентам.

Шесть лет без электричества: USB-накопители не потеряли ни байта

А Flash память кокого типа ? SLC, TLC или QLC ? SLC продержится лет 8-10. QLC - года 3.

Основная проблема с храненим данных на NAND Flash состоит в том, она очень сильно подверженна влиянию поверхностного статического заряда и ESD защита тут бессильна. Храните ваши флэшки в токопроводящей заземленной коробке. :-)

Сray: Resurrection

Didn't know that Cray maniches had Unix flavour.

Почему первый вызов моей malloc всегда аллоцирует 72 КБ?

Я правильно понимаю, что автор сам, т.е. своим аллокатором, создал себе проблему и мужественно её преодолел ? :-)

Я попробовал сделать что-то подобное на FreeBSD: две заглушки для malloc(), одна на Си, другая на C++. Вот как это выглядит у меня:

Malloc wrapper in C on FreeBSD

rz@butterfly:~/code_snippets/C/Preload % make clean testc
rm -rf libpreload.o libpreloadc.so libpreloadcpp.so

=== Building malloc wrapper in C
cc -c -fPIC -o libpreload.o libpreload.c
cc -shared -o libpreloadc.so libpreload.o

=== Testing malloc wrapper written in C
FreeBSD butterfly 13.5-RELEASE-p9 FreeBSD 13.5-RELEASE-p9 GENERIC amd64
LD_PRELOAD=./libpreloadc.so /bin/ls -al
MALLOC: 128
MALLOC: 377
ls: fts_open: MALLOC: 2
Invalid argument
*** Error code 1

Stop.
make: stopped in /usr/home/rz/code_snippets/C/Preload

Malloc wrapper in C++ on FreeBSD

rz@butterfly:~/code_snippets/C/Preload % make clean testcpp
rm -rf libpreload.o libpreloadc.so libpreloadcpp.so

=== Building malloc wrapper in C++
c++ -c -fPIC -o libpreload.o libpreload.cpp
c++ -shared -o libpreloadcpp.so libpreload.o

=== Testing malloc wrapper written in C++
FreeBSD butterfly 13.5-RELEASE-p9 FreeBSD 13.5-RELEASE-p9 GENERIC amd64
LD_PRELOAD=./libpreloadcpp.so /bin/ls -al
MALLOC: 4096
Class Test has been constructed
MALLOC: 128
MALLOC: 377
ls: fts_open: MALLOC: 2
Invalid argument
*** Error code 1

Stop.
make: stopped in /usr/home/rz/code_snippets/C/Preload

Как видно, если не использовать stdlib++, то первые аллокации совсем крохотные - столько, солько требуется утилите /bin/ls. Если использовать библиотку libstdc++, то её инициализация запрашивает 4096 байт (ровно одну страничку).

На Linux-е этот же тест действительно первым запросом показывает 72704 байт. Еще один плюс в карму FreeBSD. ;-)

Забавно, но на Linux-е результат malloc() не проверяется на NULL не внутри инициализации stdlib++, не в коде /bin/ls. Моя обертка выдает NULL, а программа продолжает работу как будь-то всё в порядке и снимается с ипольнения только системой когда уже совсем того:

Malloc wrapper in C++ on Linux

rz@devbox:~/Preload$ make clean testcpp
rm -rf libpreload.o libpreloadc.so libpreloadcpp.so

=== Building malloc wrapper in C++
c++ -c -fPIC -o libpreload.o libpreload.cpp
c++ -shared -o libpreloadcpp.so libpreload.o

=== Testing malloc wrapper written in C++
Linux devbox 4.15.0-30-generic #32-Ubuntu SMP Thu Jul 26 17:42:43 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
LD_PRELOAD=./libpreloadcpp.so /bin/ls -al
MALLOC: 72704
MALLOC: 552
MALLOC: 552
MALLOC: 1024
Class Test has been constructed
MALLOC: 5
MALLOC: 552
MALLOC: 5
MALLOC: 34
MALLOC: 10
MALLOC: 56
/bin/ls: memory exhausted
Makefile:27: recipe for target 'testcpp' failed
make: *** [testcpp] Error 2

PS: Мой код: https://github.com/pointcheck/code_snippets/tree/master/C/Preload