Svenska ElektronikForumet

Använd inte 18FXX20 ...

http://ww1.microchip.com/downloads/en/d ... 80129j.pdf

Blev först lite "orolig" av ditt inlägg. Jag kör med 18F2320 och 18F1320 ...

Har inte läst hela pdf-filen, men det gäller alltså 18F6620, 18F8620, 18F6720 och 18F8720.

Var lite slarvig... Tack Jimmy

Samt att Errata bladet gäller bara för vissa produktionsserier.

speakman skrev:Trissor kanske är att föredra framför FET om du vill multiplexa snabbt?

Har tänkt multiplexa i 100-200Hz... det är ju egentligen inte så snabbt, borde det inte gå bra med FET då?

>> frejo

Går alldeles säkert utmärkt. Om du inte väljer världens fetaste FET så kommer du högt upp i switchfrekvens med de 25 mA (cirka) du har från PICen. Men som du säkert vet är FETar lite dyrare.

2N7002 kostar 0.85 om man köper 100 pack och 0.56 om man köper 500-pack. Blir ju inte så hiskligt dyrt för 320st då...
Fast jag sitter just nuoch funderar på om jag ska slänga in darlingtondrivkretsar även på kolumnerna...

> 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...

Ny version av drivningen:



Valde att använda 6st extra darlingtondrivare istället för 40 transistorer per kort.

Ska bli spännande att se om man kan lyckas med routningen:

oops, upptäckte just att jag tänkt lite galet... Darlington drivarna är ju till för sänkning, raderna är kopplade till anoderna på lysdioderna. Blir ju inte så bra om jag sänker dom.
Måste alltså driva raderna på något sätt. Får nog bli trissor där då istället, om ingen vet nån lämplig drivkrets?

Kan ingen billig på rak hand men UDN 2981 skulle funka.

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

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.

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.

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)...

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.

Visst skulle en FPGA göra susen. Jag tycker själv att steget från en PIC/AVR till FPGA känns stort. Nya språk, hårdvara som fungerar på helt annat sätt, ny programvara, etc...