Linguaggio "C" nel PIC e nell'Arduino

[Naraj]

Solo da qualche giorno ho iniziato a giocare con l'Arduino. L'ultimo micro che ho programmato in assembler era il PIC e devo dire che quest'ultimo mi sembra più adatto a progetti miniaturizzati e vorrei continuare con esso, ma programmandolo in "C".

Mi piacerebbe sapere, da chi programma in "C" sia il PIC che l'Arduino, se ci sono notevoli differenze tra i due linguaggi di programmazione.

Naraj.

[Davide B.]

Post Duplicato... scusate.

[Davide B.]

Il linguaggio di programmazione è "quasi" lo stesso, nel senso che, a seconda del compilatore e della sua aderenza ai vari standard si somiglieranno tutti più o meno per quanto riguarda la scrittura delle istruzioni stesse.
Detto questo alcune implementazioni sono abbastanza diverse (vedi ad esempio il MikroC) per quanto riguarda la scrittura e la lettura dei registri.
Detto questo la forte differenza (chiamiamola pure limitazione) che ho notato nella programmazione in c dei pic della serie 16 e 18 rispetto agli altri microcontrollori è una limitazione di tipo architetturale, dovuta alla lunghezza dello stack che è limitata, e che quindi impone un limite più risicato nell'albero di chiamate delle funzioni stesse.
In pratica, partendo dalla funzione main con il PIC16 si possono avere annidamenti fino a 5 livelli, nei pic più grandi il numero cresce, ma non si può andare più il la di tanto.
Negli atmel tipo il 328 la ram è suddivisibile come nei micro più "seri", o meglio, nella maggioranza di essi.
Inoltre, generalmente, a parità di costo sembra che la atmel fornisca più RAM e più FLASH (ma di questo non sono sicuro).
Infine, paragonando la serie ATMEGA con la serie PIC16F il compilatore è probabilmente più efficiente(sulla 18 non ci scommetto avendoli usati poco).

[romoloman]

Quoto in parte Davide,
Ovviamente le differenze stanno tutte nella parte di basso livello, registri, timers, interrupt i/o ports, quindi ovviamente non vi è una portabilità da un'architettura all'altra

Originalmente inviato da Davide B.

Infine, paragonando la serie ATMEGA con la serie PIC16F il compilatore è probabilmente più efficiente(sulla 18 non ci scommetto avendoli usati poco).

Beh qui invece non sono d'accordo, anche perché nella stessa famiglia AVR l'efficienza dei compilatori varia non solo a seconda del produttore ma anche della versione.
avr-gcc 4.7.2 ottimizza il codice per dimensione molto più di avr-gcc 4.6.2 quindi parlare di efficienza è un concetto abbastanza astratto, non esistendo un solo compilatore C per entrambe le famiglie.
(il compilatore della microchip comunque è molto valido)

[ElNonino]

my 2 cents:

per creare codice 'C' portatile fra dispositivi diversi è una buona regola utilizzare lo ANSI C che è universalmente standard, poi crearsi alcune macro per operazioni di base anch'esse standard.

Io poi mi son creato alcuni files header contenenti i #define personalizzati dei registri o porte dei vari micro, in tal modo modifico solo alcuni <include> ed il codice resta invariato passando da un PIC16 a dsPIC33 o STM32; chiaramente tenendo poi comunque conto delle diverse risorse hw e velocità (temporizzazioni) dei dispositivi.

Per abitudine poi utilizzo un altro <include> comune a tutti che definisce alcuni tipi di variabili, char, byte, word, etc etc costituiti da struct ed union; ciò consente di accedere direttamente al singolo bit, byte...di ogni variabile; ad esempio in una media mobile di 16..64 valori basta estrarre lo lsb o lsw dalla variabile anzichè dividere per 16 o 64.

Un buon stile di programmazione facilità molto la portatilità.

[romoloman]

Originalmente inviato da ElNonino

my 2 cents:

per creare codice 'C' portatile fra dispositivi diversi è una buona regola utilizzare lo ANSI C che è universalmente standard, poi crearsi alcune macro per operazioni di base anch'esse standard.

Io poi mi son creato alcuni files header contenenti i #define personalizzati dei registri o porte dei vari micro, in tal modo modifico solo alcuni <include> ed il codice resta invariato passando da un PIC16 a dsPIC33 o STM32; chiaramente tenendo poi comunque conto delle diverse risorse hw e velocità (temporizzazioni) dei dispositivi.

Per abitudine poi utilizzo un altro <include> comune a tutti che definisce alcuni tipi di variabili, char, byte, word, etc etc costituiti da struct ed union; ciò consente di accedere direttamente al singolo bit, byte...di ogni variabile; ad esempio in una media mobile di 16..64 valori basta estrarre lo lsb o lsw dalla variabile anzichè dividere per 16 o 64.

Un buon stile di programmazione facilità molto la portatilità.

Si ma se in un processore hai solo 2 livelli di interrupt e nell'altro 6 poco aiutano i define soprattutto se ne vuoi usare 6.

[ElNonino]

Originalmente inviato da romoloman

Si ma se in un processore hai solo 2 livelli di interrupt e nell'altro 6 poco aiutano i define soprattutto se ne vuoi usare 6.

Hai ragione, ma un' altra buona regola di programmazione (in taluni campi è un must) è di limitare al massimo l'uso degli interrupt 1 o 2 massimi.

Io credo che in campo modellistico (ed anche professionale) basti usare anche solo un interrupt generato da un timer per schedulare tutte le operazioni.

E' chiaro che alcune funzioni come DMA, pwm hw, e molte altre sono appunto hw specifiche e quindi non è possibile renderle portatili con facilità: ad esempio alcuni micro Cypress comprendono blocchi analogici che è difficile trovare in prodotti di altre marche però alcune funzioni di controllo di, ad esempio, SPI, I2C, UART, protocolli di comunicazione ed altro possono essere rese facilmente portatili al 90% o più.

[Naraj]

Grazie ragazzi.
Ho ricevuto molte risposte in più di quelle che mi servivano.
Ora posso continuare la programmazione con il "C" sapendo di avere alle spalle una schiera di persone disponibili e con un'ottima preparazione specifica.
Sicuramente avrò ancora bisogno di voi.

Naraj.

[Davide B.]

Hai ragione, ma un' altra buona regola di programmazione (in taluni campi è un must) è di limitare al massimo l'uso degli interrupt 1 o 2 massimi.
Io credo che in campo modellistico (ed anche professionale) basti usare anche solo un interrupt generato da un timer per schedulare tutte le operazioni.

Dunque... USB, Ethernet, timer, seriali, SD... tutto in polling?
Nei PIC può darsi, negli ARM sicuramente esistono modi più efficienti.
Quando ho 3 seriali utilizzo 3 interrupt diversi.
Forse fai un po' di confusione tra kernel real time ed interrupt...

[ElNonino]

Originalmente inviato da Davide B.

Dunque... USB, Ethernet, timer, seriali, SD... tutto in polling?
Nei PIC può darsi, negli ARM sicuramente esistono modi più efficienti.
Quando ho 3 seriali utilizzo 3 interrupt diversi.
Forse fai un po' di confusione tra kernel real time ed interrupt...

La scelta di usare o meno interrupt a iosa dipende principalmente dal tipo di applicazione, dall'affidabilità che si vuole raggiungere e sicuramente anche dall'architettura del micro.

E' chiaro che ogni interrupt va ad interromper il normale flusso del programma, comporta il salvataggio di registri, della posizione dell'ultima istruzione e magari anche di qualche variabile nonchè il loro successivo ripristino.

Tutte queste operazioni quindi vanno ad alterare il tempo di ciclo dell'intera applicazione e quando si usano più interrupt, anche se con livelli di priorità ben congegnati, le possibiltà che qualcosa vada storto aumentano. Sicuramente si ha una latenza non predicibile del tempo di ciclo.

Gli ARM ed anche i dsPIC e famiglie superiori hanno le funzioni DMA che consentono ad esempio di ricevere dati senza interrompere la normale schedulazione del programma, quindi basta all' interno del ciclo principale andarsi a leggere il flag del canale DMA e se settato operare di conseguenza a tempo opprtuno.

A me l'uso smodato degli interrupt in applicazioni semplici come quelle che mi trovo normalmente a realizzare non piace e mi ricorda un poco lo 'spaghetti code' irto di 'GOTO' di alcuni programmatori in BASIC; in genere preferisco anche usare più micro piccoli dedicati ad operazioni time-critical anzichè un megaprocessore che fa tutto lui, son scelte.