Привет!
Fri Apr 01 2005 12:55, Igor Havtorin wrote to Alexander Golov:
...
AG>> А из-за чего такое острое желание? Hеужели 8 циклов на AG>> сохранение/восстановление это так много?
IH> Когда принимаешь пачки данных с LPT (а надо еще заголовки искать/байты IH> подсчитавать и т.п.), то до слёз жалко тех машинных циклов, которые были IH> "сожраны" группой из 6-8 movff на входе/выходе прерывания. Из прерываний IH> практически не вылезаешь, да и диаграмма LPT получается "вялой" IH> (и это на PIC18F6620 24Mhz).
IH> Хочется "содержательную" часть ISR написать вроде:
...
IH> при этом мы не портим никаких регистров - только время воруем :-).
Похоже на тот случай, когда переписать на асме только критическую часть кода без существенной потери эффективности не удастся. Может с другим компилятором?
А здесь по времени мы имеем:
interrupt 3 bra intcode 2
intcode: btfss _LPT_flags,BLK_RCV 2 bra header_search bsf _LPT_busy 1 movff _PORTD,POSTINC1 2 dcfsnz _ByteCnt 1 bsf _LPT_flags,BLK_END 1 btfsc _LPT_flags,BLK_END 1 bcf _LPT_busy 1 bcf int_request 1 retfie 2 ------ 17
При 24 МГц время выполнения обработчика будет 2,8 мкс. Если засунуть сохранение/восстановление FSR то добавятся 16 циклов, что займёт уже 5,5 мкс. Можно поднять частоту МК до 40 МГц, тогда получится 3,3 мкс. Другой вариант использовать более производительный МК, например на dsPIC30F без резервирования регистров при 30 MIPS получается 0,74 мкс (а с резервированием двух регистров 0,5 мкс):
interrupt 4 push.d w0 2 mov PtrBuf,w0 1 btfss _LPT_flags,BLK_RCV 2 bra header_search bset _LPT_busy 1 mov #_PORTx,w1 1 mov.b [w1],[w0++] 1 dec _ByteCnt 1 bra NZ,L1 2 bsf _LPT_flags,BLK_END bcf _LPT_busy L1 mov w0,PtrBuf 1 pop.d w0 2 bclr int_request 1 retfie 3 ---- 22
Александр Голов, Москва, snipped-for-privacy@mail.ru