- Vote on answer
- posted
19 years ago
Embedded OS
- Vote on answer
- posted
19 years ago
- Vote on answer
- posted
19 years ago
- Vote on answer
- posted
19 years ago
- Vote on answer
- posted
19 years ago
- Vote on answer
- posted
19 years ago
- Vote on answer
- posted
19 years ago
- Vote on answer
- posted
19 years ago
HZ> Да? А почему бы вообще все не запихать в одну? Если уж быть HZ> последовательным. Одна задача - расчеты. Все остальное крутится в HZ> прерываниях. HZ> Получится тот самый foreground-background. Это одна крайность. Вполне работоспособная.
HZ> *********************************************** HZ> Процесс 1: HZ> Переключаем_Разряд_Индикатора(); HZ> Sleep(4 миллисекунды);
HZ> *********************************************** HZ> Процесс 2: HZ> Опрашиваем_Кнопки();
А это - другая. Тоже, впрочем, работоспособная :-)
Переключение разряда индикатора вкупе с опросом кнопок в "обычном" прерывании займут времени столько, сколько одно переключение контекста.
Почему бы не считать, что динамическая индикация вообще "как бы аппаратная", просто её буфер лежит в ОЗУ процессора - так как работать это будет прозрачно и незаметно для всех задач, просто нужно складывать байтики в экранную область и всё. С кнопками не так, тут надо по нажатию дать сигнал и инициировать переключение контекста. Но сам опрос, подавление дребезга, ... - ну зачем этому задача? Разве что для того, чтобы быть последовательным, соблюдать чистоту концепции :-)
А по поводу коммуникационного - уже когда-то с тобой обсуждал. На 115200 один байт - это 87 микросекунд. Приём твоим "Процессом 1" при 30-микросекундном переключении контекста только тем и будет занят, что переключаться туда-сюда. На мой взгляд весь приём пакета по закрывающий флаг должен производиться в "обычном" прерывании, и только потом выбрасывать сигнал "наверх".
Т.е. динамическая индикация, клавиатура, приём/передача пакета должны быть "внеосевыми", с точки зрения ОС - "как бы аппаратными". Иначе надо слишком задирать быстродействие процессора.
Просто на мой взгляд если процесс работает меньше, чем переключение на него - это явный перерасход ресурсов и это надо или делать в "обычном" прерывании, предоставляющем ОС "виртуально-интеллектуальную" периферию, или к чему-то пристёгивать.
wbr,
- Vote on answer
- posted
19 years ago
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, многовато...
- Vote on answer
- posted
19 years ago
- Vote on answer
- posted
19 years ago
- Vote on answer
- posted
19 years ago
- Vote on answer
- posted
19 years ago
- Vote on answer
- posted
19 years ago
- Vote on answer
- posted
19 years ago
- Vote on answer
- posted
19 years ago
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,
- Vote on answer
- posted
19 years ago
OR>> Почему бы не считать, что динамическая индикация вообще "как бы OR>> аппаратная", просто её буфер лежит в ОЗУ процессора - так как работать OR>> это будет прозрачно и незаметно для всех задач, просто нужно AM> Потому, что это задача минимального приоритета. Если мигнет индикатор - AM> ну и AM> $DEITY с ним. Если будет потеряно ОДHО прерывание от таймера - это AM> авария со всеми вытекающими. Ну так и пустить прерывание для динамической индикации по минимальному приоритету. А то ОДНО, которое важно - по максимальному.
Кроме того, если аж так страшно - то может лучше на динамическую индикацию, клавиатуру, звуковые эффекты - да поставить полуторадолларовый отдельный контроллер, спокойнее будет?
Да и почему потеряно? Может, слегка задержано? Вывод следующей цифры при динамической индикации времени займёт - грубо как одно переключение контекста. Если то важное прерывание попадёт на начало переключения контекста, визванного чем-то менее важным - всё равно сначала завершится предыдущая операция переключателя задач, задержка сравнима.
wbr, p.s. я ж не против задач :-) Но не понимаю, зачем делать отдельную задачу и огребать двукратное переключение контекста на такие вещи, как смена цифры на индикаторе и приём одного байта из UART. На мой взгляд это - уровень "низкоуровневого драйвера", а не процесса.
- Vote on answer
- posted
19 years ago
Здравствуйте, Уважаемый 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о при этом стану использовать кристаллы с гарвардской архитектурой и надеюсь, что там это, наконец то, сработает нормально.
Всего Вам Хорошего Ольга
- Vote on answer
- posted
19 years ago
- Vote on answer
- posted
19 years ago