Programmare con MikroBASIC
Matteo
microcontrollori, in particolare mi interessano i PIC. Essendo
totalmente a digiuno di programmazione ho pensato fosse meglio partire
dal BASIC e ho acquistato sia il MikroBASIC che la demoboard EasyPIC3.
Ho letto abbastanza attentamente tutta la documentaizone a corredo ed
in effetti non è difficilissimo da capire...
Però passare dall'idea alla pratica è un'altra cosa... Fintanto che si
devono fare esperimenti va tutto bene ma per fare cose già un po più
complicate è tutta un'altra storia!
Per il mio primo progetto vorrei realizzare un simulatore dei
lampeggianti della polizia per modellismo. In pratica mentre uno dei
lampeggianti avrà un ciclo fisso (es.: 100ms on, 900 off, 100 on, etc)
l'altro avrà un tempo leggermente maggiore (es.: 100ms on, 1000 off,
100 on, 1000 off etc).
Il problema apparentemente banale non lo sono riuscito a risolvere con
un algoritmo semplice...
Quello che ho scritto è questo (ma manco a dirlo non funziona):
program Lampeggia_LED
dim T1 as word
dim T2 as word
dim T3 as word
dim T4 as word
dim T5 as word
dim T6 as word
dim T7 as word
dim T8 as word
main:
trisb = 00000001
trisc = 00000001
portb.0 = 0
portc.0 = 0
T1 = 0
T4 = 2000
T5 = 200
T6 = 200
inizio:
T7 = T1 + T5
T2 = T4
T3 = T5
T8 = T1
portb.0 = 1
if T5 > T1 then
T2 = T2 - T1
T3 = T3 - T1
portc.0 = 1
vdelay_ms(T3)
T2 = T2 - T3
portb.0 = 0
T2 = T2 - T1
portc.0 = 0
else
vdelay_ms(T5)
T2 = T2 - T5
T8 = T8 - T5
portb.0 = 0
if T8 = 0 then
else
vdelay_ms(T8)
end if
T2 = T2 - T8
portc.0 = 1
vdelay_ms(T5)
T2 = T2 - T5
portc.0 = 0
end if
if T2 = 0 then
else
vdelay_ms(T2)
end if
T1 = T1 + T6
if T1 = T4 then T1 = 0
end if
goto inizio
end.
Chi mi sa dare un occhio, una mano, un suggerimento? ;-)
Grazie in anticipo
--
Matteo
Matteo
> Salve a tutti, da qualche giorno mi sono avvicinato al mondo dei
> microcontrollori, in particolare mi
Beh mi rispondo da solo ;-)
Stanotte mi è venuta l'illuminazione...
Il problema non era tanto di programmazione ma di logica... cambiandola
radicalmente ho risolto in meno di 10 minuti di programmazione:
program Lampeggia_LED_3
const led_1_on as word = 300
const led_2_on as word = 300
const led_1_off as word = 2000
const led_2_off as word = 2100
const interv as word = 50
dim A as word 'Tempo accensione LED1
dim A2 as word 'Tempo spegnimento LED1
dim B as word 'Tempo accensione LED2
dim B2 as word 'Tempo spegnimento LED2
dim stato_1 as byte
dim stato_2 as byte
main:
trisb.0=0
trisb.1=0
portb.0=1
portb.1=1
stato_1=1
stato_2=2
parti:
if stato_1=1 then
if A < led_1_on then A=A+interv
else
A=0
portb.0=0
stato_1=0
end if
else
if A2 < led_1_off then A2=A2+interv
else
A2=0
portb.0=1
stato_1=1
end if
end if
if stato_2=1 then
if B < led_2_on then B=B+interv
else
B=0
portb.1=0
stato_2=0
end if
else
if B2 < led_2_off then B2=B2+interv
else
B2=0
portb.1=1
stato_2=1
end if
end if
vdelay_ms(interv)
goto parti
end.
--
Matteo
mmm
> Salve a tutti, da qualche giorno mi sono avvicinato al mondo dei
> microcontrollori, in particolare mi interessano i PIC. Essendo
> totalmente a digiuno di programmazione ho pensato fosse meglio partire
> dal BASIC e ho acquistato sia il MikroBASIC che la demoboard EasyPIC3.
>
> Ho letto abbastanza attentamente tutta la documentaizone a corredo ed in
> effetti non è difficilissimo da capire...
>
> Però passare dall'idea alla pratica è un'altra cosa... Fintanto che si
> devono fare esperimenti va tutto bene ma per fare cose già un po più
> complicate è tutta un'altra storia!
>
> Per il mio primo progetto vorrei realizzare un simulatore dei
> lampeggianti della polizia per modellismo. In pratica mentre uno dei
> lampeggianti avrà un ciclo fisso (es.: 100ms on, 900 off, 100 on, etc)
> l'altro avrà un tempo leggermente maggiore (es.: 100ms on, 1000 off, 100
> on, 1000 off etc).
>
rimango della mia idea che sarebbe bene ti spratichissi un po' con le
tecniche di programmazione di base prima di provare a sviluppare per
sistemi embedded
ti ho gia' consigliato di provare qualche basic per DOS dove avresti a
disposizione un debugger integrato per vedere l'effetto che fa.
>
> Chi mi sa dare un occhio, una mano, un suggerimento? ;-)
prova qualcosa di questo tipo:
' richiede una funzione msecdelay che implementa il ritardo
' ed 2 funzioni lamp1 e lamp2 per accendere/spegnere le
' rispettive lampade da implementare
' i tipi integer, boolean sono standard per il VisualBasic
' ma potresti dover fare qualche adattamento per il tuo,
' certamente il tipo boolean NON e' supportato dal
' QBasic o dal Basic Compiler Microsoft DOS
' come puoi notare il ciclo while 'avanza' per quanti di
' tempo pari al delay minimo
program Lampeggia_LED
' minimo comune multiplo tra i vari tempi on e off
Const MCMPeriodo = 100
' i 4 tempi on e off espressi come multipli del suddetto
Const tim1ReloadON as Integer = 1
Const tim2ReloadIN as Integer = 1
Const tim1ReloadOFF as Integer = 9
Const tim2ReloadOFF as Integer = 10
' due timer ( contatori ) software per i due lampeggi
Dim tim1 As Integer
Dim tim2 As Integer
' due variabili di stato ( acceso/spento) per i due lampeggi
Dim state1 As Boolean
Dim state2 As Boolean
' le necessarie inizializzazioni si parte tutto spento con i timer
' al loro tempo max
tim1 = tim1ReloadOFF
tim2 = tim2ReloadOFF
state1 = False
state2 = False
While True ' per sempre :-)
tim1 = tim1 - 1 ' decrementa un timer e se termina ...
If tim1 = 0 Then
If state1 = True Then ' agisci , ricarica il timer col
tim1 = tim1ReloadOFF ' valore giusto
Else
tim1 = tim1ReloadON
End If
state1 = Not state1 ' cambia stato
lamp1 state1 ' accendi/ spegni la lampada
End If
tim2 = tim2 - 1 ' esattamente uguale per l'altra
If tim2 = 0 Then ' lampada
If state2 = True Then ' cambiano solo le variabili
tim2 = tim2ReloadOFF
Else
tim2 = tim2ReloadON
End If
state2 = Not state2
lamp2 state2
End If
msecdelay MCMPeriodo ' perdi tempo in maniera controllata
Wend
End
>
> Grazie in anticipo
>
marcick
"Matteo" <mat...@nospam.it> ha scritto nel messaggio
news:2007043022323175249-matteo@nospamit...
> Quello che ho scritto è questo (ma manco a dirlo non funziona):
> trisb = 00000001
>
> trisc = 00000001
a me pare che hai sbagliato le istruzioni di cui sopra, dichiarando come
ingressi quelli che volevi fossero uscite e viceversa.
Marco
Marco
> Beh mi rispondo da solo ;-)
Hai risolto, bene per te.
Perņ ti consiglio di dare una letta qui
http://it.wikipedia.org/wiki/Indentazione
Marcus
"marcick" <mar...@iol.it> ha scritto nel messaggio
news:46370086$0$36445$4faf...@reader5.news.tin.it...
Strano che non sia arrivato ancora nessuno a dire che stai perdendo tempo
con il basic perche' il C e' superiore
Francesco Sacchi
> Strano che non sia arrivato ancora nessuno a dire che stai perdendo tempo
> con il basic perche' il C e' superiore
>
Eccomi: stai perdendo tempo con il basic, il C è superiore! :)
Ciao
Marcus
"Francesco Sacchi" <frasa...@libero.it> ha scritto nel messaggio
news:f17a5c$532$1...@nnrp.ngi.it...
Peccato che non andiate a vedere che questi compilatori generano identico
codice assembler e non direttamente codice macchina
Francesco Sacchi
> Peccato che non andiate a vedere che questi compilatori generano identico
> codice assembler e non direttamente codice macchina
Bhe, il codice assembly *è* il codice direttamente eseguito dalla
macchina, solo scritto in modo più comprensibile per un essere umano.
C'è una corrispondeza biunivoca tra riga in assembly <-> codice macchina.
Non conosco il compilatore in questione e quindi non so che tipo di
codice generi, ma so tante altre cose.
La generazione di codice più o meno buono non è l'unica cosa che conta
quando si sceglie un sistema di sviluppo o un linguaggio.
Conta di più la standardizzazione, la compatibilità, la portabilità, la
disponibilità di vari tool di sviluppo, la possibilità di mantenere il
codice nel tempo, il supporto, etc...
Tutte cose, che il
CompilatoreBasicFattoDallaMiaDittaPreferitaSconosciuta non può avere.
Tutti sono buoni ad inventarsi un nuovo sistema di sviluppo o linguaggio
ad-hoc, che funziona tutto sommato benino. Ma se ci affidiamo a sistemi
non standard, saremo legati al
CompilatoreBasicFattoDallaMiaDittaPreferitaSconosciuta a vita.
Queste aziende cercano di accalappiarci con delle belle IDE, linguaggi
semplici che fanno credere che programmare embedded sia una passeggiata,
anche per chi non vuole studiarsi un minimo di elettronica/informatica
di base.
Tutto sommato può andare bene se vogliamo solo divertirci, ma se vuoi un
minimo approfondire le cose o vuoi farlo professionalmente, rimani
fregato in questa geniale mossa commerciale.
Quindi se vogliamo imparare a fare qualcosa di utile e divertente
(programmare un microcontrollore) perchè non farlo nel modo più proficuo?
E' così tremendo avere miliardi di righe di codice già fatto, esempi,
tutorial su come programmare, comunità di sviluppatori, compilatori e
tool vari di mille aziende diverse, molti addirittura gratis (GPL)?
Per questo ritengo che "stai perdendo tempo con il basic", alla luce di
tutto questo "il C è superiore".
Ciao :)
Marcus
>
> Per questo ritengo che "stai perdendo tempo con il basic", alla luce di
> tutto questo "il C è superiore".
>
> Ciao :)
Il basic arriva esattamente dove arriva il C in ambito embedded, poi la
verita' e che voi avete paura che il primo che arrivi usando due semplici
istruzioni in basic possa fare tutto quello che voi fate in C conla
differenza che in basic anche chi non sa programmare capira' qualcosa.
Matteo
> rimango della mia idea che sarebbe bene ti spratichissi un po' con le
> tecniche di programmazione di base prima di provare a sviluppare per
> sistemi embedded
> ti ho gia' consigliato di provare qualche basic per DOS dove avresti a
> disposizione un debugger integrato per vedere l'effetto che fa.
Si, vero. Però mi pare di capire che ogni architettura ha il suo
dialetto BASIC e vorrei imparare direttamente sui PIC ;-)
>> Chi mi sa dare un occhio, una mano, un suggerimento? ;-)
> prova qualcosa di questo tipo:
> program Lampeggia_LED
Interessante, stanotte ho scritto un programma molto simile, ben prima
di vedere il tuo post probabilmente a causa della lentezza di
propagazione dei messaggi al server dove posto io ;-)
Ancora una volta lo stesso problema si può risolvere in modi
completamente diversi e spesso cambiare gli occhiali aiuta ;-)
Grazie molte per i suggerimenti.
Nei prossimi giorni vedrò di andare avanti.
Nel frattempo sto leggendo un bel libro: Programmazione BASIC per PIC
di Giovanni Di Maria edito da Inware Edizioni. Molto chiaro e semplice
da seguire.
Ciao
--
Matteo
Matteo
> Hai risolto, bene per te.
> Però ti consiglio di dare una letta qui
> http://it.wikipedia.org/wiki/Indentazione
Uhm, hai ragione, è che ero preso dalla mia idea che trovavo già
sufficiente per me quella indentaizone minima ;-)
Però per chi lo deve rileggere è meglio fare come dici tu.
Ciao
--
Matteo
pozz
> Il basic arriva esattamente dove arriva il C in ambito embedded, poi la
> verita' e che voi avete paura che il primo che arrivi usando due semplici
> istruzioni in basic possa fare tutto quello che voi fate in C conla
> differenza che in basic anche chi non sa programmare capira' qualcosa.
Scusate se mi intrometto nella vostra discussione, ma a leggere queste cose non
si può stare zitti (anche perchè, alla fine, qualcuno che ti legge potrebbe pure
crederci).
Il punto di vista di Francesco è ben articolato e motivato, il tuo sembra
derivare troppo da una presa di posizione aprioristica, senza troppe motivazioni.
Io vorrei mettere in evidenza, oltre a tutto quello che dice Francesco, un altro
punto di vista. Quando si parla di Basic per PIC, in genere si parla di PicBasic
(quella schifezza fatta dalla Melabs). Purtroppo, per alcuni progettini, mi
hanno *costretto* ad usare questo linguaggio di programmazione. Inutile dire
che, poichè il progettino era un tantinello complesso, in Basic ho penato molto
di più che in C.
Secondo me, la maggiore limitazione del PicBasic è l'impossibilità di utilizzare
una delle tecniche *fondamentali* della programmazione, qualcosa che ti
insegnano pure a scuola. In pratica non è possibile dividere il programma
principale in subroutine con tanto di passaggio dei parametri.
Tutti i compilatori C, essendo il C uno standard, permettono di creare delle
funzioni che accettano dei parametri e ritornano dei valori. Questi parametri
sono normalmente passati sullo stack ma, visto che i PIC hanno risorse molto
limitate, i compilatori li gestiscono tramite delle variabili globali. Ma almeno
la cosa è fattibile.
In PicBasic una cosa del genere non si può fare, o almeno io mi sono sbattuto
tantissimo ma non ci sono riuscito. Le uniche routine che si possono richiamare
con passaggio di parametri sono quelle delle librerie fornite con il
compilatore. Ma non posso sperare di utilizzare solo quelle librerie! In genere,
alcune librerie me le scrivo anche io.
Ovvio che l'hobbysta che vuole far accendere due led e non deve lavorare con la
programmazione dei micro, può tranquillamente rivolgersi a soluzioni semplici
come il Basic. Ma sappia subito che troverà grosse difficoltà non appena i suoi
desideri si complicano leggermente (non ho parlato della gestione degli
interrupt nel PicBasic... una pena totale!).
Io non credo che il C sia più difficile del Basic... alla fine sono entrambi
linguaggi ad alto livello. L'istruzione
x += 3+y;
in Basic si scrive
x = x + 3 + y
Non è proprio così diverso. La facilità del PicBasic sta più che altro nelle
numerose librerie a disposizione. Ma anche alcuni compilatori C sono ricchi di
librerie che semplificano molto il problema (MikroC). La cosa importante, però,
è che il programmatore possa scriversi le *proprie* librerie con il meccanismo
semplicissimo delle subroutine.
Ovvio che non conosco tutti i compilatori Basic per PIC e queste considerazioni
valgono principalmente per il PicBasic Pro. Se qualcuno conosce compilatori
Basic per PIC che hanno le limitazioni di cui sopra, son ben contento di
conoscerli (forse il MikroBasic si salva).
Ma, in queste ipotesi, sarebbero comunque vere tutte le considerazioni di
Francesco che comunque mi porterebbero ad utilizzare il C, piuttosto che il Basic.
Cercate di rendervi conto cosa succede se dovete trasferire un progetto Basic di
1000 righe su un altro microcontrollore che non sia un semplice PIC, magari un
Atmel AVR o un ARM. Qui, se i compilatori Basic non si trovano, i compilatori C
la fanno da padrone. Portare un programma C per PIC ad ARM non sarà una cosa
semplice, ma almeno si impiegherà molto meno tempo che partire dal Basic per PIC.
Matteo
> Per questo ritengo che "stai perdendo tempo con il basic", alla luce di
> tutto questo "il C è superiore".
Allora, il discorso è che io *oggi* *non* so nulla di programmazione.
Il Basic è certamente la partenza più soft per un neofita e su questo
almeno penso di aver visto giusto.
Successivamente non mi vorrei far mancare la capacità di programmare
anche in C, che pur essendo un linguaggio di alto livello come il BASIC
ha una maggiore portabilità e forse per alcuni versi anche versatilità.
Ma in realtà il mio obiettivo finale è di capire qualcosa di Assembly
perchè questo è l'unico sistema ad oggi per poter un codice pulito e
versatile al 100%.
A questo punto, avendo in mente quanto sopra mi sono affidato ai
compilatori Mikroelektronika perchè hanno compilatori per basic, pascal
e c, anche per altri microcontrollori, e rendono semplice inserire
nello stesso programma parti di codice Basic, C, Pascal e Assembler...
e ti pare poco? ;-)
Ciao
--
Matteo
Marcus
"pozz" <pNoOzSz...@gmail.com> ha scritto nel messaggio
news:NaKZh.22750$uJ5.4...@twister2.libero.it...
> Marcus ha scritto:
>> Il basic arriva esattamente dove arriva il C in ambito embedded, poi la
>> verita' e che voi avete paura che il primo che arrivi usando due semplici
>> istruzioni in basic possa fare tutto quello che voi fate in C conla
>> differenza che in basic anche chi non sa programmare capira' qualcosa.
>
> Scusate se mi intrometto nella vostra discussione, ma a leggere queste
> cose non si può stare zitti (anche perchè, alla fine, qualcuno che ti
> legge potrebbe pure crederci).
>
> Il punto di vista di Francesco è ben articolato e motivato, il tuo sembra
> derivare troppo da una presa di posizione aprioristica, senza troppe
> motivazioni.
Assolutamente secondo il mio parere il voler usare il C in ambito embedded
non porta a nessuna funzione superiore che non si possa fare con il Basic
>
> Secondo me, la maggiore limitazione del PicBasic è l'impossibilità di
> utilizzare una delle tecniche *fondamentali* della programmazione,
> qualcosa che ti insegnano pure a scuola. In pratica non è possibile
> dividere il programma principale in subroutine con tanto di passaggio dei
> parametri.
Questa e' una tua convinzione sbagliata, si puo' usare Include e quindi
dividere il programma
>
> Tutti i compilatori C, essendo il C uno standard, permettono di creare
> delle funzioni che accettano dei parametri e ritornano dei valori. Questi
> parametri sono normalmente passati sullo stack ma, visto che i PIC hanno
> risorse molto limitate, i compilatori li gestiscono tramite delle
> variabili globali. Ma almeno la cosa è fattibile.
> In PicBasic una cosa del genere non si può fare, o almeno io mi sono
> sbattuto tantissimo ma non ci sono riuscito. Le uniche routine che si
> possono richiamare con passaggio di parametri sono quelle delle librerie
> fornite con il compilatore. Ma non posso sperare di utilizzare solo quelle
> librerie! In genere, alcune librerie me le scrivo anche io.
Caspita proprio il basic permette di definire solo variabili globali
>
> Ovvio che l'hobbysta che vuole far accendere due led e non deve lavorare
> con la programmazione dei micro, può tranquillamente rivolgersi a
> soluzioni semplici come il Basic. Ma sappia subito che troverà grosse
> difficoltà non appena i suoi desideri si complicano leggermente (non ho
> parlato della gestione degli interrupt nel PicBasic... una pena totale!).
>
Il picbasic che tu definisci schifezza ha tante istruzioni che loportano ad
assomigliare al C
>
> Io non credo che il C sia più difficile del Basic... alla fine sono
> entrambi linguaggi ad alto livello. L'istruzione
> x += 3+y;
> in Basic si scrive
> x = x + 3 + y
> Non è proprio così diverso. La facilità del PicBasic sta più che altro
> nelle numerose librerie a disposizione. Ma anche alcuni compilatori C sono
> ricchi di librerie che semplificano molto il problema (MikroC). La cosa
> importante, però, è che il programmatore possa scriversi le *proprie*
> librerie con il meccanismo semplicissimo delle subroutine.
Non so se rispondi solo per partito preso, in C come in basic se non hai
librerie belle e pronte, o rinunci al progetto oppure te le scrivi in
assembler, oppure mi vuoi dire che senza librerie apposite con il C puoi
fare.........
> Ovvio che non conosco tutti i compilatori Basic per PIC e queste
> considerazioni valgono principalmente per il PicBasic Pro. Se qualcuno
> conosce compilatori Basic per PIC che hanno le limitazioni di cui sopra,
> son ben contento di conoscerli (forse il MikroBasic si salva).
>
> Ma, in queste ipotesi, sarebbero comunque vere tutte le considerazioni di
> Francesco che comunque mi porterebbero ad utilizzare il C, piuttosto che
> il Basic.
>
Non sono contro il C ma verso chi a partito preso dice che il C e' superiore
senza dimostralo in nessun modo, ad esempio se puoiindica cosa dovevi fare
con ilpicbasic pro che ti ha creato tanti problemi.
> Cercate di rendervi conto cosa succede se dovete trasferire un progetto
> Basic di 1000 righe su un altro microcontrollore che non sia un semplice
> PIC, magari un Atmel AVR o un ARM. Qui, se i compilatori Basic non si
> trovano, i compilatori C la fanno da padrone. Portare un programma C per
> PIC ad ARM non sarà una cosa semplice, ma almeno si impiegherà molto meno
> tempo che partire dal Basic per PIC.
>
Ma perche' dovrei passare dai pic agli ATMEL? voglio capire la superiorita'
degli ARM che comunque a certi livelli comunque non si programmano con il C
che conosci tu
mmm
> On 2007-05-01 10:18:25 +0200, mmm <m...@john.bluto.blutarsky.it> said:
>
>> rimango della mia idea che sarebbe bene ti spratichissi un po' con le
>> tecniche di programmazione di base prima di provare a sviluppare per
>> sistemi embedded
>> ti ho gia' consigliato di provare qualche basic per DOS dove avresti a
>> disposizione un debugger integrato per vedere l'effetto che fa.
>
>
> Si, vero. Però mi pare di capire che ogni architettura ha il suo
> dialetto BASIC e vorrei imparare direttamente sui PIC ;-)
>
implementazioni di cui una ( quella originale ) e' praticamente
scomparsda nell'uso comune, quello che di usa oggi e' definibile come
BASIC Strutturato in quanto presenta le classiche strutture di controllo
di flusso dei linguaggi moderni
dal mio punto di vista la padronanza di un linguaggio di programmazione
e' per l' 80 % relativa alle strutture di controllo e solo per il 20 %
la conoscenza degli statement 'operativi', col vantaggio , ripeto per la
terza volta a costo di sembrare noioso, che lo studio e l'apprendimento
puo' essere fatto senza passare attraverso la programmazione fisica che
chip quindi con tempi ridotti ed in maniera almeno parzialmente interattiva.
che poi l'accensione dei led lo simuli scrivendo A sullo schermo e' un
dettaglio marginale
>>> Chi mi sa dare un occhio, una mano, un suggerimento? ;-)
>>
>> prova qualcosa di questo tipo:
>> program Lampeggia_LED
>
>
> Interessante, stanotte ho scritto un programma molto simile, ben prima
> di vedere il tuo post probabilmente a causa della lentezza di
> propagazione dei messaggi al server dove posto io ;-)
>
diciamo che ci ho messo un po' a scrivere la risposta e facci caso mi
ero concentrato sull'algoritmo di controllo piu' che sul come pilotare i pin
NOTA BENE :
probabilmente esiste una soluzione al problema molto piu' efficiente che
fa uso di timer e/o interrupt ma qui e' necessaria la conoscenza della
piattaforma/linguaggio specifico dove il ciclo di attesa sparisce del
tutto riducendosi as un
WHILE True
WEND
mmm
> On 2007-05-01 14:53:05 +0200, Francesco Sacchi <frasa...@libero.it>
> said:
>
>> Per questo ritengo che "stai perdendo tempo con il basic", alla luce
>> di tutto questo "il C è superiore".
>
>
> Allora, il discorso è che io *oggi* *non* so nulla di programmazione.
> Il Basic è certamente la partenza più soft per un neofita e su questo
> almeno penso di aver visto giusto.
>
se ne sai poco di programmazione , nel senso che in generale hai
programmato poco forse e' meglio che ti fai un po' le ossa su una
piattaforma un pelo piu' tranquilla ( DOS ? :-) )
e magari se li riesci a trovare leggiti il Wirth ( algoritmi +
strutture dati ... ) e il Knuth ( the art of programming ) tanto per
vedere un po' di tecniche di programmazione di base
> Successivamente non mi vorrei far mancare la capacità di programmare
> anche in C, che pur essendo un linguaggio di alto livello come il BASIC
> ha una maggiore portabilità e forse per alcuni versi anche versatilità.
>
portabilita' e' una parola grossa in campo embedded :-)
> Ma in realtà il mio obiettivo finale è di capire qualcosa di Assembly
> perchè questo è l'unico sistema ad oggi per poter un codice pulito e
> versatile al 100%.
>
non ti credere, dopo aver sviluppato un po' in assembler su varie
piattaforme ed anche per progetti embedded sono passato di corsa al C
per quanto efficiente puo' essere l'assembler ( e lo e' !!! ) appena i
progetti crescono e gli algoritmi non sono semplici semplici diventa uhn
incubo sviluppare, basti pensare alla sola allocazione delle variabili
nei registri o a tirare su espressioni condizionali per i salti appena
complesse
> A questo punto, avendo in mente quanto sopra mi sono affidato ai
> compilatori Mikroelektronika perchè hanno compilatori per basic, pascal
> e c, anche per altri microcontrollori, e rendono semplice inserire nello
> stesso programma parti di codice Basic, C, Pascal e Assembler... e ti
> pare poco? ;-)
questo e' bene attualmente preferisco usare il C ed inserire piccoli
frammenti in assembler per le parti 'critiche'
tra l'altro il compilatore che uso e' piuttosto parco in funzioni di
libreria per le periferiche
>
> Ciao
>
pozz
>> Il punto di vista di Francesco è ben articolato e motivato, il tuo sembra
>> derivare troppo da una presa di posizione aprioristica, senza troppe
>> motivazioni.
>
> Assolutamente secondo il mio parere il voler usare il C in ambito embedded
> non porta a nessuna funzione superiore che non si possa fare con il Basic
Chiariamo subito, prima che creiamo confusione, soprattutto per gli altri che ci
leggono.
Sicuramente quello che puoi fare in C *lo puoi fare anche in Basic*. Su questo,
non ho molti dubbi.
Il problema è capire *come*.
Anche con l'assembler puoi fare tutto quello che fai con il C e con il Basic, ma
come lo fai? Scrivendo un programma che, nella maggior parte dei casi, è
incomprensibile o comunque difficile da manutere nel tempo.
>> Secondo me, la maggiore limitazione del PicBasic è l'impossibilità di
>> utilizzare una delle tecniche *fondamentali* della programmazione,
>> qualcosa che ti insegnano pure a scuola. In pratica non è possibile
>> dividere il programma principale in subroutine con tanto di passaggio dei
>> parametri.
>
> Questa e' una tua convinzione sbagliata, si puo' usare Include e quindi
> dividere il programma
Beh, scusa. Non voglio fare il maestrino, ma l'Include è una cosa, la divisione
del programma con subroutine, passaggio di parametri, ritorno di valore,
variabili locali, ecc. ecc. è *tutta un'altra cosa*.
Sono semplici concetti di programmazione che, ripeto, vengono insegnati anche
nelle peggiori scuole.
>> Tutti i compilatori C, essendo il C uno standard, permettono di creare
>> delle funzioni che accettano dei parametri e ritornano dei valori. Questi
>> parametri sono normalmente passati sullo stack ma, visto che i PIC hanno
>> risorse molto limitate, i compilatori li gestiscono tramite delle
>> variabili globali. Ma almeno la cosa è fattibile.
>> In PicBasic una cosa del genere non si può fare, o almeno io mi sono
>> sbattuto tantissimo ma non ci sono riuscito. Le uniche routine che si
>> possono richiamare con passaggio di parametri sono quelle delle librerie
>> fornite con il compilatore. Ma non posso sperare di utilizzare solo quelle
>> librerie! In genere, alcune librerie me le scrivo anche io.
>
> Caspita proprio il basic permette di definire solo variabili globali
Qui non mi sono spiegato io e me ne scuso.
Non si evince dalla mia frase sopra, ma quello che volevo dire è che, nelle
architettura hw più complicate, viene usato lo stack per il passaggio dei
parametri e per i valori di ritorno. Questo è un grande vantaggio perchè ti
permette di ottimizzare le risorse in RAM, ti permette di creare ricorsioni in
modo semplice, ecc.
I PIC (penso tutti quanti) non hanno uno stack hw (almeno per le variabili, ne
hanno uno solo per gli indirizzi di ritorno da una subroutine) quindi il
compilatore *non può* utilizzare lo stack ed utilizza un accorgimento: trasforma
le variabili locali e i parametri in variabili globali. Questa trasformazione
avviene in modo *completamente trasparente* al programmatre che continua a
scrivere le sue belle funzioncine con i parametri, *senza accorgersi di nulla*.
Naturalmente questo ha lo svantaggio, per esempio, di non poter fare ricorsioni
e di sprecare RAM inutilmente... ma questa è una responsabilità dei PIC, non dei
compilatore (C o Basic che siano).
Nel PicBasic (non facciamo di tutti i Basic un fascio), come avevo già intuito e
come tu mi confermi, puoi utilizzare *solo variabili globali* e questo è un
compito che non si sobbarca il compilatore, come dovrebbe essere, ma il
programmatore!!
E se le chiamate a funzioni sono complicate la cosa non è per niente semplice.
Scrivere utilizzando *solo variabili globali* è uno dei metodi *più sbagliati*
per scrivere un programma, proprio perchè viene meno un altro approccio utile,
quello della riutilizzabilità del codice.
Quando si parla con amici o sconosciuti, normalmente non si è portati a credere
all'interlocutore, soprattutto se abbiamo delle convinzioni fortemente radicate.
Per questo ti faccio una citazione da Wikipedia
(http://it.wikipedia.org/wiki/Regole_di_scope):
"*Variabili globali.* Sono quelle visibili (ovvero referenziabili) da qualunque
punto di un programma. L'uso eccessivo di variabili globali è in genere
sconsigliato nella pratica dello sviluppo del software, poiché la loro presenza
facilita l'occorrere di effetti collaterali che possono portare a errori di
programmazione molto difficili da individuare e correggere."
Il PicBasic addirittura, anzichè cercare di evitare errori da parte del
programmatore (come tutti i moderni linguaggi di programmazione che si
rispettino, primi fra tutti gli object-oriented) invoglia e, oserei dire,
*obbliga* il programmatore ad una *metodologia sbagliata*.
>> Ovvio che l'hobbysta che vuole far accendere due led e non deve lavorare
>> con la programmazione dei micro, può tranquillamente rivolgersi a
>> soluzioni semplici come il Basic. Ma sappia subito che troverà grosse
>> difficoltà non appena i suoi desideri si complicano leggermente (non ho
>> parlato della gestione degli interrupt nel PicBasic... una pena totale!).
>
> Il picbasic che tu definisci schifezza ha tante istruzioni che loportano ad
> assomigliare al C
Ti rendi conto anche tu che la frase che la tua risposta è troppo generica e non
supporta le tue convinzioni nè smentisce le mie.
Anche io, più sotto, ho detto che le istruzioni si "assomigliano" ma, almeno per
me, la bontà di un compilatore non si valuta guardando la "somiglianza visiva"
dei programmi!
>> Io non credo che il C sia più difficile del Basic... alla fine sono
>> entrambi linguaggi ad alto livello. L'istruzione
>> x += 3+y;
>> in Basic si scrive
>> x = x + 3 + y
>> Non è proprio così diverso. La facilità del PicBasic sta più che altro
>> nelle numerose librerie a disposizione. Ma anche alcuni compilatori C sono
>> ricchi di librerie che semplificano molto il problema (MikroC). La cosa
>> importante, però, è che il programmatore possa scriversi le *proprie*
>> librerie con il meccanismo semplicissimo delle subroutine.
>
> Non so se rispondi solo per partito preso, in C come in basic se non hai
> librerie belle e pronte, o rinunci al progetto oppure te le scrivi in
> assembler, oppure mi vuoi dire che senza librerie apposite con il C puoi
> fare.........
Beh, non so proprio che altro fare. Cerco di portare tutti gli esempi che vuoi e
mi dici che rispondo per partito preso senza, tra l'altro, smentirmi in modo
puntuale.
Se devi gestire un display LCD con controller XXX e il tuo compilatore (C o
Basic) non contiene delle librerie che ti permettono usarlo, hai davanti alcune
strade:
- rinunci al progetto
- scrivi le tue librerie in Assembler
- scrivi le tue librerie nel linguaggio scelto (Basic o C)
Non vorrei entrare nel merito della seconda possibilità poichè ci porterebbe
lontano dalla nostra discussione (ho il sentore che in PicBasic sia praticamente
impossibile, ma è solo un sentore...), per quello che riguarda la terza
possibilità, senza avere la possibilità di usare variabili locali e funzioni con
parametri e valori di ritorno (come nel PicBasic), è tutto *molto più
complicato* che in C.
>> Ovvio che non conosco tutti i compilatori Basic per PIC e queste
>> considerazioni valgono principalmente per il PicBasic Pro. Se qualcuno
>> conosce compilatori Basic per PIC che hanno le limitazioni di cui sopra,
>> son ben contento di conoscerli (forse il MikroBasic si salva).
>>
>> Ma, in queste ipotesi, sarebbero comunque vere tutte le considerazioni di
>> Francesco che comunque mi porterebbero ad utilizzare il C, piuttosto che
>> il Basic.
>>
> Non sono contro il C ma verso chi a partito preso dice che il C e' superiore
> senza dimostralo in nessun modo, ad esempio se puoiindica cosa dovevi fare
> con ilpicbasic pro che ti ha creato tanti problemi.
Chiunque abbia conoscenze basilari di programmazione mi ha già capito
perfettamente. Tu mi chiedi di fare degli esempi concreti ed io non posso
esimermi da ciò (altrimenti continui a dire che parlo per partito preso, mbah!)
Supponi di dover gestire delle smartcard SLE4442. Probabilmente le conosci,
probabilmente no, ma non è questo il punto. Il tuo carissimo compilatore
PicBasic Pro Ultra Super Fantastic non ha, guardacaso, alcuna libreria per le
SLE4442. Allora decidi di scriverti le tue librerie.
Una operazione che si può fare con queste smartcard è la lettura dei dati
presenti nella Main Memory. In C, la cosa che potrebbe venire in mente di fare è
quella di creare una funzione:
int sle4442_read( int addr, void *rambuf, int n );
Il primo parametro è l'indirizzo della memoria della smartcard da cui iniziare
la lettura, rambuf è il puntatore è in RAM (del PIC) dove andare a memorizzare i
dati letti, n è il numero dei byte da leggere. Il valore di ritorno potrebbe
indicare un codice d'errore (per esempio, negativo) oppure una conferma di esito
positivo (magari nullo).
Nel programma principale potrò richiamare quella funzione in modo molto semplice:
---
...
ret = sle4442_read( 0x30, &mystruct, sizeof(mystruct) );
if( ret!=SLE4442_OK )
display_message( "Error reading from smartcard!" );
...
---
Insomma, ci siamo capiti. La comodità di utilizzare i parametri è ovvia: se devi
rileggere da smartcard, magari da un altro indirizzo, basta che cambi i
parametri e il gioco è fatto (però non mi fare scrivere un manuale di
programmazione per dummies, please!)
Poichè in PicBasic Pro Ultra Super Fantastic non puoi utilizzare parametri,
l'unica cosa che puoi fare è utilizzare variabili globali che devi ogni volta
inizializzare *prima* di fare una chiamata alla tua subroutine. Ma anche il
valore di ritorno *deve* essere una variabile globale che dovrai leggere dopo
aver chiamato la tua routine.
A prima vista ti può sembrare una banalità, ma pensandoci bene non è per niente
così. Prima di tutto, va a farsi benedire la riutilizzabilità del codice. Se
devi copiare le tue routine per la gestione della smartcard in un altro
programma, ti devi ricordare di copiare le variabili globali associate, cosa non
semplice. Inoltre queste variabili globali non possono essere condivise tra di
loro (con i parametri di altre funzioni) perchè se una funzione chiama l'altra
funzione succede il casino. Un compilatore che gestisce le funzioni e il
passaggio dei parametri, si crea una tabella di chiamate a funzioni e sa
automaticamente quali parametri possono essere condivise tra più funzioni, con
un netto risparmio di risorse in RAM!
>> Cercate di rendervi conto cosa succede se dovete trasferire un progetto
>> Basic di 1000 righe su un altro microcontrollore che non sia un semplice
>> PIC, magari un Atmel AVR o un ARM. Qui, se i compilatori Basic non si
>> trovano, i compilatori C la fanno da padrone. Portare un programma C per
>> PIC ad ARM non sarà una cosa semplice, ma almeno si impiegherà molto meno
>> tempo che partire dal Basic per PIC.
>>
> Ma perche' dovrei passare dai pic agli ATMEL? voglio capire la superiorita'
> degli ARM
Diciamo che spesso passi ad altri microcontrollori non per tua scelta, ma per
scelta del tuo committente, anche se gli ATMEL/ARM/AVR ecc non sono superiori ai
PIC (cosa che dubito fortemente).
Ripeto, se sei un hobbysta che accende due led e può scegliere il micro da usare
(sempre e solo PIC, per tutta la vita) allora non stiamo neanche qui a discutere.
> che comunque a certi livelli comunque non si programmano con il C
> che conosci tu
Hai ragione, esiste il C che conosco io, quello che conosci tu e, ora che mi fai
ricordare, anche quello che conosce il mio dirimpettaio.
:))
Francesco Sacchi
> Il basic arriva esattamente dove arriva il C in ambito embedded, poi la
> verita' e che voi avete paura che il primo che arrivi usando due semplici
> istruzioni in basic possa fare tutto quello che voi fate in C conla
> differenza che in basic anche chi non sa programmare capira' qualcosa.
Accidenti! Hai scoperto il nostro segreto :)
A parte gli scherzi, ti invito ad argomentare la tua posizione come
abbiamo fatto io e pozz, altrimenti sei tu che parli solo per partito preso.
Ciao
Francesco Sacchi
> Nel PicBasic (non facciamo di tutti i Basic un fascio), come avevo già
> intuito e come tu mi confermi, puoi utilizzare *solo variabili globali*
> e questo è un compito che non si sobbarca il compilatore, come dovrebbe
> essere, ma il programmatore!!
Scusa se ti cito ma non pensavo che si fosse addrittura a questo punto.
Un tool di questo genere è il tipico esempio di mossa commerciale che
intendevo io. Sembra semplice, ma in realtà ti porta a programmare
davvero *male* e ti lega al prodotto a vita.
Purtroppo, come in tutte le cose del mondo, non esistono scorciatoie.
Marcus, e te lo dico senza offesa e con tutto il rispetto, se decidessi
di dedicarti un po' allo studio delle basi della programmazione ti
renderesti conto da solo che un compilatore che non permette modularità
e consente l'uso di sole variabili globali è un'eresia.
Devi capire che non si tratta solo alla fine di vedere il programma
funzionare o no, è molto di più.
Senza modularità (le funzioni) non puoi sperare di riusare il codice in
modo efficente. Magari non te ne frega nulla perchè non lo fai
professionalemente, ma anche in ambito hobbystico, perchè dovresti
riscrivere, per esempio, un driver per un display da capo, quando l'hai
già fatto in un altro progetto?
Ciao
Matteo
> e magari se li riesci a trovare leggiti il Wirth ( algoritmi +
> strutture dati ... )
Ho cercato questo libro, che in italia è edito da Tecniche Nuove ma mi
dicono che è fuori catalogo da anni... in effetti è del 1987
Non è che tu ne hai due? ;-)
--
Matteo
Francesco Sacchi
> Ma perche' dovrei passare dai pic agli ATMEL? voglio capire la superiorita'
> degli ARM che comunque a certi livelli comunque non si programmano con il C
> che conosci tu
E perchè non dovrebbe essere possibile?
Sai quante volte capita che un microcontrollore va fuori produzione? Che
un'altro costa meno? Che un'altro ha risorse che mancano a quello che
usi adesso?
E poi gli ARM con che C si programmerebbero scusa? Io uso lo stesso
compilatore C che uso sugli AVR, anzi ti dirò di più, uso anche lo
stesso codice e le stesse funzioni. Magari scritte anni prima.
E' proprio qui che si vede la differenza tra dei tool e un linguaggio
serio e le trovate commerciali di cui parlo.
Non si tratta di C contro BASIC ma di compatibilità, versatilità,
portabilità, modularità, etc... contro ... nulla.
Io non sono a favore del C a prescindere, sono a favore di tutti i
linguaggi e tool che mi garantiscono le cose di cui sopra. Attualmente
le features che ho descritto vengono fornite solo dal C e dai tool GPL;
magari in futuro le cose cambieranno, ma per adesso è così.
Ti sembrerà strano, ma il codice che usavano 10 anni fa alcuni miei
colleghi su processori semisconosciuti (196), l'ho riusato io, con
pochissime modifiche, sugli AVR, e da alcuni mesi, sugli ARM.
Con il tempo ci siamo fatti un vero e proprio sistema operativo, che
gira praticamente su tutti i processori di cui è fornito un compilatore
C decente. Siamo arrivati al punto che è possibile provare
l'applicazione *emulata* su PC, e una volta debuggata, la possiamo
programmare sul target.
Il 70% del codice che scriviamo lo riusiamo, rendendo lo sviluppo di un
nuovo progetto sempre più veloce.
Tutto questo è possibile solo grazie alle cose di cui sopra e una buona
conoscenza dei fondamenti della programmazione. Bisogna sempre *pensare*
che il codice verrà riusato e non bisogna fare porcate solo perchè ci
velocizzano sul momento. Se capisci questo, capirai anche perchè sono
contro questi tool che ti fanno credere di programmare al posto tuo.
Attualmente, e credo ancora per un bel po', nessuna macchina o programma
è in grado di fare il lavoro di un buon programmatore.
Quindi, lo ripeto, se vogliamo dedicarci a questo mondo, sia solo per
divertimento, la strada giusta è quella di studiare un po' di basi e
fare delle prove anche con programmi su PC, come dice mmm.
Una volta apprese le basi, capirai da solo che la sfilza di parole che
finiscono in "ità" che scrivo sempre (compatibilità, portabilità,
modularità, etc.), sono davvero importanti.
Ciao
mmm
> Marcus ha scritto:
>
> Quindi, lo ripeto, se vogliamo dedicarci a questo mondo, sia solo per
> divertimento, la strada giusta è quella di studiare un po' di basi e
> fare delle prove anche con programmi su PC, come dice mmm.
>
solo una piccola precisazione, tanto per chiarire bene, l'uso del PC
come piattaforma di prova e' per ragioni economiche, un 486 ( oggi mi
sento buono :-) ) costa zero e cosi i tool di sviluppo, inoltre la
disponibilita' di un debugger adeguato permette di semplificare la fase
di test e di capire meglio cosa sta accadendo.
poi se uno vuole puo' sempre usare la porta parallela per interfacciarsi
col mondo esterno.
inoltre cosi' si impara a separare la parte puramente algoritmica di un
programma con l'accesso alle risorse di I/O in modo d migliorare la
portabilita' del codice :-)
> Ciao
mmm
no, a dire il vero non ne ho neanche una copia
qui c'e' la versione in Oberon ( derivazione del Modula 2 a sua volta
derivazione del Pascal )
http://www.oberon.ethz.ch/WirthPubl/
come al solito il linguaggio usato e' ( DEVE ) essere marginale rispetto
agli algoritmi e le tecniche di programmazione
altrimenti prova nelle biblioteche universitarie
Francesco Sacchi
> Allora, il discorso è che io *oggi* *non* so nulla di programmazione.
> Il Basic è certamente la partenza più soft per un neofita e su questo
> almeno penso di aver visto giusto.
Ti ha già risposto mmm, ma vorrei aggiungere alcune cose.
Se il tuo scopo è arrivare velocemente al risultato a qualunque costo,
quando però il problema non è troppo complesso, può andare bene il
compilatore che usi.
Se però deciderai di dedicarti alla programmazione embedded più nel
dettaglio, probabilmente, nella migliore delle ipotesi, quello che hai
imparato con il MikroBasic non ti servirà, nella peggiore, dovrai
perdere tempo per reimparare il modo "giusto" di fare le cose.
A differenza del significato dell'acronimo, il BASIC non è
propriamente didattico. Per imparare io ti consiglio come primo passo
di studiare le basi, anche sui libri consigliati da mmm che sono ottimi.
Poi, per iniziare a mettere mano su qualcosa di concreto, oltre al C,
puoi anche usare linguaggi come il Java o il Python, che sono attuali
e diffusi e possono sempre farti comodo come bagaglio culturale.
Anche se non sono tipicamente utilizzati nell'embedded, puoi lo stesso
fare cose più "firmwarose" come dialogare con la seriale o la parallela.
L'importante è capire come si programma, fatto questo, sarai in grado
da solo di valutare tool e linguaggi in base alle tue esigenze.
Ciao :)
marcoangelo
> Ti ha già risposto mmm, ma vorrei aggiungere alcune cose.
> Se il tuo scopo è arrivare velocemente al risultato a qualunque costo,
> quando però il problema non è troppo complesso, può andare bene il
> compilatore che usi.
> didattico. Per imparare io ti consiglio come primo passo di studiare le
> basi, anche sui libri consigliati da mmm che sono ottimi.
> Poi, per iniziare a mettere mano su qualcosa di concreto, oltre al C,
> puoi anche usare linguaggi come il Java o il Python, che sono attuali e
> diffusi e possono sempre farti comodo come bagaglio culturale.
> Anche se non sono tipicamente utilizzati nell'embedded, puoi lo stesso
> fare cose più "firmwarose" come dialogare con la seriale o la parallela.
Va bene anche per Atmel
> L'importante è capire come si programma, fatto questo, sarai in grado da
> solo di valutare tool e linguaggi in base alle tue esigenze.
>
> Ciao :)
Grazie
Angelo
Francesco Sacchi
> Qualcuno mi pilota verso un soft di programmazione per i pic in Java?
> Va bene anche per Atmel
Forse mi sono espresso male.
Che io sappia non esistono compilatori java o Python per PIC o Atmel.
Il mio discroso era: per imparare a programmare puoi usare qualsiasi
linguaggio su qualsiasi piattaforma (quindi anche il java o il python,
ma su piattaforma PC).
Anche su PC è possibile fare cose "embeddose" come comunicare con la
seriale o controllare la parallela.
Ciao
SB
>Allora, il discorso è che io *oggi* *non* so nulla di programmazione.
>Il Basic è certamente la partenza più soft per un neofita e su questo
>almeno penso di aver visto giusto.
Si, per capire come si crea un programma va bene anche il basic, il problema è
che di solito il basic per microcontrollers ha molte limitazioni rispetto ad un
basic più classico come QuickBasic, per non parlare di un Visual Basic.
>Successivamente non mi vorrei far mancare la capacità di programmare
>anche in C, che pur essendo un linguaggio di alto livello come il BASIC
>ha una maggiore portabilità e forse per alcuni versi anche versatilità.
Se vuoi usare i µC devi imparare il C, non c'è altra scelta, e te lo dico io che
preferisco come linguaggio (inteso come sintassi) 100 volte il Basic.
Il C è più ostico, io ogni tanto mi sbaglio anche oggi con gli == o =-, ha le
parentesi graffe e quello stramaledetto punto e virgola da mettere in fondo che
tendo sempre a scordarmi. per non parlare dei puntatori e il casino con gli *.
Ma non c'è scelta, il C offre troppi vantaggi, come ti hanno detto Francesco e
mmm.
Se poi tu non conosci altri linguaggi e cerchi di imparare subito quello non
avrai i problemi che ho avuto io che venivo dal basic.
>Ma in realtà il mio obiettivo finale è di capire qualcosa di Assembly
>perchè questo è l'unico sistema ad oggi per poter un codice pulito e
>versatile al 100%.
L'Assembler è il modo di sfruttare al meglio le risorse del µC, ma più il
programma si complica più diventa complesso e difficile fare dele funzioni.
Il C come tutti i linguaggi ad alto livello consente ad esempio di eseguire
operazioni aritmetiche a vigola mobile, cosa che in assembler è parecchio
incasinata (parlo per esperienza), per non parlare poi delle strutture di
variabili e cose simili che sono veramente molto difficili da gestire in asm.
Anch'io uso spesso l'assembler per fare cose semplici (io uso gli AVR che hanno
delle caratteristiche che li rendono più adatti all'assembler dei pic), ma se
debbo fare qualcosa di complesso al massimo ottimizzo le routines più critiche,
ma il main lo faccio in C.
>A questo punto, avendo in mente quanto sopra mi sono affidato ai
>compilatori Mikroelektronika perchè hanno compilatori per basic, pascal
>e c, anche per altri microcontrollori, e rendono semplice inserire
>nello stesso programma parti di codice Basic, C, Pascal e Assembler...
>e ti pare poco? ;-)
Non conosco, ma il mio consiglio è usare roba GPL come il GNU e simili, sono
gratis e vanno bene.
--
ciao
Stefano
mmm
> Francesco Sacchi ha scritto:
>
>> Ti ha già risposto mmm, ma vorrei aggiungere alcune cose.
>> Se il tuo scopo è arrivare velocemente al risultato a qualunque costo,
>> quando però il problema non è troppo complesso, può andare bene il
>> compilatore che usi.
>
> cut
>
>> didattico. Per imparare io ti consiglio come primo passo di studiare
>> le basi, anche sui libri consigliati da mmm che sono ottimi.
>> Poi, per iniziare a mettere mano su qualcosa di concreto, oltre al C,
>> puoi anche usare linguaggi come il Java o il Python, che sono attuali
>> e diffusi e possono sempre farti comodo come bagaglio culturale.
>> Anche se non sono tipicamente utilizzati nell'embedded, puoi lo stesso
>> fare cose più "firmwarose" come dialogare con la seriale o la parallela.
>
> Qualcuno mi pilota verso un soft di programmazione per i pic in Java?
> Va bene anche per Atmel
>
Virtual Machine per Atmel, comunque scritte in C ed 'abbastanza'
portabili, non ti aspettare pero' grandi prestazioni
una e' questa:
http://www.harbaum.org/till/nanovm/
per il resto si usa il compilatore java standard