ну. это весь выхлоп из /proc/cpuinfo с распбиана

по флагам

целиком ща напастебиню

Кто-нибудь может рассказать как потолочные светильники (с пультами которые) запоминают режим свечения? Купил две разных модели от одного производителя - один работает правильно: при включении врубает тот режим, что я задал до этого, а второй так не может (каждый раз при включении меняет режим по кругу, как будто в памяти нет ничего)  При этом, если их параллельно подключить к одному выключателю, второй каким-то чудом начинает работать как надо. Можно ли как-то пропатчить второй светильник, чтобы он самостоятельно мог работать как первый?

А в выключателе с которым «все ок» случайно нету ли неонки?

Доброго времени суток! Я как начинающий прогер искал причины использования ОСей по типу RTOS или ядра линукса на микроконтроллерах, вместо программирования на низком уровне и наткнулся на такую статью: https://www.embedded.com/why-a-bare-metal-developer-moved-to-operating-systems/ Один из аргументов в сторону использования ОС был то что ОС работает лучше в Real-time чем если все писать на низком. И мне это показалось чухней какой-то, но хотелось бы услышать ваше мнение по этому поводу. Да и в принципе хотелось бы узнать чем вы руководствуетесь когда решаете использовать ОС или писать все просто ручками.

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

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

Все зависит как легче писать чтоб быстрее доделать

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

Наверно история была такова:
1) давайте все отлаженные полезные используемые либы объединим в статик либ
2) давайте будем использовать планировщик ведь это позволяет писать в другой парадигме, некоторые вещи более удобно
3) давайте раз уж планировщик так часто стал использоваться, и его засунем в статик либу
4) давайте и графическую систему с кли засунем а то часто нужно бывает, и управление с клавиатуры
5) о, а ведь мы получили продукт для бизнеса, запускаем стартап
6) давайте украсим графикой, чтоб людям приятнее было
7) ой оно весит 2 гига

Можно ли так настроить 2 таймера в стм32 чтобы один из них работал с ускорением, то есть при каждом переполнении уменьшал или увеличивал период при чем без участия процессора?

Почему чухней? Вполне дельный аргумент

Рынок диктует простое: выигрывает тот кто делает продукт быстрее.
Вот и тут: если быстрее на бареметал сделать - делают на нем. Если на ртос - делают на ней.
Я и так и так делал.

Хотелось бы аргументов. Просто почему я так посчитал, что ничего не может быть быстрее работы по прерыванию, те же ОС через них ведь и работают. Просто на бейрметал это будет быстрее, т.к. не будет лишнего промежуточного кода от ОС

В прерываниях нельзя делать обработку данных и какие-то сложные операции. Поэтому в самом примитивном случае в прерывании ставят флажочек, который затем обрабатывают в бесконечном цикле (это описано в статье). Вот этот бесконечный цикл и есть бутылочное горлышко

+++

я думаю все зависит от условий, если имеется ввиду латенси до 10мкс то лучше прерывания, если переключаемые задачи управляют гигабайтами и надо чтоб все задачи стартовали выполнение одновременно а не когда одна из них свои гигабайты отработает - то ртос быстрее

хотя когда гигабайты речь уже об ОС, но задумка одна

Конечно, подход с бесконечеым циклом не единственный, можно усложнять архитектуру (добавлять очереди, программные ивенты итп), но в какой-то момент становится проще заюзать ртос)

да вот именно