caxapa.ru :: Фиксировать все надо по максимуму. В пределах возможного. Если есть UART - ок. Но я рассматриваю ситуацию, когде его нет принципиально. В первый раз зафиксировали какие именно ошибки были. Потом память пожно перерасределить

Evgeny_CD, Архитектор (13.01.2008 21:37, просмотров: 273) ответил rezident на А вам важен только сам факт фиксации ошибки? Время и сопутствующие условия не интересуют?

Фиксировать все надо по максимуму. В пределах возможного. Если есть UART - ок. Но я рассматриваю ситуацию, когде его нет принципиально. В первый раз зафиксировали какие именно ошибки были. Потом память пожно перерасределить - те ошибки, которых нет - не логим. А высвободившуюся память используем для детального лога оставшихся ошибок.

Ответить

- Т.е. если ошибка данного типа зафиксирована, то уже не интерсует ее повторяемость? Что за тип прибора в котором вы собрались таким образом регистрировать ошибки? И главное, ошибки чего? Программы или ее взаимодействия с внешними объектами? - rezident(13.01.2008 21:50)
  - Радиосеть. Нетривиальная. Когда я отлаживаю токо один мастер и один слейв (начало проекта) - нормальныая отладка. Но когда я поставил на прогон сеть из сотни девайсов - я буду рад хотя бы битовым фактам ошибок, вместо одного глобального бита - сеть Evgeny_CD(12 знак., 13.01.2008 21:54)
    - вообще говоря, ошибки в радиосетях отлавливаются аппаратно-программными снифферами. Представляю, сколько вам нужно будет времени, чтобы считать эти логи из сотни-другой девайсов, а потом осмыслить результаты (если они будут) и найти закономерность... - Gamma SPb(13.01.2008 22:20)
      - Нет никаких предпосылок думать, что много. "Вкалывают роботы". А аппаратно-программные сниферы оставим для тех, у кого лишнего бабла много. Evgeny_CD(841 знак., 13.01.2008 22:28)
        
        =)))) Евгений, речь как раз о том, сколько времени займет считывание лога из мешка девайсов и заливки исправленной прошивки. А про логгеры - ну уж не надо. Это делается на том же радиоканале + ПК за довольно быстрый срок. Gamma SPb(116 знак., 13.01.2008 22:37, ссылка)
        
        кстати, по поводу количества бабла, позволю себе процитировать =) Gamma SPb(384 знак., 13.01.2008 22:52, ссылка)
        
        Один мАААААААААхонький нюанс есть. Если Вы делаете 1001 клон ZigBee, то снифер Вы можете купить. Если Вы делаете специфичный для задачи протокол (например, потому что ZigBee в данном случае не канает), то разработка снифера = решению основнойзадачи. - Evgeny_CD(13.01.2008 23:51)
        
        ну здрасте... сниффер не должен раздавать адреса и не должен обеспечивать маршрутизацию. он должен просто собирать пакеты. А по поводу канает/не канает - сейчас огромное количество open source протоколов для мелких сетей, начиная от Gamma SPb(138 знак., 14.01.2008 00:02)
        
        Согласен насче сбора. Но он еще и декодировать всю шнягу в эфире должен. А это сложнее. Насчет готовых систем - в общем, верно, но в частности - нет. В данном случае речь идет о custom решении с предельными параметрами, которые в любой универсальной Evgeny_CD(35 знак., 14.01.2008 00:08)
        
        простите, а ХYли там декодировать? пакет разобрать? - Gamma SPb(14.01.2008 00:52)
        
        Угу. И еще самую малость - декодировать состояния конечных автоматов внутри протокола. - Evgeny_CD(14.01.2008 00:59)
        
        "Я тибе адын умный вестч скажу..." Без снифера отлаживать сеть (любую) - это полный капздец. И никакие битовые логеры тебе не помогут. Чаще всего ошибки - в реализации машины состояний (очень трудно сразу учесть все нюансы) =AlexD=(624 знак., 14.01.2008 08:42)
        
        Убедили, что снифер булет рулез! Насчет "где-то есть глюк" - не совсем так. В предложенном мною примере есть 1000 "контрольных точек". Для проекта 10к строк маркер в каждой десятой строке. И "где-то" можно вычислить довольно подоробно. - Evgeny_CD(14.01.2008 10:47)
        
        Да, НО =AlexD=(524 знак., 14.01.2008 11:54)
        
        Засад масса, категорически согласен. Я всего лишь изначально изложил очень экономичную методолгию кодинга системы мониторинга, с мнимумом ручной работы. Может, что аналогичное есть, дабы опылиться идеями оттуда? - Evgeny_CD(14.01.2008 11:57)
        
        Да я не против сжатия в один бит сообщения типа "Error command for a current state" в один бит для автономного девайса. Это очевидная идея, хотя не факт, что лучшая. Но называть это "изящная идея по отладке систем" слишком громко. - =AlexD=(14.01.2008 12:12)
        
        Да бог с ней, с силой звука :) Я просто предложил один из вариантов с максимальной автоматизацией кодинга и обработки результатов. - Evgeny_CD(14.01.2008 12:31)
        
        Если ошибок мало, а вариантов ошибок много, гораздо информативнее и оптимальнее по памяти не выставление битов ошибки, а лог ошибки в виде списка их номеров(возможно с привязкой к времени, состоянию и пр.). - =AlexD=(14.01.2008 12:16)
        
        Согласен. Осталось придумать способ автоматического формирования соотвуствующей программной структуры. Типа расставляешь метки в коде - вот тут хочу пологить. Потом прикидывашь, сколько осталось памяти, и выбираешь способ логгинга в каждой точке. Ну Evgeny_CD(22 знак., 14.01.2008 12:34)
        
        Блин, ты двинулся на этих внешних тулзах. Препроцессор или шаблон сделают всё в лучшем виде. - =AlexD=(14.01.2008 12:46)
        
        Может, и есть чуток :) Но это локальное возмущение. Если серьезно, то я чувствую (поа еще не сделал в реале), что сравнительно простыми средствами можно получить качественно новый результат. В С шаблоны не завезли, так что без внешней Evgeny_CD(41 знак., 14.01.2008 13:14)
        
        +1, причем писать все это во флешу, если "размер добавленного исходника мало волнует". Потому как при ресете контроллера, например, если exeption по невыровненному адресу не обрабатывается хитро все структуры Евгения страртап обнулит =))) - Gamma SPb(14.01.2008 12:24)
        
        Да, я согласен, что SPI|I2C EEPROM сильно улучшит пользу от любых методов отладки :). If их пожно юзать - вопросов нет. - Evgeny_CD(14.01.2008 12:29)
        
        при чем тут SPI/I2C? Во внутреннюю флешу - Gamma SPb(14.01.2008 12:31)
        
        Ну и туда можно. If дырка не протрется, и место в ней есть :) - Evgeny_CD(14.01.2008 12:35)
        
        так на место вроде начхать... "Или нет?"(C) И с чего она должна протереться - вы собираетесь всю жизнь туда писать? надо-то всего один буфер под страницу и всего делов... - Gamma SPb(14.01.2008 12:42)
        
        С другой стороны, в силу дешевизны тестируемого девайса (одиночного) его можно признать расходным материалом. Идея принимается :)))) Спасибо! Вы продвинули меня. - Evgeny_CD(14.01.2008 12:44)
        
        ваш принцип подразумевает вопрос "есть или нет". А это однозначно assert или if_else_. Добавьте к вашему коду еще 1000-2000 строк. - Gamma SPb(14.01.2008 10:58)
        
        Собственно, я описал некий "битовый assert". Это нормальный assert, токо ему в качестве второго параметра передается "номер испытания". Эти номера проставляются автоматически, как я говорил, тулзой. И каждому номеру соответсвует бит в структуре. -> - Evgeny_CD(14.01.2008 12:08, ссылка, ссылка)
        
        Размер добавленного исходника меня мало волнует. Важно, сколько тактов проца будет тратиться на каждую контрольную точку, и сколько памяти надо под лог. За это и воюем. - Evgeny_CD(14.01.2008 11:03)
        
        я где то написал про размер? - Gamma SPb(14.01.2008 11:04)
        
        Интересно, а каким снифером Вы собрались отлавливать, что радиополе разное в разных точках? И что в точке стояния снифера была ошибка в эфире, а в других местах она где была, где - нет? - Evgeny_CD(13.01.2008 22:51)
        
        радиополе в сетках это неуловимый Джо, которого никто не ловит. Знаете почему? Нормальные трансиверы имеют MAC уровень, и даже если нет - при чем тут ошибка эфира? вы кого собираетесь логать, железо или свой софт, я так и не понял... - Gamma SPb(13.01.2008 22:55)
        
        или таким способом вы и канальный уровень своего проекта отлаживать собираетесь? мама родная... - Gamma SPb(13.01.2008 22:56)
        
        Я хочу получить предельно простой и экономичный способ stand alone логгинга. - Evgeny_CD(13.01.2008 23:52)
      - Ну да. Особенно, если фиксация ошибки не привязана к каким-либо временным меткам, то закономерностей можно вообще не найти. - rezident(13.01.2008 22:25)
        
        Если программа состоит из одних ошибок - отлаживать ее в 100 экземплярах глупо. Когда дожали, важно понять - какие именно ошибки позникают. А потом можно память переспределить, и записать - когда именно возникли. - Evgeny_CD(13.01.2008 22:29)
    - К сожалению, опыта отладки работы больших (>7 устройств) сетей и радиосетей у меня нет. Но, по-моему, большинство ошибок все же можно найти и в сети из двух-трех устройств. Особенно, если мастер всего один. - rezident(13.01.2008 22:05)
      - Имею в виду найти ошибки в маленькой сети до того, как объединять ее в большую. - rezident(13.01.2008 22:07)
        
        Разумеется, все, что можно отладить "на столе", так и отлаживается. Я всего лишь предложил способ для мониторнга редко проявляющихся глюков. - Evgeny_CD(13.01.2008 22:13)
- все бы хорошо, но что бы искать ошибки, нужно знать где =) И это как раз самое сложное. А так, имхо, - велосипед с моторчегом ("некая утилита, например на Пытоне") - Gamma SPb(13.01.2008 21:43)
  - Если обнаружен факт, что процессор прошелся по такой-то ветви программы, хотя он тут не должен ходить - дальше токо BRAIN.SYS поможет. - Evgeny_CD(13.01.2008 21:45)
    - Евгений, поставьте на homepage страничку по ссылке Gamma SPb(302 знак., 13.01.2008 22:24, ссылка)
      - Я не претендую, что изобрел лог :) Я предложил сделать его компактным, и удобным в работе. Насчет вложености цать функций - так от стиля программизма зависит. Для коммуникционных протоколов важнее отлавливать отдельные состояния state machine. А это Evgeny_CD(55 знак., 13.01.2008 22:34)

Средства и методы разработки