info linguaggio c x pic

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

[ElNonino]

Gli amici Davide B & Illez mi trovano chiaramente in accordo al 100%, sicuramente asm è teoricamente, ed in molti casi anche praticamente, più compatto e più veloce di qualsiasi 'C'.

I problemi dell' assembler sono solo 2: la curva di apprendimento ed il tempo richiesto per scrivere un applicazione relativamente complessa.

Fino a quando ci si limita a far lampeggiare led o qualche applicazione di poco più sofistica, l'asm è a portata anche del pivello, se iniziamo a parlare di filtri, calcoli matematici e trigonometrici complessi, pid.... le cose si complicano non poco e poichè nel mondo attuale il 'time to market' è importante....

Condivido quanto citato per il gcc ed anche i s.o. personali, è ciò che utilizzo da anni con deroghe al solo C18 di microchip (anche se nasconde qualche bug fra le sue pieghe).

All' amico faustog_2 invece mi permetto di suggerire di non dare consigli 'leggeri' per l 'asm ad un principiante; mi pare che tu abbia già problemi a gestire una semplice seriale in asm su PIC16.

[Davide B.]

Visto che mi piace fare le cose per bene, allego anche il compilato.

_main:

;LedBlinking.c,26 ::                 void main()
;LedBlinking.c,29 ::                 ANSEL  = 0;            // I pin AN sono I/O Digitali
        CLRF       ANSEL+0
;LedBlinking.c,30 ::                 ANSELH = 0;
        CLRF       ANSELH+0
;LedBlinking.c,31 ::                 C1ON_bit = 0;          // Disabilito i comparatori
        BCF        C1ON_bit+0, 7
;LedBlinking.c,32 ::                 C2ON_bit = 0;
        BCF        C2ON_bit+0, 7
;LedBlinking.c,34 ::                 TRISA = 0x00;          // Imposto la direzione della porta come uscite
        CLRF       TRISA+0
;LedBlinking.c,35 ::                 TRISB = 0x00;          // Imposto la direzione della porta come uscite
        CLRF       TRISB+0
;LedBlinking.c,36 ::                 TRISC = 0x00;          // Imposto la direzione della porta come uscite
        CLRF       TRISC+0
;LedBlinking.c,37 ::                 TRISD = 0x00;          // Imposto la direzione della porta come uscite
        CLRF       TRISD+0
;LedBlinking.c,39 ::                 do {
L_main0:
;LedBlinking.c,40 ::                 PORTA = 0x00;        // Spegni i led su PORTA
        CLRF       PORTA+0
;LedBlinking.c,41 ::                 PORTB = 0x00;        // Spegni i led su PORTB
        CLRF       PORTB+0
;LedBlinking.c,42 ::                 PORTC = 0x00;        // Spegni i led su PORTC
        CLRF       PORTC+0
;LedBlinking.c,43 ::                 PORTD = 0x00;        // Spegni i led su PORTD
        CLRF       PORTD+0
;LedBlinking.c,44 ::                 Delay_ms(1000);      // delay di 1 secondo
        MOVLW      11
        MOVWF      R11+0
        MOVLW      38
        MOVWF      R12+0
        MOVLW      93
        MOVWF      R13+0
L_main3:
        DECFSZ     R13+0, 1
        GOTO       L_main3
        DECFSZ     R12+0, 1
        GOTO       L_main3
        DECFSZ     R11+0, 1
        GOTO       L_main3
        NOP
        NOP
;LedBlinking.c,46 ::                 PORTA = 0xFF;        // Accendi i led su PORTA
        MOVLW      255
        MOVWF      PORTA+0
;LedBlinking.c,47 ::                 PORTB = 0xFF;        // Accendi i led su PORTB
        MOVLW      255
        MOVWF      PORTB+0
;LedBlinking.c,48 ::                 PORTC = 0xFF;        // Accendi i led su PORTC
        MOVLW      255
        MOVWF      PORTC+0
;LedBlinking.c,49 ::                 PORTD = 0xFF;        // Accendi i led su PORTD
        MOVLW      255
        MOVWF      PORTD+0
;LedBlinking.c,50 ::                 Delay_ms(1000);      // delay di 1 secondo
        MOVLW      11
        MOVWF      R11+0
        MOVLW      38
        MOVWF      R12+0
        MOVLW      93
        MOVWF      R13+0
L_main4:
        DECFSZ     R13+0, 1
        GOTO       L_main4
        DECFSZ     R12+0, 1
        GOTO       L_main4
        DECFSZ     R11+0, 1
        GOTO       L_main4
        NOP
        NOP
;LedBlinking.c,52 ::                 } while(1);            // Cicla per sempre
        GOTO       L_main0
;LedBlinking.c,53 ::                 }
        GOTO       $+0
; end of _main

Come si può ben notare, questo programma è assolutamente non ottimizzato, molte istruzioni si possono scrivere diversamente ed il codice può essere quasi dimezzato.
Ad esempio per scrivere 255 nei porti viene ricaricato 4 volte il working register, mentre in realtà si può ricaricarlo una volta sola.
Inoltre la funzione di delay in realtà viene tradotta come macro ed il codice duplicato, cosa che nessun programmatore medio farebbe.
Il codice in C è comunque molto manutenibile, nel senso che volendo caricare un gioco di led diverso non bisogna stravolgere la struttura del programma come invece si dovrebbe fare in caso di assembler, nel caso di codice ottimizzato.

e poichè nel mondo attuale il 'time to market' è importante....

La cosa è vera solo in parte, perchè quando il numero dei pezzi è basso, allora il tempo di lavoro (ovvero il costo di sviluppo) influisce molto sul costo finale del prodotto. Quando invece il numero dei pezzi è alto, allora dieci centesimi di risparmio per 100.000 pezzzi all'anno, perchè si usa un micro più piccolo, ripagano il tempo di sviluppo di un buon programmatore.

[Redpizza]

Ha ragione Illez, dopo aver dissertato sui massimi sistemi (per esperti), dove si può discutere per anni, rispondiamo alla richiesta di Eli78...

Teniamo conto che il nostro amico ha già qualche difficoltà solo a mettere a fuoco il concetto di sviluppare su PC un software che poi gira su un micro.

Teniamo conto che per lui è un hobby (non ci deve campare) per cui non avrà, e forse non vorrà, investire troppo del suo tempo libero.

E che per lui il Time-to-market si traduce in "vedere presto dei risultati", ovvero trovare motivazione per non lasciar perder tutto alle prime difficoltà.

Detto ciò sono ancora convinto che sia meglio per lui un ambiente di sviluppo integrato di tipo didattico, dove trova tutto adeguato alle sue capacità.
Il Pascal è un ottimo compromesso tra le limitazioni di un Basic e le inevitabili complicazioni di un C.
Fermo restando che, come ha già detto qualcuno, la cosa ancora più importante è forse quella di imparare a conoscere il tuo Microcontroller.
E qui la mia preferenza ricade su Atmel, magari tra gli utimi XMega.

Se ti interessa avere informazioni specifiche mandami pure una mail.
Buona scelta.

[elicottero78]

cavolo ragazzi,vi ringrazio tutti,ma sono solo un tornitore,leggendo tutti i vostri commenti ragionati professionalmente,mi vien voglia di chievervi scusa di aver aperto questo post.

la mia intenzione è quella di dedicare il mio tempo serale x imparare qualcosa che male non fa......qualcosa in piu che magari ti da la possibilità di poter creare un progettino che fino a ieri sarebbe stato inpossibile

non volevo scomodarvi,io voglio imparare ma solo x hobby

comunque ora sto cercando di capire il linguaggio c,poi magari riproverò con assembler,che mi sembra complicato......ma solo con il conoscere troverò quello che piu mi servirà.....comunque grazie mille a tutti

[Davide B.]

cavolo ragazzi,vi ringrazio tutti,ma sono solo un tornitore,leggendo tutti i vostri commenti ragionati professionalmente,mi vien voglia di chievervi scusa di aver aperto questo post.
la mia intenzione è quella di dedicare il mio tempo serale x imparare qualcosa che male non fa......qualcosa in piu che magari ti da la possibilità di poter creare un progettino che fino a ieri sarebbe stato inpossibile

Ma che scherzi?
Questo forum è frequentato da professionisti e "cantinari", e da tanti cantinari che si sentono professionisti... forse me compreso.
Ora. Ti ho segnalato il K&R per darci una "spolverata". Ovvero per capire i costrutti. Che sono quattro cose in croce, cosa che puoi fare su un manuale qualsiasi. Il K&R è la "bibbia" del c, che si basa su una versione che è estremamente rigorosa. Che è un subset dell'ANSI c.
Programmare con rigore e con le stesse metodologie è un buon sistema.
Detto questo ti ho scritto dall'inizio alla fine un esempio base, che ti invito a provare.
Da li puoi partire a ragionare.
Tieni conto che chi sa le cose veramente non ha paura di insegnarle, come chi vuole imparare le cose realmente non ha paura di chiedere.
E spesso puoi imparare di più ascoltando o parlando con un professionista per un'ora che sperimentando per dei giorni.
Almeno, a me è capitato così, quando, all'epoca il buon Ricciardi (il vero guru dell'ARM in Italia) è venuto a trovarmi in ufficio.
In meno di una giornata ho capito quanto avrei potuto fare da solo in mesi da solo.
Per cui non ti fare problemi a chiedere, eventualmente anche in privato.
Se poi ti sei scoraggiato (e fai male) e vuoi leggere un vero corso passo passo di programmazione in assembler per i "pic dopati", ovvero gli SX, con abbondanti spiegazioni (ma purtroppo in inglese), veramente, ma veramente ben fatto, ti lascio questo link
http://www.parallax.com/Portals/0/Do...AssemforSX.pdf

[akrobaticone]

Ho letto la discussione e colo l'occasione per segnalarvi questo
SDCC - Small Device C Compiler
è un compilatore open source e l'ho usato con successo per qualche progettino
ho usato anche questo
Piklab Homepage - Home
come ambiente di sviluppo e uso programmatore

Se può interessare ho un vecchissimo corso di C della Jackson (Per dos...recentissimo) molto semplice ,ma esaustivo.

[illez]

Originalmente inviato da Davide B.

Se poi ti sei scoraggiato (e fai male) e vuoi leggere un vero corso passo passo di programmazione in assembler per i "pic dopati", ovvero gli SX, con abbondanti spiegazioni (ma purtroppo in inglese), veramente, ma veramente ben fatto, ti lascio questo link
http://www.parallax.com/Portals/0/Do...AssemforSX.pdf

Davide, che sono questi SX??

[claudio476]

un saluto a tutti..

x rispondere alla sete di Elicottero78 di cimentarsi con i PIC:

la mia esperienza con i pic è partita con MikroBasic e scheda di sviluppo easyPic 2 comprata x 50 euro su ebay, per iniziare è il modo migliore, hai una scheda completa di LCD, led e quello che serve per iniziare con i PIC, compreso il linguaggio di programmazione a scelta tra C e Basic.

Poi sono passato al C, ho istallato Mplab e il compilatore C18 e l'hitec-C per la serie 10 e 16.. tutta un'altra musica.. nel senso che è la differenza che si trova tra fare una pagina web con il blocco note o con front-page, sicuramente più complicato ed articolato come metodo di scrittura del codice ma ti offre maggiore controllo su quello che vuoi far fare al PIC e poi.. è tutto software GRATUITO!

Recentemente ho preso il PicKit3, 40 euro per un debugger non è male!

Qundi in sintesi:
-Il microBasic è più semplice ed immediato
-usa una scheda di prototipazione tipo easyPic almeno vai sul sicuro sulla parte hardware e se qualche cosa non funziona sei sicuro che il problema è software
-se vuoi usare il C, istallati Mplab, hitec-c e C18, gratuiti e ufficiali microchip