Size: a a a

2020 July 30

AG

Anton Gorlov in Embedded Group
Valentin Kornienko
Тут не хватает указания, что он еще поддерживает
ну. это весь выхлоп из /proc/cpuinfo с распбиана
источник

AG

Anton Gorlov in Embedded Group
по флагам
источник

AG

Anton Gorlov in Embedded Group
целиком ща напастебиню
источник

AG

Anton Gorlov in Embedded Group
источник

MN

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

P.

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

T

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

TK

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

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

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

TK

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

TK

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

TK

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

I

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

A

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

T

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

I

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

A

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

TK

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

TK

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

I

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

TK

Timur Khasanshin in Embedded Group
да вот именно
источник