Atmel?

[simotravelmate]

Ragazzi nessuno del forum utilizza ATMEL? tutti pic????? io ho cominciato a sviluppare con ATMEL e mi trovo bene..

[Defcon7]

Ci sono anch'io, C, avrstudio e atmega128

Se posso aiutare Chiedi pure.

Ciao,

Giacomo.

[Nikiki]

Io ho tutto quello che serve, ma non mi ci sono ancora cimentato.

Fin'ora ho sempre usato i PIC, ma il prossimo progetto sarà sicuramente su atmel.

[pb8511]

Ciao a tutti!!!!!

Anch'io mi trovo bene con l'Atmel.

Posso chiedervi dove comprate i micro Atmel?

Modificato: 11 settembre 2009 da pb8511

[dario c.]

ciao a tutti.

Io è da tempo che vorrei iniziare ad usare l'ATmega8 della ATMEL

perchè mi sembra un ottimo micro.

Ho anche già chiest se qualcuno lo sa usare, e mi sa dare dei consigli.

Ho scaricato ed installato l'ambiente AVRStudio,

ma non so come iniziare e soprattutto come programmare

il micro.

Qualcuno sa darmi una dritta?

Delle volte penso che quando uno inizia da piccolo a fare elettronica analogica e si specializza nell'hardware poi fa molta fatica a passare ai sistemi a microprocessore.

ciao e grazie

[ffolks]

Ciao Dario,

vuoi programmare in assembler o in C?

Per l'assembler, tanto per iniziare : www.avr-asm-tutorial.net/avr_en/

Per il C, WinAVR , winavr.sourceforge.net, è il compilatore C per ambiente avr, open source, plugin per avr studio, tonnellate di esempi ed una guida dettagliatissima.

Esistono anche compilatori basic, fino a 2 di codice sono liberi, per programmi più impegnativi richiedono la licenza.

1) Bascom AVR

2) MikroBasic pro AVR

Modificato: 21 ottobre 2009 da ffolks

[dario c.]

volevo proprio iniziare con l'assembler, ho un amico che con gli Atmel fa delle cose molto interessanti. Tuttavia non volevo acquistare la scheda di programmazione dell'Atmel e stavo cercando di capire come si fa il programmatore via seriale RS232, si tratta di quel circuitino che sfrutta due pin del micro per inviare il programma alla scheda. Tra l'altro è molto comodo perchè non serve togliere il micro per montarlo sullo zoccolo di programmazione.

[Nikiki]

i programmatori che richiedono l'inserimento del chip sullo zoccolo zif sono roba antica...

Quello che dici tu si chiama ISP (In System Programmer) con cui oltre che programmare il chip, puoi anche fare un debug.

Se cerchi su e-bay le chiavi "AVR ISP" trovi una miriade di programmatori che costano pochi euro.

Se inizi adesso io ti consiglio il C, l'assembly non è molto digeribile per un principiante ed è diverso per ogni famiglia di uP.

La sintassi del C invece contrariamente a quanto si dice è abbastanza semplice, trovi molte più librerie già fatte, lo puoi trasportare su altri sistemi, ecc. ecc.

Questo è un esempio di un programmatore.

Modificato: 13 novembre 2009 da Nikiki

[tullio86]

la freescale non la considera nessuno.. i famosi HCS...nessuno?

[Nikiki]

Ciao Tullio... anche tu da queste parti?

Considerazione a parte credo che gli Atmel AVR siano notevolmente più diffusi... dopo i PIC probabilmente arrivano loro e sono molto più performanti (4 volte più veloci a parità di frequenza di clock).

[tullio86]

si anche io sono interessato all'argomento e al settore,ma è piu una passione diciamo..

si concordo che a livello di clock sono migliori,però vedo che freescale,con i suoi vari modelli propone soluzioni di microprocessori single chip..

Amtel sinceramente non la conosco,però sò che produce microchips di tipo RISC,freescale produce CISC e anche RISC..

[c'è notevole diversità sui tempi ciclici di trasferimento delle informazioni perchè i CISC hanno una memoria di controllo per le microistruzioni e dunque ogni istruzione ISA è caratterizzata da un conseguente numero di microistruzioni..... blabla..tutte cose che saprai sicuramente visto che sei abitudinario in questo forum...]

Certo è che per l'uso che ne faccio io,mi divertire molto con gli Amtel anche se sinceramente non li conoscevo,se non per sentito dire

Come è a livello di gestione la suite software che dispone Amtel?

Modificato: 13 novembre 2009 da tullio86

[tullio86]

poi va beh l'utilizzo del chip è sempre lo stesso..nel senso che come vedo sul sito della amtel anche lei dispone di chip per le reti can ,chip per lcd,automobili ecc...ma tu hce progetti hai realizzato...sai io non sono un esperto,però mi piacerebbe,appunto per accrescere questa passione fare qualcosa..

[Nikiki]

Anche per me è una passione, a tempo pieno come sai faccio ben altro.

Io per il momento non ho fatto niente con gli atmel, ma solo per pigrizia, perchè li conosco da tanto e ho anche tutti i tools di sviluppo, è solo che fin'ora ho sempre usato i PIC.

Ho cominciato molti anni fa con gli ST, ma poi sono esplosi i PIC ed ho sempre usato quelli (all'epoca gli ST erano EPROM e si dovevano cancellare con la lampada... due palle).

L'ultimo giochino che ho fatto è un convertitore di protocollo per delle speed dome.

In genere tutti i microcontrollori moderni sono RISC, il set d'istruzioni ridotto è una caratteristica che li contraddistingue ad esempio da un x86, ma la differenza tra MCU come PIC e ATMEL pur essendo entrambi RISC è che il primo impiega 4 cicli di clock per eseguire un istruzione, mentre il secondo ne usa solo 1.

La suite software dell'atmel se la vuoi provare la puoi scaricare, ovviamente è gratuita.

[tullio86]

CERTO CERTO..il fatto che sia risc e che abbia prestazioni effettive piu elevate me l'avevi detto precedentemente...

ahaha la suite di programmi non volevo scaricarla perchè di solito è pesantina in termini di spazio..anche se non ho guardato sul sito della Amtel,(magari loro hanno qualcosa di piu leggero)...

cavoli bello il convertitore..per la speed dome,in pratica hai fatto in modo che i segnali fossero piu veloci e piu sicuro per il controllo della speed dome stessa?..

[Nikiki]

No... dovevo far funzionare delle vecchie dome già installate insieme alle dome di nuova installazione utilizzando le stesse console di comando e ho dovuto fare un convertitore perchè le prime funzionavano con un protocollo proprietario (non davano la possibilità di sceglierlo come si fa sulle nuove dome) e tale protocollo non era tra quelli disponibili nei vari convertitori che si trovano in commercio, probabilmente perchè il produttore ha scelto di non renderlo pubblico.

Infatti la difficoltà non è stata tanto quella di fare il convertitore con il PIC, ma fare il reverse engineering per ricostruire dal nulla il protocollo delle vecchie dome.

[tullio86]

Beh un lavoretto mica male..direi...

Domanda:

Io mi sono accorto che le dome quando vengono comandate tramite rete da un pc mediante mouse, hanno una lentezza che è spiegata appunto da tutti i passaggi che sussistono di decodifica e codifica...volevo sapere,secondo te è possibile fare un sistema che faccia in modo di limitare il piu possibile questi ritardi, per esempio un dispositivo programmato che comunichi in maniera diretta e in determinato modo fra convertitore della speed e scheda di rete...Non sò se la cosa abbia molto senso però perchè penso che fisicamente la cosa non sta in piedi..però..

[Nikiki]

ora stiamo andando un po' OT, se vuoi possiamo continuare l'argomento in altra sezione, comunque per farla breve, le dome hanno protocolli molto lenti, arrivano al massimo a 9600 bps, quindi non si può imputare la connessione o la codifica, la lentezza che noti quando le manovri da remoto (ad esempio tramite un DVR) è dovuta alla latenza con cui ricevi lo streaming video, che a sua volta è dovuta suprattutto ad una bufferizzazione.

In pratica nel momento in cui clicchi il mouse la dome si muove immediatamente, ma tu la vedi muovere qualche istante dopo.

Il problema si potrebbe ridurre riducendo il buffer, ma non è una cosa che possiamo fare noi.

Con alcuni DVR ad esempio la manovra è molto veloce, anche utilizzando le stesse dome.

[tullio86]

capisco..dunque è un problema che volge all'architettura di interfaccia...infatti per questo avevo messo il chiarimento relativo al fatto che fisicamente per noi.. non fosse possibile..grazie comunque dei saggi consigli