Newsgroup: it.hobby.elettronica.digitale
Titolo: Programmare con MikroBASIC

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

 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

 trisc = 00000001
a me pare che hai sbagliato le istruzioni di cui sopra, dichiarando come 
ingressi quelli che volevi fossero uscite e viceversa.
Marco

 Stanotte mi č venuta l'illuminazione...

Hai risolto, bene per te.
Perņ ti consiglio di dare una letta qui
http://it.wikipedia.org/wiki/Indentazione

 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 

 
Eccomi: stai perdendo tempo con il basic, il C è superiore! :)
Ciao

 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 

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

 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. 

 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

 
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

 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.

 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


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 

 
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


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

 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

 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

 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

 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

 Ciao


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

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

 Ciao :)
Grazie
Angelo

 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

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

 
qualcosa esiste , ci sono in giro due o tre implementazioni della Java 
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
