Тут обсуждаем нужность RTOS ;)

Пpивет, Maxim!

*** 05 Feb 04 09:51, Maxim Polyanskiy wrote to Andy Mozzhevilov:

MP> системой впрыска топлива и опережением зажигания для автомобильного MP> двигателя - мы получим 150 "ЗАДАЧ" (c тем-же каном и реализацией MP> сложнейших диагностических протоколов на 3 порядка выше твоих), с MP> строгой реалтаймовой системой с привязкой даже не к времени - а к MP> угловой скорости и угловым положениям! А вычисление угловой скорости MP> от времени - недетская математика и скорострельность нужна. И MP> ты думаешь там есть RTOS?

Hу, если посмотреть, как это сделано у современных ECU - да, полноценная RTOS в хосте, и что-то (за ненадобностью не вычитывал) в вспомогательном процессоре (заведующем зажиганием, возможно, там и один цикл крутится). Да, само собой, asm-а как раз там нет...

с уважением Владислав

Thu Feb 05 2004 09:51, Maxim Polyanskiy wrote to Andy Mozzhevilov:

AM>> процессоры обычно реальные, с конкретной производительностью. MP>>> требует чтоб результирующий управляемый RTOS процессор имел MP>>> ПЯТHАДЦАТИКРАТHО! большую производительность. AM>> У тебя на потолке число 15 написано, что ли?

MP> Всем очень непонравилась цифра 15 ;)

Естественно, ибо она не имеет ни малейшего отношения к реальности.

Вот у меня есть переключатель задач, который вызывается раз в 1 ms и занимает

8mks, заодно еще пару таймеров обслуживая.

8mks/1ms = 0.8% overhead, а никак не 1500%.

MP>>> Если задача может быть решена под управлением RTOS на том-же MP>>> процессоре - она либо нифига не реалтаймовая, либо далеко не в MP>>> упоре.

Разумеется не в упоре. Какой идиот будет решать задачи в использованием

95% ресурсов?

WBR, Юрий.

Hello, Vladislav!

Чет Фев 05 2004, Vladislav Baliasov писал к Maxim Polyanskiy по поводу "Тут обсуждаем нужность RTOS ;)." MP>> вычисление угловой скорости от времени - недетская математика и MP>> скорострельность нужна. И ты думаешь там есть RTOS? VB> Hу, если посмотреть, как это сделано у современных ECU - да, VB> полноценная RTOS в хосте, и что-то (за ненадобностью не вычитывал) в VB> вспомогательном процессоре (заведующем зажиганием, возможно, там и VB> один цикл крутится). Да, само собой, asm-а как раз там нет... Это на извращенском 166-м. Hа x51 все нормально сделано через прерывания без всяких ртосов, по другому просто не успеет. А уж как такие задачи решали на моторолах HC11 - любо дорого посмотреть. VB> с уважением Владислав WBR! Maxim Polyanskiy.

Пpивет, Maxim!

*** 06 Feb 04 02:47, Maxim Polyanskiy wrote to Vladislav Baliasov:

VB>> вычитывал) в вспомогательном процессоре (заведующем зажиганием, VB>> возможно, там и один цикл крутится). Да, само собой, asm-а как VB>> раз там нет...

MP> Это на извращенском 166-м. Hа x51 все нормально сделано через MP> прерывания без всяких ртосов, по другому просто не успеет.

Так кто "извращенский" ? Может быть, все же тот, кто "по-другому не успеет ?". Hе оттуда ли растут ноги у проблем мониторинга состояния двигателя через диагностику на ходу у ВАЗовских поделий ? Хотя, конечно, так делать (мониторить на ходу) все равно не следует...

MP> А уж как такие задачи решали на моторолах HC11 - любо дорого MP> посмотреть.

Hу, вообще-то и на 166/167 все через прерывания. Только я сомневаюсь, что так уж просто получится реализовать то, что работает на 166/167 на 8-битках с ограниченным адресным пространством. Таблиц там немеряно, уже под мегабайт прошивки... Ладно, факт остается фактом - на современных ECU сделано именно так, а не иначе... Hравится это кому или нет (мне вот совершенно не нравится, внутри каша страшная, что найти - опухнуть можно, оверхед безумный), но вот как есть. Реальность.

с уважением Владислав

Maxim, ты ещё здесь сидишь?

Четверг Февраль 05 2004 09:51, Maxim Polyanskiy wrote to Andy Mozzhevilov:

MP> Давай лучше подробно с паравозами разберемся ;) Там у тебя 15 якобы MP> "задач" (по твоей ущербной логике я 15 процессоров должен поставить - MP> а вот фиг!). ;) Hачнем с процессора который я бы поставил - это x51 с MP> каном, мат сопром и развернутой периферией от infineon, по конкретике MP> я не скажу - тз надо читать. По цене не думаю, что проблемы будут MP> (системы думаю не тысячами штук делаются да и не аон это).

AM>> Задачи в порядке уменьшения приоритетов:

[поскипано]

Дружный хор со стороны "теоретиков":

Это нечестно! Ты другой алгоритм реализовал! Hельзя задачу менять, надо всё точно как на ЯВУ делать! И вообще ты задачу не решил, потому что у тебя задача режима ожидания не решается!!!

;)))))))))))))))

MP> Смысл в том, что счет вагонов - это детская задачка.

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

;-)

Георгий

Yuriy, ты ещё здесь сидишь?

Четверг Февраль 05 2004 23:58, Yuriy K wrote to Maxim Polyanskiy:

MP>>>> Если задача может быть решена под управлением RTOS на том-же MP>>>> процессоре - она либо нифига не реалтаймовая, либо далеко не в MP>>>> упоре.

YK> Разумеется не в упоре. Какой идиот будет решать задачи в YK> использованием 95% ресурсов?

Многократный оверход плюс использование всего десятка процентов ресурсов имеющегося "железа". Широко живём!......

Георгий

Hello, Vladislav!

Пят Фев 06 2004, Vladislav Baliasov писал к Maxim Polyanskiy по поводу "Тут обсуждаем нужность RTOS ;)." MP>> Это на извращенском 166-м. Hа x51 все нормально сделано через MP>> прерывания без всяких ртосов, по другому просто не успеет. VB> Так кто "извращенский" ? Может быть, все же тот, кто "по-другому не VB> успеет ?". У меня успевает. У кого не успевает - проблемы головы+рук. VB> Hе оттуда ли растут ноги у проблем мониторинга состояния VB> двигателя через диагностику на ходу у ВАЗовских поделий ? Хотя, VB> конечно, так делать (мониторить на ходу) все равно не следует... Проблемы исключительно в дибильности iso 14230. VB> Hу, вообще-то и на 166/167 все через прерывания. А где задачи? VB> Только я сомневаюсь, что так уж просто получится реализовать то, что VB> работает на 166/167 на 8-битках с ограниченным адресным VB> пространством. Таблиц там немеряно, VB> уже под мегабайт прошивки... Потому, что решается вовсе не проблема управления одним конкретно взятым двигателем (как это было в старые добрые времена когда автоэлектроника знавала, что такое mcs48). А проблема управления всеми двигателями мира (сферическим двигателем), всех систем и моделей, с любым числом цилиндров, c любыми вариациями датчиков и исполнительных механизмов, да еще и в свете решений пропагандируемых тут как якобы "не совок". Если же мы возьмем один конкретный двигатель - мы увидим что программа, таблицы, и диагностические протоколы избыточны на 60-70%. И настолько-же тормозны. Так при этой избыточности еще придумали код на си писать уроды, вот и получается что то что раньше влезало в

16к маски HC11 теперь не лезет в 256к на 16-ти битке... А чего стоит логика аварийного управления при отказах которая занимает чуть-ли не 70% алгоритма - просто плакать хочется. Все настолько надуманно и настолько по дурацки сделанно, что иной раз лучше чтоб машина сразу вставала, чем по такой логике пыталась ездить. VB> Ладно, факт остается фактом - на современных ECU сделано именно так, VB> а не иначе... Hравится это кому или нет (мне вот совершенно не VB> нравится, внутри каша страшная, что найти - опухнуть можно, оверхед VB> безумный), но вот как есть. Реальность. Посмотри на это с другой стороны, ты 1 РАЗ это все расковыряешь - и у тебя не будет никаких проблем с ЛЮБОЙ машиной оснащенной этой системой (коих сотни моделей) ;)

У меня кстати мотор диагностируется на ходу легко на тупом x51. После того как я вылизал прошиву, выкинул константы, оптимизировал доступ в таблицы и математику,придумал эфективный протокол диагностики. И кстати 4-др впрыск тоже на этом-же железе не тормозит даже на 8000rpm - а стандарт надо в консерватории править. VB> с уважением Владислав WBR! Maxim Polyanskiy.

AM>> процессоры обычно реальные, с конкретной производительностью. MP>>> требует чтоб результирующий управляемый RTOS процессор имел MP>>> ПЯТHАДЦАТИКРАТHО! большую производительность. AM>> У тебя на потолке число 15 написано, что ли? MP> Всем очень непонравилась цифра 15 ;) Hу что предложить 2 банальных элементарных MP> задачи и доказать эту цифру банальным потактовым расщетом их исполнения сначала MP> на 2-х CPU в реалтайме и 100%-й загрузки а потом на одном под управлением RTOS MP> ? Только вот боюсь 15 еще занижено... А ты думал логика подмены контекста либо MP> бакгроунда - она чего на халяву что-ли работает?

Я не думал, я знаю как она работает, и знаю, на каком этапе RTOS начинает давать выигрыш. Потому что я все это пробовал сам, в отличие от...

AM>> Под х51 у меня используется только кооператичная многозадачность.

MP> Так - твои стеки сразу скипаются. Hе вижу сдесь никакой реалтаймовости и MP> многозадачности. Вопервых данные у тебя не падают с неба а передаются MP> процессору по вполне реальным и довольно медленым протоколам. Принимать пакеты MP> и парсить одним майном - детский сад.

Так сделай. Ты делал стек TCP/IP? В каком объеме?

MP> Давай лучше подробно с паравозами MP> разберемся ;) Там у тебя 15 якобы "задач" (по твоей ущербной логике я 15 MP> процессоров должен поставить - а вот фиг!). ;) Hачнем с процессора который я бы MP> поставил - это x51 с каном

:) Ты на одних только обращениях к внешней памяти не пролезешь по производительности, хоть запишись на ассемблере.

MP> , мат сопром

Это типа Сименса 517 - го чтоли? Чего ему там считать-то?

MP> и развернутой периферией от infineon, по MP> конкретике я не скажу - тз надо читать. По цене не думаю, что проблемы будут MP> (системы думаю не тысячами штук делаются да и не аон это).

Этот х51 стоит дороже, чем 16-ти битный MB90F543, который там сейчас молотит.

AM>> Задачи в порядке уменьшения приоритетов: AM>> 1. Отметка вагонов. По сигналам от датчиков производит счет осей, AM>> выделение вагонов и определение их типов. Тик задачи - 500 мкс от AM>> отдельного таймера. MP> Все датчики заводятся на входы пинов автомата CAPTURE. Прерываниям по событиям MP> CAPTURE назначается высший приоритет. Вся логика счета вагонов - внутри этих MP> прерываний. Временные метки между любыми из датчиков на аппаратном уровне MP> получаются с точностью до одного тика Т2. Мат сопроцесор позволяет производить MP> любые вычисления с высокой точностью... Hа выходе данные (типы вагонов) валятся MP> в FIFO стек [вагоны] расположенный в iram.

Я тебе скажу, что на классическом х51 пиковая нагрузка алгоритма обработки - где-то около 300-400 мкс на тик в 500, при тактовой 24 МГц. У меня есть и такой вариант чисто законченного устройства только отметки вагонов.

MP> Кусок процедуры control (вызываемой из main) а именно Control_вагоны:

MP> 1) если в fifo нет вагона - ret MP> 2) если есть вагон - снимаем его с fifo MP> 3) Вгоняем тип вагона в FIFO стек [CAN-OUT] (если разрешено флагом {вывод MP> вагона в CAN}).

По can еще надо передать срабатывание кажного датчика оси. Причем сразу, как оно обнаружено.

MP> 4) Печать юзер-инфо о вагоне в буфер экрана (пусть будет в xram 0) с скролингом MP> если надо, если опция не запрещена флагами {управление дисплеем от can} {работа MP> юзер интерфейса} MP> 5) Cчет вагонов (можно по типам, можно с учетом времени и прочего).

Задача счета вагонов - это одна из задач, под которую ты фактически занял все время процессора.

MP> Длительность control_вагоны в упоре максимум несколько 10-ков милисекунд.

Ты, я смотрбю и в этой области специалист, как считал?

AM>> 2. Задача передачи информации об отметке вагонов в CAN MP> Выполняется в прерываниях CAN интерфейса по готовности передатчика путем снятия MP> данных с FIFO буфера [CAN-OUT] и отстрела в кан.

А если кан слетел, что делать? Ждать в прерываниях пока он восстановится?

AM>> 3. Задача вывода сообщений на дисплей MP> Выполняется в таймере (периодические прерывания с частотой скажем 25гц с низким MP> приоритетом). Путем копирования экранного буфера из xram в дисплей. (можно MP> оптимизировать создав 2 буфера таким образом копируя только реальные MP> изменения).

У меня их по моему 5 - несколько контекстов дисплея, на дисплее отображается наимоблее приоритетный контекст в данный момент. Остальные просто живут в памяти.

AM>> 5. Задача обслуживания режима ввода команды MP> Выполняется в том-же таймере что и экран. Клавиатура сканируется, подавляется MP> дребезг, реализуется логика автоповтора (если надо), звукового подтверждения MP> (если надо) на выходе глобальная переменная [код клавиши] и флаг {клавиша MP> нажата}

А по меню тоже в прерываниях таскаться?

AM>> 7,8. Задачи связи по связи по 2-ум последовательным каналам.

MP> В прерываниях uasrt. При необходимости заводятся стеки этих каналов и MP> организуется функция в main - control.

А пакеты где обрабатывать, тоже в прерываниях?

AM>> По приему сообщений возможна записть данных в I2С EEPROM MP> Обработчик в таймере проверяет наличие задачи по состоянию сложного MP> структурированного fifo буфера [eeprom_out] если буфер не пуст - проверяется MP> статус шины i2c путем контроля аска на передаче команды 0a0. Если шина занята - MP> выходим. Если шина свободна из буфера снимается ровно столько байт, сколько MP> возможно загнать в i2c еепромину за один прием (можно выравнивание под размер MP> блоков организовать в задачах заполнения этого буфера таким образом разделив MP> задачи и сэкономив время в этом участке). По I2c дается команда запись c MP> строкой данных и тут-же выходим без всякого ожидания конца записи!

А если запись не удалась, что делать?

AM>> 9. Задача "Кинг" протокола CAN Kingdom. используется для динамической AM>> конфигурации устройств в сети CAN. MP> Те-же прерывания от кана. Как говорицца всему своя очередь.

Он передает, какие прерывания? Прерывания в can будут возникать при окончании передачи. Кто будет инициализировать ее начало?

AM>> 11. Задача приема информационных сообщений из CAN и раскладывающая по AM>> приоритетным очередям. MP> Прерывания кана (опять-же не ясно, что делают твои инфосообщения кроме как MP> раскидываются по очередям) ;)

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

AM>> 12. Задача приема диагностических сообщений от устройств из CAN MP> Прерывания кана. Hу не бывает так что с кана все это свалилось вдруг - все эти MP> события валятся по очереди, либо валятся только какие-то из них, либо вообще MP> ничего не валится. ;)

Ты CAN представляешь? Может легко свалиться сразу несколько сообщений подряд. Одно сообщение передается 100-200 мкс, где-то.

AM>> 13. Задача обслуживания пользовательского последовательного AM>> интерфейса. MP> Помоему мы уже обслуживали 2 последовательных интерфейса где-то выше.

Те связевые.

AM>> 14. Задача обслуживания дисплея 16х4 MP> Ты повторяешься - это часть таймера.

Тот был виртуальный, для предоставления ресурса дисплея через CAN.

MP> Если это еще один дисплей - то значит это MP> еще одна такая-же часть таймера (кстати задачку с дисплеем на асме мы с тобой MP> уже решали - стыдно называть обслуживание дисплея "задачей" временни оно почти MP> не жрет).

MP> Смысл в том, что счет вагонов - это детская задачка.

:)))

MP> Если я руководствуясь твоей логикой разложу на "задачи" алгоритм MP> управления системой впрыска топлива и опережением зажигания для MP> автомобильного двигателя - мы получим 150 "ЗАДАЧ"

Да какой там алгоритм вспрыска? Максимум, что ты делал, это корректировал таблицы в этом контроллере.

MP> (c тем-же каном и реализацией сложнейших диагностических протоколов на 3 MP> порядка выше твоих),

Ты очень удачно выбрал под мою задачу х51. Все сделел в прерываниях. И как у тебя все здорово получилось, как это я сам не догадался. Только я тебя огорчу. Эта система работать не будет, потому что пока ты будешь обрабатывать одно прерывание по отметке вагонов и обсчет этих результатов, у тебя уже легко пропадет символ по UART на 38400, сообщение в приемном буфере CAN, на которое ты положил, потому что затащил задачу обсчета результата в самое приоритетное прерывание.

MP> с строгой реалтаймовой системой с привязкой даже не к MP> времени - а к угловой скорости и угловым положениям!

!!! :)

MP> А вычисление угловой MP> скорости от времени - недетская математика

У всех все детское, у одного МР - недетсткое.

MP> и скорострельность нужна.

И ты утверждаешь, что ты это сам написал с нуля? :) На нихрена. Ты дизассемблировал бинарник, залез туда, нашел таблицы и изменил форму зависимостей. Потом еще пытаешься кого то учить.

MP> И ты думаешь там есть RTOS? ХА! Все это тупо пишется в 1 жирный майн в лоб на MP> АСМ-MCS51 c правильными и грамотно придуманными обработчиками прерываний!

И где эта твоя разработка используется? Какими тиражами?

MP>>> Поможет метка времени и счетчик обеспечивающий это самое MP>>> детерминирование и промбуфер для данных полученных в прерываниях. MP>>> Опять-же ничего нового я не увидел. AM>> Метка времени чего, события? AM>> Да мне его обработать уже надо и предпринять определенные действия, AM>> скажем, через 200 мкс после его наступления. MP> Hе вопрос - кладешь 200мс в тиках таймера в COMPARE регистр - через 200мкс MP> возникает прерывание по событию compare где живет обработчик. Где проблему MP> нашел - не вижу.

Не видишь, твои проблемы. Я вообще не о том.

MP>>> Тебе дествительно интересно почему я объявлю его как massiv equ MP>>> 0xx00h (где x - некие значения) или ты просто включаешь дурака? AM>> Чтобы в ассемблере не попало, то нужно объявлять его в определенной AM>> секции с указанием типа выравнивания, а не пользоваться equ. Hо во AM>> первых, надо это помнить, во вторых, может просто не влезть, если AM>> понадобится больше 256 байт. MP> Господи боже мой, ну хочешь извращений - вот тебе извращения:

MP> .data MP> ... MP> org ($ + 0xff) & 0xffffff00 MP> massiv label byte MP> ds 100h MP> ...

Для задания выравнивания все приличные ассемблеры имеют специальные директивы. Это пример для ассемблера Keil 51/251.

RxBufSeg SEGMENT XDATA INPAGE PAGE

Создает сегмент с именем MySeg, размещенный в xdata, который должен помещаться в 256 байт (атрибут INPAGE) и должен быть выравнен по границе 256 байт (атрибут PAGE)

Потом собственно резервирование нужного количесва байт в этом сегменте: RSEG RxBufSeg RxBuffer: DS 256

Дальше о соблюдении твоих требований будет заботиться ассемблер и/или линкер. При попытке RxBuffer: DS 257 ты сразу же получишь ругань ассемблера и/или линкера. Какой конкртено будет выделен адрес для RxBuffer в данном случае не важно, для тебя главное, чтобы он удовлетворял эти требованиям. Линкер его разместит в нужное место, в соответствии с параметрами доступной памяти. В этом случае не будет никаких пустых дырок в памяти при применении твоего извращения: org ($ + 0xff) & 0xffffff00 и каких либо граблей.

А теперь внимание - вопрос: Какого х.. ты тут пытаешься всех учить эффективности работы на ассемблере по сравнению с Си, если ты не знаешь элементарных возможностей ассемблера - того инструмента, которым сам пользуешься ???

Пpивет, Maxim!

*** 06 Feb 04 08:24, Maxim Polyanskiy wrote to Vladislav Baliasov:

MP> Проблемы исключительно в дибильности iso 14230.

VB>> Hу, вообще-то и на 166/167 все через прерывания.

MP> А где задачи?

А пес его знает. Т.е. я знаю даже, что за система там крутится, и как ее зовут, но обработчиков прерываний там выше крыши. Hу, может быть, я просто неверно выразился...

VB>> Только я сомневаюсь, что так уж просто получится реализовать то, VB>> что работает на 166/167 на 8-битках с ограниченным VB>> адресным пространством. Таблиц там немеряно, уже под мегабайт VB>> прошивки...

MP> Потому, что решается вовсе не проблема управления одним конкретно MP> взятым двигателем (как это было в старые добрые времена когда MP> автоэлектроника знавала, что такое mcs48). А проблема управления всеми MP> двигателями мира (сферическим двигателем), всех систем и моделей, с MP> любым числом цилиндров, c любыми вариациями датчиков и исполнительных MP> механизмов, да еще и в свете решений пропагандируемых тут как якобы MP> "не совок".

Вообще-то - именно конкретным типом двигателя..

MP> занимает чуть-ли не 70% алгоритма - просто плакать хочется. Все MP> настолько надуманно и настолько по дурацки сделанно, что иной раз MP> лучше чтоб машина сразу вставала, чем по такой логике пыталась ездить.

Однако ездит. Hеплохо...

MP> Посмотри на это с другой стороны, ты 1 РАЗ это все расковыряешь - и у MP> тебя не будет никаких проблем с ЛЮБОЙ машиной оснащенной этой системой MP> (коих сотни моделей) ;)

Хрена. Hесколько похожих на первый взгляд (по железу - полностью) внутри (в прошивке) не имеют ничего общего. То ли чем-то другим перекомпилировали, то ли еще что...

с уважением Владислав

Hello, Maxim Polyanskiy !

Да, просто кошмар какой эти фольксвагены, хонды и пежо. То ли дело ЖИГУЛИ...

С уважением, Дима Орлов.

"Maxim Polyanskiy" <Maxim snipped-for-privacy@p12.f.n5020.z2.fidonet.org>

сообщил/сообщила в новостях следующее: news:MSGID_2=3A5020=2F887.12=40Fidonet snipped-for-privacy@fidonet.org...

логика

алгоритма -

сделанно, что иной

Понимание этого отчетливо придет в голову, когда пользуясь твоей логикой встанет машина где-нибудь, да что далеко ходить - где-нибудь за Тураном (всего-то ~200 км от Иркутска) а на улице - -20 (вобщем-то и не холодно). Так что разработчиков всего этого обходного кода лучше не трогать, если сам этот код не пишешь. Едет ниссан со сдохшим ДРВ коптит, дымит, бензин жрет как свинья помои пусть чего хочет делает, но едет. И до дома доезжает. И это правильно.

Денис.

Пpивет George!

06 Фев 04 06:59, George Shepelev -> Yuriy K:

GS> Многокpатный овеpход плюс использование всего десятка пpоцентов GS> pесypсов имеющегося "железа". Шиpоко живём!......

Возможность шиpоко жить pазpешают пpоизводители однокpисталок. Hе вижy пpичин пpотивится этомy pазpешению.

Igor

Hello, Dennis!

Пят Фев 06 2004, Dennis Opanasenko писал к All по поводу "Re: Тут обсуждаем нужность RTOS ;)." MP>> логика аварийного управления при отказах которая занимает чуть-ли не MP>> 70% алгоритма - просто плакать хочется. Все настолько надуманно и MP>> настолько по дурацки сделанно, что иной раз лучше чтоб машина сразу MP>> вставала, чем по такой логике пыталась ездить. DO> Понимание этого отчетливо придет в голову, когда пользуясь твоей DO> логикой встанет машина где-нибудь, да что далеко ходить - где-нибудь DO> за Тураном (всего-то ~200 км от Иркутска) а на улице - -20 (вобщем-то DO> и не холодно). Hормальные люди "за Тураном" на инжекторных авто не ездят. К тому-же ничего не мешает сделать для "заТуранщиков" систему с MAP. Они не дохнут как ДМРВ. DO> Так что разработчиков всего этого обходного кода лучше DO> не трогать, если сам этот код не пишешь. Едет ниссан со сдохшим ДРВ DO> коптит, дымит, бензин жрет как свинья помои пусть чего хочет делает, DO> но едет. И до дома доезжает. И это правильно. Правильно проектировать безотказные системы а не писать надуманную логику обхода отказов. DO> Денис. WBR! Maxim Polyanskiy.

Hello, Andy!

Пят Фев 06 2004, Andy Mozzhevilov писал к Maxim Polyanskiy по поводу "Re: Тут обсуждаем нужность RTOS ;)." MP>> Только вот боюсь 15 еще занижено... А ты думал логика подмены MP>> контекста либо бакгроунда - она чего на халяву что-ли работает? AM> Я не думал, я знаю как она работает, и знаю, на каком этапе RTOS AM> начинает давать выигрыш. Потому что я все это пробовал сам, AM> в отличие от... Что еще ты пробовал? Ты думаешь, что твоя задача имеет единственное правильное решение - то что написал ты? Hе заходи так далеко в своих заблуждениях. Любой сдесь ее может решить и каждый сделает это по своему. MP>> Так - твои стеки сразу скипаются. Hе вижу сдесь никакой MP>> реалтаймовости и многозадачности. AM> Так сделай. Ты делал стек TCP/IP? В каком объеме? В досе делают в лоб и это работает. - Отсюда выводы... MP>> Давай лучше подробно с паравозами разберемся ;) Там у тебя 15 якобы MP>> "задач" (по твоей ущербной логике я 15 процессоров должен поставить MP>> - а вот фиг!). ;) Hачнем с процессора который я бы поставил - это MP>> x51 с каном AM> :) Ты на одних только обращениях к внешней памяти не пролезешь по AM> производительности, хоть запишись на ассемблере. Смешно. При таком количестве DPTR регистров и скорости кристала я не то, что пролезу но и буду с легкостью обрабатывать структуры разной длинны (которые мне нужны в логике работы с eeprom и возможно can-ом). MP>> , мат сопром AM> Это типа Сименса 517 - го чтоли? AM> Чего ему там считать-то? А ты не видишь чего считать? Я например вижу, но это сугубо мое видение... У меня нет достаточной информации чтоб подтвердить его правильность. AM> Этот х51 стоит дороже, чем 16-ти битный MB90F543, который там сейчас AM> молотит. Хочешь соревноватся в цене - заставлю вагоны считать 629-й пик а вся остальная шняга будет на 18-м с can-ом... Причем опять-же мне не понадобится 16-ти битность, чтоб считать вагоны ;) MP>> высокой точностью... Hа выходе данные (типы вагонов) валятся в MP>> FIFO стек [вагоны] расположенный в iram. AM> Я тебе скажу, что на классическом х51 пиковая нагрузка алгоритма AM> обработки - где-то около 300-400 мкс на тик в 500, при тактовой 24 AM> МГц. У меня есть и такой вариант чисто законченного устройства только AM> отметки вагонов. Ты мне говоришь время которое у тебя получилось для решения задачи - это сферический параметр. С чего ты решил что я буду решать ее так-же как ты? К тому-же я почему-то уверен, что задачу ты решаешь асболютно програмными методами (лобовое переписывание методики контроля состояний датчиков из тз в исходник), даже если это не так - нет гарантии, что твои методы эфективны. Ведь "эфективность не самоцель"?! Работает и ладно... ;) Лучше скажи точное количество датчиков и алгоритм их совмесного функционирования - возможно время мне вообще не понадобится. MP>> 3) Вгоняем тип вагона в FIFO стек [CAN-OUT] (если разрешено флагом MP>> {вывод вагона в CAN}). AM> По can еще надо передать срабатывание кажного датчика оси. Причем AM> сразу, как оно обнаружено. Прекрасно. Добавляем к записи в стеке кана ячейку приоритета. Приоритетные сообщения снимаем в первую очередь. MP>> 4) Печать юзер-инфо о вагоне в буфер экрана (пусть будет в xram 0) MP>> с скролингом если надо, если опция не запрещена флагами MP>> {управление дисплеем от can} {работа юзер интерфейса} 5) Cчет MP>> вагонов (можно по типам, можно с учетом времени и прочего). AM> Задача счета вагонов - это одна из задач, под которую ты фактически AM> занял все время процессора. Задача счета как таковая тобою поставленна не была. И время под нее не занималось. Я просто предложил посчитать вагоны по типам (ну для статистики ;) MP>> Длительность control_вагоны в упоре максимум несколько 10-ков MP>> милисекунд. AM> Ты, я смотрбю и в этой области специалист, как считал? Я упор считал, чтоб юзер-интерфейс не тормозил и стеки не переполнялись. Реально там конечно и 1-й мс не набирается пока. AM>>> 2. Задача передачи информации об отметке вагонов в CAN MP>> Выполняется в прерываниях CAN интерфейса по готовности передатчика MP>> путем снятия данных с FIFO буфера [CAN-OUT] и отстрела в кан. AM> А если кан слетел, что делать? Ждать в прерываниях пока он AM> восстановится? Зависит от времени востановления и ТЗ. Тут разную логику можно предусмотреть... AM>>> 3. Задача вывода сообщений на дисплей MP>> Выполняется в таймере (периодические прерывания с частотой скажем MP>> 25гц с низким приоритетом). Путем копирования экранного буфера из MP>> xram в дисплей. (можно оптимизировать создав 2 буфера таким MP>> образом копируя только реальные изменения). AM> У меня их по моему 5 - несколько контекстов дисплея, на дисплее AM> отображается наимоблее приоритетный контекст в данный момент. AM> Остальные просто живут в памяти. Прекрасно. Их может быть и 10-ть суть не меняется. Копируем активную 25 раз в сек. AM>>> 5. Задача обслуживания режима ввода команды MP>> Выполняется в том-же таймере что и экран. Клавиатура сканируется, MP>> подавляется дребезг, реализуется логика автоповтора (если надо), MP>> звукового подтверждения (если надо) на выходе глобальная MP>> переменная [код клавиши] и флаг {клавиша нажата} AM> А по меню тоже в прерываниях таскаться? Меню в main деревом. Я же писал об этом. AM>>> 7,8. Задачи связи по связи по 2-ум последовательным каналам. MP>> В прерываниях uasrt. При необходимости заводятся стеки этих MP>> каналов и организуется функция в main - control. AM> А пакеты где обрабатывать, тоже в прерываниях? Зависит от сложности обработки. Возможно - да там. Причем на лету, при приходе каждого байта, c помощью логики состояний. AM>>> По приему сообщений возможна записть данных в I2С EEPROM MP>> Обработчик в таймере проверяет наличие задачи по состоянию MP>> сложного структурированного fifo буфера [eeprom_out] если буфер не MP>> пуст - проверяется статус шины i2c путем контроля аска на передаче MP>> команды 0a0. Если шина занята - выходим. Если шина свободна из MP>> буфера снимается ровно столько байт, сколько возможно загнать в MP>> i2c еепромину за один прием (можно выравнивание под размер блоков MP>> организовать в задачах заполнения этого буфера таким образом MP>> разделив задачи и сэкономив время в этом участке). По I2c дается MP>> команда запись c строкой данных и тут-же выходим без всякого MP>> ожидания конца записи! AM> А если запись не удалась, что делать? Усложним алгоритм. К структуре блока записи добавляем 1 байт. 7-й бит флаговый

0-write 1-verify. 0-6 счетчик попыток. Работает так - после успешной записи пакет не снимается с стека а устанавливается флаговый бит. В следующей итерации когда автомат записи отработает происходит верификация пакета. Если она прошла успешно - пакет снимается. Если она завершилась неудачей - бит 7 сбрасывается а счетчик в битах 0-6 увеличивается. Таким образом в следующей итерации снова произойдет попытка записи. Так по кругу либо пока не запишется успешно, либо до достижения счетчиком критического значения, после которого в CAN отстреливается ошибка eeprom и поведение устройства подчиняется логике "отказ eeprom". (попытки записи больше не производятся, на дисплее соответствующие надписи)...

AM>>> 9. Задача "Кинг" протокола CAN Kingdom. используется для AM>>> динамической конфигурации устройств в сети CAN. MP>> Те-же прерывания от кана. Как говорицца всему своя очередь. AM> Он передает, какие прерывания? Прерывания в can будут возникать при AM> окончании передачи. Кто будет инициализировать ее начало? Я с тебя удивляюсь. Как будто ты никогда не писал фифошный rs232 передатчик... Если буфер передачи пуст в прерываниях ставится флаг холостого выхода. Если выход продуктивный (идет передача) этот бит сбрасывается. Процедура которая отправляет байт в буфер передачи по JBC этого бита взводит аппаратный флаг прерывания, коие тут-же возникает. (Есть грабли - но я знаю как обходить, тебе не скажу... ;-) AM>>> 11. Задача приема информационных сообщений из CAN и AM>>> раскладывающая по приоритетным очередям. MP>> Прерывания кана (опять-же не ясно, что делают твои инфосообщения MP>> кроме как раскидываются по очередям) ;) AM> Передаются потом по последовательным каналам, если логические AM> соединения установлены. Значит сразу пойдут в их TX буфера. AM>>> 12. Задача приема диагностических сообщений от устройств из CAN MP>> Прерывания кана. Hу не бывает так что с кана все это свалилось MP>> вдруг - все эти события валятся по очереди, либо валятся только MP>> какие-то из них, либо вообще ничего не валится. ;) AM> Ты CAN представляешь? Может легко свалиться сразу несколько сообщений AM> подряд. Одно сообщение передается 100-200 мкс, где-то. Хватит времени. AM>>> 13. Задача обслуживания пользовательского последовательного AM>>> интерфейса. MP>> Помоему мы уже обслуживали 2 последовательных интерфейса где-то MP>> выше. AM> Те связевые. А юзерский - это что который удаленного администрирования? Так его можно тупо крутить паралелно с user интерфейсом управляя поведением ввода-вывода по битикам. MP>> Если я руководствуясь твоей логикой разложу на "задачи" алгоритм MP>> управления системой впрыска топлива и опережением зажигания для MP>> автомобильного двигателя - мы получим 150 "ЗАДАЧ" AM> Да какой там алгоритм вспрыска? Максимум, что ты делал, это AM> корректировал таблицы в этом контроллере. Только вот для того, чтоб коректировать даже таблицы надо знать как работает программа не так-ли? MP>> (c тем-же каном и реализацией сложнейших диагностических MP>> протоколов на 3 порядка выше твоих), AM> Ты очень удачно выбрал под мою задачу х51. AM> Все сделел в прерываниях. И как у тебя все здорово получилось, как это AM> я сам не догадался. Только я тебя огорчу. Эта система работать не AM> будет, потому что пока ты будешь обрабатывать одно прерывание по AM> отметке вагонов и обсчет этих результатов, у тебя уже легко пропадет AM> символ по UART на 38400, сообщение в приемном буфере CAN, на которое AM> ты положил, потому что затащил задачу обсчета результата в самое AM> приоритетное прерывание. Действительно ты сбил меня с толку. Конечно приоритет кана и возможно уартов должен быть выше этих убогих capture. Ведь вагоны в отличие от байтов в CAN не летают с околосветовыми скоростями, а являются вполне осмысленной железной сущностью, обладающей не малой длинной, весом, и абсолютно детской со всех точек зрения скоростью ;). MP>> и скорострельность нужна. AM> И ты утверждаешь, что ты это сам написал с нуля? :) AM> Hа нихрена. Ты дизассемблировал бинарник, залез туда, нашел таблицы и AM> изменил форму зависимостей. Потом еще пытаешься кого то учить. Да ты прав - я залез в бинарник, понял алгоритм, сначала даже прифигел от того, что сложные вещи на самом деле можно сделать просто. А если привнести туда немножко своих идей - то сложные вещи делаются ну очень просто! И сделал соответствующие выводы о эфективных механизмах управления и контроля. Теперь скажи мне пожалуйста, что кроме спефикации на RTOS ты читал в это самое время? Мне действительно интересно почему твой вывод базируется на том, что задача решаема только посредством RTOS? AM>>> действия, скажем, через 200 мкс после его наступления. MP>> Hе вопрос - кладешь 200мс в тиках таймера в COMPARE регистр - MP>> через 200мкс возникает прерывание по событию compare где живет MP>> обработчик. Где проблему нашел - не вижу. AM> Hе видишь, твои проблемы. Я вообще не о том. А о чем? Ты хотел действие через 200мкс - получите! [...] AM> Для задания выравнивания все приличные ассемблеры имеют специальные AM> директивы. Это пример для ассемблера Keil 51/251. [.] AM> случае не будет никаких пустых дырок в памяти при применении AM> твоего извращения: org ($ + 0xff) & 0xffffff00 и каких либо граблей. И зачем ты написал этот трактат? Все это галимый развод, я тебе уже писал и повторюсь:

метка EQU выражение!!!

Работает в ЛЮБОМ ассемблере ЛЮБОГО процессора! Обеспечивает все на свете - резервирование, выравнивание, отсутствие дырок, явный самоконтроль. AM> А теперь внимание - вопрос: Какого х.. ты тут пытаешься всех учить AM> эффективности работы на ассемблере по сравнению с Си, если ты не AM> знаешь элементарных возможностей ассемблера - того инструмента, AM> которым сам пользуешься ??? У меня нет ассемблера от Кейла, небыло и не будет, согласись, что вполне логично мое незнание методик выравнивания, используемых в ассемблере от кейла. Даже наоборот мое знание оных должно настораживать. ;) А учить тут тебя никто не пытается. Мы просто обсуждаем различные механизмы решения задач. AM> Andy WBR! Maxim Polyanskiy.

Igor, ты ещё здесь сидишь?

Пятница Февраль 06 2004 22:00, Igor Ulanov wrote to George Shepelev:

GS>> Многокpатный овеpход плюс использование всего десятка пpоцентов GS>> pесypсов имеющегося "железа". Шиpоко живём!...... IU> Возможность шиpоко жить pазpешают пpоизводители однокpисталок. Hе IU> вижy пpичин пpотивится этомy pазpешению.

А кто противится? Пусть разрешают. Широко жить не запретишь ;)

Конкурентом меньше...

Георгий

AM>> Я не думал, я знаю как она работает, и знаю, на каком этапе RTOS AM>> начинает давать выигрыш. Потому что я все это пробовал сам, AM>> в отличие от...

MP> Что еще ты пробовал?

foreground/background, кооперативную RTOS, вытесняющую RTOS. Нужно что-то еще?

MP> Ты думаешь, что твоя задача имеет единственное правильное MP> решение - то что написал ты?

Нет, конечно.

MP> Hе заходи так далеко в своих заблуждениях. Любой MP> сдесь ее может решить и каждый сделает это по своему.

Да, и вообще любой из детсада ее решит за пол-дня.

MP>>> Так - твои стеки сразу скипаются. Hе вижу сдесь никакой MP>>> реалтаймовости и многозадачности. AM>> Так сделай. Ты делал стек TCP/IP? В каком объеме? MP> В досе делают в лоб и это работает. - Отсюда выводы...

Ты делал? Делают http на PIC12C509 - и какие отсюда выводы?

MP>>> , мат сопром AM>> Это типа Сименса 517 - го чтоли? Чего ему там считать-то?

MP> А ты не видишь чего считать? Я например вижу, но это сугубо мое видение...

Да, я вот не первый год в этой тематике - и не вижу, тут пришел MP и сразу все увидел...

MP> У меня нет достаточной информации чтоб подтвердить его правильность. AM>> Этот х51 стоит дороже, чем 16-ти битный MB90F543, который там сейчас AM>> молотит. MP> Хочешь соревноватся в цене - заставлю вагоны считать 629-й пик а вся остальная MP> шняга будет на 18-м с can-ом... Причем опять-же мне не понадобится 16-ти MP> битность, чтоб считать вагоны ;)

В этом случае у тебя скорость обмена между твоими пиками ограничит время реакции системы на события. А так считать можно, только кому это будет нужно?

AM>> Я тебе скажу, что на классическом х51 пиковая нагрузка алгоритма AM>> обработки - где-то около 300-400 мкс на тик в 500, при тактовой 24 AM>> МГц. У меня есть и такой вариант чисто законченного устройства только AM>> отметки вагонов. MP> Ты мне говоришь время которое у тебя получилось для решения задачи - это MP> сферический параметр. С чего ты решил что я буду решать ее так-же как ты?

Да ты просто не будешь.

MP> К тому-же я почему-то уверен, что задачу ты решаешь асболютно програмными MP> методами (лобовое переписывание методики контроля состояний датчиков из тз в MP> исходник), даже если это не так - нет гарантии, что твои методы эфективны.

Конечно, эффективны они только у Полянского и Шепелева, остальным просто "повезло".

MP> Ведь "эфективность не самоцель"?! Работает и ладно... ;) Лучше скажи точное MP> количество датчиков и алгоритм их совмесного функционирования - возможно время MP> мне вообще не понадобится.

Ух ты какой быстрый. Может тебе еще и исходник кинуть, и ключ от квартиры где деньги лежат?

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

Ты CAN вообще видел, хотя бы документацию?

AM>> Задача счета вагонов - это одна из задач, под которую ты фактически AM>> занял все время процессора. MP> Задача счета как таковая тобою поставленна не была. И время под нее не MP> занималось.

А что было? Думаешь я под:

AM> 1. Отметка вагонов. По сигналам от датчиков производит счет осей, AM> выделение вагонов и определение их типов. Тик задачи - 500 мкс от AM> отдельного таймера.

имел ввиду что-то другое. Или для тебя неочевидно, что если ты сделал задачу отметки, по подсчитав - сколько ты сделал отметок, получишь количество вагонов?

AM>> Ты, я смотрбю и в этой области специалист, как считал? MP> Я упор считал, чтоб юзер-интерфейс не тормозил и стеки не переполнялись. MP> Реально там конечно и 1-й мс не набирается пока.

За 1 мс передаются/принимаются 4 символа по UART на скорости 38400. А ты в это время торчишь в прерываниях, теряя символы.

AM>> А если кан слетел, что делать? Ждать в прерываниях пока он AM>> восстановится? MP> Зависит от времени востановления и ТЗ. Тут разную логику можно предусмотреть...

И всю в прерываниях?

AM>>>> 7,8. Задачи связи по связи по 2-ум последовательным каналам. MP>>> В прерываниях uasrt. При необходимости заводятся стеки этих MP>>> каналов и организуется функция в main - control. AM>> А пакеты где обрабатывать, тоже в прерываниях? MP> Зависит от сложности обработки. Возможно - да там. Причем на лету, при приходе MP> каждого байта, c помощью логики состояний.

А при этом прерывание отметчика вагонов занимает 1 мс. Так что ты выберешь, правильно посчитать вагоны или правильно принять пакет? Или поставишь 2 uC?

MP>>> ожидания конца записи! AM>> А если запись не удалась, что делать? MP> Усложним алгоритм. К структуре блока записи добавляем 1 байт. 7-й бит флаговый MP> 0-write 1-verify. 0-6 счетчик попыток. Работает так - после успешной записи MP> пакет не снимается с стека а устанавливается флаговый бит. В следующей итерации

Кто эти итеррации будет запускать/проверять их результат?

MP>>> Прерывания кана (опять-же не ясно, что делают твои инфосообщения MP>>> кроме как раскидываются по очередям) ;) AM>> Передаются потом по последовательным каналам, если логические AM>> соединения установлены. MP> Значит сразу пойдут в их TX буфера.

А если пока не надо? Логической соединение не создано, оборвалось? А когда создалось, то нужно передавать сообщения в порядке их важности (приоритета).

AM>> Ты CAN представляешь? Может легко свалиться сразу несколько сообщений AM>> подряд. Одно сообщение передается 100-200 мкс, где-то. MP> Хватит времени.

Хватит или/или/или на обработку CAN, обработку UART, отметку вагонов. Да не беда, поставим 3 uC.

AM>> Да какой там алгоритм вспрыска? Максимум, что ты делал, это AM>> корректировал таблицы в этом контроллере. MP> Только вот для того, чтоб коректировать даже таблицы надо знать как работает MP> программа не так-ли?

Надо, и что?

MP>>> (c тем-же каном и реализацией сложнейших диагностических MP>>> протоколов на 3 порядка выше твоих), AM>> Ты очень удачно выбрал под мою задачу х51. AM>> Все сделел в прерываниях. И как у тебя все здорово получилось, как это AM>> я сам не догадался. Только я тебя огорчу. Эта система работать не AM>> будет, потому что пока ты будешь обрабатывать одно прерывание по AM>> отметке вагонов и обсчет этих результатов, у тебя уже легко пропадет AM>> символ по UART на 38400, сообщение в приемном буфере CAN, на которое AM>> ты положил, потому что затащил задачу обсчета результата в самое AM>> приоритетное прерывание. MP> Действительно ты сбил меня с толку. Конечно приоритет кана и возможно уартов MP> должен быть выше этих убогих capture. Ведь вагоны в отличие от байтов в CAN не MP> летают с околосветовыми скоростями, а являются вполне осмысленной железной MP> сущностью, обладающей не малой длинной, весом, и абсолютно детской со всех MP> точек зрения скоростью ;).

Какая разница, чем они являются. Я тебе привел пиковую нагрузку для х51 по обработке срабатывания датчика оси. Куда бы ты не запихал, на какой бы приоритет - у тебя не хватит производительности все крутить в прерываниях. Потому что ты используешь неэффективное распределение времени процессора. То, что можно обработать на уровне задачи - ты сделал в прерываниях, хотя реально этой необходимости нет. Тем самым заблокировал систему от других событий полностью, на время обработки.

MP> скажи мне пожалуйста, что кроме спефикации на RTOS ты читал в это самое время? MP> Мне действительно интересно почему твой вывод базируется на том, что задача MP> решаема только посредством RTOS?

Я этого не говорил. В противном случае цитируй. Но я утверждаю, что при помощи RTOS на сложных задачах, где существует множество асинхронных процессов, напрямую друг с другом не связанных, RTOS дает выигрыш, потому что более эффективно распределяет вычислительные ресурсы процессора, позволяя в данный конкретеный момент выполнять самую неотложную работу. Писать под RTOS подобыне задачи гораздо проще и эффективнее, чем обеспечивать то же самое в foreground/background системе.

AM>>>> действия, скажем, через 200 мкс после его наступления. MP>>> Hе вопрос - кладешь 200мс в тиках таймера в COMPARE регистр - MP>>> через 200мкс возникает прерывание по событию compare где живет MP>>> обработчик. Где проблему нашел - не вижу. AM>> Hе видишь, твои проблемы. Я вообще не о том. MP> А о чем? Ты хотел действие через 200мкс - получите!

Я сказал, что от возникновения события до начала выполнения определенных действий должно пройти не более чем... Если пройдет более чем, и если я даже буду знать, на сколько "более" на момент начала этих действий - все равно уже будет поздно.

AM>> случае не будет никаких пустых дырок в памяти при применении AM>> твоего извращения: org ($ + 0xff) & 0xffffff00 и каких либо граблей.

MP> И зачем ты написал этот трактат? Все это галимый развод, я тебе уже писал и MP> повторюсь:

MP> метка EQU выражение!!!

Следующая твоя вершина - писания программы прямо в кодах. Есть к чему стремиться, желаю успехов.

AM>> знаешь элементарных возможностей ассемблера - того инструмента, AM>> которым сам пользуешься ??? MP> У меня нет ассемблера от Кейла, небыло и не будет, согласись, что вполне MP> логично мое незнание методик выравнивания, используемых в ассемблере от кейла.

Да эти методики есть в любом приличном ассемблере. Keil я привел просто в качестве примера.

AM>>Я не думал, я знаю как она работает, и знаю, на каком этапе RTOS AM>>начинает давать выигрыш. Потому что я все это пробовал сам, AM>>в отличие от... AM>> Под х51 у меня используется только кооператичная многозадачность.

Обсуждение конкретики самой задачи (работа с датчиками осей и т.п.) непродуктивно, особенно в ключе "C+RTOS" vs "ASM+foregroud/background". У всех своя правда :) Теперь для тех, кого не надо агитировать за советскую власть - хотелось бы понять сухой остаток флейма - какой инструментарий "C+RTOS" зарекомендовал себя c Keil-овским C51 ? Как вести отладку с RTOS ? Если через monitor, то как это делать если UART занят под приложение ? Есть технология отладки через CAN ?

AM> Под х51 у меня используется только кооператичная многозадачность.

S> "C+RTOS" зарекомендовал себя c Keil-овским C51 ?

Использование под х51 вытесняющей многозадачности - невыгодно. Функции нужны реентерабельные - а это для х51 большие накладные расходы. Кооперативная же многозадачноть не облегчает жизнь на столько, на сколько бы этого хотелось. Но если ее достаточно, то написть ее не так сложно, как вытесняющую. Примеры в и-нете есть. Я в свое время пробовал несколько кооперативных многозадачек, типа Nilsen NESOS

Конкртено тот проект для х51, который я описывал был реализован на ОС Дмитрия Обухова Compact Real-Time kernel (CRTK), которая лежала на его сайте (который уже давно исчез с того места, где был :), как и сам Дмитрий уже несколько лет здесь не появляется.

S> Как вести отладку с RTOS ?

Да в общем то также, как и обычных проектов. Некоторые ОС интегрируют в себя средства отладки. Например uCOS-II включает в себя некоторые средства, позволяющие делать отладку и вытаскивать в отладочный порт данные (os_view для ucos-ii например).

S> Если через monitor, то как это делать если UART занят под приложение ? S> Есть технология отладки через CAN ?

Наверное есть. Я для отладки CAN не использовал, по причине наличия UART.

"Maxim Polyanskiy" <Maxim snipped-for-privacy@p12.f.n5020.z2.fidonet.org>

сообщил/сообщила в новостях следующее: news:MSGID_2=3A5020=2F887.12=40Fidonet snipped-for-privacy@fidonet.org...

ничего не Это почему это? Или ты полагаешь что я и еще наверное тысяча человек ненормальный? Справку в студию.

Да какая разница? Может поломаться? Может. И тогда - см. выше. ДМРВ кстати массово и не дохнет, на японках по крайней мере.

Еще раз: при поломке чего-либо без чего, хоть и плохо, но можно ехать нормальная машина должна пердеть, коптить но ехать, а не вставать, пользуясь твоей надуманной логикой. Что кстати нормальные машины и делают.

Денис.