Абе няма лошо, трябва да се правят и упражнения от време на време ...

В началото на поста ставаше дума за SPI, сега стана асинхронна комуникация ... загубих му дирите. Определено да правиш софтуерно приемане на SPI, където скоростите са по-големи от 1 Mbsp ( за по-ниски интерфейсът се обезсмисля ), не е опрадано. За асинхронният оаче скоростите са по-ниски и там бива.
Софтуерен UART се прави сравнително лесно, ако процесорът ти е мислен за бърза реакция на прекъсвания. В едно изделие имам 3 софтуени канала пълен дуплекс, работещи на 9600 - 1 бр и на 19200 - 2 бр. Процесорът ми е 16 MHz MSP430. При 100% заетост и на трите канала процесорът се натоварва допълнително с около 25%. Проблемът при софтуерните канали е, че налагат големи изисквания към останалата част на кода: да не забранява прекъсванията за повече от 10-20 микросекунди; да няма обработка да други прекъсвания, които заедно да достигнат 10-20 микросекунди; да е толерантен към чести прекъсвания за по няколко микросекунди. Например тези софтуерни канали не могат посмъртно да се сработят с четене на iButton точно заради несъвместимост на времедиаграмите. Процесорът ми има 4 хардуерни UART-a, от които ползвам 3, останалите 3 асинхронни канала са ми софтуерни.

Що се занимавате с тия антики?
М16 имат до 6-7 UART-а...

Ми що.... То устойството разработено преди 6-7 години и си се продава, ами се наложи да му се добави комуникация с нов модул. Новите са с ARM. Но ако зависи от мен, ще изхвърля и Hitachi-то, и ARM-a.