Собственно вот и вопрос, а зачем всё это? Имеется ввиду архитектура Mega, в xMega там ресурсов поболее и прочие няшки есть. Но вот зачем городить RTOS на Mege, какой выигрыш и в чем это даст. Спасибо!
Собственно вот и вопрос, а зачем всё это? Имеется ввиду архитектура Mega, в xMega там ресурсов поболее и прочие няшки есть. Но вот зачем городить RTOS на Mege, какой выигрыш и в чем это даст. Спасибо!
Если спрашиваете, то Вам это (RTOS) не нужно.
Регулярно такие вопросы возникают. Если "на пальцах", любая ОС (как RT так и не RT) предоставляет набор функций (API). Например, если я пишу код тектового интерфейса с пользователем (терминал), то у меня появляется новая абстрация - символьный поток. И мне: 1) "по барабану" на какам процессоре будет выполнятся мой код (хоть на меге, хоть на xМеге, хоть на ARMе) 2) совершенно не важно, как подключен терминал ползователя (к UART-у, или, например, это telтet клиент) А RTOS обеспечит, чтобы "общение с пользователем" не мешало более важным задачам.
ОСРВ позволяет программисту сосредоточить свои усилия на решении конкретных задач (алгоритмических, математических и т.п.), не отвлекаясь на задачи второстепенные. Она берет на себя:
переключение между параллельными процессами (например, опрос клавиатуры, вывод информации на экран, управление реле и.т.п.); отсчет таймаутов, выдержку задержек; выбор готовой к выполнению задачи с наивысшим приоритетом и передача ей управления; обмен данными между задачами (с помощью семафоров, сообщений и пр.).
Задачами в ОСРВ OSA являются обычные функции. Тело функции должно содержать бесконечный цикл, внутри которого должен быть хотя бы один вызов сервиса переключения задач (иначе остальные задачи не получат управления).
Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ очень важен контроль процесса заряда и разряда для избегания воздействия внешнего зарядного напряжения после достижения 100% заряда. Инженеры КОМПЭЛ подготовили список таких решений от разных производителей.
Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре.
Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.
Алексей bird, Вы видимо имели в виду применимость OS в контроллерах с небольшим объёмом памяти (1-16 kB). Для таких МК, по моему скромному мнению, использование RTOS избыточно (или невозможно), и к тому же программы таких размеров я пишу на ассемблере. Для себя я написал фрагменты кода (затем оформил их в виде макросов), которые позволяют структурировать программу на ассемблере, разбивая её на отдельные подзадачи. Если Вам будет интересно, можете посмотреть статьи "RTOS для маленьких" и "Изобретение велосипеда" (avr-assm.ru).
Да причем тут заставляют? Как можно оценить инструмент, если не знать какие он даёт преимущества? Взять и попробовать мысль хорошая, но для начала всё-таки хочу понять какие выгоды мне это даст(или может дать). dimmer нет не применимость, а именно зачем это нужно. Как я понял использование RTOS в простых задачах ни к чему. А вот при сложных, может дать серьёзный плюс. Спасибо всем, буду пробовать
Более интересно, если кто нибудь дал рабочий пример проекта (не демонстрацию процессов), с небольшим описанием. Сам пытался использовать, сначала понравилось, но потом на AVR уперся в количество процессов. Как выход, в процессе использовал суперцикл. Получился старый подход к написанию программы, но с быстрым переключением нескольких суперциклов. Вообщем как писать правильно программы на ОС я не понял.
Интересные выводы. Только как понять нужна ли мне САПР, ведь я рисую на миллиметровке и мне нравится.
Мой смайлик ввел Вас в заблуждение. На самом деле ответ был без сарказма. На мой взгляд, при увеличении сложности задач, Вы придете к выводу, что затраты на разработку неприемлемые и нужен новый уровень абстракции. Даже сейчас Вы на XMEGA видите преимущества, но и меги разные бывают 128 или 256K программной памяти - это прилично.
"Зачем мне экскаватор, если я за день выкопаю траншею, а подъезд экскаватора затруднен?" Если задается такой вопрос, то экскаватор спрашивающему не нужен.
---------- Я предполагаю, если Вы знаете, что на AVR можно запустить RTOS, то Вы хоть что-то прочитали про эту RTOS. Так же предполагаю, что прочитав хоть самую малость, Вы в общих чертах поняли, что дает использование RTOS. На мой взгляд основные: 1) использование "чужого" кода (и многократное использование своего) 2) переносимость (когда пишется большая часть кода, не важно на каком целевом микроконтролле он будет работать), 3) "изолированность" кода. Т.е. все это ведет к уменьшению затрат на разработку и увеличению надежности ПО. Естественно, это все не бесплатно. Например, может понадобится больше памяти, большая производительность...
Получился старый подход к написанию программы, но с быстрым переключением нескольких суперциклов.
надежды, что применение RTOS для AVR развяжет программисту руки и даст невиданную свободу, никогда не оправдаются. RTOS не для AVR, даже если применяется "монстр" atmega2560. И не надо добиваться невиданных успехов, насилуя RTOSами жалкое ядро... надо именно что использовать по-максимуму возможности "старых" подходов. Вы уверены, что исчерпали эти "старые" подходы? А вспомните ZX Spectrum - процессор там был примерно в 5-8 раз менее производительный, чем AVR, ресурсов там было заметно меньше, чем в той же atmega128, а тем не менее такое там вытворялось! Посмотрите на UzeBox - та же мега, разве что немного разогнанная, и что вытворяет! И при этом ни в спектруме, ни в UzeBox-е не то что реального времени, а вообще никакой ОС нет. Раз уж судьба толкает вас применять AVR - не подражайте другим, идите традиционным путем, просто тщательнее разрабатывайте программы
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
Мой смайлик ввел Вас в заблуждение. На самом деле ответ был без сарказма. На мой взгляд, при увеличении сложности задач, Вы придете к выводу, что затраты на разработку неприемлемые и нужен новый уровень абстракции. Даже сейчас Вы на XMEGA видите преимущества, но и меги разные бывают 128 или 256K программной памяти - это прилично.
"Зачем мне экскаватор, если я за день выкопаю траншею, а подъезд экскаватора затруднен?" Если задается такой вопрос, то экскаватор спрашивающему не нужен.
---------- Я предполагаю, если Вы знаете, что на AVR можно запустить RTOS, то Вы хоть что-то прочитали про эту RTOS. Так же предполагаю, что прочитав хоть самую малость, Вы в общих чертах поняли, что дает использование RTOS. На мой взгляд основные: 1) использование "чужого" кода (и многократное использование своего) 2) переносимость (когда пишется большая часть кода, не важно на каком целевом микроконтролле он будет работать), 3) "изолированность" кода. Т.е. все это ведет к уменьшению затрат на разработку и увеличению надежности ПО. Естественно, это все не бесплатно. Например, может понадобится больше памяти, большая производительность...
Я думаю можно на "ты", а то как-то глаз режет, всё-таки это не официальная переписка Ну вот например: 1) А разве код не нужно будет "прилизывать" к каждой RTOS? Ведь они используют разные имена, переменные и прочее. 2) А разве без RTOS это сложно? 3) Поподробней можно?
Вот зачем нужна ОС на обычном компьютере я понимаю, но там есть тот же HAL, GUI которые сильно помогают(облегчают работу) в написании программ. Но ведь того же HAL'а для AVR нет, или я ошибаюсь?
Карма: 29
Рейтинг сообщений: 645
Зарегистрирован: Сб май 14, 2011 21:16:04 Сообщений: 2694 Откуда: г. Чайковский
Рейтинг сообщения:0 Медали: 1
ARV писал(а):
И при этом ни в спектруме, ни в UzeBox-е не то что реального времени, а вообще никакой ОС нет.
На счет спектрума не соглашусь. Роль ОС в спектруме выполнял встроенный в 16КБ ПЗУ Бэйсик. Разработчики программ активно пользовались его функциями, экономя тем самым драгоценное ОЗУ. В русифицированных спектрумах был несколько изменен код в ПЗУ из-за чего не все игры работали на таких компах. Но это так, ремарка, не имеющая значения для данной темы.
_________________ Добро всегда побеждает зло. Поэтому кто победил - тот и добрый.
1) А разве код не нужно будет "прилизывать" к каждой RTOS? Ведь они используют разные имена, переменные и прочее.
Нужно. Но можно использовать и другой подход. Класс своих задач представляшь? Выбери себе одну ОС, которая предоставляет Вам наиболее полный список сервисов, которые могут понадобится (остальное придется самому реализовывать). Желательно, чтобы выбранная ОС кроме AVR работала и на других платформах, возможность перехода на которые может понадобиться в будущем: Cortex, MSP430...
Алексей bird писал(а):
2) А разве без RTOS это сложно?
Я и говорю, что если ты спрашиваеш, либо нет задач, на которых можно "прочуствовать", либо ты крут. Пример: было у нас устройство на mege103, которое реализовывало необходимую заказчику функцию. Другой заказчик говорит: нам подходит устройство по функцоионалу, но нам необходимо удаленно мониторить/управлять устройствами по SNMP протоколу. Если у тебя нет проблем быстро "запихнуть" реализацию ARP/IP/UDP/SNMP в свое устройство, тогда - ты крут.
Последний раз редактировалось viiv Чт апр 13, 2017 14:03:59, всего редактировалось 1 раз.
но и меги разные бывают 128 или 256K программной памяти - это прилично.
Флеш в ОС не основное, главное ОЗУ. Оно определяет сколько процессов можно использовать. У меня получалось только 4 процесса на 1к ОЗУ. Сколько у Вас обычно процессов крутится? Думаю, что набор/заготовка пустого проекта, если следовать пунктам 2 и 3, будет стандартной.
Флеш в ОС не основное, главное ОЗУ. Оно определяет сколько процессов можно использовать. У меня получалось только 4 процесса на 1к ОЗУ. Сколько у Вас обычно процессов крутится? Думаю, что набор/заготовка пустого проекта, если следовать пунктам 2 и 3, будет стандартной.
У меги128 4К (если я правильно помню), кроме того есть интерфейс к внешней SRAM
Карма: 29
Рейтинг сообщений: 645
Зарегистрирован: Сб май 14, 2011 21:16:04 Сообщений: 2694 Откуда: г. Чайковский
Рейтинг сообщения:0 Медали: 1
ARV писал(а):
это не аналог ОС, это аналог библотеки подпрограмм
Я знаю что Вас нельзя переубедить, так что не буду пробовать. Однако замечу, что при таком подходе MS-DOS тоже не ОС. А в спектруме, кроме встроенного бэйсика управляющего компом при его старте, еще существует TR-DOS. Ну и определение из википедии
Цитата:
Операцио́нная систе́ма, сокр. ОС (англ. operating system, OS) — комплекс взаимосвязанных программ, предназначенных для управления ресурсами компьютера и организации взаимодействия с пользователем.
ARV писал(а):
спектрум как был, так и остался однозадачной системой,
Ну вроде никто обратного и не утверждал.
_________________ Добро всегда побеждает зло. Поэтому кто победил - тот и добрый.
Алексей bird, на примере постараюсь показать что можно получить от RTOS.
Допустим, к нашему устройству подключен символьный LCD экранчик и keypad. Допустим, есть гипотетическая ОС, в которой определен API символьного экранчика и API простенькой клавиатуры. Спойлер
/* возвращает ID нажатой кнопки, если !nblock, вызывающий блокируется до момента нажатия */ u8_t get_key (bool_t nblock); #define KEY_NONE 0 #define KEY_UP 1 #define KEY_DOWN 2 #define KEY_LEFT 4 #define KEY_RIGHT 5 #define KEY_SELECT 6 #define KEY_ESC 7
Требуется написать реализацию простого главного меню устройства. С учетом приведенных выше API получается простой и понятный код, который не зависит от того, как подключен I2C, SPI, внешней шине... Кроме того, этому коду все равно, на AVR-е он выполняется или на Cortex-M3...
Эта функция выполняется в потоке взаимодейтвия с пользователем, средствами RTOS можно добиться, чтобы данный поток не мешал более высоприоритетным задачам (грубо говоря, расставить правильно приоритеты потоков).
Вы можете привести код, реализующий такое главное меню, без RTOS?
PS. К возможным ошибкам в коде не предираться, написано в попыхах и код не просматривал.
Эта функция выполняется в потоке взаимодейтвия с пользователем
при классическом подходе это ГЛАВНЫЙ ЦИКЛ
viiv писал(а):
данный поток не мешал более высоприоритетным задачам
в классическом подходе это ОБРАБОТЧИКИ ПРЕРЫВАНИЙ и никакой ОС не надо...
P.S. меню и покруче писывали... и тоже максимально от архитектуры отделено. на AVR далеко от ограничений архитектуры не уйдешь, но попробовать можно. в частности, я давно и весьма успешно работаю с ЖКИ и/или USART при помощи printf... пробовал и при помощи scanf, но не понравился вообще подход, предлагаемый классикой Си...
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
RTOS нужна, когда код стал слишком сложным и нужно разделить сервисный и прикладной код. Используя главный цикл подразумевается знакомство с его архитектурой и ограничениями, пользователь должен знать как именно работает этот главный цикл. В RTOS всю эту сложность скрывают и делается предположение, что у вас есть несколько ядер, работающих параллельно. Это упрощение для прикладного программиста. Задачи держать в голове возможно одному человеку. С главным циклом это гораздо сложнее или очень трудно в сопровождении. Поэтому при определённости сложности не имеет смысла использовать главный цикл, его заменяют на RTOS. Это тот же главный цикл, но знать как он работает нужно лишь в общих чертах.
Сейчас этот форум просматривают: Starichok51 и гости: 46
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения