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

Если выкинуть агрессию и включить могзи, то дело выглядит так. Облом - это замечательно, ибо он двигатель прогресса, но всякая вещь несет в себе инструмент самоуничтожения. Иначе жизнь завершится. Конечно, здорово натыкать проводков в LPT порт, порубить к нему нечто на DIP микрухах на макетке, налобать программу с nop для временных задержек - и чудо! Ты уже разработчик embedded системы!!! Но когда 3 ГГц проц убивается ап стенку дров COM, LPT и прочих очень удобных для нас устройств 30 летней давности разработки, то серьезный человек должен приходить в ярость. Почему и зачем нужны 3 ГГц процы - нас не спросили, но они есть, и стоят дешево. Можно исходить яростью, а можно то, что на 51 ты писал на asm, написать на пысюке на питоне или еще на каком языке с хорошими средствами защиты от ошибок, и ресурс проца потратить не на nop для организации задержки, а на защиту от всех мыслимых и немыслимых ошибок, чтобы у тебя точно не утекла память, не произошло переполнение стека и пр, чтобы юзер не делал с твоей программой и твоей платой. Относительно реального времени. Много раз сказано. Любая унивресальная ОСь общего назначения, которая выжимает 101% из аппаратных ресурсов, асинхронна, хоть ты тресни. И я не знаю, что есть больший маразм - делать RT на виндах или переделывать Word, чтобы он пошел под RTEMS. Богу - богово, кесарю - кесарево. Таким образом, любое устройство, которое подрубается к универсальной ОСи Win|Lin|Mac|что там еще есть, должно быть интеллектуальным, со встроенным процом, и обмениваться с ОСью высокоуровневыми блоками. Самое смешное, что это не ухудшит производительность даже в простейших случаях, типа вывод в порт (каждое переключение контекста на современных процах с их мегабайтами кеша - это аццкое упражнение! Прерывания от того, что у тебя в буфере 16c554 накопилось 12 байтов данных - ДУРЬ!!!), зато кардинально поднимет ее, когда тебе нужно записать 1кбайт данных в периферийное устройство. Что касается цены - то в диапазоне $1...5 полно нехилых контроллеров. В том числе с USB. Если немножко подумать, и ввести нормальное понятие реального времени в периферийном контроллере, и сделать простейший планировщик, и немножко буферов на данные, то, как я пиал не раз, латентность большой ОСи может быть гораздо больше, чем при "ногодрыгстве". Конечно, есть зловредность как делателей софта (геморой с USB дровами для виндов) так и делеза (обычный PCI уходит, вот что страшно! Все на express переводится. А он куда дороже в реализации), но тут нас спросить забыли. Резюме: * отказ от примитивных IO устройств без процессора - это благо и магистральный путь развития. Так точно будет. И проявлящие агрессю против этого "писают против ветра" * конструктив может состоять в публичном обсуждении намболее безгеморойного использования USB, и публикации всяких исходников для этого. Причем понимание там часто важнее исходника: если ты внятно понимаешь, что надо сделать, чтобы USB работало, то закодить - это уже "дело техники", ничуть не сложнее любой другой задачи. * на периферийном устройстве надо вводить локальную шкалу времени. И давать ему команды дерни за.., через 10 мкс дерни это. Ну и флаги, что устройство полезло в буфер, а там нифга. Задача притивная, очень полезная для отладки, после ее решения RT свойста пысюка волнуют в контексте секунд, а это достижимо. Как известно, M$ позаботилась о нашем геморое. Если я все правильно понимаю, есть толко 3 класса, которые могут жить без дров на любой машине: * HID - но там скорость мала * Mass Storage - круто, но это как бы не совсем канал ввода-вывода. Заметим, это большое благо, ибо на каждое воткнутое устройство можно положить конфигуратор, доку; конфигуратор прямо в виде файла запишет конфигурацию и прошивку - круто, правда? * Remote NDIS - на нем живет WinCE. Вроде как он и в больших виндах, и в WinCE есть. Вот создание открытого проекта под remote NDIS - вот это конструктивно. А для начала обсуждение - а правильно ли я все понял насчет этого remote NDIS?