Алексей bird, на примере постараюсь показать что можно получить от RTOS.
Допустим, к нашему устройству подключен символьный LCD экранчик и keypad. Допустим, есть гипотетическая ОС, в которой определен API символьного экранчика и API простенькой клавиатуры... Вы можете привести код, реализующий такое главное меню, без RTOS?
Могу. Приведу простенький код на макроассемблере без RTOS, реализующий ваш пример (мнемоника несколько изменена).
L: Opros_Knopok (Knopki = Kn_Pusk) → Pusk ' Переход на режим пуск, если нажата кнопка пуск (flg_Int0 = 1) → Int0 ' Переход на обработку прерывания, если был установлен флаг Int0 Vyvod_Indikator → L ' Переход на метку L
Opros_Knopok — подпрограмма опроса кнопок, результаты которого хранятся в переменной Knopki. Vyvod_Indikator - подпрограмма вывода на индикатор.
Для ускорения обработки прерывания в подпрограммах Opros_Knopok и Vyvod_Indikator можно поставить команды ускоренного выхода при появлении флага прерывания. Такой флаг устанавливается программно при возникновении прерывания. Тут тоже получается простой и понятный код, небольшой по объёму и, наверно, намного быстрее выполняемый. Написал за несколько минут. И в чём преимущество RTOS?
Как раз по вашему примеру и видно - приходится постоянно опрашивать флаг/флаги. В RTOS потоки, это как бы отдельные программы, которые могут ничего не знать о друг друге - задача ядра по очереди запускать их.
приходится постоянно опрашивать флаг/флаги. В RTOS потоки, это как бы отдельные программы, которые могут ничего не знать о друг друге
Это только если "потоки" не взаимодействуют. Например, один поток мигает светодиодами, делая бегущие огни, а другой пищит динамиком, наигрывая "в лесу родилась ёлочка". Как только вы вознамеритесь из одного потока в другой передать данные - начнутся флаги и т.п. В простых случаях это будет сделано незаметно для верхнего уровня, типа send_message-функцией, в других будет куча семафоров, мьютексов и т.п. сложноперевариваемой хрени.
Только для вышеописанного случая музыкальных бегущих огней без ОС получится ничуть не сложнее.
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
Как только вы вознамеритесь из одного потока в другой передать данные - начнутся флаги и т.п. В простых случаях это будет сделано незаметно для верхнего уровня, типа send_message-функцией, в других будет куча семафоров, мьютексов и т.п. сложноперевариваемой хрени.
имхо не очень то и сложноперевариваемо:
The following steps are required to use signals: In the thread (for example thread ID tid_thread1) that is supposed to wait for a signal, call the wait function:
Код:
osSignalWait (0x0001, osWaitForever); // wait forever for the signal 0x0001
In another thread (or threads) that are supposed to wake the waiting thread up call:
Код:
osSignalSet (tid_thread1, 0x0001); // set the signal 0x0001 for thread tid_thread1 osDelay (1000); // wait for 1 second
реальный примерчик блинканья группой светодиодов по кнопке CMSIS-RTOS из паков Кейла: Спойлер..
Код:
/*---------- * blinkLED: blink LED and check button state *----------*/ void blinkLED(void const *argument) { int32_t max_num = LED_GetCount(); int32_t num = 0;
for (;;) { LED_On(num); // Turn specified LED on osSignalWait(0x0001, osWaitForever); LED_Off(num); // Turn specified LED off osSignalWait(0x0001, osWaitForever);
num++; // Change LED number if (num >= max_num) { num = 0; // Restart with first LED } } }
for (;;) { // main must not be terminated! osDelay(500); while (Buttons_GetState() & (button_msk)); // Wait while holding USER button osSignalSet(tid_blinkLED, 0x0001); } }
вполне перевариваемо (имхо), да можно и без RTOS вполне красиво оформить, но говорят с RTOS некоторые задачи решать лучшее, чем без оной
Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ очень важен контроль процесса заряда и разряда для избегания воздействия внешнего зарядного напряжения после достижения 100% заряда. Инженеры КОМПЭЛ подготовили список таких решений от разных производителей.
с RTOS некоторые задачи решать лучшее, чем без оной
лично я с этим и не спорю. но точно так же "некоторые задачи" на AVR лучше вообще не решать, особенно если задачи тянут за собой ОС... а придумать для AVR задачи, решение которых с ОС кардинально удобнее, чем без нее, я не могу.
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре.
Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.
не так страшен... Попробовал AVR порт распространенной FreeRTOS, которая поддерживает большую хучу микроконтроллеров (и даже Quark и x86), на mega8. Две задачи блинканья светодиодами. В протеусе проверил - блинкают. Заняло половину ресурсов, ram поболее половины:
жить с RTOS можно и на AVR, тем более в наличии AVR имеются экземпляры с более ресурсами, а еще есть xmegи тож AVRы, а на AVR32 линуксы запускают. Основной main файл выглядит не страшно: Спойлер
Код:
#include "FreeRTOS.h" #include "task.h"
/*----------*/ /* Задача #1 */ /*----------*/ void vTask1( void *pvParameters ) { /* задача построена на базе бесконечного цикла */ for(;;) { /* Инвертировать бит 0 порта PORTC */ PORTC ^= (1 << PC0); /* Задержка на некоторый период Т1 */ vTaskDelay(200); // T1 = 200 системным тикам } /* Уничтожить задачу если произошел выход из бесконечного цикла */ vTaskDelete(NULL); }
/*----------*/ /* Entry Point */ /*----------*/ int main( void ) { /* Биты 0,1 порта PORTC будут работать как выходы */ DDRC |= (1<<DDC0) | (1<<DDC1);
/* Установка задачи #1. В этом примере не используется проверка на коректную установку */ xTaskCreate( vTask1, /* Указатель на исполняемую функцию */ (signed char *) "Task1", /* Имя задачи */ configMINIMAL_STACK_SIZE, /* Размер стэка задачи */ NULL, /* Передаваемый параметр */ 1, /* Приоритет задачи */ NULL ); /* Дескриптор задачи */
/* Установка задачи #2 */ xTaskCreate( vTask2, /* Указатель на иполняемую функцию */ (signed char * ) "Task2", /* Имя задачи */ configMINIMAL_STACK_SIZE, /* Размер стэка задачи */ NULL, /* Передаваемый параметр */ 1, /* Приоритет задачи */ NULL ); /* Дескриптор задачи */
Не знаю насчет практической ценности порта RTOS под 8 бит AVR, но поучится можно, с целью получить потом престижную работу . Вроде для промышленных применений микроконтроллеров, где жизнь человека может быть подвергнута опасности применяют сертифицированные безопасные RTOS типа: https://www.highintegritysystems.com/em ... lications/
Как раз по вашему примеру и видно - приходится постоянно опрашивать флаг/флаги. В RTOS потоки, это как бы отдельные программы, которые могут ничего не знать о друг друге - задача ядра по очереди запускать их.
Чем флаги не понравились? Опросить флаги несложно, да и флаги по прерыванию стараюсь минимизировать. А программа получается относительно несложной, скоростной, легко читаемой. Насчёт того, что «В RTOS потоки, это как бы отдельные программы, которые могут ничего не знать о друг друге». Даже если потоки логически не связаны друг с другом, думаю, есть ещё важный связывающий фактор — временной, когда МК должен быстро отработать некоторые процессы. Наверно, «скоростные» задачи без RTOS лучше решаются.
Наверно, «скоростные» задачи без RTOS лучше решаются.
В большинстве RTOS реализована возможность задавать приоритеты потоков.
Для примера: первый поток - работа с SD-картой, низкий приоритет; второй поток - обработка сообщений от UART, высокий приоритет. При некоторых допущениях (например, обработку нельзя вынести в прерывание), в реализации на флагах работа с SD будет приводить к потере сообщений, получаемых по UART.
Чем флаги не понравились? Опросить флаги несложно, да и флаги по прерыванию стараюсь минимизировать. А программа получается относительно несложной, скоростной, легко читаемой
Дык флагами сам таки и пользуюсь. Речь то о том, что с RTOS программа получается вообще несложной и еще более читаемой, переносимой и надежной. Отдельные задачи могут писать разные программисты.
Наверно, «скоростные» задачи без RTOS лучше решаются.
Ну самая популярная в России RTOS — QNX 4.0 (правда на AVR порта нет) 8К микроядро (да-да, восемь килобайт!) время переключения контекста — 2,5 наносекунды, и ядро полностью написано на ассемблере, что обеспечивает высочайшую скорость. Кроме того, в такой небольшой программе легче находить ошибки, что делает его (ядро) чрезвычайно надежным. QNX смело можно назвать одной из самых проработанных ОС. Не удивительно, что ей доверяют контроль над ядерными реакторами и медицинским оборудованием. И то, и другое напрямую связано с жизнью и здоровьем людей.
Зарегистрирован: Вс май 21, 2017 16:43:56 Сообщений: 22
Рейтинг сообщения:0
Попробую дополнить этот топик...позанудничаю, можно?
ОС, как и есть в Вики: "набор подпрограмм для .. и взаимодействия с ползателями". То есть ОС решает задачи запуска программ на данном железе, управления ресурсами этого железа И взаимодействия с человеком. Перенося это на AVR как управляющий контроллер, имеем: чтобы данная библиотека могла носить гордое название "Операционная Система", требуется выполнение условий (с конца): а) типовой комплект средств взаимодействия с пользователем. В целом если и нет, то нетрудно ввести некий "стандарт" на базе libc: printf() и т.д.; б) управления ресурсами .. вот тут уже хорошо выходит. Ибо контроллер .. управляющий и его "ресурсы" практически индивидуальны в данном конкретном применении. Разве что "процессорное время" и "распределение памяти"... в) запуск программ .. и тут совсем "засада": управляющий контроллер предназначен для решения некой конкретной задачи управления в строго этом, конкретном окружении .. управление термостатом, пробник-осцилограф, ПИД-регулятор гоночной тележки, контроль работы видеокамеры и системы её включения/выключения, поворота .. КАК это все совместить в рамках одной "ОС" с единым механизмом управления? Ну и где тут "Операционная Система", когда каждое применение можно считать уникальным?
Можно вести речь за "кусок RTOS", а именно за систему прозрачного распараллеливания задач - "диспетчер задач". Он интересен и полезен больше в рамках "автоматного" программирования. Когда каждый ресурс управляется своим конечным автоматом и разработчику неважно в каком конкретно порядке исполняются эти автоматы .. порядок их действий все равно определяется сменой их состояний. Но, как ни странно, "юникс-подобный" стиль распараллеливания задач .. внезапно не подходит для такой работы. Куда интереснее в этом плане механизмы межзадачного взаимодействия языка Ада. Правда он похоже давно заброшен..
Зарегистрирован: Вс май 21, 2017 16:43:56 Сообщений: 22
Рейтинг сообщения:0
Пасибки, не знал. Жаль что ну очень давно, ещё до стандарта "Ада-95" пользовал этот язык. Да и как-то конкрус исключительно под STM32F4xx .. есть STM32F405, но я его ещё не распаковывал. Срок до сентября .. маловато времени, чтобы вспомнить язык, разобраться с новым для себя процом и что-то закодить "оригинальное".
Integrity — операционная система реального времени, разработанная калифорнийской компанией Green Hills Software. Сертифицирована на соответствие POSIX. Ориентирована на однопроцессорные встраиваемые системы, в центральном процессоре которых есть блок управления памятью (архитектуры ARM, XScale, Blackfin, Freescale ColdFire, MIPS, PowerPC, x86). Система основана на микроядре µ-velosity. Главная особенность системы — отказоустойчивость (если произойдет отказ в какой-либо программе запущенной в этой операционной системе, система в целом будет продолжать работать в штатном режиме, а перезапуск упавшего приложения попытается провести с предоставлением ему тех областей памяти данных, которые были выделены приложению до его падения). Используется в американских военных самолетах (например F-16, F-22, F-35) и вертолетах, так же в гражданских Airbus A380, Boeing 787.
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 49
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения