/var/www/tqfp.org/templates/compiled/bsvi/0d05b75eab3b2725749144bfae7199a59edeab1e_0.file.profile_top.tpl.php on line 35
Warning: Attempt to read property "value" on null in /var/www/tqfp.org/templates/compiled/bsvi/0d05b75eab3b2725749144bfae7199a59edeab1e_0.file.profile_top.tpl.php on line 35
">
Warning: Attempt to read property "value" on null in /var/www/tqfp.org/templates/compiled/bsvi/0d05b75eab3b2725749144bfae7199a59edeab1e_0.file.profile_top.tpl.php on line 35
">
Рейтинг
+0.52
Сила
1.43
trapper
Сергей
Мне кажеться что SmartPipe и автономный логгер это все таки принципиально разные устройства. Логгер должен собирать ВСЕ логи и только потом на компьютере к его диску можно подключить SmartPipe для облегчения анализа этого лога. Да и входной интерфейс у логгера какой-нибудь RS-485.
Насчет запилить самому… необязательно даже DualCDC можно просто взять пример виртуального COM- порта из ST и добавить туда фильтрацию. Но «дьявол» в мелочах… как вы будете менять правила? как хранить правила? как обрабатывать ошибки при вводе правила и работе системы? и тд… Да можно все решать перепрошивкой и изменением кода. Вот только врядли это будет удобно даже вам, для отладки сложного проекта правила надо менять очень часто и для этого каждый раз пересобирать и перепрошивать «инструмент» (вылавливая и фикся свои ошибки на ходу) очень неудобно. Польза от такокого проекта только гордость и опыт — тут я согласен это можно получить только от своего проекта. Эти бонусы SmartPipe не предоставляет :)
А есди вы преодалеете все трудности то у вас и получится свой SmartPipe, как он получился у меня… вот правда у меня он получился далеко не за вечер.
Насчет сложности настройки… да в современном мире «визуального программирования» такая проблема имеется, но как сделать проще пока не знаю.
Я тоже по началу любил делать сам USB-Serial адаптеры(на FT232), Jtag-отладчики и тд. а не покупать, но когда мои амбиции выросли а проекты «подросли», мне стало не интересно этим заниматься и уже логический анализатор и нормальный JTAG-отладчик я покупал.
Я совершенно уверен, что достаточно просто сделать какую-нибудь «поделку», которая раскрашивает логи и пользоваться которой может только разработчик (так получаеться из-за того, что цель разработки — «раскрасить логи» достигнута, а довести проект до ума требует много нудной и неинтересной работы). Именно поэтому пользоваться вы ей не будете, так как это не инструмент а скорее прототип инструмента, а когда перепрошьете «дискавери» на что-то другое то и забудете зачем это надо было (у меня у самого таких «проектов» навалом).
Вообщем мне кажеться, что инструменты надо покупать, а не делать… но это конечно кому как нравиться :).
Да, пока проект планируется с закрытым исходным кодом… но возможно, что это обычные предрассудки и в конце концов коммерциализация будет производиться по схеме BusPirate например.
В любом случае «тревога по поводу фильтрации» скорее проблема доверия — вряд ли вы будете копаться в 300K+ байтах кода если он будет открыт. Плюс(а при «раскрученном» проекте скорее минус), когда код закрыт — я за него отвечаю, когда открыт уже нет.
Вот дорабатывать напильником все таки прийдется… по крайней мере они мне прислали корпус без вырезов, хотя контур для mini-usb явно просматривается.
Собираюсь договориться чтоб они сделали вырезы когда буду новую партию заказывать.
Сейчас в SmartPipe предусмотренна возможность выдачи логов от устройства по двум каналам один с фильтрацией так сказать для анализа и второй «на прямую» для архива и уточнения.
Про устройство с SD картой. Вы предлагаете сделать устройство другого типа это устройство-логер для автоматческого сбора логов, которому фильтрация логов действительно не очень нужна, так как предполагается, что вы их будете анализировать целиком для поиска любой особености или бага. А вот если вы там увидете баг, то вы его запостите на разработчика… вот для фикса этого конкретного бага разработчику и может пригодиться SmartPipe, для выделения нужных логов при пересбрках soft-а при попытки воспроизвести и зафиксить баг.
Вопрос реализации (прошивка микроконтроллера и далее по тексту) я уже решил.
Мне кажеться что написать правила для SmartPipe будет проще чем писать реглуярные выражения в grep/sed… да grep/sed намного мощнее и универсальнее но это не всегда надо ИМХО.
Ну «абсолютно любой мыслемой и немыслемой ситуации» конечно в правилах для SmartPipe описать нельзя — но наиболее полезные случаю для анализа логов я пытаюсь охватить, что не будет — можно будет добавить в последствии.
По поводу «открытости» — вы же используете логический анализатор soft для которого придумали американцы а железку спаяли китайцы… и вас обычно не сильно беспокоит что они могут терять критические импульсы… например. Не вижу разницы с SmartPipe.
Например баг: в один из пяти раз куда-то не приходит сообщение.
Конечно тебе повезет если в функции отправки этого сообщение стоит просто rand… но в реальной жизни тебе прийдется анализировать очень большой лог чтоб уловить связи в soft-e и поймеш ты эти связи далеко не сразу а с так 20+ итерации. И работать через файл/grep/sed быстро устанешь (конечно если ты не гуру bash/grep/sed/регулярных выражений и прочих esc-последовательностей).
Можно провести аналогию с операцией по «закрутке шрупа». Для «закрутке шрупа» можно использовать:
ответку (в нашем случае анализировать лог глазами);
дрель (файл/grep/sed);
или специальное устройство — шуруповерт
Первые два способа вполне работоспособны — ведь закручивали же люди шурупы до шуруповертов :)