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

Набор идей по использованию UDP поверх Ethernet для быстрой и удобной связи с устройством для целей отладки. http://ru.wikipedia.org/wiki/UDP
http://windata.ru/windows-world/com/utilita-arp/
1. ARP релизуем ручками. В коде устройства пишем MAC адрес, ARP кеш венды прописываем ручками -> 2. Структура UDP пакета сложностью не страдает -> 3. CRC для UDP не обязательно! Поскольку у нас пересылка "в пределах стола", то будем использовать контрольную сумму Ethernet, благо она сама считается во всех контроллерах. 4. Например, в Tcl с UDP работать легко и просто. Во многих других языках тоже. http://wiki.tcl.tk/8493 http://tcludp.sourceforge.net/ http://www.packtpu …-tcl-using-udp-sockets 5. Общий алгоритм работы устройства - есть некий процесс, порождающий данные для отправки в ПЦ - заводим массив, формируем начальные байты под IP UDP, включая поля Ethernet пакета - заполняем массив целевыми данными - программируем Ethernet контроллер на отправку На прием аналогично. Можно также сделать потверждения и ввести нумерацию пакетов, чтобы адекватно работать с задержками (т.е. не ждать ответа сразу) Что имеем в итоге? - канал связи ПЦ с устройтвом с CRC, хорошей пропускной сопособностью (10 Мбайт/сек дуплекс - это не хухры-мухры) и минимальной нагрузкой на целевой проц - память под буфера нужна, но ее не так мало в современных контроллерах - автоматичское соблюдение границ пакета - удобный программный интерфейс, который пойдет под любой ОСью - использование бинарного протокола (граница пакета соблюдается!) повысит эффективность коммуникаций. Printf во встраиваемом устройстве для целей отладки суть ересь - тут же программируем сценарий обмена на высокоуровневом языке. Из устройтва можно слать структуры прямо в бинаром виде. И тут же запрограммировать их удобну раскладку в нужную визуальную форму. Отправлять тоже можно сразу упакованные структуры - expect на ура прикручивается. - масса монотонной ручной работы легко автоматизируется. Вкалывают роботы! Важно: - нужно отойти от стандартных стеретотипов - RS-232, консоль, telnet. Т.е. для самого начального запуска RS-232 самое то:), но не более. - гальваническая развязка тоже штука полезная. - высокая скорость обмена и небольшая латентность позволят часть алгоритма обоработки вынести в ПЦ. Например: - мы делаем некий достаточно сложный алгоритм, которые работает с непростой периферией. - есть реализация алгоритма на ПЦ, на плавучке, быстрая, правильная, проверенная. - нам надо проверить, что вообще целевую зазачу можно решить - делаем работу с периферией на MCU - целевой алгоритм пока реализуем на ПЦ - гоням данные как описано - навскидку, при требованиях по RT до 1мс при использовании RT Linux в качестве хоста больших проболем с задержками не будет - после проверки начинаем утаптыват алгоритм в MCU (например переводим, в 16 бит целочисленные, что-то упрощаем), при этом писюковую реализацию используем как эталон для тестов -- например, из устройства отгоняем в ПЦ полученные данные и результат работы встроенной версии алгоритма -- проверяем на ПЦ - получила ли эталонная версия из исходных данных конечные. Проверяем допустимость ошибок и проч.