Size: a a a

2020 July 31

A

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

T

ThunderWoof in Embedded Group
Ivan
Конечно, подход с бесконечеым циклом не единственный, можно усложнять архитектуру (добавлять очереди, программные ивенты итп), но в какой-то момент становится проще заюзать ртос)
Это получается свою ОС писать придется?)
источник

TK

Timur Khasanshin in Embedded Group
источник

I

Ivan in Embedded Group
ThunderWoof
Это получается свою ОС писать придется?)
Ртос это гораздо больше, чем диспетчер)
источник

F

Faberge in Embedded Group
Ivan
Ртос это гораздо больше, чем диспетчер)
scmRTOS?
источник

F

Faberge in Embedded Group
Ну там ещё + межпроцессный обмен
источник

F

Faberge in Embedded Group
Но вообще ОС минималистичная
источник

TK

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

TK

Timur Khasanshin in Embedded Group
cli
источник

T

ThunderWoof in Embedded Group
Можно тогда узнать, если не секрет, какие задачи вы решали в программировании МК с использованием РТОСа или Линукса?
источник

K

Kernel M.D. in Embedded Group
К слову, если мк жирный, то маленькая unix-система с готовым сетевым стеком и шеллом таки может быть удобна.
источник

T

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

TK

Timur Khasanshin in Embedded Group
есть еще такой фреймворк, touchGFX. Богатые возможности по части графического интерфейса и HMI сенсорного. ему тоже лучше воткнуть ртос
источник

TK

Timur Khasanshin in Embedded Group
там есть функция у него "taskEntry()", и ее надо вызывать в отдельном потоке
источник

TK

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

СС

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

I

Ivan in Embedded Group
Ну если осторожненько только
источник

СС

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

СС

Сиие Сууие in Embedded Group
Ivan
Ну если осторожненько только
Можно и не осторожно, 70% времени жил в прерывании, полет нормальный
источник

СС

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