Använd inte 18FXX20 ...
http://ww1.microchip.com/downloads/en/d ... 80129j.pdf
Led-skylt - 32-ledmatriser - 2240 punkter
-
JimmyAndersson
- Inlägg: 26308
- Blev medlem: 6 augusti 2005, 21:23:33
- Ort: Oskarshamn (En bit utanför)
- Kontakt:
> Använd inte 18FXX20 ...
Varför inte ?
Det enda av vikt i errata sheetet är 4Mhz begränsningen
om vilket det står :
> This problem is specific to Rev. A3 silicon and has
> been resolved by Rev. A4 (devices with date code
> 0421 or later) of the silicon.
Annars är det bara småsaker som förekommer på många
PIC18 modeller. DAW och C-flaggan t.ex, en klassiker.
Något annat som krånglar vid -40 grader C...
För övrigt så pekar mycket just nu på att Wisp628 skulle
kunna programmera 18F8622, men det verkar inte vara
någon som har provat...
Varför inte ?
Det enda av vikt i errata sheetet är 4Mhz begränsningen
om vilket det står :
> This problem is specific to Rev. A3 silicon and has
> been resolved by Rev. A4 (devices with date code
> 0421 or later) of the silicon.
Annars är det bara småsaker som förekommer på många
PIC18 modeller. DAW och C-flaggan t.ex, en klassiker.
Något annat som krånglar vid -40 grader C...
För övrigt så pekar mycket just nu på att Wisp628 skulle
kunna programmera 18F8622, men det verkar inte vara
någon som har provat...
Jag hade nog byggt med någre SIPO (Serial In Parallell Out) skiftregister för att driva raderna. Det finns ju 10bit sådana kretsar och då sätter man en bakom varje LED-modul och sedan behöver man bara dra 3-4 ledare mellan dessa och till CPUn... Man har ju gott om tid att klocka ut hela raden medans den föregående visas.
På kolumndrivningen skulle nog jag använda 7 st transistorer med tillhörande motstånd istället för det två ULN:arna.
Gör man så klarar man sig med 12 I/O pinnar på processorn + de för kommunikationen) och då kan man köra med en mindre, enklare och billigare, Varför inte 18F1220 som kostar hälften så mycket och är SO18...
//B1N4RY
På kolumndrivningen skulle nog jag använda 7 st transistorer med tillhörande motstånd istället för det två ULN:arna.
Gör man så klarar man sig med 12 I/O pinnar på processorn + de för kommunikationen) och då kan man köra med en mindre, enklare och billigare, Varför inte 18F1220 som kostar hälften så mycket och är SO18...
//B1N4RY
Jag skulle rekommendera leddrivers. För det första så slipper du resistorer till alla leds och för det andra så blir det enklare att korrigera avvikelserna mellan ledarna. Kolla på Texas TLC5941, funderar på att använda dessa i mitt ledprojekt. Dessa klarar av 12 bitars PWM och kan korrigera varje led så hela skärmen lyser med samma nyans vid samma färg. Eftersom de har inbyggd PWM så behöver inte överföringen till dem bli så hög heller. Klocka in datan under tiden PWM cyklen körs.frejo skrev:Nej, jag kommer inte kunna ha en hel rad tänd åt gången som jag först tänkt. Den klarar 200mA på alla IO-portar samtidigt. Så det blir att tända max 8 kolumner åt gången. Får se om jag kommer på nån smart lösning på det, börjar bli trångt på kortet nu.
Har ju även tittat på separata led-drivare men då blir det lite segt att svepa hela displayen, fördelen med en mikrokontroller är att den kan hålla bilddata i ram och sköta uppdateringen av lysdioderna oberoende av mitt styrkort.
TLC5941 (och TLC5940) har en stor nackdel som gör dom lite svåra
att jobba med i mindre lösningar...
De har ingen intern PWM klocka. Man måste själv mata de med en
klocka på en pinne. Man måste dessutom hålla reda på hur många
pulser man har kört in för att veta när en hel PWM period har passerat
(4096 pulser).
Så "inbyggd PWM" är inte helt korrekt. Det är inget man bara slår på
och som sedan rullar på av sig självt.
Se timing diagram på sidan 16 i databladet...
Det extra strulet med PWM-klockan gjorde att jag skippade denna
och istället tittar på en programvaru-PWM i en PIC18 (30 kanaler
med en LED på varje med ca 100 olika ljusnivåer som ska köras
upp och ner efter en konfigurationstabell i Flash).
EDIT:
Ett förtydligande...
Eftersom varje PWM-cykel är 4096 pulser på PWM-klockingången,
och om man vill ha flimmerfria LEDs (säg 100 Hz), så behöver man
en frekvens på PWM klockan som är högre än vad man "bekvämt"
genererar på t.ex en PIC/AVR pinne (alltså nästan en halv Mhz)...
att jobba med i mindre lösningar...
De har ingen intern PWM klocka. Man måste själv mata de med en
klocka på en pinne. Man måste dessutom hålla reda på hur många
pulser man har kört in för att veta när en hel PWM period har passerat
(4096 pulser).
Så "inbyggd PWM" är inte helt korrekt. Det är inget man bara slår på
och som sedan rullar på av sig självt.
Se timing diagram på sidan 16 i databladet...
Det extra strulet med PWM-klockan gjorde att jag skippade denna
och istället tittar på en programvaru-PWM i en PIC18 (30 kanaler
med en LED på varje med ca 100 olika ljusnivåer som ska köras
upp och ner efter en konfigurationstabell i Flash).
EDIT:
Ett förtydligande...
Eftersom varje PWM-cykel är 4096 pulser på PWM-klockingången,
och om man vill ha flimmerfria LEDs (säg 100 Hz), så behöver man
en frekvens på PWM klockan som är högre än vad man "bekvämt"
genererar på t.ex en PIC/AVR pinne (alltså nästan en halv Mhz)...
Du har rätt sodjan, men skulle det inte gå att lägga en timer med ett interupt som håller koll på och räknar upp PWM klockan. Sen låter man resten av tiden gå till att klocka ut ny data till dem.
Inte bättre att bygga drivingen till skrämen med en CPLD eller FPGA istället ? Om du vill kunna köra grafik och animationer så behövs det bra med processorkraft. En CPLD skulle kunna ha ett block som styr PWM klockan och ett annat block som klockar in ny data parallellt med varandra. Datan skulle kunna komma från ett dubbelports RAM där CPLD hämtar pixelvärden och under tiden kan en PIC skriver in nya värden i lägre fart.
Inte bättre att bygga drivingen till skrämen med en CPLD eller FPGA istället ? Om du vill kunna köra grafik och animationer så behövs det bra med processorkraft. En CPLD skulle kunna ha ett block som styr PWM klockan och ett annat block som klockar in ny data parallellt med varandra. Datan skulle kunna komma från ett dubbelports RAM där CPLD hämtar pixelvärden och under tiden kan en PIC skriver in nya värden i lägre fart.
