Привет bsvi. Подскажи пожалуйста использовал ли ты Altium CircuitStudio 1.0.4 ?? circuitstudio.com/#why Дело в том что ни как не могу понять как преобразовать проект в 3D вид.
Пока у меня нет таких далеко идущих планов, как регистрация моего устройства в госреестре поэтому я не думал о измерении и испытании надежности работы soft-а и hard-а.
Сейчас в SmartPipe предусмотренна возможность выдачи логов от устройства по двум каналам один с фильтрацией так сказать для анализа и второй «на прямую» для архива и уточнения.
Про устройство с SD картой. Вы предлагаете сделать устройство другого типа это устройство-логер для автоматческого сбора логов, которому фильтрация логов действительно не очень нужна, так как предполагается, что вы их будете анализировать целиком для поиска любой особености или бага. А вот если вы там увидете баг, то вы его запостите на разработчика… вот для фикса этого конкретного бага разработчику и может пригодиться SmartPipe, для выделения нужных логов при пересбрках soft-а при попытки воспроизвести и зафиксить баг.
«На что только не идут люди, лишь бы не учить регулярные выражения».
А что касается логических анализаторов и прочих измерительных приборов — их показания должны соответствовать действительности. И все эти измерения проводятся у меня перед глазами. Более того, основная часть используемого мной оборудования внесена в госреестр средств измерений и только поэтому я могу им доверять, как измерительным приборам.
И раз уж вы коснулись темы потери критических импульсов, то у измерительных приборов есть характеристика достоверности результатов измерений — абсолютная или относительная погрешность, указанная в паспорте на прибор. Она может стремиться к нулю, но она НЕ нулевая. т.е. я всегда знаю, с какой достоверностью мне относиться к результатам измерений. Эта наука называется Метрология.
Какую погрешность фильтрации вы можете гарантировать пользователям?
Например 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 не выступает. Эмбеддить в метро больше не призывает. Сходок нет. На форуме кроме тесел — нифига. Война. Короче, печаль-тоска.
tqfp
...разрабатываем электронику вместе
Сейчас в SmartPipe предусмотренна возможность выдачи логов от устройства по двум каналам один с фильтрацией так сказать для анализа и второй «на прямую» для архива и уточнения.
Про устройство с SD картой. Вы предлагаете сделать устройство другого типа это устройство-логер для автоматческого сбора логов, которому фильтрация логов действительно не очень нужна, так как предполагается, что вы их будете анализировать целиком для поиска любой особености или бага. А вот если вы там увидете баг, то вы его запостите на разработчика… вот для фикса этого конкретного бага разработчику и может пригодиться SmartPipe, для выделения нужных логов при пересбрках soft-а при попытки воспроизвести и зафиксить баг.
А что касается логических анализаторов и прочих измерительных приборов — их показания должны соответствовать действительности. И все эти измерения проводятся у меня перед глазами. Более того, основная часть используемого мной оборудования внесена в госреестр средств измерений и только поэтому я могу им доверять, как измерительным приборам.
И раз уж вы коснулись темы потери критических импульсов, то у измерительных приборов есть характеристика достоверности результатов измерений — абсолютная или относительная погрешность, указанная в паспорте на прибор. Она может стремиться к нулю, но она НЕ нулевая. т.е. я всегда знаю, с какой достоверностью мне относиться к результатам измерений. Эта наука называется Метрология.
Какую погрешность фильтрации вы можете гарантировать пользователям?
Например 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 (я просто его не знаю)…