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ù.