c'è un tutorial sulla creazione di una matrice di led 96 x 48 è suddivisa in 4 moduli di 32 per 16 il tipo ha fatto un gran lavoro secondo me...
ha messo a punto una routine per creare un illusione di pwm utilizzando gli shift register in maniera molto veloce da come ho capito ha un pwm con una precisione di 5bit
ho più o meno fatto la stessa cosa... anch'io con shift register e transistor di potenza
l'unica differenza è nel core lui utilizza un atmel88 cloccato a 20Mhz io ho utilizzato un 18f2550 cloccato a 24 con PLL con modulo usb , A/D, MSSPI disattivato...
beh...lui riesce a gestire 512 pwm senza flickering io non riesco ad andare oltre i 32... ora... ok che il software sarà diverso ok che l'ho scritto in C e lui l'avrà scritto in assembler... grossomodo però dovrà essere lo stesso..
mi chiedo... possibile che ci sua tutta questa differenza tra i chip ATMEL e MICROCHIP?!
In generale l'assembler è molto + performante e veloce. Se riesci prova a prendere una funziona, anche piccola, e confronta l'ASM del programma originale con l'ASM generato dal tuo compilatore C (sarà in un file con estensione .lst) e confronta le lunghezze se sono molto diverse. Poi prova a calcolarti il tempo per eseguire quel codice. Andando a memoria ogni istruzione ASM di Microchip sono 4 clock di CPU. Non mi ricordo Atmel. ciao
Il giorno Wed, 26 Nov 2008 12:15:47 +0100, "Contrario" ha scritto:
Ci sono diverse cose da notare.
Gli AVR sono più performanti dei pic perchè eseguono la maggior parte delle istruzioni in un ciclo di clock ed hanno un set di istruzioni più completo.
Inoltre per applicazioni come quella del tuo esempio, dove occorre maggior velocità e bisogna calibrare le routines al µS, l'assembler è molto più efficiente del C proprio perchè permette gradi di libertà molto maggiori al programmatore.
Inoltre quando si fanno software per circuiti del genere in assembler si possono escogitare veri e propri 'trucchi software' per sfruttare al meglio le potenzialità del software, come cercare di valutare le istruzioni e ottimizzare i registri usati nelle routines temporizzate per risparmiare cicli di push e pop. E bisogna pensare di sfruttare al meglio le caratteristiche dell'hardware, ad esempio usare il pin OE\ per controllare lo spegnimento senza dover ricaricare il tutto.
Io ho fatto una cosa del genere con una rete di Tiny2313 collegati ad un host tramite USART @ 4Mhz e ti posso assicurare che le prestazioni sono veramente notevoli, tanto che qualcuno era convinto che usassi delle FPGA, perchè riteneva impossibile avere delle velocità di aggiornamento simili senza.
In conclusione la scelta di usare i pic e un compilatore per fare cose del genere non consente per forza di ottenere prestazioni elevate.
Si! Una delle differenze fra Atmel e Pic e' che i primi eseguono una istruzione ogni ciclo di clock mentre i secondi eseguono una istruzione ogni quattro cicli di clock. In pratica si puo' considerare che, a parita' di clock, gli Atmel vanno quattro volte piu' veloci dei Pic. ciao Angelo
non sapevo di questa differenza... ora capisco perchè con un 20Mhz riesce a fare tutto quel lavoro... aggiungi il fatto che avrà ottimizzato molto in assembler ed ecco ke riesce a gestire 512 pwm software a 5 bit
io utilizzo il compilatore mikroC la soluzione più conveniente in termini di tempi di sviluppo sarebbe utilizzare il tag asm presente nel C il problema è che in mikroC non viene implementato correttamente in 10 minuti di lavoro ho trovato una valanga di bug...
un "triste" esempio...
asm { movlw 0x0F movwf PORTB }
Questo codice da ERRORE
asm { movlw 0x0F movwf PORTB }
QUESTO COMPILA!!! :=O
ed è solo la punta dell'iceberg
sto cercando di convertire il codice C in asm ma non è facile una difficoltà è quella di riuscire a gestire ildoppio array che uso per memorizzare i pixel che compongono la matrice di 8 x 8
Tanto per completezza, avendo attivato il PLL recuperi quella differenza. Il busillis credo stia nel compilatore C... perche' non hai usato il C18 che e' decisamente meglio del MikroC?
Non ti assicuro che otterrai le stesse prestazioni degli Atmel, ma sicuramente migliori. Poi bisogna vedere come scrivi il codice... ;)
Il giorno Thu, 27 Nov 2008 12:20:02 +0100, "Contrario" ha scritto:
E non è la sola.
Gli AVR non usano un registro accumulatore, ma tutti i registri da R16 a R31 possono lavorare da accumulatori, mentre i primi 16 sono 'quasi' accumulatori, essenzialmente perchè non supportano le istruzioni 'immediate'
Es. puoi fare Ldi R16,1 ma non Ldi R1,1
mentre puoi fare:
Add R1,R16 ; con destinazione R1
Oltretutto gli mnemonici degli AVR sono più facilmente comprensibili di quelli dei pic e comprendono più istruzioni.
Qui trovi molta roba in asm:
formatting link
Inoltre la presenza di uno stack pointer rende il tutto molto più usabile rispetto allo stack hardware a livelli definiti.
Anche la memoria indirizzabile linearmente è un bel vantaggio rispetto alla memoria paginata quando lavori in assembler, così come la presenza di istruzioni di indirizzamento indiretto quali ICall e IJmp che facilitano la creazione di codice condizionale con soluzioni rapidissime.
Sulle caratteristiche tecniche ti segnalo anche un vecchio thread, tanto sono sempre le stesse cose.
formatting link
Se lavori in assembler lo fai per ottimizzare e sfruttare al meglio le caratteristiche del µC, anche perchè è più difficile, almeno a certi livelli.
Qui puoi scaricare l'assembler IAR:
formatting link
formatting link
Per cominciare poi ti puoi costruire un programmatore seriale o parallelo con 4 componenti:
formatting link
Poi esiste la possibiltà di usare migliori strumenti di debugger come ad esempio il JTAG, davvero una cosa galattica usato insiema a WinAvr.
Mi ero limitato alla spiegazione dei quattro cicli a operazione perche' chi usa un 2550 non puo' essere un novellino e deve sapere che arma ha tra le mani; altrimenti rischia di spararsi un colpo in un piede. Comunque, discorso chiuso, dato che, come avrai visto, si prospetta un passaggio al "galattico" ambiente Avr. ciao Angelo
è esattamente quello che ho iniziato a fare questo pomeriggio...
anke a me era venuto il sospetto che mikroC fosse un compilatore troppo poco ottimizzato punta molto sulla semplicità che va naturalmente a discapito delle prestazioni
Ciao Angelo nel mio piccolo e umile mondo elettronico i 16f iniziavano a starmi stretti troppa poca ram, troppa poca rom sono passato al 2550 in quanto l'avevo comprato tempo fa per fare un piccolo progetto con l'usb so che l'entry level dei 18F è il 452 se non erro
mi sto rendendo conto che vista dal punto di vista di un programmatore C che ha usato fin ora il mikroC le cose cambiano..ma non poi molto a parte qualche configurazione da fare
lato asm invece... credo che sia una ventata di reali novità
infatti nei mei piccoli esperimenti con l'asm ho iniziato con il 628
p.s. oggi ho "perso" 2 ore per capire perchè i sorgenti di alcuni tutorial per asm scritti in funzione del 16F84 non funzionavano con il suo compatibile 628 poi mi sono reso conto dell'oblio e dell'utilità di quell'immagine che trovato in tutti i datasheet riferita all'architettura della memoria che avevo sempre snobbato in quanto poco utile ^__^
dietro 2 righe di codice org 0x20 cnt RES 1 ci sono state grande scoperte per un niubbo come me ^_^
La cosa piu' importante e' che la serie low non e' molto adatta all'uso con compilatore C.
A parte il fatto che hai un Pll e un generatore di clock interno che ti permette di andare a 48 MHz. di clock con un quarzo a 4, e anche senza, con il clock interno, se non usi la periferica Usb come mi sembra tu stia facendo.
Come vedi, non avevo sbagliato nel dire che chi usa il 4550 deve sapere quale arma ha in mano... e aggiungerei anche che sei niubbo, cosi' ti autodefinisci, ma fino ad un certo punto; perdere due ore per trovare l'inghippo nella gestione della memoria dati fra due micro, presuppone, a mio avviso, un tasso di niubbaggine non troppo elevato.
per il niubbo, vedi sopra per altre cose e... comunque... ad majora... ci risentiamo per i descrittori usb, quando "forse", potro' esserti piu' utile! Ormai il 4550 ce l'hai, spero che non vorrai utilizzare solo una piccola parte delle sue possibilita'. ciao Angelo
Beh, non avevi tutti i torti. Quando si sceglie un tipo di controller il minimo che si possa pretendere è che tutti i modelli abbiano lo stesso modello di memoria (almeno da 0 a 64K) e che periferiche uguali funzionino nello stesso modo.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.