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