info linguaggio c x pic

[Redpizza]

Ciao Nonino,

in effetti già la prima serie Atmel AVR era nata con un instruction set ASM ottimizzato per compilatori C.
E' comunque da escludere che un compilatore C possa produrre un codice asm più efficiente di una stesura diretta in assembler. Semmai potrà essere uguale e comunque dipendente dalle capacità del programmatore asm.
E' infatti buona norma vedere cosa produce il compilatore C (o Pascal) rispetto a quello che avresti scritto tu.

Comunque sono daccordo che sugli ARM la MChip è l'ultima che prenderei in considerazione (anche se ho appena finito un progetto LCD con PIC24FJ256). Atmel invece è un leader nel settore ARM con prodotti ben colludati.

[ElNonino]

Questa è la spiegazione che da la ST delle migliori prestazioni del C rispetto all' asm dopo aver condotto dei benchmark sulle loro stesse librerie:

"Analysis of the PID timing shows that assembly code is not as fast as C code. The compiler is more efficient in accessing variables than manual optimization (offset computation and data placement in literal pool)."

La descrizione delle librerie, i test ed altro sono contenuti nel UM0585 User manual reperibile sul sito ST, precisamente: www.st.com/stonline/books/pdf/docs/14988.pdf

Non essendo io un mostro del' assembler (e nemmeno del C) mi fido di chi ne sa più di me ed anche delle mie verifiche sperimentali.

In alcuni casi, anche con i PIC, è piuttosto difficile ottimizzare veramente al 100% calcoli complessi in ASM, è possibile che un buon compilatore adotti strategie migliori.

[illez]

Originalmente inviato da ElNonino

Questa è la spiegazione che da la ST delle migliori prestazioni del C rispetto all' asm dopo aver condotto dei benchmark sulle loro stesse librerie:

"Analysis of the PID timing shows that assembly code is not as fast as C code. The compiler is more efficient in accessing variables than manual optimization (offset computation and data placement in literal pool)."

La descrizione delle librerie, i test ed altro sono contenuti nel UM0585 User manual reperibile sul sito ST, precisamente: www.st.com/stonline/books/pdf/docs/14988.pdf

Non essendo io un mostro del' assembler (e nemmeno del C) mi fido di chi ne sa più di me ed anche delle mie verifiche sperimentali.

In alcuni casi, anche con i PIC, è piuttosto difficile ottimizzare veramente al 100% calcoli complessi in ASM, è possibile che un buon compilatore adotti strategie migliori.

Ho letto (velocemente) l'articolo; quello che dici è corretto.
Cioè la funzione PID in ASM è più lenta di quella scritta in C.
Perché il compilatore è in grado di ottimizzare il codice meglio di quanto riesce a fare un umano con l'assembler. Mi chiedo allora perché tenere entrambe le versioni; probabilmente la risposta la potrei trovare leggendo un po' di più, ma non ho tempo

Alla fine stiamo confrontando l'assembler generato da un compilatore e l'assembler generato da un umano. Pare vinca il compilatore

Da come scrivevi mi era sembrato di capire che il C è più veloce dell'ASM, che non ha molto senso...

[marcosinatti]

Più di dieci anni che utilizzo i pic, i primi 4 anni totalmente in assember con la serie 12-16, poi in basic con la serie 16-18, e adesso mi stò avvicinando al C utilizzando anche i DsPic, con non poche difficoltà in quanto autodidatta con basi non troppo solide e lacune ancora da colmare non indifferenti .
E comuque il C non è insormontabile, specialmente se si parte già con le idee chiare di come funziona il pic, questo è il primo progetto sviluppato in C Dc Servo Drive - Marco Sinatti
Dalle mia esperienza posso consigliare i pic dal momento che sono economici, la gamma è vastissima, i tools di sviluppo costano poco e la documentazione completata dalle application notes è più che esaustiva.
Se dovessi tornare indietro, per quanto riguarda il linguaggio io mi farei qualcosina in assembler e poi integrerei subito con il C, altri linguaggi non hanno senso dal momento che il C ha una portabilità enorme, inoltre è il linguaggio più diffuso e il più supportato dalla microchip stessa, fino al punto che producono i processori C oriented come già è stato detto.
Il basic lo lascerei perdere, è il più semplice ma l'ottimizzazione del codice lascia molto a desiderare, anche se rimane la possibilità di inserire delle parti di codice in assembler.
Per quanto riguarda il pascal che io sappia, utilizzandolo sui micro è poco meglio del basic.

[Davide B.]

Dipende da chi scrive il codice cosa significa?
Per quanto mi risulta, il compilatore C genera codice assembler, quindi mi spiegate come fa ad assere più veloce dell'assembler stesso?

Significa che il migliore ottimizzatore è quello che sta tra le tue orecchie.
Ti faccio un esempio. Tempo fa una ditta mi ha chiesto di ottimizzare un progetto fatto su un hcs12, con un micro che costava, all'epoca 8 euro.
Ho riscritto il codice con le stesse funzioni in ASM PIC per un pic che ne costa 3 e 50 e che ha circa un quarto della flash. Conta che sono partiti da un compilato della Metrowerks, che non è una cacca come compilatore.
Programmare in assembler è un arte, le intuizioni di un buon programmatore in assembler un compilatore non le può avere, proprio perchè non ha la visione globale di quanto deve fare l'applicazione. Se il paragone è tra un programmatore MEDIO ed un compilatore MEDIO, posso essere d'accordo che il codice C sia più veloce di un codice ASM. Che sia più compatto ho qualche dubbio.
Per esperienza (160 design in 9 anni) posso affermare che:
1) Se chi scrive assembler sa scrivere assembler non c'è compilatore che gli stia dietro, in termini di efficienza oppure velocità.
2) L'assembler non è morto. Ma con i compilatori attuali lo usi in pochi casi: Quando devi impaccare il codice al massimo o quando devi lesinare il colpo di clock, vedi applicazioni a batteria. Esiste ancora l'approccio dell'autodidatta, che parte con l'assembler, e tutto sommato gli fa pure bene per capire la macchina con cui sta lavorando.
3) Il mondo embedded lavora in C per il 90 % di chi ci lavora. Il 9% lavora in ASM ed in C, il resto vive nelle riserve indiane.
Il programmatore figo utilizza lo IAR. Il vero programmatore utilizza lo GNU.
4) Il programmatore figo utilizza un sistema operativo (kernel) sul microcontrollore. Il vero programmatore il kernel se lo è scritto, o ne ha fatto un porting, o, almeno, ha i sorgenti e ci ha messo le mani perchè non lo soddisfaceva in alcuni punti. Chi usa il PIC18 dovrebbe dare un'occhiata all'OSA. Chi usa ATMEL AVR il BeRTOS. Chi usa ARM il FreeRTOS o il TnKernel.
Quello con maggior numero di port è il FreeRTOS. Questo non perchè usare un kernel per la gestione del micro sia più figo, ma semplicemente perchè programmi meglio e più velocemente, ovviamente in C.

[illez]

Originalmente inviato da Davide B.

Significa che il migliore ottimizzatore è quello che sta tra le tue orecchie.

Non vorrei essere frainteso, perché a volte si scrivono i messaggi nel forum molto velocemente.
La mia domanda è nata dall'affermazione di Elnonino, dove si diceva che alcune funzioni di libreria per ARM sono più veloci in C che in ASM.
Il documento a cui fa riferimento riporta in effetti questo; sembra davvero il contrario rispetto a quanto tu affermi: il compilatore ottimizza meglio dell'umano.
Quello che volevo dire, per chiarezza verso chi è alle prime armi, è che il C è un linguaggio compilato: lo strumento chiamato compilatore genera codice macchina, non ha quindi molto senso dire che il C è più veloce dell'assembler (visto che lo genera).

Penso anche io che un buon programmatore assembler sia in grado di generare codice migliore rispetto al compilatore C, ma la mia è un'affermazione basata su un'esperienza minima sui microprocessori; ho scritto tantissimo codice in C++ ma per applicazioni Win32, dove non ha molto senso usare l'assembler (non sto parlando di applicativi di real time spinto o driver di dispositivo).
Quanto riportato da Elnonino sembra invece dire che in programmi complessi il compilatore riesce a generare codice assembler migliore di quello scritto da un programmatore.

Per tornare in tema e rispondere a elicottero78: credo che per i primi esperimenti sul PIC tu possa iniziare anche con il Basic. E' semplice e non ti crea molti problemi. Immediatamente dopo, o meglio contemporaneamente, studiati un pochino l'assembler: non puoi programmare i PIC (ma nemmeno altri microprocessori) senza conoscere come funzionano e quindi l'assembler. DEVI conoscere l'architettura del processore, i registri, fuse etc. altrimenti non capirai mai cosa stai facendo e perché il tuo programma funziona o non funziona.
Fatto ciò, se vuoi, puoi continuare a usare il basic se realizzi qualcosa di semplice, oppure provare a studiare un po' il C, un linguaggio strutturato che ti rende la vita più semplice rispetto all'assembler ma in grado di generare codice molto efficiente.
Personalmente, sarà per pigrizia, sarà perché lo uso da 20 anni, scrivo in C. Se ho esigenze particolari, vado a vedere l'assembler prodotto per capire se e come ottimizzare.

[Davide B.]

La mia domanda è nata dall'affermazione di Elnonino, dove si diceva che alcune funzioni di libreria per ARM sono più veloci in C che in ASM.

Ed io molto velatamente insistevo sul fatto che l'affermazione la faccia ST. Che, in campo ARM, non gode di un'ottima fama. Chi ha usato i loro primi Cortex sa di cosa parlo.
Per ritornare al tema, continuo a ritenere il C LA scelta. Prendi il compilatore che vuoi, basta che sia C. Perchè per qualsiasi micro ha un compilatore C.
Non è che cosa fai in C tu non lo possa fare in basic o in pascal, si tratta di acquisire degli automatismi nel pensare che ti rimangono. Punto e basta.
Alla fine della fiera, le prime quattro cavolate in C, le fai senza grossi problemi, e quando devi fare quelle successive, ti sei smaliziato e vai avanti.
Il primo impatto è un po' criptico, ma lo scoglio non è così duro.
Credo che la domanda sul C per microcontrollori andrebbe impostata così.
Quali sono i primi passi che devo fare per poter programmare in C un microcontrollore?
La MIA risposta è:
Passo 0: Trovati un compilatore, un programmatore o un debugger che ti consenta di scaricare il compilato nel micro ed una scheda FUNZIONANTE da poter utilizzare per i tuoi esperimenti. Provi a buttarci dentro un programma demo qualsiasi. Quando programmi ed esegui, puoi passare al punto 1.
Passo 1: Scrivi il classico programma HelloWorld. Che, per i micro NON è questo

#include <stdio.h>
 int main() 
 {
        printf("hello, world");
        return 0;
 }

Ma il codice per far lampeggiare dei led. Ovvero, ad esempio, questo (Mikroc, Micro PIC16F887)

void main() 
{

  ANSEL  = 0;            // I pin AN sono I/O Digitali
  ANSELH = 0;
  C1ON_bit = 0;          // Disabilito i comparatori
  C2ON_bit = 0;

  TRISA = 0x00;          // Imposto la direzione della porta come uscite
  TRISB = 0x00;          // Imposto la direzione della porta come uscite    
  TRISC = 0x00;          // Imposto la direzione della porta come uscite    
  TRISD = 0x00;          // Imposto la direzione della porta come uscite    
  
  do {
    PORTA = 0x00;        // Spegni i led su PORTA
    PORTB = 0x00;        // Spegni i led su PORTB
    PORTC = 0x00;        // Spegni i led su PORTC
    PORTD = 0x00;        // Spegni i led su PORTD
    Delay_ms(1000);      // delay di 1 secondo
    
    PORTA = 0xFF;        // Accendi i led su PORTA
    PORTB = 0xFF;        // Accendi i led su PORTB
    PORTC = 0xFF;        // Accendi i led su PORTC
    PORTD = 0xFF;        // Accendi i led su PORTD
    Delay_ms(1000);      // delay di 1 secondo

  } while(1);            // Cicla per sempre
}

Notare che questo programma è la versione per sboroni che fa lampeggiare tutti i led (più o meno) attaccati, e che il ciclo "forever" lo si può scriver in almeno altri 3 modi semplici(for (;;), while (1), goto)
Dopo il punto 1, fatto funzionare e capito cosa fanno le varie sitruzioni, si può andare avanti con semplici circuiti combinatori (leggo degli ingressi, setto delle uscite), fino alle cose più complicate.
Ma QUESTO è il punto di partenza, ovviamente secondo me.