Ну в каком-то виде безусловно поместится, например если не подключать стандартные С библиотеки и все работу со строками и другие «вкусности» писать самому.
Учитывая что мелких быстрых контроллеров с >64Кб как-то не видно то тут на этом не сэкономиш.
Мне кажеться что SmartPipe и автономный логгер это все таки принципиально разные устройства. Логгер должен собирать ВСЕ логи и только потом на компьютере к его диску можно подключить SmartPipe для облегчения анализа этого лога. Да и входной интерфейс у логгера какой-нибудь RS-485.
Ну может и лишнее, что-то я тоже стал в диске сомневаться… с другой стороны его всегда можно отключить а так help, драйвера всегда подрукой не надо в инете искать…
Писалось как обычно на С. Но вы конечно понимаете что кроме основного кода надо еще где-то правила хранить, код загрузчика для обновления ПО плюс в устройстве огранизован USB диск для help-а, драйверов и тд. Так что 512КВ еще хватает но уже не так и много.
Мне надо было три функции: по больше частота, ОЗУ > 64Кб, Flash > 512КБ. Камень с такими характеристиками да еще и 48-и ногий «в пределах моей досягаемости» я не нашел.
Да цена больше, где-то пятнадцать-двадцать баксов… меньше не позволяют маленькие объемы производства — тут до китайцев на всем далеко.
Насчет запилить самому… необязательно даже DualCDC можно просто взять пример виртуального COM- порта из ST и добавить туда фильтрацию. Но «дьявол» в мелочах… как вы будете менять правила? как хранить правила? как обрабатывать ошибки при вводе правила и работе системы? и тд… Да можно все решать перепрошивкой и изменением кода. Вот только врядли это будет удобно даже вам, для отладки сложного проекта правила надо менять очень часто и для этого каждый раз пересобирать и перепрошивать «инструмент» (вылавливая и фикся свои ошибки на ходу) очень неудобно. Польза от такокого проекта только гордость и опыт — тут я согласен это можно получить только от своего проекта. Эти бонусы SmartPipe не предоставляет :)
А есди вы преодалеете все трудности то у вас и получится свой SmartPipe, как он получился у меня… вот правда у меня он получился далеко не за вечер.
Насчет сложности настройки… да в современном мире «визуального программирования» такая проблема имеется, но как сделать проще пока не знаю.
Да, я согласен, что основной «контингент» для этого устройства «разработчики+». И обычно такие разработчики делают что-то свое и не хотят отвлекаться на изготовление «инструментов» так сказать.
Я тоже по началу любил делать сам USB-Serial адаптеры(на FT232), Jtag-отладчики и тд. а не покупать, но когда мои амбиции выросли а проекты «подросли», мне стало не интересно этим заниматься и уже логический анализатор и нормальный JTAG-отладчик я покупал.
Я совершенно уверен, что достаточно просто сделать какую-нибудь «поделку», которая раскрашивает логи и пользоваться которой может только разработчик (так получаеться из-за того, что цель разработки — «раскрасить логи» достигнута, а довести проект до ума требует много нудной и неинтересной работы). Именно поэтому пользоваться вы ей не будете, так как это не инструмент а скорее прототип инструмента, а когда перепрошьете «дискавери» на что-то другое то и забудете зачем это надо было (у меня у самого таких «проектов» навалом).
Вообщем мне кажеться, что инструменты надо покупать, а не делать… но это конечно кому как нравиться :).
Без проблем, но когда это будет я не знаю… заказ с доработкой должен быть крупным, так что пока до этого дойдет пока не знаю. Стоили мне эти корпуса 1$. Позиции для светодиодов на корпусах видны, но так как в моей конструкции они не предусмотрены то делать их не буду.
SmartPipe поддерживает «выдачу» логов по двум каналам (если надо) один фильтрованный, один нет. К тому же все зависит от правил, которые пользователь задал. Например если вы задали только покрасить самые интересные для вас логи в красный цвет, то вы получите абсолютно полный лог просто некоторые строки будут подкрашены.
Да, пока проект планируется с закрытым исходным кодом… но возможно, что это обычные предрассудки и в конце концов коммерциализация будет производиться по схеме BusPirate например.
В любом случае «тревога по поводу фильтрации» скорее проблема доверия — вряд ли вы будете копаться в 300K+ байтах кода если он будет открыт. Плюс(а при «раскрученном» проекте скорее минус), когда код закрыт — я за него отвечаю, когда открыт уже нет.
Пока у меня нет таких далеко идущих планов, как регистрация моего устройства в госреестре поэтому я не думал о измерении и испытании надежности работы soft-а и hard-а.
Сейчас в SmartPipe предусмотренна возможность выдачи логов от устройства по двум каналам один с фильтрацией так сказать для анализа и второй «на прямую» для архива и уточнения.
Про устройство с SD картой. Вы предлагаете сделать устройство другого типа это устройство-логер для автоматческого сбора логов, которому фильтрация логов действительно не очень нужна, так как предполагается, что вы их будете анализировать целиком для поиска любой особености или бага. А вот если вы там увидете баг, то вы его запостите на разработчика… вот для фикса этого конкретного бага разработчику и может пригодиться SmartPipe, для выделения нужных логов при пересбрках soft-а при попытки воспроизвести и зафиксить баг.
Я здесь предлагаю рассмотреть вопрос использования SmartPipe как инструмента.
Вопрос реализации (прошивка микроконтроллера и далее по тексту) я уже решил.
Мне кажеться что написать правила для SmartPipe будет проще чем писать реглуярные выражения в grep/sed… да grep/sed намного мощнее и универсальнее но это не всегда надо ИМХО.
Ну «абсолютно любой мыслемой и немыслемой ситуации» конечно в правилах для SmartPipe описать нельзя — но наиболее полезные случаю для анализа логов я пытаюсь охватить, что не будет — можно будет добавить в последствии.
По поводу «открытости» — вы же используете логический анализатор soft для которого придумали американцы а железку спаяли китайцы… и вас обычно не сильно беспокоит что они могут терять критические импульсы… например. Не вижу разницы с SmartPipe.
Ну дебаг левлел обычно дает очень много информации не нужной тебе в данный момент, а отключить все ненужное это еще то «квест» (хотя бы потому что ты сначала должен знать что не нужно ;)). Заганять это все в файл и натравливать grep/sed, писать регулярные выражения и тд. — тоже очень утомително, если приходиться пересобирать soft много раз… а если ты фиксиш баг — то полюбому прийдется.
Например баг: в один из пяти раз куда-то не приходит сообщение.
Конечно тебе повезет если в функции отправки этого сообщение стоит просто rand… но в реальной жизни тебе прийдется анализировать очень большой лог чтоб уловить связи в soft-e и поймеш ты эти связи далеко не сразу а с так 20+ итерации. И работать через файл/grep/sed быстро устанешь (конечно если ты не гуру bash/grep/sed/регулярных выражений и прочих esc-последовательностей).
Можно провести аналогию с операцией по «закрутке шрупа». Для «закрутке шрупа» можно использовать:
ответку (в нашем случае анализировать лог глазами);
дрель (файл/grep/sed);
или специальное устройство — шуруповерт
Первые два способа вполне работоспособны — ведь закручивали же люди шурупы до шуруповертов :)
Честно говоря, не очень понял что такое «не прочувствовал»… Могу порекомендовать только, включить логи при сборке ядра Linux / DirectFB или чего-то подобного и оценить «глубину» проблемы анализа этого лога и поиска в нем информации.
Мне кажется мы говорим о разных сценариях отладки. Ваш сценарий применим, когда устройство уже «в поле» так сказать и вам просто надо исследовать лог который пользователь прислал вам на почту. Я же говорю о сценарии поиска бага, когда вам необходимо включать разные уровни логирования, добавлять свои логи, комментировать куски кода и тд. и так большое количество раз… в этом случаем постоянно сохранять лог в файл и натравливать на него grep/sed/excel достаточно утомительно по сравнению скажем с подсветкой всех логов которые вы добавили на последней итерации отладки… конечно это просто вопрос удобства и привычки… но когда что-то пресобираешь 20+ раз хочется как то упростить технологию
tqfp
...разрабатываем электронику вместе
Мне кажеться что 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);
или специальное устройство — шуруповерт
Первые два способа вполне работоспособны — ведь закручивали же люди шурупы до шуруповертов :)