[INTERRUPT] Info importante per aspiranti microcontrollisti

[posta10100]

Se poi il compilatore fa cag... ehm ... non è dei migliori allora si mette mano all' assembler.

Se non hai bisogno di prestazioni e se hai abbastanza flash lo lasci fare... l'ultimo firmware che ho scritto l'ho lasciato tradurre al compilatore, tanto qualche millisecondo in più o in meno non cambiavano nulla.
E la flash... è avanzata
Se invece sei alle strette ti tocca smontare, ripulire e ottimizzare. Ma lo sai meglio di me

[TardoFreak]

Sono d'accordo,
Resta comunque il fatto che, a mio avviso, è importante sapere come lavora il compilatore.
Ovviamente bisogna conoscere l' assembler del micro in questione altrimenti non si è in grado di valutare.
In buona sostanza lasciamo al compilatore il lavoro noioso per concentrarsi sulle cose importanti.

[angel99]

Le palle!

Ho seguito gli altri 3D dove elogi il C e mi viene prurito alla barba. Nel senso che è indubbio il fatto che con l'abbondanza di flash e di RAM degli ultimi micro, i compilatori adesso possano fare anche delle cose carine. Così ogni volta che inizio un nuovo progetto mi viene voglia di provare. Scrivo un paio di routine, poi desisto. E' quella sensazione di costruire sulle sabbie mobili che mi ferma. E' la stessa sensazione del VHDL: prima ci provo, poi passo alle porte e ai FF. Forse sto diventando vecchio e non riesco a stare al passo con queste diavolerie da giovani.

[TardoFreak]

Alura,
Secondo me non bisogna essere degli integralisti.
Il C è comodo, i compilatori di oggi fanno cose eccellenti, a volte migliori di quello che possono fare certi umani.
Quello che dico è che è bene sapere, conoscere, essere curiosi.
Solo assembler è improponibile (soprattutto per certi progetti complessi), solo C senza sapere quello che succede dietro le quinte è, come dire, troppo comodo e pericoloso.
Sapere come viene compilato il codice è conoscenza.
Quindi che si scriva in C ma sempre con occhio critico ed attento.

[posta10100]

Così ogni volta che inizio un nuovo progetto mi viene voglia di provare.

Anche io pensavo di scrivere direttamente in assembler, poi ho iniziato con il C e mi sono tolto di torno parecchie noie.
Pensa solo a fare la somma tra due numeri a 32 bit senza la "somma con riporto" su un PIC a 8 bit. Sono uno sproposito di istruzioni. Oppure la gestione della RAM, il compilatore in genere è in grado di riutilizzare la memoria senza che tu nemmeno ci debba pensare.

Insomma, i vantaggi ci sono, ma come già detto, non sempre il compilatore da il miglior risultato.
Se serve, gli si da una mano

[angel99]

Oppure la gestione della RAM, il compilatore in genere è in grado di riutilizzare la memoria senza che tu nemmeno ci debba pensare.

Aggghhhhhh!!!!! Vedi, è proprio questo che mi spaventa. I miei programmi (assembler) sono suddivisi in più file, uno di questi si chiama Memory.asm. Ho una serie di templates, in genere uno per ogni tipologia di micro, e su questi file vengono, volta per volta, definiti gli ambiti delle variabili, delle zone temporanee, di quelle riallocabili. Tutto sotto controllo. Sono IO che impongo cosa debba succedere, non è qualcosa che funziona, ma è deciso da qualcun altro praticamente fuori dal mio controllo.

La mia paura (magari infondata) è il butterfly effect: cambi un'istruzione da una parte del programma e il compilatore ti sconvolge il codice perché la strada che aveva scelto prima, ora non è più perseguibile. Cosa dovrei fare io? Verificare il compilato ad ogni compilazione, leggendo dell'assembler scritto da una macchina? No grazie.

Poi, come esiste chi scrive in C e chi scrive bene in C, lo stesso vale per l'assembler. Ho visto ben pochi programmatori sfruttare in modo completo le potenzialità di un MACROassembler. Io di macro ne scrivo a iosa e le utilizzo in continuazione, anche per rendere più leggibile il codice. Posta faceva l'esempio delle somme a più Byte: questo è il tipico caso dove una macro è ancora più veloce (nella stesura del codice) di quanto sia scrivere il paradigma in C. Se poi vuoi che quella macro appoggi le variabili in un punto diverso oppure che esca con un'eccezione, copi il codice chiamandolo _MACRO2 e modifichi ciò che serve.

Io ho una libreria di macro talmente estesa che il main.asm ha quasi sempre più rige in maiuscolo che istruzioni in assembler. Non sto dicendo che la strada giusta è questa e che il C sia sbagliato, ma lasciare questa strada per quella, la vedo ancora da venire. Ovvio, per me.

[WALTERmwp]

Oltre all'aspetto relativo alla gestione del contenuto della routine di interrupt, finalizzata alla sua ottimizzazione e a quella del programma in generale, si potrebbe prendere in considerazione una possibile conseguenza dovuta alla chiamata della routine stessa.

Allora, l'aspetto "didattico" conferito al thread, visto che magari tanti altri utenti potrebbero leggere questi passaggi, consente di ricordare che l'interruzione di una operazione (da parte di un altro processo ma in tal caso meglio scrivere, da parte della routine di interrupt) può avere conseguenze "particolari" sulla esecuzione di un programma; è necessario quindi sapere cosa si va a chiedere ad una routine di interrupt e cosa potrebbe interrompere, una routine di interrupt.

Così argomentando nel merito, facendo riferimento per esempio a questo link "file:///C:/Documents%20and%20Settings/Nobody/Documenti/Downloads/Beyond_volatile.pdf" (per citare una risorsa già considerata), ci si può rendere conto (o eventualmente ricordare) cosa comporta un intervento che non garantisce la "atomic operation".

Dal mio punto di vista, come ha scritto TardoFreak nel Post [34], assume importanza fondamentale la conoscenza e la consapevolezza di quello che si va a fare, sopratutto se si scrive il codice con un linguaggio superiore; se poi si sa "cosa combina" il compilatore, tanto meglio.
Al tempo stesso, mi pare, come ha scritto angel99 nel Post [36], aderendo il più possibile al codice "asm" riduci i rischi insiti del passaggio attraverso un compilatore.
Ognuno poi adotta il proprio stile, ricorre alle proprie consuetudini ma, certamente, senza prescindere dalla conoscenza.

Saluti

[angel99]

Si può azzardare anche un passo ulteriore.

asm: controllo hardware del micro. Sai esattamente cosa fa, istruzione per istruzione.
C: devi sapere cosa fa il compilatore. Se sei in grado di farlo, hai quasi lo stesso controllo.
Arduino: non sai nulla, non puoi sapere nulla e non saprai mai nulla.

[posta10100]

C: devi sapere cosa fa il compilatore.

In realtà è abbastanza logico sapere cosa fa.
Non puoi semplicemente dire "accendi un led ogni 3 secondi", devi impostare i timer, le porte, ...
Come per l'ASM ma in maniera più comoda.

Arduino: non sai nulla, non puoi sapere nulla e non saprai mai nulla.

Ma non si parlava di aspiranti microcontrollisti? Arducoso è altra cosa

[speedyant]

Ma esistono gestioni tipo "polling" anche per i micro? Vanno emulate?

Se si cerca USB polling su google si "intuisce" il mio dubbio.