ВходНаше всё Теги codebook 无线电组件 Поиск Опросы Закон Суббота
4 мая
385680 Топик полностью
Evgeny_CD, Архитектор (06.02.2013 17:54, просмотров: 282) ответил Mahagam на ну а поток этот откуда-то получается? если он != тому что будет обрабатывать контроллер, то я не вижу толка в такой отладке
Вот что мы однажды делали, когда никак не могли найти ошибку. В том чипе не было Ethernet, сделали по UART, но все было на грани по причине медленного канала. Есть куча функций. Они получат на вход указатель на входную и выходную структуры и несколько параметров. Возвращают код ошибки. Раз в час происходит тонкий сбой. Ничего не валится, но результат обработки неправильный. Где именно? В начале каждой функции делаем дебаг секцию. Критическую. Специальной отладочной функции передаем: * значение таймера * id функции * указатель на входную структуру * ее sizeof * входные параметры. Она кладет все это в память, включая копию структуры и выдает команду отработчику прерываний от Ethernet - услать это нах. Обработчик, получив управление, читает параметры блока, настраивает DMA Ethernet и говорит - шли. RAW Ethernet, блок в памяти правильно разложен. Перед завершением функции то же самое в части выходной структуры и кода возврата. Никакого квитирования по Ethernet. Вероятность потери пакета в одном свитче считаем малой. В случае потери просто херим данные от этого цикла работы. Далее высокоуровневая софтина разгребает гигабайты данных на ПЦ (лучше сразу разложить в SQL базу) и автоматически находит место, где "не так". У нас есть: * порядок вызова * выходные и выходные данные. Можно написать автоматический анализ любой сложности. В варианте UART поток данных иногда превышал скорость UART, был геморрой. В варианте 100 мбит Ethernet, по моей оценке, хватит.