Е то изчисленията ако се правят в прекъсването няма да станат по-бързо. От друга страна се заключва процесора за други прекъсвания.

Заключването за други прекъсеания е частен случай но да речем и това е причина за да не циклиш твърде дълго в прекъсване. Друга честа причина за някои специфични прицесори е дълбочината на стека, а някои това изобщо го пропускат. Изобщо много причини. Аз гледам повече като жичкаджия, и се стремя да парализирам процесите, ясно е че това не е възможно поради същността на макките контролери, но ги дискеритизирам така че да няма процес който да да се изпълнява твърде дълго. Критерия за твърде дълго зависи от задачата.

Като нищо може да са пробвали както трябва, но да не е тръгнало... Специално със ST библиотеките е съвсем нормално да не тръгне. Примерно в USB-то имаше едни while() дето може да останеш в прекъсване със секунди... Под подобно прекъсване нищо не може да вирее, камо ли управление на двигател

Е аз те затова и избягвам готови библиотеки, масово се пишат с while.

и всичко да си пишеш сам не е работа

Аз поне съм оптимист че с времето нещата ще почнат да се подобряват. Ако бумът в софтуерния бранш отмине ще почне да се гледа качеството и мърлячите трудно ще оцеляват. И единаците също...

Освен USB стека на ST, друго какво "неправилно" има написано?

Май имаше тема за ST и вътре изброявах "постиженията" им

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

Присетих се за бате Линус как е правил git - като се е чудил за някава функционалност е хвърлял по едно око на CVS и е правил точно обратното щото там всичко било сбъркано

Аз темата я намерих, но там става въпрос само за USB стека. Сега като писа за бъговете им, реших че нещо някъде съм изпуснал и е имало още бъгове.
Ако библиотеката им е толкова гадна, то какво да ползва човек? Сам да седна да си пиша абстракция в/у периферията няма да стане. Libopencm3 ли?
По принцип лично на мен ми допада как се пише с нея, но липсата на документация (онова генерираното с доксиген не го броя за такава) направо ме отказва.

Уви, даже и затова не можах да им ползвам кода

То повечето дразнещи неща са елементарни. Примерно най-нормално е библиотеките и чаршафите да ползват едни и същи имена на регистрите на периферията. Така, че да може лесно да направиш справка от едното в другото. Това не е спазено.
Но не спират само до тук. За много от перифериите се правят INIT структури. Няма лошо, стандартна практика. Структурите се попълват runtime, не е особено ефектвно ама карай. Константите които ползват обаче не съответстват нито на чаршафа, нито на регистрите. Примерно ако имаш един бит в един регистър, който управлява нещо си, то в чаршафа ще е с едно име, в хедъра с регистрите друго, а в INIT-тите с трето. Да не говорим че едни и същи периферии ги има в стотици контролери и даже да знаеш какво търсиш като ти излезе едно и също нещо 100 пъти пак търсенето е мъка.

Това с naming конвенциите отдавна е измислено... Нямам разумно обяснение защо ST не се съобразяват. Между другото и от самите АРМ има много подобни безобразия и като документация и като код (CMSIS).... И в други производители има немърливости, така че като критикувам ST това не значи че има много по-читави алтернативи...

о
Поне няколко RTOS-чета шунтират ако не всичко, то голяма част от ST. Така или иначе аз не бих ти препоръчал bare metal така че проблемът ти е по-скоро кой RTOS и там аз ще се въздържа да давам акъл.
Libopen съм го чувал, но в момента не се сещам за подробности...

Е така и така си казал че са няколко, поне ги изброй, за да стане по-полезна темата

Темата хубаво е озаглавена "закачки", но реално тръгна от друго. Някак е странно подобна липса на единомислие по въпроса, какво се прави в прекъсване и какво не се прави.
Какъв е изходът от подобна ситуация? Все пак, това са основни неща, и би трябвало "голямата дебела книга" да дава някакъв по-категоричен отговор?

Както казах предпочитам да се въздържам поради ред причини. Като почнеш от факта че аз самият правия RTOS и не върви да препоръчвам чужди. Пък и когато го правя хората не остават доволни. Може би аз имам извратен вкус... последно тук бях препоръчвал нут-а, но реакциите не бяха положителни. На всичкото отгоре вече почти си имам всичко и поне от 1-2 години не ми се налага да заглеждам по чуждо... така че и информацията ми е стара.


Освен закачки, по-горе писах аргументи... Повярвай ми няма чак такова разминаване. Особено при големите ОС-и там е твърдо. Даже преди години в бозата беше много актуално едно синьо екранче с IRQ Dispatch level. Ха си тръгнал да правиш нещо където не му е мястото и посиняваш
Така че единомислие има... Поне досега не съм срещал аргументи в обратна посока. А това че понякога нещата не се правят така както е редно е друга бира...

itso.t,

съгласен съм, че основното правило: 'минимум код в прекъсване' важи. Просто дадох обратен пример при който трябва да се съобразиш с физичен процес и искаш или не товариш процесора. Ако го направиш в прекъсването не губиш нищо, даже можеш да си гарантираш, че най-важната задача ще бъде на първа линия. Не виждам от къде идват притесненията за поддържането на проекта. От този процесор не се очаква нещо друго, морковите задвижвания са с по няколко процесора/логики. Сигурно и техните инженери и програмисти не са били на лекция по сигнали и системи...

Също още един пример: ако искаш с Windows или Linux да управляваш осите на CNC (TwinCAT или LinuxCNC) добавяш RT kernel който 'заобикаля' добрите практики на OS.

П.П: В РОБКО 01 (http://mcu-bg.com/mcu_site/viewtopic.php?f=22&t=11875) сметките за движение по права се правят извън прекъсването на моторите. Просто да вметна, че баба знае две и двеста