ВходНаше всё Теги codebook 无线电组件 Поиск Опросы Закон Воскресенье
19 мая
183147 Топик полностью
AlexandrY (26.02.2010 23:05, просмотров: 119) ответил bialix на писатели на PC борятся с собственными багами, которые так же как и у писателей на МК практически неизбежны. В красивые слова про открытую книгу -- не верю. И в целом не согласен, чем JTAG поможет? А про логирование в риалтайме я уже ниже писал -- это
Мда, в сотый раз приходится объяснять правильные пути разработки ;) JTAG действительно не поможет если применять процы без разбору от балды, якобы под задачу. Для меня как один из критериев ламерства это когда говорят, что работают с несколькими процами разных архитектур одновременно. У проца ИМХО должен быть один главный критерий выбора - простота и скорость отладки. Таких на пальцах пересчитать и все они на архитектуре ARM ;) Логи для оперативной отладки непосредственно программы в uC это прошлый век. Отладочные логи прежде всего требуют написания тонны лишнего кода, во вторых вносят местный эффект, в третьих требуют сами отладки и т.д. Логи не умеют делать мгновенный снимок системы поскольку сами занимают ресурсы системы. Современные же процы все больше ориентированы на то что их отлаживать будут JTAG-ом. В периферии вводят специальные отладочные режимы, делают каналы передачи через JTAG, делают изощренные условные брекпойнты. Скажем JTAG-ом отловить причину абортов по недопустимым инструкциям, неинициализированным указателям, выборки из недопустимой памяти, причину переполнению стека занимает считанные минуты. Логами вы можете вечно искать причины таких сбоев. Т.е. программер отлаживающий логами сознательно опускает свою производительность к нулю. Еще хуже если делает он это от того что в его процах нет нормального JTAG-а, значит он сделал системную ошибку. Реалтайм в логах я бы назвал ключевой проблемой. Кому нужны логи пропускающие события? А кому нужны логи подавляющие события потому что сами жрут ресурсы процессора? А кому нужны логи на 5 мин? Логи должны писаться весь цикл работы дивайса во включенном состоянии. А как тогда с гиганскими файлами? FAT поддерживает файлы весьма ограниченной длины. Т.е. есть большая проблема архивирования и катологизации логов. А еще ведь бывает нужно отослать только фрагменты логов. Бывает устройству и поиск в логах надо организовать. А как насчет записи конкурентно десятков логов в неизвестной среде RTOS c неизвестным быстродействием носителя и как реализовать приоритеты у логов? Вот все эти вопросы либо не раскрыты либо плохо раскрыты для реалтайм систем. Хотя для Windows СE скажем эта тема проработана вполне конкретно. Вот откуда наверно многие дергают свои бредовые идеи. Именно там есть разделение логов на зоны и регистрация зон, разделение на модули и на стадии релизов и т.д. Там и диспетчеры логов и отладочные командные оболочки и дебагеры с раскодировкой логов ядра и т.д. Бинарник винды при включении логов раздувает более чем в два раза. Из-за этого винда не может до сих пор быть нормально отлажена на бюджетных малоресурсных платформах без применения JTAG-а.
INDEMSYS