Newsgroup: it.hobby.elettronica.digitale
Titolo: Passaggio da Arduino ad AVR Studio

Salve,
(sono Troy McLure) forse vi ricorderete di me per post come "modulo GPRS 
e connessione TCP". Per chi si fosse interessato alla vicenda, non ho 
ancora ordinato il modulo Gprs Simcom300. Questo perchè il consiglio di 
Francesco Sacchi - all'interno del thread - di passare ad un altro micro 
mi è entrato come un tarlo nel cervello.
Ho fatto un paio di considerazioni: con arduino è Facile, fin troppo 
facile ottenere ciò voglio realizzare, e visto che il mio è un progetto 
didattico questo è un limite. Inoltre in una fase un po' più avanzata 
del progetto avrò bisogno di due UART, e cercando in rete mi è sembrato 
di capire che se non si è ancora scelto il micro, è meglio prenderne uno 
  con due Uart, per evitare poi di dover gestire il multiplexing della 
seriale con metodi strani e accrocchi.
Dato che non ho fretta (per adesso sto studiando più approfonditamente 
il sistema GPRS e i protocolli IP, TCP e UDP), ho congelato l'acquisto 
del modulo e ho pensato di passare all'Atmel ATmega128. Per questi motivi:
- ha 2 Uart;
- ha abbastanza memoria di programma e ram per utilizzare uno degli 
stack tcp/ip di cui si è parlato nel thread "modulo Gprs e connessione Tcp";
- posso utilizzare degli ambienti di sviluppo free (AVR Studio e WinAvr);
- ho trovato su ebay una scheda di sviluppo alla portata delle mie 
tasche: 
http://cgi.ebay.it/STK128-ATMEL-AVR-ATMEGA128-16AU-Development-Board-kit_W0QQitemZ290269570491QQcmdZViewItem?hash=item290269570491&_trksid=p3286.m63.l1177
- ho trovato pure i programmatori ISP, sempre a prezzi ragionevoli:
http://cgi.ebay.it/Serial-Atmel-ISP-programmer-works-with-AVR-Studio-4_W0QQitemZ310095809506QQcmdZViewItem?hash=item310095809506&_trksid=p3286.c0.m14&_trkparms=66%3A2|65%3A15|39%3A1|240%3A1318
http://cgi.ebay.it/USBasp-USB-ATMEL-AVR-ATMEGA-ISP-Programmer-AVRDUDE_W0QQitemZ280280029609QQcmdZViewItem?hash=item280280029609&_trksid=p3286.c0.m14&_trkparms=66%3A2|65%3A15|39%3A1|240%3A1318
- Essendo Arduino Basato sull'ATmega168 posso già cominciare a 
programmare in C con le IDE di cui sopra, riducendo ulteriormente la 
fretta di prendere la scheda per l'ATmega128.
Cosa ne dite? Esiste qualche altro micro con caratteristiche simili 
all'ATmega128 (soprattutto le 2 uart) che potrebbe fare al caso mio, 
magari in un package DIP (unica mancanza del 128... certo, con 64 pin è 
anche comprensibile)? La scheda di sviluppo e gli ISP che ho trovato 
andranno bene (con ebay c'è sempre quel certo timore di fondo...)?
Non ho un ISP per programmare l'ATmega168, ma quello che ho ha già il 
bootloader di Arduino. Posso usarlo per programmare il chip con AVR Studio?
Grazie, e grazie a tutti quelli che mi hanno aiutato nello scorso thread!
athos

 
io ho lasciato arduino per un ARM7, in particolare un LPC2103. 2 UART, 
32kb di flash e 8kb di ram, SPI, I2C e compagnia cantante.
http://www.futurlec.com/ARM2103_Controller.shtml
Ci ha messo 3-4 settimane ad arrivare, ma funziona benone. In corredo ti 
danno un CD pieno di esempi, manuali vari e il compilatore/debugger della 
KEIL in versione DEMO (il cui limite è di compilare max 32kb di codice, 
per cui chissenefrega :D). 
-- 
Nuno on zx-6r '04 & CRe 250 '99 working in progress...
...la paura fa 90, la mia moto 280

 fretta di prendere la scheda per l'ATmega128.
Questo è vero, infatti se cambi famiglia di micro devi abbandonare 
arduino del tutto.
-- 
  _|/ Francesco Sacchi - Develer S.r.l., R&D dept.
   |\ 
http://www.develer.com/
 - 
http://www.bertos.org

 di passare ad un altro micro mi č entrato come un tarlo nel cervello.
Hummm. Dovessi essere sincero, pur essendo un fan degli AVR, secondo me TCP
e 8 bit vanno poco d'accordo. Gli ARM Luminary costano piů o meno quanto i
corrispondenti AVR.

 arduino del tutto.
Vabè, non lo abbandono mica, poverino! Ho un paio di altri progetti che 
per Arduino andranno benissimo :) In ogni caso ho pensato che, invece di 
tentare di caricare un nuovo bootloader sull'ATmega168 (che pure si può 
fare da arduino, senza isp, con qualche modifica) per poterlo 
programmare con AVR studio, posso semplicemente usare la IDE di arduino 
ed evitare di usare le funzioni "incorporate" nel linguaggio di arduino 
e includere le librerie AVRlib e AVRlibc. Giusto?
grazie,
athos

 La scheda segnalata da Nuno
non so come hai fatto, ma hai letto bene il mio nick. sono commosso.


 e includere le librerie AVRlib e AVRlibc. Giusto?
Non conosco la IDE di Arduino e quindi non so risponderti, però ho 
l'impressione che ci sia troppo hype rispetto a quello che 
effettivamente è e può fare.


 necessiti di sicuro di una RAM esterna 
Sto giocando proprio in questi giorni con uIP (su uno stellaris) e devo
dire che va benone. Risponde ai ping ( :-) ), lo metto in ascolto su una
porta tcp e quando riceve dei dati fa l'echo rispedendoli indietro. Non
devo fare grandi cosa con l'ethernet, tipicamente come sostituzione della
seriale che ormai non esiste più sui portatili, ed allo stesso tempo come
soluzione galvanicamente isolata a basso costo, cosa che con l'usb non
riesce altrettanto bene.
Che vantaggi ha il lwIP (oppure, in altri termini, che problemi ha il uIp)?

 Che vantaggi ha il lwIP (oppure, in altri termini, che problemi ha il uIp)?
lwIP ha un'interfaccia a socket ed è quindi più facile da usare in 
applicazioni più corpose.
uIP lo considero un semplice serial cable replacement, ma se devo fare 
un'applicazione in cui la rete serve davvero pesantemente userei lwIP.
Ciao
-- 
  _|/ Francesco Sacchi - Develer S.r.l., R&D dept.
   |\ 
http://www.develer.com/
 - 
http://www.bertos.org/

 il classico "C programming language" di Kernighan & Ritchie.
Quello già campeggia fiero sulla scrivania, gode in famiglia di una
considerazione maggiore della mia... persino mia madre a volte gli
chiede se vuole il caffè anche lui!
Mi riferivo più in particolare proprio a librerie specifiche per gli arm
(quelle per gli avr sono davvero molto comode), e ad una eventuale
documentazione.
Intanto ho trovato una ide free (winarm), un po' di documentazione anche 
grazie al mulo, e sto sempre cercando le schede di sviluppo. Ho visto i 
Luminary Stellaris serie 1000, e sembrerebbero adatti. Comunque se 
qualcuno ha altre esperienze il suo consiglio è ben accetto :D
athos

 dire che va benone.
Che micro è, di preciso? Usi una scheda di sviluppo?
athos

 impazzisci per gestire tu la concorrenza.
La mia applicazione non sarà una cosa complessa, nulla o  poco più che 
leggere da un gruppo di sensori collegati via seriale, manipolare i dati 
e inviarli al server remoto, restando in attesa per eventuali richieste 
(di dati o di configurazione). In questo caso potrei cavarmela anche con 
uIP?
Sarà il caso di studiarli entrambi... quanta roba da studiare!
athos
PS: La domanda potrà sembrare scema, ma io nel mio progetto ho dato per 
scontato un approccio procedurale. Visto che però il micro dovrà 
svolgere diversi compiti "insieme" (lettura dei sensori, manipolazione 
dei dati, gestione della connessione) è possibile già pensare in termini 
di programmazione ad oggetti (sulla quale non sono affatto ferrato, però 
studio per studio...)

 un'applicazione in cui la rete serve davvero pesantemente userei lwIP.
Benissimo, per ora il rimpiazzo della seriale e' sufficiente. L'unica cosa che
mi tiene ancora distante da lwIp e' la quasi obbligatorieta' di un sistema
operativo vero e proprio: il mio scheduler embrionale non preemptive non
sarebbe adatto :-)

 Che micro è, di preciso? Usi una scheda di sviluppo?
E' l'LM3S6965, montato nella scheda di sviluppo "LM3S6965 Ethernet Evaluation
Kit".

 non so come hai fatto, ma hai letto bene il mio nick. sono commosso.
L'avrà forse letto in firma? :-p
Io l'avrei interpretato come "None" :-p
P.

 studio per studio...)
Svolgere diversi compiti insieme non richiede per forza un approccio 
OOP, casomai server un kernel multitasking. In ogni caso usare un 
approccio orientato agli oggetti semplifica lo sviluppo. Chiaramente non 
puoi sviluppare in C++, però si riesce abbastanza bene lo stesso ad 
usare questo paradigma anche in C.
Se interessato puoi dare un'occhiata al nostro SO (linkato in firma) che 
fornisce un kernel e tanti driver scritti con l'approccio "a oggetti"



Bhe, anche cooperativo va bene (noi lo usiamo così). Io sono fermamente 
convinto che il preemptive nelle classiche applicazioni embedded I/O 
bound non serva, anzi a volte può essere controproducente.


 bound non serva, anzi a volte può essere controproducente.
A parte il "bhe", sottoscrivo sia questo che la programmazione con dati
incapsulati (per avere degli oggetti veri e propri devi avere anche
l'ereditarietà) fatta in C e non C+.