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

09 Feb 04, Andy Mozzhevilov пишет Sergey:

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

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

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

Hемедленно нажми на RESET, Maxim Polyanskiy!


 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> этих

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

    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.

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

    Hello, Alexey!

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

Hello Maxim,


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

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

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

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

Hello Maxim,

11 Feb 04 02:36, Maxim Polyanskiy wrote to Kirill Frolov:

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

 Ты узко мыслишь. А если мне нужно не 2 сигнала детектировать?
 Если мне нужно восемь сигналов? Предложишь мне восемь процов ставить?
 А если, хуже того, мне нужно детектировать изменяющееся число частот?
 Бегать с паяльником и подпаивать недостающие процы? :-)

 Значит так. Есть такая методика задания уровней приоритетов задач RTOS -
называется пропорциональной диспетчеризацией.


 =Далее цитата из книги по микроСи/ОС-II=


 При этом происходит присвоение задачам приоритетов пропорционально частоте их
выполнения. Делаются следующие допущения:

 1. Все задачи периодичны (происходят регулярно).
 2. Задачи не синхронизированы друг с другом, не разделяют ресурсов,
    и не обмениваются данными.
 3. Процессор всегда выполняет задачу с наивысшим приоритетом,
    то есть должно использоваться ядро вытесняющего типа.


 При этом набора из n задач все требования жесткого реального
 времени выполняются, если соблюдено следующее неравенство:

 Сумма(Ei/Ti)<n(2^^1/n  - 1),
    где Ei - наибольшее время выполнения задачи i
        Ti - период выхода задачи i на процессор

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

 =Конец цитаты из книги по микроСи/ОС-II=

 Так что с пятнадцатикратным превышением ты немного преувеличил.




 Alexander.

    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 Maxim,


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

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

сообщил/сообщила в новостях следующее:

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


любых типов

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


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

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

    Hello, Dennis!

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

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

Привет, *Maxim*!

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


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

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

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

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

[кусь]