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

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

Hа халяву -- за электричество. Денег платить не надо. И откуда цифра 15 ты обосновать, по видимости, не можешь. А она определяется соотношением времени потраченного на исполнение собственно задачи, ко времени затраченному на исполнение ядра. В реальных ОС это что-то порядка единиц процентов. Сам должен понимать, что с

15-кратным превышением времени-в-ядре над временем-в-задаче такая ОС никому задаром не нужна...

MP> Все датчики заводятся на входы пинов автомата CAPTURE. Прерываниям по MP> событиям MP> CAPTURE назначается высший приоритет. Вся логика счета вагонов - внутри MP> этих

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

Reply to
Kirill Frolov
Loading thread data ...

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.

Reply to
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.

Reply to
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, Юрий.

Reply to
Yuriy K

Hello, Dennis!

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

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

Reply to
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. ;)

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

1) Есть безстыковые пути 2) Системы контроля по правилам не устанавливаются напротив стыка. 3) ... но это уже совсем другая история и здесь оффтопик.

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> на метр в тележке всяко не меньше полутора метров между осями.

1.85 - в грузовых, 2.4 - в пассажирских.

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> Какие-то у тебя вечно сферические задачи...

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

Reply to
Andy Mozzhevilov

Привет, *Maxim*!

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

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

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

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

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

[кусь]
Reply to
Andrey Solomatov

"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. тут однако из треда филиал карза получается я однако свернусь пока модератор не увидел, а то потом больно будет.

Reply to
Dennis Opanasenko
09 Feb 04, Andy Mozzhevilov пишет Sergey:

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

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

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

Reply to
Denis Sotchenko

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.

Reply to
Maxim Polyanskiy

Hello Maxim.

11 Feb 04 02:36, you wrote to Kirill Frolov:

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

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

Alexey

Reply to
Alexey Boyko

Hello, Alexey!

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

Reply to
Maxim Polyanskiy

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

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

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

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

Reply to
Andy Mozzhevilov

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