«На что только не идут люди, лишь бы не учить регулярные выражения».
А что касается логических анализаторов и прочих измерительных приборов — их показания должны соответствовать действительности. И все эти измерения проводятся у меня перед глазами. Более того, основная часть используемого мной оборудования внесена в госреестр средств измерений и только поэтому я могу им доверять, как измерительным приборам.
И раз уж вы коснулись темы потери критических импульсов, то у измерительных приборов есть характеристика достоверности результатов измерений — абсолютная или относительная погрешность, указанная в паспорте на прибор. Она может стремиться к нулю, но она НЕ нулевая. т.е. я всегда знаю, с какой достоверностью мне относиться к результатам измерений. Эта наука называется Метрология.
Какую погрешность фильтрации вы можете гарантировать пользователям?
Например UART может внезапно сожрать половину ключевого слова, по которому происходит фильтрация и все, сообщение не попало в лог. При нестабильном тактовом генераторе и некорректной настройке UART это возможно.
Ваш прибор предполагает лежать на столе и втихую фильтровать логи. При работе с устройством, у меня должен быть полный лог-файл, из которого можно достать либо то, либо другое.
Лучше добавьте в ваше устройство SD-карту, поддержку записи лога с устройства на эту карту автономно — с питанием от исследуемого устройства, а со стороны USB обеспечьте возможность чтения этой SD-карты, желательно в виде внешнего накопителя.
Такое устройство будет полезно, в том числе и мне, когда к автономному устройству можно подключить такой самописец на пару тройку суток, а потом на компьютере обработать данные.
Я здесь предлагаю рассмотреть вопрос использования SmartPipe как инструмента.
Вопрос реализации (прошивка микроконтроллера и далее по тексту) я уже решил.
Мне кажеться что написать правила для SmartPipe будет проще чем писать реглуярные выражения в grep/sed… да grep/sed намного мощнее и универсальнее но это не всегда надо ИМХО.
Ну «абсолютно любой мыслемой и немыслемой ситуации» конечно в правилах для SmartPipe описать нельзя — но наиболее полезные случаю для анализа логов я пытаюсь охватить, что не будет — можно будет добавить в последствии.
По поводу «открытости» — вы же используете логический анализатор soft для которого придумали американцы а железку спаяли китайцы… и вас обычно не сильно беспокоит что они могут терять критические импульсы… например. Не вижу разницы с SmartPipe.
Вы таки хотите сказать, что разработать прошивку для микроконтроллера, которая будет поддерживать загрузку набора правил фильтрации логов, программу для создания конфига, содержащего набор правил фильтрамии логов, и утилиты, которая будет загружать результат работы программы по созданию конфига, содержащего набор правил по фильтрации логов будет ПРОЩЕ, чем воспользоваться grep/sed?
я и коллеги выше не можем понять именно этого момента.
Вы еще не забывайте, что ваша цепочка должна поддерживать создание абсолютно любой мыслимой и немыслимой ситуации в логах. Если что-то не будет поддерживаться вашей железкой — то цепочку придется переписывать.
Кроме того, данное устройство является MITM, и если его исходники не будут открыты, то пользоваться им я не могу, так как он не может гарантировать, что при модификации логов (а именно этим он занимается, будем называть вещи своими именами) не будут изменяться критически важные сообщения.
Ну дебаг левлел обычно дает очень много информации не нужной тебе в данный момент, а отключить все ненужное это еще то «квест» (хотя бы потому что ты сначала должен знать что не нужно ;)). Заганять это все в файл и натравливать grep/sed, писать регулярные выражения и тд. — тоже очень утомително, если приходиться пересобирать soft много раз… а если ты фиксиш баг — то полюбому прийдется.
Например баг: в один из пяти раз куда-то не приходит сообщение.
Конечно тебе повезет если в функции отправки этого сообщение стоит просто rand… но в реальной жизни тебе прийдется анализировать очень большой лог чтоб уловить связи в soft-e и поймеш ты эти связи далеко не сразу а с так 20+ итерации. И работать через файл/grep/sed быстро устанешь (конечно если ты не гуру bash/grep/sed/регулярных выражений и прочих esc-последовательностей).
Можно провести аналогию с операцией по «закрутке шрупа». Для «закрутке шрупа» можно использовать:
ответку (в нашем случае анализировать лог глазами);
дрель (файл/grep/sed);
или специальное устройство — шуруповерт
Первые два способа вполне работоспособны — ведь закручивали же люди шурупы до шуруповертов :)
Дак, можно этот лог направить в файлик и после этого смотреть разные дебаг левелы. А если дебаг левел задать сразу, то ядро придется пересобирать просто чтобы посмотреть лог с разными левелами или разной подсветкой.
Единственный плюс — уменьшение времени передачи данных. Передача по UARTу действительно, периодически тормозит. Беда в том, что тормоз в деле анализа логов не принимающая сторона, а передающая.
Думаю, что проблем с доставкой в Украину быть не должно. Это зависит от конкретного Интернет-магазина и почты. По крайней мере я недавно заказывал книгу в обратную сторону — из Украины в Россию — посылка пришла быстро и без каких-либо проблем. А так последите, может в DiaMail книги появятся или отправьте заявку в DiaMail, как увидите, что книги появились в других Интернет-магазинах — можете ощутимо сэкономить на доставке, хотя цена самой книги в DiaMail может быть значительно выше, ну и плюс непредсказуемые скачки курсов валют, поэтому надо считать, где в конкретный момент выгоднее заказать. Если из России, то, возможно, выгоднее сразу несколько книг заказать, чтобы стоимость доставки меньше влияла на конечную цену книг.
А ещё лучше задайте вопрос в блоге ген. директора издательства Вильямс, будет ли книга продаваться в DiaMail, а лучше — просьбу, чтобы издательство знало о вашей потребности.
Честно говоря, не очень понял что такое «не прочувствовал»… Могу порекомендовать только, включить логи при сборке ядра Linux / DirectFB или чего-то подобного и оценить «глубину» проблемы анализа этого лога и поиска в нем информации.
Мне кажется мы говорим о разных сценариях отладки. Ваш сценарий применим, когда устройство уже «в поле» так сказать и вам просто надо исследовать лог который пользователь прислал вам на почту. Я же говорю о сценарии поиска бага, когда вам необходимо включать разные уровни логирования, добавлять свои логи, комментировать куски кода и тд. и так большое количество раз… в этом случаем постоянно сохранять лог в файл и натравливать на него grep/sed/excel достаточно утомительно по сравнению скажем с подсветкой всех логов которые вы добавили на последней итерации отладки… конечно это просто вопрос удобства и привычки… но когда что-то пресобираешь 20+ раз хочется как то упростить технологию
Мягко говоря не вижу смысла… Гораздо удобнее разобрать логи на ПК… Там хоть форматируй, хоть в эксель закидывай…
Может я чего-то не понял? Я обычно быстренько набрасывал программку на C# которая визуализировала мне все данные со стрелочками, графиками и прочими свистоперделками… А еще есть LabView (я просто его не знаю)…
Отличная новость!В марте будет допечатан малым тиражом (200 экз.) первый том «Конструирование высокоскоростных цифровых устройств: начальный курс черной магии», Говард В. Джонсон, Мартин Грэхем двухтомника «Конструирование высокоскоростных цифровых устройств». Книга в типографии. Делимся комментариями по этому поводу на соответствующей странице блога генерального директора издательства Вильямс.
Спасибо. Но всё равно скучно. BSVi не выступает. Эмбеддить в метро больше не призывает. Сходок нет. На форуме кроме тесел — нифига. Война. Короче, печаль-тоска.
А теперь возьми какой-нибудь полевик не шибко мощный, и ткни прозвонкой сток-затвор, а потом исток-сток, а потом то же самое в обратной полярности. Всё прекрасно откроется и закроется. На то он и полевик, что открывается полем, напряжение вторично.
Гы, сталкивался с этим. Делал по работе мощную переключалку на 200 ампер на автомобильных транзисторах AUIRF3004WL. При отключении транза выбросы на таких токах ацкие. Решил резать их супрессором. Поставил «супермощные» 5-ти киловаттные 5KP15CA. Сгорели в первую же секунду. А тонюсенькие SA30 хоть и сильно грелись, но выбросы на 150 герцах сдерживали. Вот такой парадокс.
Я 5KP15CA распилил, там толщенный слой пластика, наверное из-за этого теплообмен был плохой (хотя… они же рассчитаны на гашение одиночных выбросов, а не серии). А SA30 из-за своей тонкости тепло отдавали нормально.
Сейчас стоят 1.5KE15CA, две штуки последовательно. Греются, но не сильно.
tqfp
...разрабатываем электронику вместе
А что касается логических анализаторов и прочих измерительных приборов — их показания должны соответствовать действительности. И все эти измерения проводятся у меня перед глазами. Более того, основная часть используемого мной оборудования внесена в госреестр средств измерений и только поэтому я могу им доверять, как измерительным приборам.
И раз уж вы коснулись темы потери критических импульсов, то у измерительных приборов есть характеристика достоверности результатов измерений — абсолютная или относительная погрешность, указанная в паспорте на прибор. Она может стремиться к нулю, но она НЕ нулевая. т.е. я всегда знаю, с какой достоверностью мне относиться к результатам измерений. Эта наука называется Метрология.
Какую погрешность фильтрации вы можете гарантировать пользователям?
Например UART может внезапно сожрать половину ключевого слова, по которому происходит фильтрация и все, сообщение не попало в лог. При нестабильном тактовом генераторе и некорректной настройке UART это возможно.
Ваш прибор предполагает лежать на столе и втихую фильтровать логи. При работе с устройством, у меня должен быть полный лог-файл, из которого можно достать либо то, либо другое.
Лучше добавьте в ваше устройство SD-карту, поддержку записи лога с устройства на эту карту автономно — с питанием от исследуемого устройства, а со стороны USB обеспечьте возможность чтения этой SD-карты, желательно в виде внешнего накопителя.
Такое устройство будет полезно, в том числе и мне, когда к автономному устройству можно подключить такой самописец на пару тройку суток, а потом на компьютере обработать данные.
Вопрос реализации (прошивка микроконтроллера и далее по тексту) я уже решил.
Мне кажеться что написать правила для SmartPipe будет проще чем писать реглуярные выражения в grep/sed… да grep/sed намного мощнее и универсальнее но это не всегда надо ИМХО.
Ну «абсолютно любой мыслемой и немыслемой ситуации» конечно в правилах для SmartPipe описать нельзя — но наиболее полезные случаю для анализа логов я пытаюсь охватить, что не будет — можно будет добавить в последствии.
По поводу «открытости» — вы же используете логический анализатор soft для которого придумали американцы а железку спаяли китайцы… и вас обычно не сильно беспокоит что они могут терять критические импульсы… например. Не вижу разницы с SmartPipe.
Вы таки хотите сказать, что разработать прошивку для микроконтроллера, которая будет поддерживать загрузку набора правил фильтрации логов, программу для создания конфига, содержащего набор правил фильтрамии логов, и утилиты, которая будет загружать результат работы программы по созданию конфига, содержащего набор правил по фильтрации логов будет ПРОЩЕ, чем воспользоваться grep/sed?
я и коллеги выше не можем понять именно этого момента.
Вы еще не забывайте, что ваша цепочка должна поддерживать создание абсолютно любой мыслимой и немыслимой ситуации в логах. Если что-то не будет поддерживаться вашей железкой — то цепочку придется переписывать.
Кроме того, данное устройство является MITM, и если его исходники не будут открыты, то пользоваться им я не могу, так как он не может гарантировать, что при модификации логов (а именно этим он занимается, будем называть вещи своими именами) не будут изменяться критически важные сообщения.
троллейбус-буханка.jpg.to/
Например баг: в один из пяти раз куда-то не приходит сообщение.
Конечно тебе повезет если в функции отправки этого сообщение стоит просто rand… но в реальной жизни тебе прийдется анализировать очень большой лог чтоб уловить связи в soft-e и поймеш ты эти связи далеко не сразу а с так 20+ итерации. И работать через файл/grep/sed быстро устанешь (конечно если ты не гуру bash/grep/sed/регулярных выражений и прочих esc-последовательностей).
Можно провести аналогию с операцией по «закрутке шрупа». Для «закрутке шрупа» можно использовать:
ответку (в нашем случае анализировать лог глазами);
дрель (файл/grep/sed);
или специальное устройство — шуруповерт
Первые два способа вполне работоспособны — ведь закручивали же люди шурупы до шуруповертов :)
Единственный плюс — уменьшение времени передачи данных. Передача по UARTу действительно, периодически тормозит. Беда в том, что тормоз в деле анализа логов не принимающая сторона, а передающая.
Вообщем, смысла мало вижу :(
А ещё лучше задайте вопрос в блоге ген. директора издательства Вильямс, будет ли книга продаваться в DiaMail, а лучше — просьбу, чтобы издательство знало о вашей потребности.
Может я чего-то не понял? Я обычно быстренько набрасывал программку на C# которая визуализировала мне все данные со стрелочками, графиками и прочими свистоперделками… А еще есть LabView (я просто его не знаю)…
Я 5KP15CA распилил, там толщенный слой пластика, наверное из-за этого теплообмен был плохой (хотя… они же рассчитаны на гашение одиночных выбросов, а не серии). А SA30 из-за своей тонкости тепло отдавали нормально.
Сейчас стоят 1.5KE15CA, две штуки последовательно. Греются, но не сильно.