> как раз на них и медленно работает, драйвер надо писать для того
> что бы было быстрее,При человеческом подходе aka программированию этого как кастомного I/O чипа с специфичными свойствами, а не "компорта" - нормально. А компортовые апи сроду не предназначались для потуг дергать лапками в режиме GPIO, это вообще всегда был гнусный хак для компортов и просто горбатый подход для LPT, особенно в многозадачках.
> а всем побинарю, что бы с этим игратся,
Вообще-то в том же OpenOCD сделали довольно резвый JTAG на 2232 и более новых.
А тот же UART там до 12Мбит IIRC можно разогнать. То что некоторые тупизни используют медленные и неэффективные API типа потуг изобразить по USB компорт с дерганием API типичных для COM портов для потуг помахать лапками.
> дешевле купить технику старую и прошивать.
Как по мне это подход defective by design: вместо освоения новых решений уткнуться в доисторические ошметки, используемые через зад, и работающие под стать,
> AVR-USB есть он шьет быстро. Но мне надо еще и Х90
> шить и 1-wire DS2432, AT88* ...
Вообще, если уж пиндец надо скорость - ну взять uC с более-менее приличной RAM, прицепить его к USB или если влом разбираться то хоть той же FTDI, по usb ему кидаем пакет который надо зашить в буфер, он получает и далее может шить с максимальной скоростью.
Пора бы уже принять как данность что x86 не создан для быстрого дергания лапками вообще, а в многозадачных системах - в частности. Он может выдавать большую bulk производительность, но скорость реакции на события - фиговая. И поэтому надо пакетизатор/депакетизатор с буфером. Человек программирующий микроконтроллеры должен бы к 2014 году осознать этот очевидный факт. Поэтому все эти пони всю жизнь работали так как и должны - ЧЕРЕЗ Ж...У!
