Перейти к содержанию
    

Прерывание в прерывании

Super Simple Tasker - один из вариантов реализации вытесняющей многозадачности для микроконтроллеров. Как в нём работает асинхронное переключение на более приоритетные задачи написано в статье под рисунком 3. Для реализации SST нужна такая вещь: в функции-обработчике прерывания, после выполнения необходимого кода, нужно как-то сообщить микроконтроллеру, что с прерыванием закончили работать но из функции-обработчика не выходить. Т.е. нужно разрешить вложенные прерывания (одни и те же).

 

В статье в примере для ПК это делается так: используется команда End Of Interrupt (EOI) - outportb(0x20, 0x20). Обычно она выполняется непосредственно перед выходом из функции-обработчика прерывания, но в SST после EOI вызывается диспетчер, прямо в контексте прерывания. Т.е. вызвав EOI, но оставаясь в контексте прерывания, мы разрешаем вложенные прерывания. Как это можно сделать для ARM (Cortex)?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

один из вариантов реализации вытесняющей многозадачности для микроконтроллеров...

Может быть я стал слишком старый и "отстал от поезда", поэтому на всякий случай спрошу: НАФИГА ???

Чем не годится готовая RTOS? В частности freeRTOS позволяет использовать вложенные прерывания без подобного "дрочева".... :laughing:

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Как минимум, это интересно - попробовать разные подходы к построению ПО. А ещё есть мелкие контроллеры, у которых мало свободных ресурсов. Вот на них особенно интересно попробовать SST - тут при наличии вытесняющей многозадачности очень эффективное использование памяти.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

А ещё есть мелкие контроллеры, у которых мало свободных ресурсов.

В мелких МК прекрасно влезает классическая готовая RTOS, особенно если использовать минимум ресурсов - семафоры и на край мьютексы. Использую RTOS даже в мелких ARM CM0.

Я относительно недавно перешел на KEIL RTX, она занимает меньше места, чем freeRTOS да и сделана более что-ли классически - системные вызовы используют SVC, т.е. как это изначально и было задумано ARM.

 

Впрочем, если больше нечем заняться, то поизучайте готовые порты под разные RTOS, посмотрите как там сделано низкоуровневое "сопряжение" с конкретным ядром.

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

нужно как-то сообщить микроконтроллеру, что с прерыванием закончили работать но из функции-обработчика не выходить. Т.е. нужно разрешить вложенные прерывания (одни и те же).

"Всё смешалось в доме Облонских" - прерывания для того и выдуманы, чтоб, быстро отреагировав, быстро выполнить требуемое и вернуться к "рутине".

 

В статье в примере для ПК это делается так: используется команда End Of Interrupt (EOI) - outportb(0x20, 0x20). Обычно она выполняется непосредственно перед выходом из функции-обработчика прерывания, но в SST после EOI вызывается диспетчер, прямо в контексте прерывания. Т.е. вызвав EOI, но оставаясь в контексте прерывания, мы разрешаем вложенные прерывания. Как это можно сделать для ARM (Cortex)?

Вот прям "дословно" как по ссылке - никак. Но у кортекса весьма изощрённый контроллер прерываний: вложенные (если приоритет не ниже текущего (базового)) там получаются нативно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Как это можно сделать для ARM (Cortex)?

Здесь была тема про SST. Посмотрите там, может, там есть ответ.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В мелких МК прекрасно влезает классическая готовая RTOS, особенно если использовать минимум ресурсов - семафоры и на край мьютексы. Использую RTOS даже в мелких ARM CM0.

Я относительно недавно перешел на KEIL RTX, она занимает меньше места, чем freeRTOS да и сделана более что-ли классически - системные вызовы используют SVC, т.е. как это изначально и было задумано ARM.

 

Впрочем, если больше нечем заняться, то поизучайте готовые порты под разные RTOS, посмотрите как там сделано низкоуровневое "сопряжение" с конкретным ядром.

Я отказался от FreeRTOS, 256 К памяти не хочу транжирить, SST "х расходы стековой памяти по сравнению с традиционными операционными системами сокращается на 80%."

. Так что насчет "нечем заняться" не стоит огульно, SST прекрасно ложится на мелкие 1M/256K контроллеры, на средние (16G/1G) полноценный Линукс проще. Места классическим RTOS я лично не вижу

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Я отказался от FreeRTOS, 256 К памяти не хочу транжирить, SST "х расходы стековой памяти по сравнению с традиционными операционными системами сокращается на 80%."

Какие-то дикости вы тут рассказываете :wacko:

Звучит как попытка экономии на соли при мариновке огурцов :)

 

Ядро RTOS занимает всего несколько кБ флэши, а объем занимаемого ОЗУ сильно зависит от кода: стек прерываний общий, большой не нужен, обычно хватает 0.2кБ, стеки задач - зависит от самих задач, у меня их стеки крайне редко превышают 0.5 кБ, обычно хватает 128....256 байтов.

Съэкономить ОЗУ можно перейдя на кооперативную многозадачность.

У меня МК по 16...32к флэши (озу 4..6 кб) и при этом там прекрасно живут несколько объемных задач и делают некислый функционал.

А уж что говорить про "толстые" МК с 256 кб, там вообще нет никакого смысла экономить на спичках - суём RTOS с самым серьезным функционалом (например, моя любимая трассировка под Segger SystemView).

По-моему вы сильно заморачиваетесь на пустом месте )))

 

SST прекрасно ложится на мелкие 1M/256K контроллеры

Голый ассемблер тоже прекрасно ложится на любой МК, но что-то желающих сидеть на голом асм все меньше и меньше...

Нужда в RTOS пропадает в реально примитивных проектах, но таких уже и не осталось, не те времена нынче ))

 

Места классическим RTOS я лично не вижу
Вот это-то и вызывает у меня некоторое недоумение!

И потому прихожу лишь к одному выводу - вы вообще не использовали RTOS.

Искренне советую исправить это недочет :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Подтверждаю, RTX RTOS от Keil - весьма достойная простая "классическая" ОС.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

"прихожу лишь к одному выводу " - приходите

", обычно хватает 128....256 байтов"- просто у вас " в реально примитивных проектах"

Вы лучше скажите, каким образом вы доказываете, что данная задача никогда не превысит отведенный стек, при условии, что если такое возникнет - аппарат под контролем процессора с вашим замечательным ртос со стеком задачи 128 байт отрежет например рабочему руку.

" "толстые" МК с 256 кб" вы серьезно считаете, что это толсто? Это копейки с нынешними стеками и протоколами, стек BLE один сожрет 300 кб флеша, порядка 100 к ОЗУ, а к нему еще Thread прикуртить надо, оный тоже 250 кбайт и ОЗУ немерянно.

Очень интересно глянуть вашу "сурьезную задачу" с 128 байт ОЗУ

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Как минимум, это интересно - попробовать разные подходы к построению ПО. А ещё есть мелкие контроллеры, у которых мало свободных ресурсов. Вот на них особенно интересно попробовать SST - тут при наличии вытесняющей многозадачности очень эффективное использование памяти.

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

 

PS: При задавании подобных вопросов, очень уместно указывать ядро о котором спрашивается. Ибо реализация очень сильно зависит от этого самого ядра.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Я отказался от FreeRTOS, 256 К памяти не хочу транжирить

Интересно - на что у вас FreeRTOS транжирил память?

ЗЫ: Всегда думал, что память в программах транжирит исключительно программист... наверное старый стал - чего-то уже не понимаю.... :wacko:

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Так может Вы дадите совет, сколько памяти давать каждой задачи, чтобы ей гарантированно хватило, и при этом не было бы потерь памяти из-за этого "на всякий случай"?

Потоки и жрут.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

А вы каким доказываете, что руки пролетарию не отхватите? Поделитесь опытом....

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...