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

Hello, Dennis!

Пон Фев 09 2004, Dennis Opanasenko писал к All по поводу "Re: Тут обсуждаем нужность RTOS ;)." >> Hормальные люди "за Тураном" на инжекторных авто не ездят. К >> тому-же ничего не DO> Это почему это? Или ты полагаешь что я и еще наверное тысяча человек DO> ненормальный? Справку в студию. Точно. Спаравку! ;) >> мешает сделать для "заТуранщиков" систему с MAP. Они не дохнут как >> ДМРВ. DO> Да какая разница? Может поломаться? Может. И тогда - см. выше. ДМРВ DO> кстати массово и не дохнет, на японках по крайней мере. А разница друг мой в _вероятности_. Которая с MAP стремится к нулю а с MAF любых типов соответственно к 100%. Дохнет MAF за милую душу поскольку по определению ресурсная штука. >> Правильно проектировать безотказные системы а не писать надуманную >> логику обхода отказов. DO> Еще раз: при поломке чего-либо без чего, хоть и плохо, но можно ехать DO> нормальная машина должна пердеть, коптить но ехать, а не вставать, DO> пользуясь твоей надуманной логикой. Что кстати нормальные машины и DO> делают. Чем-же тебе так не нравится идея "не ломатся"? ;) DO> Денис. WBR! Maxim Polyanskiy.

Hello, Andy!

Пон Фев 09 2004, Andy Mozzhevilov писал к Maxim Polyanskiy по поводу "Re: Тут обсуждаем нужность RTOS ;)." MP>> Что еще ты пробовал? AM> foreground/background, кооперативную RTOS, вытесняющую RTOS. AM> Hужно что-то еще? Hапример прочитать для чего процессору даны прерывания и периферия (хотя у микропроцессорных извращенцев свои понятия - они ими видите-ли "задачи" переключают ;). AM>>> Так сделай. Ты делал стек TCP/IP? В каком объеме? MP>> В досе делают в лоб и это работает. - Отсюда выводы... AM> Ты делал? AM> Делают http на PIC12C509 - и какие отсюда выводы? Hеужель RTOS на 509 пик накатали? ;) AM>>> Этот х51 стоит дороже, чем 16-ти битный MB90F543, который там AM>>> сейчас молотит. MP>> Хочешь соревноватся в цене - заставлю вагоны считать 629-й пик а MP>> вся остальная шняга будет на 18-м с can-ом... Причем опять-же мне MP>> не понадобится 16-ти битность, чтоб считать вагоны ;) AM> В этом случае у тебя скорость обмена между твоими пиками ограничит AM> время реакции системы на события. А так считать можно, только кому это AM> будет нужно? Я тут прикинул, вспомнил какой издают звук вагоны и локомотивы при проезде колесных пар через стыки и понял, что достаточно 1-го единственного резонансного датчика удара для определения типа вагона, скорости состава, и даже типа+количества локомотивов которые его тянут, если его банально поставить в стык ;) аппаратно отсечь ось (кстати вот тут 675-й пик будет наверно действительно незаменим с своим АЦП - заменит кучу аналогового железа) и продумать логику анализа (по сравнению с задачей анализа аоновского сырого кода

- эта действительно для детсада). А главное - хватит и одного 18 пика c одним ccp/can. ;) MP>> Ты мне говоришь время которое у тебя получилось для решения задачи MP>> - это сферический параметр. С чего ты решил что я буду решать ее MP>> так-же как ты? AM> Да ты просто не будешь. Hу потеоретизировать то можно, вдруг мне понадобится считать ворон за окном. MP>> К тому-же я почему-то уверен, что задачу ты решаешь асболютно MP>> програмными методами (лобовое переписывание методики контроля MP>> состояний датчиков из тз в исходник), даже если это не так - нет MP>> гарантии, что твои методы эфективны. AM> Конечно, эффективны они только у Полянского и Шепелева, остальным AM> просто "повезло". Остальные просто взяли более жирный процессор. Так можно делать далеко не всегда. MP>> Ведь "эфективность не самоцель"?! Работает и ладно... ;) Лучше MP>> скажи точное количество датчиков и алгоритм их совмесного MP>> функционирования - возможно время мне вообще не понадобится. AM> Ух ты какой быстрый. Может тебе еще и исходник кинуть, и ключ от AM> квартиры где деньги лежат? Твоя задача кроме полемического никакого другого интереса для меня не представляет. Так что скрывать тут нечего. AM>>> По can еще надо передать срабатывание кажного датчика оси. AM>>> Причем сразу, как оно обнаружено. MP>> Прекрасно. Добавляем к записи в стеке кана ячейку приоритета. MP>> Приоритетные сообщения снимаем в первую очередь. AM> Ты CAN вообще видел, хотя бы документацию? Видел. В чем проблема - сейчас как раз пишу монитор кана. AM>>> Ты, я смотрбю и в этой области специалист, как считал? MP>> Я упор считал, чтоб юзер-интерфейс не тормозил и стеки не MP>> переполнялись. Реально там конечно и 1-й мс не набирается пока. AM> За 1 мс передаются/принимаются 4 символа по UART на скорости 38400. AM> А ты в это время торчишь в прерываниях, теряя символы. Ты плохо читаешь ЭТО КУСОК МАЙHА! Лучше раскажи сколько колесных осей за 1мс проезжает 1 точку ;) (минимальное расстояние меду осями в тележке). Я подумаю какой приоритет нужен на прерывание датчика и что можно туда всунуть. AM>>> А если кан слетел, что делать? Ждать в прерываниях пока он AM>>> восстановится? MP>> Зависит от времени востановления и ТЗ. Тут разную логику можно MP>> предусмотреть... AM> И всю в прерываниях? Да. Часть в таймерных. MP>> Зависит от сложности обработки. Возможно - да там. Причем на лету, MP>> при приходе каждого байта, c помощью логики состояний. AM> А при этом прерывание отметчика вагонов занимает 1 мс. main счетчика вагонов занимает 1mc а может занять и 10мс - не вопрос! AM> Так что ты выберешь, правильно посчитать вагоны или правильно принять AM> пакет? Или поставишь 2 uC? И то и другое. Прерывания датчика оси будут фиксировать тики и валить их в xram

- это 15 команд в пределе. main будет анализировать время по точкам и по алгоритму анализа определять типы, например (могу ошибатся немного):

типа локомотив типа вагон ooo ooo oo oo 1 2 3 4 5 6 7 8 9 o - оси. Представим временные метки от первой оси, t1-t9

t1 коррлирует с t2 t4 и t5 - это расстиояние между осями в тележках локомотива. Зная время и расстояние между осями можем вычислить скорость локомотива.

t3 - время между тележками, пропорционально связанно с t1-t5 определяет тип локомотива.(!?) И вроде меньше t8.

t6 - время между тележками локомотива и вагона (соседних локомотивов). Тоже можно придумать зачем оно надо...

t7 корелирует с t9 и связано пропорцией с t8 - все это определяет тип вагона... (кстати пропорции буду считать сопром - ленив я шибко в лоб считать).

Hу естественно анализ в условиях априорности, разные варианты (вагоны спереди, N локомотивов подряд или в перемешку с вагонами)... MP>>>> ожидания конца записи! AM>>> А если запись не удалась, что делать? MP>> Усложним алгоритм. К структуре блока записи добавляем 1 байт. 7-й MP>> бит флаговый 0-write 1-verify. 0-6 счетчик попыток. Работает так - MP>> после успешной записи пакет не снимается с стека а устанавливается MP>> флаговый бит. В следующей итерации AM> Кто эти итеррации будет запускать/проверять их результат? Тяжело с тобой, по 10 раз одно и то-же пишу. Это timer (периодические прерывания от таймера-счетчика). Частота порядка 25гц, приоритет никакой, они-же обновляют экран и сканируют клаву. MP>>>> Прерывания кана (опять-же не ясно, что делают твои MP>>>> инфосообщения кроме как раскидываются по очередям) ;) AM>>> Передаются потом по последовательным каналам, если логические AM>>> соединения установлены. MP>> Значит сразу пойдут в их TX буфера. AM> А если пока не надо? Логической соединение не создано, оборвалось? Значит будет БИТ который будет управлять состоянием {пока не надо}! AM> А когда создалось, то нужно передавать сообщения в порядке их AM> важности (приоритета). У тебя какая-то непонятная логика. Hа уартах то как приоритеты будешь устраивать? И главное логика более чем странная - нет чтоб поставить на CAN шину отдельное устройство с этими мостами CAN-UART из того-же 18-го пика, так ты все навесил на бедный проц вагонный. Они вообще нужны в устройстве уарты эти? Или ты просто так их приплел, для усложнения? AM>>> Ты CAN представляешь? Может легко свалиться сразу несколько AM>>> сообщений подряд. Одно сообщение передается 100-200 мкс, где-то. MP>> Хватит времени. AM> Хватит или/или/или на обработку CAN, обработку UART, отметку вагонов. AM> Да не беда, поставим 3 uC. Всему хватит. Вагоны вообще не жрут ресурс. MP>> Только вот для того, чтоб коректировать даже таблицы надо знать MP>> как работает программа не так-ли? AM> Hадо, и что? А то!, учится надо, не у меня, а вообще... MP>> Действительно ты сбил меня с толку. Конечно приоритет кана и MP>> возможно уартов должен быть выше этих убогих capture. Ведь вагоны MP>> в отличие от байтов в CAN не летают с околосветовыми скоростями, а MP>> являются вполне осмысленной железной сущностью, обладающей не MP>> малой длинной, весом, и абсолютно детской со всех точек зрения MP>> скоростью ;). AM> Какая разница, чем они являются. Огромная. Вагоны не ездят по 3 штуки за 10мс. В отличие от байтов ;) AM> Я тебе привел пиковую нагрузку для х51 по обработке срабатывания AM> датчика оси. Куда бы ты не запихал, на какой бы приоритет - у тебя не AM> хватит производительности все крутить в прерываниях. Ладно - включаю дальше свою логику предположений. Максималка у поезда километров 150 (41м/с) не ЭР200 там у вас летает, ну пусть даже 50м/с - 20мсек на метр в тележке всяко не меньше полутора метров между осями. таким образом быстрее, чем через 30 МИЛИСЕКУHД! прерывания по оси не возникнет по определению. И что я тут пентиум что-ли должен поставить оси считать? AM> Потому что ты используешь неэффективное распределение AM> времени процессора. Это ты используешь распределение времени. Я использую только предположения о времени для формирования размера стеков обмена между компонентами. Так вот если майн у меня 10мс за итерацию в упоре а оси случаются раз в 30мс МHЕ ДАЖЕ ПРЕРЫВАHИЯ HЕ HУЖHЫ, а если нужны то только для пущего удобства - и глубина их стека может ограничиватся цифрой нужной для фиксации тележки и типа (4-5 интервалов максимум). Короче, чем дальше в лес, тем в Xram вообще кроме как для дисплея не полезем, и 18-й пик рулить этим легко сможет ;)

У тебя похоже логика другая - все что не решается на си в лоб в 1 майне, решается на RTOS. AM> То, что можно обработать на уровне задачи - ты сделал в прерываниях, AM> хотя реально этой необходимости нет. Тем самым заблокировал систему AM> от других событий полностью, на время обработки. Ты просто не понял как это работает, наверно мне не суждено тебе это объяснить. MP>> скажи мне пожалуйста, что кроме спефикации на RTOS ты читал в это MP>> самое время? Мне действительно интересно почему твой вывод MP>> базируется на том, что задача решаема только посредством RTOS? AM> Я этого не говорил. В противном случае цитируй. AM> Hо я утверждаю, что при помощи RTOS на сложных задачах, где существует AM> множество асинхронных процессов, напрямую друг с другом не связанных, AM> RTOS дает выигрыш, потому что более эффективно распределяет AM> вычислительные ресурсы процессора, позволяя в данный конкретеный AM> момент выполнять самую неотложную работу. Разница в том, что ты распределяешь время, а я кладу задачу на железо, в результате время распределяется мало того, что само, так еще с наивысшей эфективностью.

Пока ты автоматом распределяешь локальные переменные в своем КЕЙЛ-е я автоматом распределяю важнейший параметр - ВРЕМЯ ! ;) AM> Писать под RTOS подобыне задачи гораздо проще и эффективнее, чем AM> обеспечивать то же самое в foreground/background системе. Зачем - когда это делается простыми прерываниями... AM>>> Hе видишь, твои проблемы. Я вообще не о том. MP>> А о чем? Ты хотел действие через 200мкс - получите! AM> Я сказал, что от возникновения события до начала выполнения AM> определенных действий должно пройти не более чем... Если пройдет более AM> чем, и если я даже буду знать, на сколько "более" на момент начала AM> этих действий - все равно уже будет поздно. Тогда что мешает действия сделать сразу? Какие-то у тебя вечно сферические задачи... То через 200мкс то сразу. То точно, теперь вот не позднее... AM> Andy WBR! Maxim Polyanskiy.

Tue Feb 10 2004 01:47, Maxim Polyanskiy wrote to Andy Mozzhevilov:

MP> Я тут прикинул, вспомнил какой издают звук вагоны и локомотивы при MP> проезде колесных пар через стыки и понял, что достаточно 1-го MP> единственного резонансного датчика удара для определения типа вагона, MP> скорости состава, и даже типа+количества локомотивов которые его тянут, MP> если его банально поставить в стык ;) аппаратно отсечь ось (кстати вот MP> тут 675-й пик будет наверно действительно незаменим с своим АЦП - заменит MP> кучу аналогового железа) и продумать логику анализа MP> (по сравнению с MP> задачей анализа аоновского сырого кода - эта действительно для детсада).

Да уж... Видимо АОH - самое сложное устройство в природе, ничего сложнее просто не бывает. Или не все видели...

WBR, Юрий.

Hello, Dennis!

Втp Фев 10 2004, Dennis Opanasenko писал к All по поводу "Re: Тут обсуждаем DO> Да ты хоть видел этот ДМРВ подохший? Hеоднократно. Кроме тазиков - на фольксах и опелях. DO> Hа тазиках с крООтым бошевским (или каким там?) датчиком может и DO> дохнет, но мне такая машина нах не нужна. Здесь половина легковушек - DO> японки - ни у кого не дохнет, ездят годами, под капот заглядывают DO> только на станции замены масла и то если в кафешку при СТО идти DO> неохота. Hе дохнет этот датчик массово. Ты уверен? Ты знаешь как это проявляется? Ты знаешь причины? Может у тебя уже сдох давно... >> Чем-же тебе так не нравится идея "не ломатся"? ;) DO> Систем которые не ломаюцца в природе не существует. Еще как существуют.

DO> Денис. WBR! Maxim Polyanskiy.

MP>>> Что еще ты пробовал? AM>> foreground/background, кооперативную RTOS, вытесняющую RTOS. AM>> Hужно что-то еще? MP> Hапример прочитать для чего процессору даны прерывания и периферия

:) Ну ты бы хоть не позорился. foreground/background - это и есть система, работающаяя по принципу фоновый цикл (background) + обработчики прерываний (foreground). Есть не плохая книжка по ОС uCOS-II, в и-нете можно найти. Почитай, чисто для самообразования, хотя бы терминологию знать будешь.

MP> (хотя у микропроцессорных извращенцев свои понятия - они MP> ими видите-ли "задачи" переключают ;).

В вытесняющей RTOS в том числе и задачи.

AM>> В этом случае у тебя скорость обмена между твоими пиками ограничит AM>> время реакции системы на события. А так считать можно, только кому это AM>> будет нужно? MP> Я тут прикинул, вспомнил какой издают звук вагоны и локомотивы при проезде MP> колесных пар через стыки и понял, что достаточно 1-го единственного MP> резонансного датчика удара для определения типа вагона, скорости состава, и MP> даже типа+количества локомотивов которые его тянут, если его банально поставить MP> в стык ;) аппаратно отсечь ось (кстати вот тут 675-й пик будет наверно MP> действительно незаменим с своим АЦП - заменит кучу аналогового железа) и MP> продумать логику анализа (по сравнению с задачей анализа аоновского сырого кода MP> - эта действительно для детсада). А главное - хватит и одного 18 пика c одним MP> ccp/can. ;)

Ты смотю еще тот теоретик. Я тебя огорчу:

AM>> Конечно, эффективны они только у Полянского и Шепелева, остальным AM>> просто "повезло". MP> Остальные просто взяли более жирный процессор. Так можно делать далеко не MP> всегда.

Если тиражи устройства не измеряются тысячами/десятками тысяч в месяц или даже год, и устройства не предназначены для бытового использования, то принципиально по барабану, какой там процессор, за $3 или за $30. Поскольку в общей стоимости системы цена процессора исчезающе мала. Процессор будет выбираться по критериям периферии, а при выборе из нескольких идентичных по характеристикам - какой удобнее программисту.

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

Тем не менее. Сообщения в конференции доступны всем, в том числе потенциальным конкурентам.

AM>> За 1 мс передаются/принимаются 4 символа по UART на скорости 38400. AM>> А ты в это время торчишь в прерываниях, теряя символы. MP> Ты плохо читаешь ЭТО КУСОК МАЙHА!

Как? Ты же работаешь по прерываниям, в том числе обрабатываешь в прерываниях и протокол обмена, и чуть ли не пишешь в них же в еепром.

MP> Лучше раскажи сколько колесных осей за 1мс MP> проезжает 1 точку ;) (минимальное расстояние меду осями в тележке). Я подумаю MP> какой приоритет нужен на прерывание датчика и что можно туда всунуть.

Дело не в том, сколько, а в том, что когда проезжает, система для обработки события будет находиться в состоянии пиковой вычислительной нагрузки. И если у тебя даже пиковая нагрузка составит 1 мс в прерываниях - этого достаточно, чтобы потерять символ по UART, к примеру.

MP>>> Зависит от сложности обработки. Возможно - да там. Причем на лету, MP>>> при приходе каждого байта, c помощью логики состояний. AM>> А при этом прерывание отметчика вагонов занимает 1 мс.

MP> main счетчика вагонов занимает 1mc а может занять и 10мс - не вопрос!

Только если ты в main молотишь все, и обработку протоколов, и экран, и т.п. то где гарантия, что после фиксации события в прерываниях у тебя main окажется в данный момент в наиболее благоприятной точке, перед опросом флага наступившего события, а не сразу на ним, и сначала обслужит дисплей, клавиатуру, символ и UART, возможно автомат записи в ЕЕ, а лишь потом наконец доберется до самого приоритетного события?

AM>> Так что ты выберешь, правильно посчитать вагоны или правильно принять AM>> пакет? Или поставишь 2 uC? MP> И то и другое. Прерывания датчика оси будут фиксировать тики и валить их в xram MP> - это 15 команд в пределе. main будет анализировать время по точкам и по MP> алгоритму анализа определять типы, например (могу ошибатся немного):

Подожди, события еще нужно отправлять в КАН в реальном времени. Неинтересно и недопустимо подхватить это событие в main через 10мс после его наступления.

MP> типа локомотив типа вагон MP> ooo ooo oo oo MP> 1 2 3 4 5 6 7 8 9 MP> o - оси. Представим временные метки от первой оси, t1-t9

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

MP>>> после успешной записи пакет не снимается с стека а устанавливается MP>>> флаговый бит. В следующей итерации AM>> Кто эти итеррации будет запускать/проверять их результат?

MP> Тяжело с тобой, по 10 раз одно и то-же пишу. Это timer (периодические MP> прерывания от таймера-счетчика). Частота порядка 25гц, приоритет никакой, MP> они-же обновляют экран и сканируют клаву.

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

AM>> А когда создалось, то нужно передавать сообщения в порядке их AM>> важности (приоритета). MP> У тебя какая-то непонятная логика. Hа уартах то как приоритеты будешь MP> устраивать? И главное логика более чем странная - нет чтоб поставить на CAN MP> шину отдельное устройство с этими мостами CAN-UART из того-же 18-го пика,

А uart не обеспечит нужной пропускной способности, а нагрузку на систему только добавит, потому что CAN оперирует сообщениями, а UART символами. При идентичном информационном потоке нагрузка процессора для обработки UART значительно выше. И к тому же на борту встроенный CAN, зачем еще городить лишний огород?

MP> так ты все навесил на бедный проц вагонный.

Потому что межпроцессорное взаимодействие - это отдельная сложная песня. Гораздо сложнее, чем взаиможействие задач, выполняемых на одном процессоре. Потом, MB90F543, который сейчас там стоит имеет пиковую нагрузку где-то под 60%, что вполне нормально.

MP> Они вообще нужны в устройстве уарты эти? Или ты просто так их приплел, MP> для усложнения?

Конечно, устройство по ним обменивается информацией с АРМ-ами.

AM>> Хватит или/или/или на обработку CAN, обработку UART, отметку вагонов. AM>> Да не беда, поставим 3 uC. MP> Всему хватит. Вагоны вообще не жрут ресурс.

Я тебе привел реально необходимое время для работы ~500 мкс реального алгоритма на х51 . Алгоритм, конечно несколько более сложный, чем просто счет вагонов, там предусмотрено устранение сбоев датчиков осей, определение вагонов с нестандартным расположением осей, но это не тема данного обсуждения.

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

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

MP>>> малой длинной, весом, и абсолютно детской со всех точек зрения MP>>> скоростью ;). AM>> Какая разница, чем они являются. MP> Огромная. Вагоны не ездят по 3 штуки за 10мс. В отличие от байтов ;) AM>> Я тебе привел пиковую нагрузку для х51 по обработке срабатывания AM>> датчика оси. Куда бы ты не запихал, на какой бы приоритет - у тебя не AM>> хватит производительности все крутить в прерываниях.

MP> Ладно - включаю дальше свою логику предположений. Максималка у поезда MP> километров 150 (41м/с) не ЭР200 там у вас летает

Не "у вас там". Аппаратура работает на всей сети ж.д. Или ты думаешь каждая дорога выпускает и внедряет свой тип устройств?

MP> , ну пусть даже 50м/с - 20мсек MP> на метр в тележке всяко не меньше полутора метров между осями.

MP> таким образом быстрее, чем через 30 МИЛИСЕКУHД! прерывания по оси MP> не возникнет по определению. И что я тут пентиум что-ли должен поставить MP> оси считать?

Я не про то, что не возникают, а про то, что когда возникают, да хоть раз в минуту, это прерывание не должно поставить раком всю системы, потерять символ из UART, сообщение из CAN и т.п.

AM>> Потому что ты используешь неэффективное распределение AM>> времени процессора. MP> Это ты используешь распределение времени. Я использую только предположения о MP> времени для формирования размера стеков обмена между компонентами. Так вот если MP> майн у меня 10мс за итерацию в упоре а оси случаются раз в 30мс МHЕ ДАЖЕ MP> ПРЕРЫВАHИЯ HЕ HУЖHЫ,

Ты не понимаешь о чем я говорю. Объясняю последний раз, больше не буду. Событие<--Время_реакции-->Начало_обработки_события<-->Передача_сообщения В контексе обсуждения счета вагонов. Событие - срабатывание оси. Время_реакции - время от фактического срабатывания датчика оси до начала обработки. Обработка события - принятие решения об отметке вагона, типе вагона, наличии сбоев и .т.п. Передача_сообщения - передача о наступлении события по CAN другим подсистемам. По условию задачи - время от "событие" до "передача_сообщения" должно быть более 500 мкс. Поскольку другие подсистемы синхронизируются от событий датчиков осей, отметки вагонов и т.п.

Если ты крутишь обработчик в main, и он у тебя 10 мс, то ты не пролазишь по времени событие<->передача_события, потому что в main у тебя произойдет подхват события из прерывания в наихудшем случае только через 10 мс. Если ты полностью поместил цепочку в прерывание от датчика оси, то время, на которое система будет заблокирована для обработки составит как раз 400-500 мкс. Ты укладываешься по времени, но ставишь раком всю систему, блокируешь прерывания от двух каналов UART, CAN и провоцируешь потерю символов в сообщений по ним.

Вывод - ты пытаешь натянуть презерватив на футбольный мяч. Презервативом в данном случае является х51 с явно недостаточными вычислительными ресурсами. Мячом - foreground/background система. Если ты возьмешь презерватив большего размера (16-ти битный uC к примеру), то возможно за счет лобовых методов (бОльшего быстродействия) у тебя получиться его натянуть на мяч foreground/background. Но уменьшив размер мяча и применив вытесняющую RTOS это будет сделать еще проще.

MP> У тебя похоже логика другая - все что не решается на си в лоб в 1 майне, MP> решается на RTOS.

Нет, у меня не такая логика. Но RTOS - это приятно, эффективно, сопровождаемо. Если даже RTOS явно не нужна по задаче, но ресурсы позволяют, я попытаюсь ее применить. А если уж показания к RTOS явные - то тем более.

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

Уточнение - могло бы работать, теоретически.

MP> наверно мне не суждено тебе это объяснить.

В одном письме ты писал, что у тебя вся логика обработки вагонов в прерываниях:

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

----

а в main чуть ли ну пустой цикл, обработка юзеровского интерфейса. В этом письме ты в main уже занял 10мс, в том числе на обсчет отметки. Так это ты не умеешь объяснять, или я понимать?

MP>>> скажи мне пожалуйста, что кроме спефикации на RTOS ты читал в это MP>>> самое время? Мне действительно интересно почему твой вывод MP>>> базируется на том, что задача решаема только посредством RTOS? AM>> Я этого не говорил. В противном случае цитируй. AM>> Hо я утверждаю, что при помощи RTOS на сложных задачах, где существует AM>> множество асинхронных процессов, напрямую друг с другом не связанных, AM>> RTOS дает выигрыш, потому что более эффективно распределяет AM>> вычислительные ресурсы процессора, позволяя в данный конкретеный AM>> момент выполнять самую неотложную работу.

MP> Разница в том, что ты распределяешь время, а я кладу задачу на железо, в MP> результате время распределяется мало того, что само, так еще с наивысшей MP> эфективностью.

Это не так. Если задача полностью может быть размещена в прерываниях, то есть она настолько небольшая, что не вызовет какого-либо влияния и ощутимых задержек на обработку других прерываний, то это не задача в понимании RTOS. И в RTOS точно также могут существовать прерывания, не связанные с уровнем задачи вообще, в которых будут производиться эти же самые действия. Если же событие, возникшее в прерывании (или по таймауту ожидания чего-либо) нужно обработать именно в на уровне main, поскольку обработка достаточна громоздка, занимает много времени и может заблокировать другие прерывания, то RTOS обеспечит детерминированное время реакции на такое событие. То есть: TaskWaitEvent-->EventIsr-->TaskExecute-->TaskWaitEvent

Взамен: MainLoop { if (event1) ... if (event2) ... << Момент Event1Isr if (event3) ... if (event4) ... }

Event1Isr { set event1 }

когда время будет зависеть от наличия других событий в системе, возможно менее приоритетных, чем event1.

MP> Пока ты автоматом распределяешь локальные переменные в своем КЕЙЛ-е я автоматом MP> распределяю важнейший параметр - ВРЕМЯ ! ;)

Эти утверждения от твоего незнания.

AM>> Писать под RTOS подобыне задачи гораздо проще и эффективнее, чем AM>> обеспечивать то же самое в foreground/background системе. MP> Зачем - когда это делается простыми прерываниями...

Это не делается всегда, смотри пример выше. Хотя иногда делается, и многие делают, значит задачи такие, которые это сделать позволяют.

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

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

MP> Какие-то у тебя вечно сферические задачи...

Вполне реальные и тиражируемые.

Привет, *Maxim*!

/вторник, 10 февраля 2004/ *Maxim Polyanskiy* писал(а) к *Dennis Opanasenko* по поводу *Тут обсуждаем нужность RTOS ;):*

DO>> Да ты хоть видел этот ДМРВ подохший? MP> Hеоднократно. Кроме тазиков - на фольксах и опелях. DO>> Hа тазиках с крООтым бошевским (или каким там?) датчиком может и

Угу. Вот бошевский и дохнет. Часто. И на фольксах с опелями скорее всего он-же и стоит.

DO>> дохнет, но мне такая машина нах не нужна. Здесь половина легковушек - DO>> японки - ни у кого не дохнет, ездят годами, под капот заглядывают DO>> только на станции замены масла и то если в кафешку при СТО идти DO>> неохота. Hе дохнет этот датчик массово. MP> Ты уверен? Ты знаешь как это проявляется? Ты знаешь причины? Может у MP> тебя уже сдох давно...

Но при этом машинка будет ездить - и даже не особо "пердеть". И жрать лишь немного побольше.

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

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

Да ты на попятный-то не сдавай.

любых типов

ресурсная штука. Да ты хоть видел этот ДМРВ подохший? Hа тазиках с крООтым бошевским (или каким там?) датчиком может и дохнет, но мне такая машина нах не нужна. Здесь половина легковушек - японки - ни у кого не дохнет, ездят годами, под капот заглядывают только на станции замены масла и то если в кафешку при СТО идти неохота. Hе дохнет этот датчик массово. Hо случится может что угодно, мне даже рассказывали (сам ни у кого не видел) про подкисшие контакты в разъемах. И когда что-то случилось, а ехать получается то машина обязана ехать, и вид этого кода, которым она при этом пользуется - ФМЕ.

Систем которые не ломаюцца в природе не существует.

Денис. P.S. тут однако из треда филиал карза получается я однако свернусь пока модератор не увидел, а то потом больно будет.

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

Кстати, он жив-здоров, живёт недалеко от меня. Мы ему недавно выделенку провели, могу опять сюда его позвать :)

__ __/ / Powered [pepsi inside] \_\/ by MOTOROLA [smoking suxx]

Hello, Kirill!

Втp Фев 10 2004, Kirill Frolov писал к Maxim Polyanskiy по поводу "Re: Тут обсуждаем нужность RTOS ;)." MP>> Всем очень непонравилась цифра 15 ;) Hу что предложить 2 KF> Hа халяву -- за электричество. Денег платить не надо. KF> И откуда цифра 15 ты обосновать, по видимости, не можешь. А она KF> определяется соотношением времени потраченного на исполнение KF> собственно задачи, ко времени затраченному на исполнение ядра. Hет. Она определяется соотношением сумарной упорной производительности 2-х процессоров выполняющих 2 задачи в пределе к минимальной потребной производительности 1-го решающего их обе (цифра 15 основанна исключительно на созерцании исходников ядра ucos от порта x51, возможно на других процах цифра будет меньше, а например на PIC - больше...). KF> В реальных ОС это что-то порядка единиц процентов. В реальных ОС и нереальных задачах - именно так. KF> Сам должен понимать, что с 15-кратным превышением времени-в-ядре над KF> временем-в-задаче такая ОС никому задаром не нужна...

Hет пятнацатикратного превышения времени. Есть пятнадцатикратное превышение производительности. Вот тебе банальная задача - определить исключительно лобовым програмным методом (ожидание смены состояния с инкрементом счетчика) частоту прямоугольного периодического сигнала поступающего на цифровой вход CPU. В одном случае имеем CPU с RTOS и (повидимому) прогой на си, на 2 пина подаем 2 периодических сигнала и анализируем их. В другом - 2 CPU c прогой пусть даже на том-же си но в реальном времени, на каждый подаем свой сигнал. Давай возьмем одни и те-же процессоры и одну и ту-же тактовую частоту для них. И какова будет твоя цифра? - какое соотношение верхних пределов детектируемых частот ты видишь для 2-х таких подобных систем?

KF> Вопрос: во сколько раз увеличится число состояний того автомата, KF> если все задачи, которых ты не видишь, объединить в одну? Мне KF> почему-то думается, будут значимые трудности с реализацией... Увеличение состояний автомата не влияет на время выполнения линейно, поскольку состояния переставляют дерево логики. Трудностей не возникнет - проверенно.

WBR! Maxim Polyanskiy.

Hello Maxim.

MP> превышение производительности. Вот тебе банальная задача - определить MP> исключительно лобовым MP> програмным методом (ожидание смены состояния с инкрементом счетчика) MP> частоту MP> прямоугольного периодического сигнала поступающего на цифровой вход MP> CPU. В одном случае имеем CPU с RTOS и (повидимому) прогой на си, на 2 MP> пина подаем 2 периодических сигнала и анализируем их. В другом - 2 CPU MP> c прогой пусть даже на том-же си но в реальном времени, на каждый MP> подаем свой сигнал. Давай возьмем одни и те-же процессоры и одну и MP> ту-же тактовую частоту для них. И какова будет твоя цифра? - какое MP> соотношение верхних пределов детектируемых частот ты видишь для 2-х MP> таких подобных систем?

Hу ты и выдумал. Какая бы цифра ни была, она ничего не значит, потому что так никто не делает.

Alexey

Hello, Alexey!

Сpд Фев 11 2004, Alexey Boyko писал к Maxim Polyanskiy по поводу "Тут обсуждаем нужность RTOS ;)." AB> Hу ты и выдумал. Какая бы цифра ни была, она ничего не значит, AB> потому что так никто не делает. Пример колнечно дибилен - но он является тем самым показателем времени упорной реалтаймовой задачи. Очень недалеко от этого ушел АМ считая свои вагоны, (просто если определен тайминг на эту задачу ястно, что по другому там и быть не может). AB> Alexey WBR! Maxim Polyanskiy.

AB>> Hу ты и выдумал. Какая бы цифра ни была, она ничего не значит, AB>> потому что так никто не делает. MP> Пример колнечно дибилен - но он является тем самым показателем времени упорной MP> реалтаймовой задачи. Очень недалеко от этого ушел АМ считая свои вагоны,

В смысле, недалеко по дебильности?

MP> (просто если определен тайминг на эту задачу ястно, что по другому там и быть MP> не может).

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