[INTERRUPT] Info importante per aspiranti microcontrollisti

[speedyant]

Li lappate e ci mettete un waterblock e poi fate a gara!
Il fatto che io abbia un impianto a liquido nel PC non vi deve trarre in inganno, non sono mica un fanatico dell' overclocking!

[angel99]

E.... l'azoto liquido è permesso o no? Con quello si fanno cose troppo simpatiche!

Adesso Pietro arriva e chiude il 3D...

[speedyant]

Prima che chiuda e ci "banni" a vita, se riesce a darmi qualche "info" sulle differenze, se esistono, della gestione degli interrupt dei micro rispetto ai "processori" x86...

[angel99]

Se parliamo dell'8086 e dei fratelli vicini, diciamo fino al 386, sostanzialmente non ci sono differenze nel loro utilizzo. Se invece parli dei micro x86 attuali, non ha neppure senso parlarne perché non credo (io non ho mai sentito) che siano stati scritti programmi che gestiscano il micro a tale livello. Attendiamo altre fonti.

[PietroBaima]

Adesso Pietro arriva e chiude il 3D...

Chiuderei volentieri quelli di coloro che usano gli interrupt in quel modo e poi si lamentano che il micro a 72MHz è lento, quando con uno Z80 a 4MHz si potrebbero fare il triplo delle cose...ma non posso.

[posta10100]

Di norma nell'interrupt si lascia il minimo indispensabile, ma purtroppo alle volte il minimo indispensabile corrisponde a buona parte del programma.
Sto mettendo a punto un generatore di funzioni DDS (senza troppe pretese a dir la verità) utilizzando un PIC18F4450 (ce l'ho in casa e lo voglio usare ).
Di fatto, dopo aver programmato la RAM esterna, deve far girare all'infinito una routine che fa la somma di due numeri a 24 bit mettendo sui pin il risultato.
Deve girare all'infinito fino a quando un evento esterno (pressione di un tasto o simili) richiedono attenzione e bisogna assecondarli :)
Ora, la somma dei due numeri richiede una ventina di cicli macchina, aggiungerne anche solo 4 per verificare se una variabile ha cambiato valore significa decrementare del 20% le prestazioni.
L'idea (ma forse si può fare altrimenti) è quella di lasciare nel programma principale solo la routine che fa la somma e gestire tutto il resto nell'interrupt.
Al momento non mi vengono in mente altre soluzioni.
Purtroppo, alle volte, gli interrupt devono essere corposi.

[angel99]

Ciò di cui Freak sta parlando (mi arrogo ad interpretatore ufficiale) è che bisognerebbe analizzare il firmware prima di scriverlo. Ciò che si infila in una routine o in un'altra non deve essere ciò che appare necessario al momento, ma ciò che si è pianificato prima di scrivere il primo mov (o il primo void per chi non conosce l'assembler ).

Nella routine di IRQ ci va solo quello che deve essere fatto prima che possa arrivare lo stesso interrupt una seconda volta! Tutto il resto va demandato alla parte "interruptibile" (aghhh che termine!) del programma (il main loop).

[gotthard]

"interruptibile" (aghhh che termine!).

Forse asservibile è più "normale" (e carino)

[angel99]

L'italiano è una lingua bellissima. Ma quando si tratta di parlare di software...

[TardoFreak]

.. e non è che io ne capisca tantissimo di quello che succede.

Questo è male, non s'ha da fare.
Rimedio: munirsi di buona volontà e studiare il/i microcontrollori.

Scrivete, scrivete in C... e poi quello che fa il micro lo sa solo il compilatore (e forse neppure lui).

Assembler forever!

Le palle! (emoticon con gesto dell' ombrello)
Si scrive in C prendendosi la briga di andare a vedere come lavora il compilatore (cosa che quasi nessuno fa e che invece dovrebbero fare tutti ).
Se poi il compilatore fa cag... ehm ... non è dei migliori allora si mette mano all' assembler.