caxapa.ru :: 1) протоколирование сырых данных периферии. В боооольшой файл на ПЦ. Чтобы потом его матлабом, скажем, анализировать. Например, тупо отсчеты АЦП. 2) тупой дамп больших структур из памяти. Чтобы искать трудноуловимые ошибки.

Evgeny_CD, Архитектор (06.02.2013 01:47, просмотров: 291) ответил Mahagam на ого. а пример такой задачи можно? вкратце.

1) протоколирование сырых данных периферии. В боооольшой файл на ПЦ. Чтобы потом его матлабом, скажем, анализировать. Например, тупо отсчеты АЦП. 2) тупой дамп больших структур из памяти. Чтобы искать трудноуловимые ошибки. Т.е. просто тупо капчурить максимальный поток из устройства. А потом удобными высокоуровневыми тулзами на ПЦ разребать и автоматом искать, "что не так" "Вкалывают роботы".

Ответить

- ну-ну. 10 метров в секунду - это каким контроллером вы такой поток без ПЦ собрались переваривать? - Mahagam(06.02.2013 10:27)
  - Это ПЦ переваривает поток 10Мбайт/сек от контроллера. - Evgeny_CD(06.02.2013 15:34)
    - ну а поток этот откуда-то получается? если он != тому что будет обрабатывать контроллер, то я не вижу толка в такой отладке - Mahagam(06.02.2013 15:48)
      - Вот что мы однажды делали, когда никак не могли найти ошибку. В том чипе не было Ethernet, сделали по UART, но все было на грани по причине медленного канала. Evgeny_CD(1351 знак., 06.02.2013 17:54)
        
        странные у вас методы... я обычно добивался того, чтобы ошибка проявляла себя как можно чаще. - Mahagam(06.02.2013 18:02)
        
        Куча функций зависит от сотового мудема. А тот - от глюков ОПсоса. Как ускорить появление глюков у опсоса? Evgeny_CD(380 знак., 06.02.2013 18:08)
        
        В варианте Ethernet отлаживать вполне можно даже в поле, на живой системе. На ноут капчурим и все. Потом в лаборатории спокойно анализируем. JTAG для поля не очень подходит, да и фоновая отладка в течении часов - искусство. - Evgeny_CD(06.02.2013 17:56)

Средства и методы разработки