|
|
Вот читаю я посты многоуважаемых товарищей в топиках про MPC5200 (большое спасибо всем!) и нифига не понимаю.
==== Моя собственная теория ОС РВ ====
Есть CPU. Его призводительность C (в попугаях в секунду)
Есть ОС РВ. Ее ресурсоемкость (в тех же попугаях) OSmin, OSmid, OSmax - минимальные затраты, средние затраты и пики затрат.
Есть целевая задача или задачи. Им необходимо TSmin, TSmid, TSmax попугаев.
Если (C-OSmid) =================================== Важное замечание. Есть аппаратное время (то, что на таймере натикало) и есть системное время=аппаратное время + знаковая поправка. Таймер инициализируют один раз при старте и не трогают больше, поправки считают по мере необходимости. Есть прерывание, котрое опрашивает входной пин, пишет принятый бит в буфер. Кроме того, оно проверяет состояние буфера, пишет инфу в байт диагностики своего состояния, и к блоку пинятых бит (например, к принятому байту) приписыват значение таймера (например, в момент первого бита блока). Есть процесс - обработчик нижнего уровня уровня. Биты выделяет (опрос с оверсемплингом), фронты и т.д. Читает из буфера прерываний, пищет в свой буфер (далее поток). Есть процесс - обработчик среднего уровня. Читает поток нижнего уровня, корректирует ошибки (БЧХ). Самая трудоемкая работа. Пишет в свой поток. Есть процесс - обработчик высокого уровня. Разбирает само сообщение, выдает команды процессу среднего уровня. Все, сообщение мы разобрали. Теперь, предположим, в этом сообщении была команда от БС на коррекцию времени. Нам надо поддерживать время с точностью 1 мс. А мы х.з. сколько времени потратили на обработку сообщения. Для этого и служат метки о времени, записанные прерыванием! Вычисление поправки - пара пустяков! Если система сделана правильно, то в начале она входит в синхронизм. И только когда поправки будут менее некоей малой величины, разрешается нормальная работа. Время таймера монотонно! Таким образом, реально имеет место конвейризация задач. Задачи работают в нереальном времени, но укладываются в допуск на время обработки. Короче, System V, со всей красотой архитакутры streams. Если говорить о производительность, то, поскольку полный сервис streams нафиг не нужен, можно написать набор упрощенных функций (скорее, даже макросов) для работы с буферами и потоками. Да, на этом мы потеряем немножко времени (но очень мало, если все написать грамотно, с указателями т .д.) Зато сколько времени мы сэкономим на отладке!!! Эту простую задачу из примера могут писать 3 человека, независимо отлаживать, и вместе все точно заработает! Так вот, эта задача (+ в фоне еще много чего) была реализована на Mega103 6 Мгц (не так красиво, но не суть - это был 2000 год), и все ок! ===== Вопрос по ОС РВ ============= Если не выполняется условие (C-OSmid)>K*TSmid - ничего не поделаешь. Ввод/вывод по DMA, в особо извращенных случая поставить плисину, и тоже по DMA. Конвейризация задач - это вопрос архитектуры системы целиком. Полагаю, в 99% случаев ее можно достичь. А ради 1 % городить весь этот огород с "жекстким временем", "мягким временем"? Время реакции ОС? При DMA нас оно не очень волнует. При прерываниях - не запрещать надолго прерывания внутри ядра ОС. У ОС всего-то несколько моментов есть, когда надо прерывания запрещать. Самое мутное, IMHO, дисковый ввод-выод. Без UDMA делать нечего, с другой стороны винч, котороый даже UDMA33 не тянет еще поискать надо :)) Я не знаю, по стандарту UDMA можно делать перерывы в программировании регистров? Т.е. начали процедуру общения с контроллером. Записали в регистр. Тут нас прервали. Вернулись - записали следующее значение из того блока параметров, который надо передать. ==== Мой наглый вывод === 1. Соотношение скорости/потребления/цены - супер! BGA с шагом 1.27 - нет проблем с разводкой и пайкой. -40 тоже полезно! Буду очень признателен за аргументированную критику моих воззрений.
E-mail:
Понятный мне пример. Программый приемник POCSAG со скоростью 1200 бит/сек.
Скажите, а как можно построить систему, которая не успеет? Помнится, в свое время легендарный Володя Василевский (VLV) развил жуткий флейм в ФИДО темой "О ненужности и бесполезности VLbus" и чего-то еще, я не помню чего. Так вот, сдается мне, что все эти RTOS - развод народа на деньги в 90% случает (мало кому они __реально__ нужны).
=================================
Freescale MPC5200 является гениальным чипом.
2. Выделенная шина DDRAM/SDRAM - нет проблем с разводкой (отражения и т.д.). Берем чип 512мбит (16Mx32) и все путем. 64М, IMHO, хватит для многого :))
3. PCI шина - очень хорошая перспектива для подключения периферии и DSP всяких разных в качестве сопроцессора.
4. Набор периферии - вполне достаточный.
5. Самое главное. Структурированная монстровость. Надо что-то простое, но быстрое - запустил програмку (хоть uCOS, хоть вообще без ос) и вперед. Надо полноценную OS - MMU поднял. Облом писать все правильно - написал на основе тупого ввода /вывода. Есть возможность - драйвера написал, DMA поднял. Не нужен PCI - забудь о нем. Нужен - доку почитал, разобрался.
Ответы
info@telesys.ru
