=AlexD= (24.02.2010 16:19, просмотров: 168) ответил bialix на простой текстовый вывод -- это реальная проблема. у UART ограниченная пропускная способность.Это моё личное предвзятое мнение. Любое совпадение с реальностью является случайным и непреднамеренным.
-
- общей картины уже и я не вижу. для меня логирование соприкасается с областью телеметрии, когда дивайс сыпет не просто текст, а состояние некоторых своих параметров. простое текстовое логирование как раз легче анализировать глазами, тут не автоматизируешь bialix(114 знак., 24.02.2010 16:35)
- В моем представлении логирование и телеметрия несколько разные вещи. Логирование больше нацелено на события, произошедшие в девайсе, на возникающие ошибки. А телеметрия - на происходящие процессы, значения с датчиков, выходы алгоритмов. И fms_2(116 знак., 24.02.2010 17:12,
)
- можно и так считать. однако оба способа служат одной и той же цели: понять что происходит в системе и вокруг неё. вернемся к вашей исходной посылке: как вы видите логирование в МК? И какого класса МК (разраядность/память/быстродействие)? - bialix(24.02.2010 18:26)
- Сейчас работаю с dsPIC с 32 кБ ОЗУ. Но хотелось бы иметь масштабируемый логгер и для более мелких камней (AVR, MSP430) с возможностью вывода по нескольим каналам. Например на данный момент у меня девайс с SD-карой (опционально) и последовательным портом fms(290 знак., 24.02.2010 21:54)
- про телеметрию интересно -- опишите пожалуйста. - bialix(25.02.2010 00:49)
- Для меня стояла задача главным образом унифицировать разбор кадров телеметрии, выполнять отображение данных и сохранение их в файлы. fms(5545 знак., 25.02.2010 14:23 - 26.02.2010 14:52)
- про недостатки расскажите, пожалуйста. понятно что они есть, хотелось бы знать какие они у вас. не для забавы, а для перенимания опыта. - bialix(26.02.2010 16:57)
- Я надеялся, что про недостатки вы мне скажете=) Все-таки со стороны виднее бывает! fms(484 знак., 26.02.2010 19:09)
- я видел похожее решение на ваше, но только там были не xml, а просто конфиг файлы для описания пакетов телеметрии. такое используется в одной из серий контроллеров инжекторного двигателя. у себя я использую подход с маркером типа пакета, например 1й байт bialix(1015 знак., 26.02.2010 20:17)
- А что делать будете, когда все 256 значений маркера "закончатся"?:) - fms(26.02.2010 20:33)
- А кого боимся? :) Я действительно храню описательную часть в устройстве (просто текст) и "умею" писать-читать его через группу из двух MODBUS регистров (счетчик и символ). Просто и удобно. - Скрипач(26.02.2010 19:17)
- Ну в моём случае простым текстом не обойтись, сложно будет графический интерфейс описать!:) Кроме того, я использую готовый fms(488 знак., 26.02.2010 20:13)
- систему визуализации вряд ли имеет смысл запихивать в МК, а вот описание пакетов с данными -- вполне. только не как xml, такое у меня мнение. xml даже хуже текстового формата здесь. хотя для Java -- это нативный формат, но я бы все равно не стал. - bialix(26.02.2010 20:20)
- Ну не такой уж и нативный:) Всё-равно внешние либы использую для преобразования в DOM (встроенные неудобные). Я его из-за GUI-генератора использую, чтобы всё в одном файле было. Мне вот кажется, при разделении описания формата кадров и способа их fms(241 знак., 26.02.2010 20:31)
- я не совсем согласен. если вы задаете формат кадров как описание логических сущностей, то описание GUI может оперировать тоже в терминах логических сущностей. неужто от прошивки к прошивке кардинально меняются эти сущности? мне кажется, что нет. но bialix(263 знак., 26.02.2010 20:37)
- Не всегда бывает прямая связь девайса с приёмником данных. Например, в одной версии я пишу весь поток на SD-карту, используя специальный протокол, а потом программой-декодером считываю и декодирую. В этом случае, декодеру нужно знать формат данных. fms(654 знак., 26.02.2010 21:04)
- по-моему вы сами себя путаете. для этого и нужно понятие формата данных. я уже писал выше: наиболее простой путь -- это однозначная идентификация содержимого кадра/пакета/записи по некоему идентификатору. Следующим вариантом -- иметь описание формата в bialix(94 знак., 27.02.2010 13:00)
- во, это примерно то, о чём я пару недель назад спрашивал, только чуть под другим углом koyodza(709 знак., 26.02.2010 22:24 - 22:28, ссылка)
- Не всегда бывает прямая связь девайса с приёмником данных. Например, в одной версии я пишу весь поток на SD-карту, используя специальный протокол, а потом программой-декодером считываю и декодирую. В этом случае, декодеру нужно знать формат данных. fms(654 знак., 26.02.2010 21:04)
- я не совсем согласен. если вы задаете формат кадров как описание логических сущностей, то описание GUI может оперировать тоже в терминах логических сущностей. неужто от прошивки к прошивке кардинально меняются эти сущности? мне кажется, что нет. но bialix(263 знак., 26.02.2010 20:37)
- Ну не такой уж и нативный:) Всё-равно внешние либы использую для преобразования в DOM (встроенные неудобные). Я его из-за GUI-генератора использую, чтобы всё в одном файле было. Мне вот кажется, при разделении описания формата кадров и способа их fms(241 знак., 26.02.2010 20:31)
- систему визуализации вряд ли имеет смысл запихивать в МК, а вот описание пакетов с данными -- вполне. только не как xml, такое у меня мнение. xml даже хуже текстового формата здесь. хотя для Java -- это нативный формат, но я бы все равно не стал. - bialix(26.02.2010 20:20)
- Ну в моём случае простым текстом не обойтись, сложно будет графический интерфейс описать!:) Кроме того, я использую готовый fms(488 знак., 26.02.2010 20:13)
- я видел похожее решение на ваше, но только там были не xml, а просто конфиг файлы для описания пакетов телеметрии. такое используется в одной из серий контроллеров инжекторного двигателя. у себя я использую подход с маркером типа пакета, например 1й байт bialix(1015 знак., 26.02.2010 20:17)
- Я надеялся, что про недостатки вы мне скажете=) Все-таки со стороны виднее бывает! fms(484 знак., 26.02.2010 19:09)
- про недостатки расскажите, пожалуйста. понятно что они есть, хотелось бы знать какие они у вас. не для забавы, а для перенимания опыта. - bialix(26.02.2010 16:57)
- Для меня стояла задача главным образом унифицировать разбор кадров телеметрии, выполнять отображение данных и сохранение их в файлы. fms(5545 знак., 25.02.2010 14:23 - 26.02.2010 14:52)
- про телеметрию интересно -- опишите пожалуйста. - bialix(25.02.2010 00:49)
- Сейчас работаю с dsPIC с 32 кБ ОЗУ. Но хотелось бы иметь масштабируемый логгер и для более мелких камней (AVR, MSP430) с возможностью вывода по нескольим каналам. Например на данный момент у меня девайс с SD-карой (опционально) и последовательным портом fms(290 знак., 24.02.2010 21:54)
- можно и так считать. однако оба способа служат одной и той же цели: понять что происходит в системе и вокруг неё. вернемся к вашей исходной посылке: как вы видите логирование в МК? И какого класса МК (разраядность/память/быстродействие)? - bialix(24.02.2010 18:26)
- В моем представлении логирование и телеметрия несколько разные вещи. Логирование больше нацелено на события, произошедшие в девайсе, на возникающие ошибки. А телеметрия - на происходящие процессы, значения с датчиков, выходы алгоритмов. И fms_2(116 знак., 24.02.2010 17:12,
- на основе чего делали такой вывод? у вас есть реальные цифры? для мелких МК гемора с текстовым выводом будет на порядок больше, чем тупо выплевывать бинарные данные, а не пропущенные через printf. - bialix(24.02.2010 16:32)
- общей картины уже и я не вижу. для меня логирование соприкасается с областью телеметрии, когда дивайс сыпет не просто текст, а состояние некоторых своих параметров. простое текстовое логирование как раз легче анализировать глазами, тут не автоматизируешь bialix(114 знак., 24.02.2010 16:35)