@RedPizza: uso professionalmente il Pascal in ambiente win e lin dai tempi del primo Turbo Pascal Borland & Kylix, poi da Delphi 1 fino al 2009, ottimo per S.O. ad alto livello per i microembedded decisamente meno indicato.

Sempre per professione utilizzo micro Microchip e Cypress da oltre 10 anni anche in campo automotive e la MC è sicuramente quella che offre una gamma più ampia di prodotti dalla serie 8 bit PIC10 fino ai DsPic ed ai recenti a 16 e 32 bit, credo che sia già disponibile (o lo sarà a breve) anche una preserie ARM.

Il linguaggio 'C' è sicuramente il più efficiente ed il più pagante in ambito micro embedded e non solo, lo consiglio vivamente anche ad un principiante perchè quello che imparerà sarà sicuramente 'riciclabile' facilmente in futuro.

Molti micro recenti sono progettati a livello strutturale per ottimizzare al massimo le prestazioni proprio tenendo conto dei compilatori 'C', in alcuni casi superiori all' assembler (ad esempio alcune funzioni di libreria per PID, FIR ed IIR per processori ARM ST sono più veloci in C che in ASM).

:yeah:

Appoggio tutte le considerazioni sul C, ma mi spieghi quest'ultima affermazione?
Come fanno alcune librerie ad essere più veloci in C che in ASM?
Considerato che il C genera del codice macchina, perché non riportarlo nelle librerie ASM? Sarebbero la stessa cosa no?

1) Dipende da chi scrive il codice.
2) Si parla di ARM ST. :fiu:

Quanto alla disponibilità di un core ARM per Microchip... Non ne ho sentito parlare, e la cosa mi lascia MOOOOOOOOOOOOOOOOOOOOOOOOOLTO perplesso, visto che in Microchip sono estremamente autarchici, e dovrebbero dismettere il 99% dei loro ambienti di sviluppo.

Continuo a non capire...

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?

grazie

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.

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.

:yeah:

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 :rolleyes:

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

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

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 :D.
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.

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.

assembly
 

ti consiglio di affrontare il tema direttamente con assebly