Newsgroup: it.hobby.elettronica.digitale
Titolo: Consiglio per iniziare a lavorare sui microcontrollori (speriamo sia il gruppo giusto)

Ciao a tutti,
vorrei un vostro giudizio.
Ho lavorato per anni con i microcontrollori, Microchip, Motorola (nello 
specifico 68HC11) ma solo a livello hardware. Il software è sempre stato 
scritto da altri, io mi limitavo alla progettazione del circuito ed alla 
stesura del flow chart e delle direttive di funzionamento.
Anche se questo è sempre risultato funzionale, ho ritenuto spesso che la 
limitazione nel non saper gestire il programma fosse una cosa che andava 
affrontata.
Ora mi sono deciso ad imparare tutto quello che riguarda la scrittura del 
codice.
Ho usato MPLAB in passato solo per modificare piccoli paramentri di 
funzionamento, ma dell'oscura stesura del codice globale nulla so.
Qualche consiglio sull'ambiente di sviluppo?
Ho visto l'ambiente easypic5 della mikroelektronika:
http://www.mikroe.com/en/tools/easypic5/
ma non so scegliere fra basic, C, pascal...qualche suggerimento, oltre 
all'ambiente generale di sviluppo?
Grazie per chi vorrà darmi una mano,
Onda SOnora
-- 
"La luce è più veloce del suono. Per questo motivo alcune persone sembrano 
brillanti fino a quando non parlano." 

 all'ambiente generale di sviluppo?
assembly in primis!
poi ti consiglio il C
-ice- 

 ha scritto nel messaggio 
news:E4Ygl.169398$Ca.3...@twister2.libero.it...


 dell'MPLAB, che voi sappiate?
bho... io uso il textpad come editor e compilo con il c della ccs (il solo 
compilatore non costa neanche tantissimo)
-ice- 

 poi ti consiglio il C
Su questo, scusami, io sarei più cauto, non perché non riconosca la 
potenza del C (tutt'altro!), ma essenzialmente dipende dall'uso che fa 
lui del micro e dalle sue attuali conoscenze.
Naturalmente tutto questo IMHO!
Ciao!
-- 
Stefano Martini (Italy)
WEB: 
http://www.lemming.it
I am so scared, / I am so guilty, / I am so sad!!

 dell'MPLAB, che voi sappiate?
L'MPLAB è un po' complesso, è verissimo, ma ti permette di fare 
tantissime cose che renderanno il tuo firmware stabile ed affidabile.
Che sappia io, non esiste editor che sia così potente come quello!
Se ti va, dai una occhiatina al mio manuale che sto scrivendo, magari lo 
puoi trovare utile! E' sul mio sito, il link lo trovi in firma.
Ciao!!
Stefano


 del micro e dalle sue attuali conoscenze.
certo ma che senso ha impararsi il basic quando imparando il C hai già in 
mano uno strumento di lavoro?
-ice- 

 linguaggio ad alto livello!
Appunto per questo è consigliabile il C: non è ad alto livello, ma ha un
livello di astrazione più che accettabile. Chiaramente non si può usare con
le vecchie architetture PIC, che sono totalmente inadatte (non che in
assembly siano tanto meglio).

Che sappia io, non esiste editor che sia così potente come quello!
Tra l'altro l'ultima release consente di utilizzare un editor di testo esterno,
se si preferisce.

Ringrazio tutti per le risposte.
L'orientamento verso il sistema di sviluppo easy pic 5 è fatta sulla base 
della comodità.
Ho in laboratorio uno scatolone di schede millefori create per testare o 
vari circuiti, ed ogni modifica, come ben sapete, è mettere mano al 
saldatore, staccare giusto quel migliaio :-) di cavetti e montare il display 
a led su di un'altra porta.
La comodità dell'ambiente di sviluppo è di poter provare varie soluzioni 
senza montare nulla, ed accedere a funzioni che a volte non implementi per 
non dover costruire il circuito.
Ora il problema sorge quando apparentemente e furbescamente questa scheda di 
sviluppo si interfaccia solo con i software della casa, dove l'assembly non 
è previsto.
Io ho necessità di apprendere l'uso di questi micro per la gestione di 
pulsanti, display e quant'altro per una nuova attività di progetto di 
soluzioni specializzate e personalizzate per la gestione dei segnali audio 
( controllo di volume, selettore di ingressi, barre di registrazione e 
quant'altro) per amplificatori autocostruiti.
Ecco perchè, anche se già studiato l'assembly ai tempi del PIC16C74 ( età 
della pietra!!:-))
avevo bisogno di sapere se esiste un linguaggio più flessibile e meno mov, 
ret, nop e movimenti di bit, somme, riporti.
Se devo azionare dei relè alla pressione di alcuni pulsanti, e probabilmente 
riportarne l'avvenuto azionamento su un display 2x16, magari è più semplice 
con un linguaggio dove le macro funzioni sono già implementate ( anche in 
assembly, lo so, esistono le routine di gestione di un display, ma le 
ritengo eccessivamente complesse).
Insomma, sostengo, IMHO, che non bisogna sapere il codice macchina del 
processore del PC per stendere dei programmi applicativi, ma potrebbe non 
essere un esempio calzante.
Vorrei sapere questo, insomma, se devo per forza, a vostro parere, 
affrontare la programmazione a basso livello o se alcuni linguaggi sono 
sufficientemente validi per le mie applicazioni.
( Non devo fare un videogame con un pic, insomma...:-)
Grazie
"Stefano Martini" <konnori...@yahooNOSPAM.itNOSPAM> ha scritto nel 
messaggio news:gm1k5j$bh8$1...@nnrp.ngi.it...


 assembly siano tanto meglio).
Il C ha un livello di astrazione comunque superiore che, IMHO, non gli 
permetterebbe di capire bene il funzionamento del microcontroller. Per 
questo sono dell'idea che comunque č meglio studiare almeno un pochino 
l'ASM, poi ci si dedica al linguaggio che si preferisce.
Ciao!
Stefano


 gestione di un display, ma le ritengo eccessivamente complesse).
Se il tuo obiettivo è fare questo con un PIC, cercati Great Cow Basic (si, 
il basic della grande mucca!! :-) ) non ti serve sapere niente altro :-) 
(ed è pure free) 
Solo, non dire in giro che sai usare un microcontroller ;-) 

 in mano uno strumento di lavoro?
Se non ci fosse quella antipatica cosa che si chiama "curva di 
apprendimento" (e quell'altra ancora più antipatica che si chiama Deadline) 
avresti perfettamente ragione ;-) 

Va da se che a parte problemi di aggiornamento, i principi di funzionamento 
di un microcontrollore, se ti occupi di progettazione hardware li devi ben 
conoscere, no?
Non puoi elaborare uno schema e poi farti correggere dal programmatore 
perchč hai sbagliato ad usare le porte!:-)
"Stefano Martini" <konnori...@yahooNOSPAM.itNOSPAM> ha scritto nel 
messaggio news:gm1qrn$e7a$1...@nnrp.ngi.it...


Grazie di tutto!
Ora, a pensarci bene, sarà poi  la Microchip la scelta migliore per 
applicazioni leggere?
Sempre riferendomi al sito mikroelektronica ( e non sono il distributore 
italiano!!! Mi pare solo che sia la più completa e relativamente economica), 
ci sono diversi sistemi di sviluppo per:
Atmel AVR
Intel 8051
Motorola 68HC11
Microchip
A parte le caratteristiche specifiche dei vari processori, ritenete ci sia 
una scelta migliore?
"Axeman" <m...@dont.thik.so.invalid> ha scritto nel messaggio 
news:Xns9BA4AA1B6BFEAte...@194.177.97.96...


 assembly siano tanto meglio).
SI può usare benissimo e senza problemi, fino a che la complessità
dell'algoritmo è bassa.
Io ho usato compilatore CCS per lavoro per qualche anno, con Pic
famiglia 16F e 18F. Ho lasciato in produzione decine di schede che
vanno benissimo per la loro strada. E anche dove sono adesso, anche se
il lavoro principale è su DSP e ARM, vedo progettare varie schede
accessorie con Pic 16F programmate in C da qualche studio esterno.
Per l'OP, una volta fatti due esercizi con l'assembler, poi basta.
Hanno inventato la pillola, la lavatrice, le pizzeria a domicilio e i
compilatori i C per semplificarci la vita.
saluti,
simone.bern

 datasheet...
Ma lui vuole *l'intero* schema elettrico del PIC! E che se ne fa 
dello schema a blocchi? Non c'č nulla da copia-incollare lě dentro! 
;-)
-- 
Make love with a teacher, it's educational 
News 2002 [v 2.3] / StopDialer / PopDuster - 
http://www.socket2000.com
Akapulce portal: 
http://www.akapulce.net


se fai una ricerca troverai su ebay troverai di sicuro qualcosa di piu' 
economico, stai attento al paladino del quoting tale Coglionazzi, perche' 
stai quotando veramente male. 

accessorie con Pic 16F programmate in C da qualche studio esterno.
Tanto per far capire tutti senza ovviamente fornire i sorgenti delle tue 
applicazioni puoi descrivere qualche tua applicazione fatta con PIC e 
compilatore C, altrimenti qualcuno dira' che si puo' solo far lampeggiare un 
led.


Io prenderei in considerazione Amel AVR, c'e' l'ambiente IDE AVRSTUDIO che 
ha un compilatore in assembler e uno in C completamente gratuito, per fare i 
test ci sono in giro schede a basso costo.

;-)
Non se ne fa nulla né dell'uno né dell'altro, a lui basta gettare fango ed è
soddisfatto... Non capisce che continua a farsi autogol.

 dell'algoritmo è bassa.
Ovvero fin quando il C non serve.

 soddisfatto... Non capisce che continua a farsi autogol.
Fango? Prima leggiti *tutti* i miei interventi sui PIC, poi spara giudizi. 
Claro?

 perchè hai sbagliato ad usare le porte!:-)
Sarebbe un pochino....  uhm....  diciamo una stupidata! ;-)
Ciao!


 applicazioni leggere?
Ciao!
Secondo il mio parere, se il tuo intento sono solo relè comandati da 
segnali o pulsanti e display, forse ti basta qualcosa come il nutchip 
(
http://www.nutchip.com/
), e questo per questi motivi:
1) è molto facile da programmare
2) è economico (è anche questa una cosa da considerare!)
3) il programmatore è fattibile con 4 componenti in croce


 2) � economico (� anche questa una cosa da considerare!)
16 euro un chip ? Mica tanto economico...
-- 
A bug in the code is worth two in the documentation.



 Grazie, pare interessante ma mi sembra un po' limitato.
Ad una lettura superficiale sembra una FPGA con qualche funzione accessoria 
e preconfezionata, come il timer e la lettura del telecomando...
Volessi inserire funzioni come la seriale o USB..
Grazie comunque.

 Ovvero fin quando il C non serve.
non vedo faccine, ma probablmente stai scherzando.
Anche il minimo problema di attuazione, la più banale macchina a
stati, la più elementare delle funzioni di trasferimento si risolvono
non so quante volte più velocemente in C rispetto all'assembler.
Per non parlare delle specifiche sfumate, da adattare alle idee poco
chiare del committente, che crescono linearmente con l'avanzare del
lavoro, che ti si rivoltano di 180 gradi quando stai per consegnare.
Credo siano ormai 5 anni che non scrivo una riga in assembler, e se
mai dovessi far solo lampeggiare un led, lo farei in C.
Comunque, la maggior parte dei miei lavori su PIC è (stata) sviluppata
intorno ad un banale scheduling:
-un ciclo fast, che viene scatenato da un interrupt-timer
-uno o più cicli slow/bground, interrompibili dal precedente, che
seguono l'evolversi di un contatore sw.
-la maggior parte delle volte c'è ache un interrupt sull' RX della
seriale, in cui riempio un buffer circolare.
Tutto questo si adatta volta per volta ad algoritmi più o meno
semplici, e viene compilato liscio come l'olio sia su 16F che su 18F
dal CCS richiamato da MPLAB.
saluti,
simone.bern

 mai dovessi far solo lampeggiare un led, lo farei in C.
A me capita abbastanza spesso, soprattutto per gli interrupt handler, di
scriverli in C, prendere l'output assembly del compilatore e rimaneggiarlo
per ottenere velocità di esecuzione migliori o invarianti.

 scriverli in C, prendere l'output assembly del compilatore e rimaneggiarlo
naturalmente a questo è sempre servito l'asm...


"consistenti".
Certo, anche perchè molto spesso il problema complicato lo si può rendere
semplice, o perlomeno si può cercare di semplificarlo.
Io penso sempre che per ogni problema esista una via più semplice di quella che
ho scelto, solo che non sono stato capace di trovarla.
Poi si possono facimente risolvere con l'assembler anche dei problemi
relativamente complessi, almeno per quello che si può fare con i µC a 8 bit.
Io non riesco ad essere obiettivo sulla questione, dato che una delle mie più
alte priorità è proprio evitare le odiate graffe, però posso tranquillamente
affermare che con una libreria di macro ben fatta si riescono a gestire
agevolmente stringhe e operazioni aritmetiche, in meno tempo e senza doversi
scervellare su * & e schifezze varie o sorbire gli incomprensibili messaggi del
compilatore.
--
ciao
  Stefano

 alte priorità è proprio evitare le odiate graffe
Niente di più facile:
#define BEGIN {
#define END }

F. Bertolazzi:

Credi davvero che il preprocessor del C abbia qualcosa da invidiare ad un
macro assembler? ;-)

F. Bertolazzi:

No, infatti mi sono chiesto se qualcuno ha mai fatto qualcosa con i  #DEFINE per
rendere più digeribile l'orribile sintassi del C.
Fino a qui ci si può arrivare:
#DEFINE Then {
#DEFINE EndIf }
Ma come fai con * e & ?
Forse
#DEFINE *   Stored
#DEFINE &   AddressOf
Non ho mai provato, ma mi piacerebbe sapere se qualcuno l'ha fatto.
Possibile che solo io sul pianeta trovi steomachevole questa sintassi?
--
ciao
  Stefano

 Possibile che solo io sul pianeta trovi steomachevole questa sintassi?
Può darsi di no, ma sono disposto a scvommettere che per ognuno come te ne
trovo mille che adorano il C proprio per la sua sintassi.

 #DEFINE Then {
Semmai
#define IF if(
#define THEN ){
#define ENDIF }
Il C è case sensitive, quindi dovresti scrivere
#define DEFINE define
ma questo mi sa non funzionerebbe.
Ci sono alcune macro consigliate da ISO 646:
and &&
and_eq &=
bitand &
bitor |
compl ~
not !
not_eq !=
or ||
or_eq |=
xor ^
xor_eq ^=
alle quali aggiungerei
#define EQ ==

   
ne conosco un po' che hanno fatto giochetti del genere,
traslando alcune keyword tipo le graffe o & o | o ^ come
begin..end, AND, OR, NOT etc., con il risultato di avere, dopo
qulache tempo, un sorgente pseudo-pascal praticamente immanutenibile
e lasciando poveri cristi a lanciare invettive a simili idioti.
Oltretutto a *volte* la miscomprensione di operandi C introduce
degli errori difficili da trovase se la lettura non e' esplicita....
A parte che non vedo perche' sprecare tempo a scrivere 'begin'
quando basta la graffa, sintetica ed espressiva ....ma de gustibus etc...
La sintassi del C č studiata anche per ottimizzare la scrittura di
un programma, qundi usa i simboli sitetici presenti sulle tastiere
standard  la' dove altri usano usana grafia estesa.
E' opinabile? Puo darsi, ma non sono poi molti i simboli  monocarattere
criptici.
Se vuoi un consiglio, usa il C cosi' come' o usa un altro linguaggio.
La copertura di keyword con macro si fa, ma per altri motivi!
Bye
B.

La copertura di keyword con macro si fa, ma per altri motivi!
Ci sto provando da parecchio tempo, ma proprio non mi piace, e il lavoro deve
essere anche una cosa gradevole.
--
ciao
  Stefano

#define EQ ==
Terrò presente.
--
ciao
  Stefano

 alte priorità è proprio evitare le odiate graffe, però posso tranquillamente
ALTGR+SHIFT+[
ALTGR+SHIFT+]
-- 
Revolutionary:  Disk drives go round and round.


   
Ovvio, ma purtroppo per te nel mondo embedded qualcosa di compatto
e anche (opinione molto personale) elegante come il C non e' ancora stato
proposto o non e' sopravvisuto al tempo.
Se fosse ancora vivo penso che il PL/M Intel sarebbe stato un linguaggio
piu' adatto ai tuoi gusti: abbastanza simile al Pascal ma con costrutti
di piu' basso livello piu' simili al C.
Ciao!
B.

 assembler?
Lascia stare. C'ho già provato. ;-)
In fondo a lui va bene così...
Mi raccomando: evita di scrivere cose tipo "*professionalmente*" con chi
non conosci. In questo caso, ti assicuro, hai beccato forse la persona più
sbagliata del NG.

sbagliata del NG.
Ti ringrazio per gli apprezzamenti, non foss'altro perchè in questo periodo sto
lavorando 10-12 ore, anche se riesco ad andare a sciare nei weekend, ma bisogna
pur vivere, cavolo.
(*) ogni riferimento al C è puramente casuale  :-PP
--
ciao
  Stefano

 (*) ogni riferimento al C è puramente casuale  :-PP
Manco ar cane.

 e lasciando poveri cristi a lanciare invettive a simili idioti.
parole sante