Citazione:
Originalmente inviato da SoldatoSemplice Se tu mi parli di un dsPIC30F allora ti posso concedere che magari realizzare alcune parti in "alti linguaggi" può essere comodo, ma in questo genere di processori l'esadecimale finale è generato, mai da un unico linguaggio ad alto livello, quanto più da un'amalgama di una moltitudine di linguaggi di programmazione, che possono raggiungere alte rese, tanto che sia le applicazioni, sia gli sviluppatori per questo genere di super prototipi sono molto rari, tanto che questi stessi PIC sono rari da trovare in un comune negozio. Vorrei capire cosa intendi per amalgama di linguaggi di programmazione: nel 'C' nativo Microchip è possibile wrappare routine in assembler o scrivere parti in assembler all'interno dello stesso codice , basta usare la direttiva #asm......
forse intendi le librerie disponibili sia in C che in assembler, queste però utilizzano sempre lo stesso linguaggio.
I DSPic si trovano facilmente sia da R&S che tramite Microchip direct che vende pure a privati.
Per il rimanente 98% delle applicazioni (tra cui rientra la totalità delle possibili necessità di un aeromodellista: sai che c'è un utente qui che ha sviluppato un regolatore brushless con un serie 16F? Chiedi di Ivan) possono essere egregiamente risolte da un pic serie 16F. Vero solo in parte, se hai necessità di velocità di elaborazione anche per scopi semplici è meglio passare alla serie 18Fxxxxx, la differenza di costo è irrisoria.
Ho visto utenti passare da un pic 16F ad un 18F solo perchè non avevano abbastanza pin a disposizione, ed usare solo il 3% delle potenzialità di un processore 18F. E questo è un male o forse consente in un secondo tempo di implementare altre funzioni senza dover cambiare micro ? Ripeto parliamo di differenze di costo dell'ordine di 1 euro.....
Alcune delle più elementari tecniche come il multiplexing sviluppato via firmware o il multi-PWM sempre via firmware sono cose ostiche e di solito vengono delegate alle risorse hardware di un PIC, questo perchè svilupparle via software complicherebbe di non poco il codice stesso, in pratica il motivo per cui i programmatori assembler sono così pochi è presto detto: programmare in un linguaggio difficile ma dalle potenzialità nettamente superiori agl altri linguaggi(almeno per questo tipo di architettura) è difficile.
Alla fine: Vuoi usare bene i PIC? Impara l'assembler, avrai in questo modo il controllo di ogni singolo bit. |
Concordo che l' assembler, essendo il linguaggio a più basso livello, è sicuramente più efficiente e meno esoso di risorse, a patto però che sia utilizzato veramente bene, ha l'enorme svantaggio di richiedere tempi di sviluppo, test e debug molto più lunghi che linguaggi ad alto livello.
L'assembler è ottimo per realizzare delle piccole macro o routine in cui è richiesta la massima velocità ed efficienza del codice, od ove le risorse hw siano molto limitate. E' praticamente impossibile sviluppare applicazioni complesse, real-time, multitasking et similia in assembler, a meno di non avere molto tempo a disposizione e moltissima esperienza.
Il controllo di ogni singolo bit lo si ottiene anche utilizzando compilatori 'C' non per nulla la stessa Microchip ( e non solo lei ma anche Cypress, Atmel, Freescale) fornisce gratuitamente il compilatore 'C' e numerose librerie pronte all'uso.
Imparare bene un linguaggio come il 'C' consente poi di utilizzare lo stesso anche in ambiente P.C. per interfacce utente o simili poichè le funzioni base seguono lo standard ANSI in quasi tutti i S.O. windows o linux che sia.
Il mio consiglio è di fare qualche esperimento con l'assembler usando i PIC della serie 12, poi passare alla serie 18Fxxxx ed imparare molto bene a programmare in 'C', investirai bene il tuo tempo e ti divertirai di più.
IMHO