Studiare un micro - quale famiglia ?

Famiglia AVR. Ha un set di istruzioni pi=F9 ricco e permette implementazioni di linguaggi migliori. Per sviluppi impegnativi, ho provato ed utilizzato FUJITSU a 16 bit che rappresenta una soluzione professionale molto potente ed elastica. Non trovi in rete, per=F2, l'abbondanza di supporto tipica degli AVR.

Piccio.

atatat ha scritto:

La famiglia AVR di Atmel.

nembo kid ha scritto:

Volendo andare contro corrente potrei dire un PIC 18F o meglio ancora un dsPIC che è un PIC preogettato per fare da DSP. Volendo volare un po' più alti c'è ARM che fa degli ottimi core...

-- Il Razziatore, "Lo sviluppo di una nazione si misura anche dallo stato della sua rete ferroviaria". Camillo Benso Conte di Cavour "Per tutto quanto non previsto nel presente regolamento il capostazione deve usare senno e ponderatezza." Regolamento d'esercizio FS

----------------------------------------------- MSN : snipped-for-privacy@netscape.net ICQ : 67552596 Yhaoo : Razziatore82

----------------------------------------------- Founder of MediaPlayer Project

Ciao a tutti!

Ragazzi mi sembra di capire che odiate tutti i Pic, ma cosa vi hanno fatto? :-) forse sono troppo semplici e alla portatata di tutti?

Esattamente l'opposto, sono troppo complicati e limitati a causa della loro architettura bislacca. Comunque se ne è già parlato, puoi vedere qui:

Ho capito , ma quei discorsi sulla paginazione, stack, ecc. riguardano hardware nello specifico, usando compilatori con linguaggio C, basic, pascal, ecc., dovrebbero essere gestiti da questi ultimi, se poi il discorso vogliamo portarlo sulla efficienza del codice generato, allora secondo me e' come ho detto nell' altro post, cioe' c'e' l'avete con la Microchip, perche' non si puo' dire che per far accendere un led ci vuole micro ARM a 32 bit, per poi parlare di efficienza del codice generato dai compilatori per il Pic.

Comunque ammetto nel mio piccolo, di aver notato che alcuni prodotti commerciali (parlo del mio campo cio' della sicurezza) sono nati con microcontrollori della Microchip e con il tempo sono stati sostituiti da quelli AVR

Niente, ho programmato per anni i PIC di classe 16F in assembly e posso assicurare che sono decisamente scomodi.

Il giorno Sat, 21 Jun 2008 09:35:23 +0200, "Enzo" ha scritto:

Nessuno li odia, semplicemente vengono valutati con criteri tecnici, e obiettivamente hanno caratteristiche che non li rendono attraenti.

Se ti leggi il thread che ha indicato Franceso sono state spiegate le ragioni.

-- ciao Stefano

In quel thread ci sono poche cose tecniche, c'e' piu' lite fra i partecipanti che altro, per la questione dello stack basta usare le variabili globali, poi in giro si trova tanta di quel materiale sui Pic che per chi vuole iniziare e' una buona cosa, poi come si dice l'appetito vien mangiando.

Il giorno Sat, 21 Jun 2008 12:37:14 +0200, "Enzo" ha scritto:

L'errore è che venga vista come una guerra di religione invece che una disputa tecnica.

Insomma, lo stack hw ti impedisce anche di fare chiamate nidificate di funzioni.

Indubbiamente, ma per cominciare io preferirei un AVR, poi, come ho scritto in un altro post, penso che tradirò gli amati AVR per un ARM7, è che bisogna stare sul treno giusto, non se ne possono + perdere, soprattutto oggi.

-- ciao Stefano

he

Per applicazioni ben strutturate lo stack =E8 essenziale per le chiamate a subroutine ma soprattutto per gli interrupts. Con gli AVR posso permettermi di passare dati sullo stack tra subr. perch=E9 =E8 accessibile con push e pop. Ho scritto brevi subr., ad esempio, dove facevo seguire alla call dei parametri.

rcall print .db "Hello world",CR,LF,nul

nop nop

tradotto poi in:

;************************************************************** ;* STAMPA LA STRINGA ASCIIZ CHE SEGUE LA RCALL ;**************************************************************

print: pop ZH ;address MSB di ritorno (inizio stringa) - word - pop ZL ;address LSB di ritorno (inizio stringa) - word -

lsl ZL rol ZH ;converti puntatore word in puntatore byte print_loop: lpm tst r0 breq print_end ;esci se il chr =E8 0x00

push RX0 mov RX0,r0 rcall RS_write ;invia chr alla RS232C pop RX0

ld r0,Z+ ;prossimo chr rjmp print_loop print_end: lsr ZH ror ZL ld r0,Z+ ;indirizzo corretto di ritorno ijmp ;PC

Il giorno Sat, 21 Jun 2008 04:14:16 -0700 (PDT), Piccio ha scritto:

e mancava anche l' AND (o forse era l'OR) tra i registri.

Gli ST6 sono in fondo alla classifica dei µC che ho usato, sono meglio i PIC.

-- ciao Stefano

i PIC.

Quoto a met=E0. Gli ST6 potevano accedere alla memoria programma tramite una finestra di 64 byte rimappata, i PIC non avevano tale prerogativa. Per avere delle costanti multibyte dovevi scrivere altrettante istruzioni di caricamento immediato.

Certo che avendo fatto le ossa sullo Z80 e famiglia completa, l'ST6 =E8 stato un trauma. Per=F2 uno impara a come tesaurizzare le risorse (soprattutto di RAM e, ancor di pi=F9, di memoria programma).

Piccio.

Il giorno Sat, 21 Jun 2008 04:39:01 -0700 (PDT), Piccio ha scritto:

Non ricordo bene gli ST6, li ho usati un paio di volte negli anni '90, come del resto i PIC.

Io ho iniziato con i WD della Western Digital e i COP della National, ma lo Z80, mitico, era tutta un'altra cosa, ho fatto delle macro per usare sugli AVR le istruzioni Z80.

Con i µC di allora si tesaurizzava per forza, con 1K di mem. programma e 64 bytes di ram c'era poco da scialacquare.

-- ciao Stefano

SB ha scritto:

E' ancora il leader indiscusso in ambito didattico. ;-)

Il Sat, 21 Jun 2008 14:42:53 +0200, nembo kid ha scritto:

non credo. Noi usiamo il PIC 16F per assembler e 18F.. con il C.

Per via che i sistemi di sviluppo sono economici e richiedono hardware molto ristretto. Lo Z80 =E8 un microprocessore che non ha sviluppato molto la filosofia del microcontrollore (Z180,Z280 ecc). E' pi=F9 impegnativo da mettere in piedi (ROM e RAM perlopi=F9 esterni) ed ha molte istruzioni, alcune delle quali specializzate (OTIR ecc.). Il sistema vettorizzato degli interrupt non =E8 di immediata comprensione cos=EC come la daisy-chain tra periferiche.

L'assembler ed il C imperano in ambito Zilog, anzi, con il CP/M hanno fatto da musa ispiratrice per tutto ci=F2 che storicamente =E8 seguito.

Stiamo parlando, per=F2, di filosofie diverse: Harvard Vs Von Neumann. Le differenze sembrano sottili, ma non lo sono. Con architetture Von Neumann =E8 possibile (e l'ho fatto) generare codice non rientrante pi=F9 a=F2tre finezze.

Piccio.

adriano ha scritto:

Scelta didatticamente del tutto sbagliata, IMHO.

Il giorno Sat, 21 Jun 2008 10:01:22 -0700 (PDT), Piccio ha scritto:

Come ad esempio codice eseguito direttamente in RAM, cosa che feci a suo tempo per gestire un sistema a banchi di EPROM, con un Harvard non si può fare.

-- ciao Stefano