Och om det är OK att processorn gör "en sak i taget". D.v.s t.ex under tiden som ett "kommando" sänds, så gör man inget annat. Det beror också på om man tror att det kommer att finnas delar i konstruktionen som man tidsmässigt inte har full kontroll över, t.ex om man vill kompletterar med ett seriellt gränssnitt för att kunna sända texter från en PC (skulle inte förvåna mig om man ganska snart vill komplettera med det, även om det inte finns med i först versionen), så underlätter det betydligt om man redan från början har byggt det hela runt en arkitektur som gör att USART rutiner kan "pluggas in" utan att störa den befintliga koden allt för mycket.
Normalt betyder detta en interruptstyrd grund med korta/snabba ISR's för de olika delarna, och en pollande main loop där man sedan tar hand om den icke tidskritiska bearbetningen. T.ex så används USART-receive ISR'en bara till att hämta inkommen byte till en buffert och sätta en flagga som signalerar att ny data finns i bufferten. Main loopen pollar denna flagga (tillsammans med andra flaggor från andra ISRs), och tar sedan ta hand om den bearbetningen som behövs. På så sätt är det ganska enkelt att plugga in nya funktionallitet, lägg till en ISR, fixa en ny flagga, komplettera main loopen med en poll på flaggan och ett CALL till bearbetningen.
En annan sak är att aldrig används programvara om det finns härdvara i processorn som gör samma sak bättre och enklare. T.ex att använda PWM modulen för att generera 38 Khz bärvågen istället för timade loopar.
När det gäller att interrupt kan "störa" övrig bearbetning, så är det ju det som är hela finessen med interrupt !
Om det sedan finns (korta!) kodsegment som absolut inte får avbrytas, så är det ju bara att tillfälligt stänga av interrupten. Inget speciellt konstigt med det.PIC18 har interrupt i två prio-nivåer, men de flesta använder det inte. Om man ser till att ingen ISR exekverar längre en den längsta accepterade fördröjningen för *något* av interrupten, så är det inget problem i alla fall. Det är bara att låta interrupten köras efter varandra även om två eller flera interrupt skulle råka inträffa "samtidigt".
Nåväl, det hela handlar i grunden om att hitta en applikationsarkitektur som man tror kommer att fungera både för behoven i "Rev 1A", och som även kommer att fungera när man lägger till ytterligare funktioner.
Det är väldigt enkelt att skriva en enkel loop som generar en 38 Khz signal, och om detta är det *enda* som processorn skall göra, så är det väll OK...
)
