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

Программирование ATMEL в BASCOM.

Информация о пользователе

Привет, Гость! Войдите или зарегистрируйтесь.


Вы здесь » Программирование ATMEL в BASCOM. » Вопросы - ответы » Операционная Система для Bascom AVR существует ???


Операционная Система для Bascom AVR существует ???

Сообщений 1 страница 26 из 26

1

Существует ли  операционная система реального времени, например как тут OSA, которые можно было бы использовать совместно с BascomAVR ?

0

2

Нет.

0

3

SV12 написал(а):

Существует ли  операционная система реального времени, например как тут OSA, которые можно было бы использовать совместно с BascomAVR ?


Посмотрите здесь

0

4

sasha_1973 написал(а):

Посмотрите здесь

  Спасибо, а то я уж велосипед начал изобретать. Как я раньше не обратил внимание?  Ещё бы подробное описание не помешало.  Хотя, я со своим "велосипедом" я уже далеко зашел.
Если я правильно понял, здесь переключатель на 2 параллельно работающие задачи ?

0

5

о! правда, а есть какая-либо инструкция?

0

6

Предлагаю вашему вниманию "операционную систему"   - диспетчер процессов (задач) + виртуальные таймеры . 
Тип ОС - кооперативная. Т.е. задачи(процессы) исполняются в порядке их приоритета в режиме очереди, за чем и следит  диспетчер процессов.
Вариант 1  пробный .   Описание внутри.
OS_MOON

Отредактировано SV12 (2017-11-10 14:28:42)

0

7

Kaspersky
Endpoint Security 10 для Windows
Доступ запрещен

0

8

RDW написал(а):

Kaspersky
Endpoint Security 10 для Windows
Доступ запрещен

Sorry.   Там ссылка на Яндекс.Диск. Конструктор покалечил. 
Исправил.

0

9

Теперь всё - ок.
Есть опасение, что повиснет один из процессов и вся ОС умрет. ;)

0

10

На самом деле, была давняя "мечта"/идея, сделать не много поточность (что и так всегда присутствует в проектах и она уникальна для каждого случая), а многоядерность. Что-то на подобии пропеллера (центральный хаб и куча вокруг ядер).
А так, архитектура внутри МК не позволяет сделать нормальную, независимую систему выполнения кода. Придется тогда делать "свой" процессор/эмулятор внутри. Иначе ЭТО всё похоже больше на пародию.
Можно конечно привязаться к таймеру, пытаться быстро переключать задачи, но:

1. непонятно насколько быстро надо их вообще переключать.
2. процесс выполнения процесса можно прервать и продолжить, но стек общий и регистры одни и теже, рано или поздно будет конфликт и память закончится. Что повлияет на всё...

0

11

RDW написал(а):

а многоядерность

Если в МК одно ядро, то программа второе не добавит. :dontknow:

0

12

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

Отредактировано RDW (2017-11-10 16:57:17)

0

13

Тоже как-то однажды "после рюмки выпитой" ;) цмыкнула подобная идея, подобная той, про которую говорит RDW...

Вопрос многозадачности как-то сразу отпал из-за слабости для этой цели ресурсов МК.
На то они и "микро", да еще и "контроллер", а не "процессор"... ;)
А вот идея использования нескольких МК под управлением "головного" до сих пор теплится...

Не многопоточность, конечно, но применение найдется...

Отредактировано Nord (2017-11-10 17:28:07)

0

14

RDW написал(а):

чтобы программа была/работала на нескольких ядрах - это закладывается в саму программу.

Да, создается несколько потоков.

RDW написал(а):

Программы быстрее не работают от того, что они делятся на несколько ядер

Если процессор имеет несколько ядер и в программе созданы несколько потоков между которыми поделены вычисления, то программа работает быстрее примерно в столько же раз сколько ядер в процессоре (естественно число потоков должно быть не меньше числа ядер). Речь в данном случае идет про комп, но к многоядерным МК это тоже относится, т. к. принцип тот же.
Но к AVR это не имеет отношения.

Nord написал(а):

Вопрос многозадачности как-то сразу отпал из-за слабости для этой цели ресурсов МК

МК бывают разные. В основном все упирается в размер ОЗУ, поскольку стек и т. д. у каждого потока свои.
Когда в МК скажем 20 или больше КБ ОЗУ, ресурсов вполне достаточно для десятка потоков и еще много свободной памяти останется (при грамотном распределении ресурсов). :)

Nord написал(а):

А вот идея использования нескольких МК под управлением "головного" до сих пор теплится

Просто нужно взять МК "пожЫрнее", а не Tiny10. :D
Межмикроконтроллерный обмен тоже требует ресурсов. :dontknow:

0

15

Пётр написал(а):

МК бывают разные. В основном все упирается в размер ОЗУ...

Неоспоримо...
Еще количество ног разное... ;)

Пётр написал(а):

Просто нужно взять МК "пожЫрнее", а не Tiny10.  Межмикроконтроллерный обмен тоже требует ресурсов.

Тоже вариант...
Но есть задачи, которые неудобно совмещать в одном чипе чисто конструктивно.

Например, есть у нас оборудование, где в виде отдельных блоков-модулей выполнены конкретные устройства.
В каждом - МК.
Реле времени, преобразователи и т.п...
И есть т.н. "головной" модуль, который принимает от них информацию, принимает "решение", рулит дисплеем...
Далеко не многозадачность.

Но если добавить обратную связь "головного" с остальными модулями - уже ее признаки появляются.
Можно будет вносить корректировки в считывание, например...

Только тут правильнее будет назвать такую систему не "многозадачной", а "многоядерной", где у каждого "ядра" будет свой функционал и свое поле памяти... ;)

0

16

Ну вот в качестве DMA будет отдельный МК, который будет собирать данные (как хаб) и если что, по особым правилам раздавать дальше действия остальным. Но тут всё равно упрется всё в какие-то доп команды, свой язык. Насколько такое оправдано - неизвестно. А тупо грузить в соседние МК код и получать результат...сомнительное применение, хотя...если их использовать именно как ядра.

0

17

Многоядерность - это про другие камни. И даже виртуальная "многоядерность"
Параллельность процессов жрет много ресурсов на стеки.
И тем не менее, разделение задач между МК вполне обычная вещь.
К примеру, в настоящее время в работаю над устройством с двумя МК.  1-й центральный, 2-й вспомогательный.

RDW написал(а):

Теперь всё - ок.
Есть опасение, что повиснет один из процессов и вся ОС умрет. ;)


  Настоящая ОС работает с разными ВНЕШНИМИ задачами, и там действительно вопрос устойчивости ОС важен.
В нашем случае, МК в готовом изделии работает с одной программой.  Если процесс повис, то что с ОС, что без нее - никакой разницы. ОС в нашем случае не для пользователя, а для разработчика.
Как я говорил выше, "OS_MOON" (буду так ее называть), всего лишь "диспетчер задач". По сути - главный цикл DO-LOOP 

Что-то на подобии пропеллера (центральный хаб и куча вокруг ядер).

   
  Что-то вроде этого:
К примеру, нужно гонять 3 задачи (Подпрограммы) каждая в виде бесконечного цикла. В OS_MOON можно сделать так: Пишем, как обычно, 3 подпрограммы(ПП) Вместо "DO" метка начала ПП, вместо "LOOP" - "Return".
Флаги вызова этих процессов не сбрасывать (Os_pr_fl(X).7=1) . Тогда по кругу будут исполняться по 1 циклу каждой из ПП.
Bascom хорош тем, что при работе с операндами он каждый раз "достает" их из ОЗУ, и не нужно делать громоздких стеков, при переключении между процессами (хотя, наверно, возможны исключения). Каждая из ПП работает со своими переменными, и не мешает другой. Разве что время отнимают друг у друга.

Отредактировано SV12 (2017-11-10 18:36:13)

0

18

RDW написал(а):

Но тут всё равно упрется всё в какие-то доп команды, свой язык. Насколько такое оправдано - неизвестно.

Вот потому я и не занялся вплотную реализацией размышлений... ;)
Доп. команды - банальный обмен одним байтом в качестве флагов. Их аж 255 будет ! ;)
Свой язык ? Зачем ?
Насколько оправдано не знаю... Это пока только идея, а будет она развиваться или нет...?  :confused:

RDW написал(а):

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

Ну да, идеология примерно такая... ;)

0

19

SV12 написал(а):

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

Ну так большинство программ так и пишутся... ;)
Один "Главный цикл" и из него поочередно вызываются на исполнение ПП.
Или вы хотите после каждой строки переключаться между ПП ?

0

20

RDW написал(а):

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

Где-то я читал (кажется у Евстифеева), что МК могут работать с внешней ОЗУ (Древние МК только так и работали). Вот и рулите, если уж так хочется. Вопрос только в совместном доступе к ОЗУ (контроллере памяти).

Отредактировано SV12 (2017-11-10 18:46:15)

0

21

Nord написал(а):

Один "Главный цикл" и из него поочередно вызываются на исполнение ПП.

Так и есть.

0

22

Nord написал(а):

Еще количество ног разное

Я про многопоточность в МК. Число выводов с этим мало связанно.

Nord написал(а):

Например, есть у нас оборудование, где в виде отдельных блоков-модулей выполнены конкретные устройства.В каждом - МК.

Одно дело когда конструкция состоит из нескольких блоков и совсем другое когда разделяют задачу на несколько МК только лишь потому что в один не влазит.

Nord написал(а):

только тут правильнее будет назвать такую систему не "многозадачной", а "многоядерной", где у каждого "ядра" будет свой функционал и свое поле памяти...

Это не многоядерная, а многомодульная конструкция. К многозадачности отношения не имеет.

SV12 написал(а):

МК могут работать с внешней ОЗУ

Некоторые модели это поддерживают. Например ATmega8515.

0

23

SV12 написал(а):

Так и есть.

В чем тогда цель, если она уже реализуется ?

Лично я совсем не против "много...." в применении МК... ;)
Если у кого-то это реально получится - реально зааплодирую !

0

24

Nord написал(а):

SV12 написал(а):    Так и есть.

В чем тогда цель, если она уже реализуется ?

 

Скелет (пустышка) главного цикла (с очередью, приоритетами, виртуальными таймерами,  ... ) .  Наверно, как и все подобные вещи, с разной степенью наворотов и требованию к ресурсам.
Просто для Си такого написано много. А вот для Bascom нет.  В моей ОС несложно разобраться, там коду на 1 страницу.  Есть ещё над чем поработать. 
(Например, переделать прерывание Timer0 на ASM.)

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

0

25

SV12 написал(а):

Просто для Си такого написано много. А вот для Bascom нет.

Искренне рад вашим успехам.
Что поимеем в результате ?
Эмуляцию Windows на линейке Atmel ?
Я не видел, что там писано на Си, с ним так и не подружился ;) , но до сих пор не могу вкурить - что нам здесь это даст ?
Конечная цель ?!
Сделать то, что есть на Си, но нет на Bascom ? ;)

0

26

Nord написал(а):

Эмуляцию Windows на линейке Atmel ?

Вообще не причем.

SV12 написал(а):

ОС в нашем случае не для пользователя, а для разработчика.

Nord написал(а):

Я не видел, что там писано на Си, с ним так и не подружился ;) , но до сих пор не могу вкурить - что нам здесь это даст ?

См пост 24. 
Всё что далее, с Bascom не дружит, или я не знаю как это подружить ->  Смотри : OSA с примерами и объяснениями, документацией ,   AVRasmOSjacos ,  Вот тут ещё ТЕОРИЯ подробно:   uRTOS . Не буду это все перепечатывать.  А нужно оно Вам или нет и что даст, решайте сами.

Отредактировано SV12 (2017-11-11 00:51:29)

0


Вы здесь » Программирование ATMEL в BASCOM. » Вопросы - ответы » Операционная Система для Bascom AVR существует ???