Embedded OS

Loading thread data ...
Reply to
Andy Mozzhevilov
Reply to
Andy Mozzhevilov
Reply to
Alexey V Bugrov
Reply to
Andy Mozzhevilov
12-Mar-05 07:24 Harry Zhurov wrote to Yuriy K:

HZ> Да? А почему бы вообще все не запихать в одну? Если уж быть HZ> последовательным. Одна задача - расчеты. Все остальное крутится в HZ> прерываниях. HZ> Получится тот самый foreground-background. Это одна крайность. Вполне работоспособная.

HZ> *********************************************** HZ> Процесс 1: HZ> Переключаем_Разряд_Индикатора(); HZ> Sleep(4 миллисекунды);

HZ> *********************************************** HZ> Процесс 2: HZ> Опрашиваем_Кнопки();

А это - другая. Тоже, впрочем, работоспособная :-)

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

Почему бы не считать, что динамическая индикация вообще "как бы аппаратная", просто её буфер лежит в ОЗУ процессора - так как работать это будет прозрачно и незаметно для всех задач, просто нужно складывать байтики в экранную область и всё. С кнопками не так, тут надо по нажатию дать сигнал и инициировать переключение контекста. Но сам опрос, подавление дребезга, ... - ну зачем этому задача? Разве что для того, чтобы быть последовательным, соблюдать чистоту концепции :-)

А по поводу коммуникационного - уже когда-то с тобой обсуждал. На 115200 один байт - это 87 микросекунд. Приём твоим "Процессом 1" при 30-микросекундном переключении контекста только тем и будет занят, что переключаться туда-сюда. На мой взгляд весь приём пакета по закрывающий флаг должен производиться в "обычном" прерывании, и только потом выбрасывать сигнал "наверх".

Т.е. динамическая индикация, клавиатура, приём/передача пакета должны быть "внеосевыми", с точки зрения ОС - "как бы аппаратными". Иначе надо слишком задирать быстродействие процессора.

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

wbr,

Reply to
Oleksandr Redchuk
12-Mar-05 16:16 Alexey V Bugrov wrote to Andy Mozzhevilov:

AB> Для пакетных протоколов (которых все-таки большинство) все очень даже AB> прозрачно. По прерыванию выгребаем байт, AB> проверяем его на валидность кладем в буфер... вобщем выполняем все AB> задачи до момента разбора принятого пакета. Это AB> легко т.к. простейший конечный автомат с малым и детерминированным AB> временем выполнения (иногда даже сопоставимым со AB> временем переключения контекста). А иногда - так совсем несопоставимо :-) Вот специально полез глянул. Дано - приходят пакеты, разделённые флагами. Байт-стаффинг (по SLIP, у меня так "исторически сложилось"). Разбор "а чего это там флагом отмахнулось - там хоть CRC совпала?" - это делается "выше", в прерывании только разбор подстановки байтов, сохранение уже восстановленных данных в буфере, подсчёт числа байтов в пакете, короче, минимум, необходимый для выделения пакета без его анализа. По осциллографу - продолжительнсть тела обработчика прерывания - болтается в окрестности 2.2-2.3мкс, по листингу - вход и выход в прерывания (включая неявный "call" и явный reti) - ещё в сумме окло 2.5мкс. Итого меньше 5мкс, около 70 тактов процессора (AVR @ 14.7458MHz). На AVR переключение контекста таким маленьким не будет даже если зафиксировать и исключить из контеста половину регистров.

wbr, p.s. а таки многовато регистров у AVR, многовато...

Reply to
Oleksandr Redchuk
Reply to
Maxim Polyanskiy
Reply to
Maxim Polyanskiy
Reply to
Andy Mozzhevilov
Reply to
Maxim Polyanskiy
Reply to
Anatoly Mashanov
Reply to
Sergey Pinigin
13-Mar-05 03:21 Maxim Polyanskiy wrote to Harry Zhurov:

MP> Или вот например методика создания 3-х уровней приоритетов на x51:

MP> Скажем у тебя usart имеет самый высокий уровень а обработчик пакетов MP> должен MP> быть с уровнем выше main но ниже usart. Берешь любое незадействованное в MP> программе прерывание ставишь ему низкий приоритет и взводишь в теле MP> usart MP> interupt его битик в точке приема пакета. Оно будет вызванно сразу-же по MP> выходу из usart,

Тю, зачем?

jnz L?done ; ещё не весь пакет acall single_reti

; обработка принятого пакета

L?done: _pop <AR0,ACC,PSW>

single_reti: reti

Очистили логику прерываний выполнением reti - теперь все остальные прерывания будут спокойно прерывать данное, оно уже выполняется на уровне фоновой. Понятное дело, что биты приоритета процессора в его слове состояния - это более правильный и удобный метод, но с 51-ым и такое работает.

wbr,

Reply to
Oleksandr Redchuk
13-Mar-05 09:16 Anatoly Mashanov wrote to Oleksandr Redchuk:

OR>> Почему бы не считать, что динамическая индикация вообще "как бы OR>> аппаратная", просто её буфер лежит в ОЗУ процессора - так как работать OR>> это будет прозрачно и незаметно для всех задач, просто нужно AM> Потому, что это задача минимального приоритета. Если мигнет индикатор - AM> ну и AM> $DEITY с ним. Если будет потеряно ОДHО прерывание от таймера - это AM> авария со всеми вытекающими. Ну так и пустить прерывание для динамической индикации по минимальному приоритету. А то ОДНО, которое важно - по максимальному.

Кроме того, если аж так страшно - то может лучше на динамическую индикацию, клавиатуру, звуковые эффекты - да поставить полуторадолларовый отдельный контроллер, спокойнее будет?

Да и почему потеряно? Может, слегка задержано? Вывод следующей цифры при динамической индикации времени займёт - грубо как одно переключение контекста. Если то важное прерывание попадёт на начало переключения контекста, визванного чем-то менее важным - всё равно сначала завершится предыдущая операция переключателя задач, задержка сравнима.

wbr, p.s. я ж не против задач :-) Но не понимаю, зачем делать отдельную задачу и огребать двукратное переключение контекста на такие вещи, как смена цифры на индикаторе и приём одного байта из UART. На мой взгляд это - уровень "низкоуровневого драйвера", а не процесса.

Reply to
Oleksandr Redchuk

Здравствуйте, Уважаемый Andy!

Sun Mar 13 2005 07:41, Andy Mozzhevilov wrote to Maxim Polyanskiy:

AM> А чего его читать? Там в все то же самое, что и в предыдущих твоих AM> письмах. AM> 1) Ты сначала попробуй хоть что-нибудь написать на Си - потом спорь. AM> 2) Ты сначала хотя бы пойми насчет того, "что там и как переключается", AM> потом спорь.

AM> Тебе привели гипотетический пример, общий подход без деталей, AM> а ты принял его за конечную реальную задачу.

Hасколько я смогла понять, обсуждается обоснованность использования многозадачных OS в мелких однокристаллках. Люди обмениваются реальным опытом из жизни, а не гипотетическими примерами. Позвольте и мне внести лепту. Я думаю, что громоздить многозадачную OS для мелких однокристаллок- это лишняя трата интеллекта, времени и сил. Сама идея создания многозадачной OS с упором на ограниченные ресурсы кристалла, на экономию каждого бита и байта - порочна в корне своей задумки. Такая "экономия" на деле оборачивается отказом от многих важных фич у многозадачных OS, например, создание и удаление процессов, очереди и FiFo для сообщений, семафоры не накапливаются, количество процессов очень ограничено, и т.д. Я понимаю, что в однокристаллках с игрушечными задачами ничего из перечисленного и не нужно. Hо, зачем тогда нужна вся эта возня с игрушечной OS? Hа какой качественно более высокий уровень выводит разработчика софта данный подход?

AM> Если ты не разбираешься в Си, RTOS - так чего лезть и жужжать постоянно?

По поводу Cи в контексте многозадачной OS пожужжать совсем не лишне. Пишут на Cи многозадачные OS ради независимости от платформы использования. Hо на практике, для неймановской архитектуры, которой обладают подавляющее большинство мелких однокристаллок, - никакой независимости Cи-программ от платформы достичь не удается. И начинают плодится отдельная OS для каждого из AVR, отдельная для MSP430. Более того, они еще будут требовать вдумчивой модификации для каждого компилятора Си от разных фирм. А дело-то в одном простом моменте- программирование на Си предназначено для платформ с гарвардской архитектурой. И только там оно дает эффективные и платформонезависимые решения. Вот почему, "пожужжать" лишний раз про порочность Си в мелких однокристаллках неймановской архитектуры и слегка промыть мозги народу- никогда не помешает.

AM> Пишешь на асме, так никто ж не против. А рассуждать о вкусе устриц, если AM> их не ел, дурной тон.

Подозреваю, что человек пишет на макроассемблере как раз потому, что попробовал и нахлебался неприятностей с Си и "готовыми" RTOS- вдосталь. Я тоже нахлебалась, когда имела дело с неймановской архитектурой однокристаллок и тоже перешла в конце концов на собственную библиотеку макросов на ассемблере. Так оказалось проще и быстрее. Однако, сейчас я возвращаюсь к программированию на Cи и к многозадачным OS. Hо при этом стану использовать кристаллы с гарвардской архитектурой и надеюсь, что там это, наконец то, сработает нормально.

Всего Вам Хорошего Ольга

Reply to
Olga Nonova
Reply to
Anton Abrosimov
Reply to
Andy Mozzhevilov

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.