[HowTo] Ledbar met 64 leds

.

exter wijzigde dit bericht 05-08-2004 02:00 (151%)

quote:

Corpse2 schreef op 05 februari 2004 @ 10:46:
Voor degenen die dit niet direct zien, waar staat het juist en waar verkeerd?
Is dat eaglebestandje in de opening correct?

ja hij staat goed in het eagle bestand. de "opening" in de header moet naar het midden van de print staan. Ipv naar buiten zoals in 1 van de pics staat

dat klopt jah
k heb zelf beide headers andersom op de print gezet (waarom weet ik niet meer, maar ik denk dat het te maken heeft met de trekontlasting op de connector waar de bandkabel ingeknepen zit).

De pinconnecties in mn voorgaande post zijn gebaseerd op de eagle boards. Als je de boxheader 180 graden draait tov die eagle boards(zoals op de foto's) moet je ff uitzoeken wat dan de pinconnecties zijn. Voor de ledprints is het niet zo'n ramp als deze verkeerd zitten, er gaat dan iig niks kapot. Maar voor de programmeerkabel is t wel belangrijk, als die verkeerd is gaat ws je parallele poort kapot.

FF goed opletten dus

Damn stoere muziek bij die filempies:)

welke nr's sijn dat?
nice shit man

bgin die tekst al te kenne van et plaatje.......Just get yourself HA!! ofsow:)

BVD

Coole mod mah k had em al de hoogte in geprezen geloof ik

Als je dit draadje had gelezen wist je het wel.

Nyw het is : The Chemical Brothers , met ........

Mensen, even een waarschuwing (eendje is te druk): Let op dat je molex met de RODE draad doorverbind, NIET de gele. Anders gaat het gruwelijk stinken. Dus als je de chips naar je toe hebt liggen, en de molex van je af, dan zit de rode draad LINKS.

mwa let dus goed op! ik had een molexconnector (die imho heel normaal is) maar daarmee blijkt dus dat je 12volt op je chippies zet... niet echt heel handig.. geeft veel rook en veel rotzooi

maar nu werkt alles weer

arghhh een pic proggen onder winxp is bij mij een no go... ik krijg het maar niet voor elkaar.. zuig zooi

Gaat dat via de parallelle poort? Dan moet je een dll (dlportio oid) downloaden!!!

quote:

Benadski schreef op 06 februari 2004 @ 15:41:
Gaat dat via de parallelle poort? Dan moet je een dll (dlportio oid) downloaden!!!

i know en ook nog een ander progje wat het dan als device installeert... maar dat andere progje is fubar...

probeer het eens hiermee: fpp+giveio+installer

Extracten naar een dir, installer.exe draaien, in dat programma giveio.sys selecteren, en dan op install klikken.
Dat zou moeten werken (zowel onder win2k als winxp).

thnxs fpp werkt eindelijk. alleen nu moet ik een zooi dingen instellen waar ik niet helemaal uitkom. bij setup moet je (duh) natuurlijk kiezen voor lpt1 en voor de 16f628 maar wat moet je bij hardware kiezen? topic geeft een can't program error. Moet er nog wat anders ingesteld worden?

instellingen voor fpp:

hardware: tlvp
on port: lpt1
device: 16f628

dan zou t moeten werken

ik doe gewoon load en neem dan die hex van je ga naar setup en vul die dingen in. doe dan program en krijg nog steeds dezelfde error

hum

je hebt wel spanning op je controllerprint staan ?

een wilde gok maar
dit staat op die site (http://www.finitesite.com/d3jsys/) van die programmer

WARNING!!!
This programmer currently only works with a short parallel cable. I advise not using a cable more than 2 feet in length. Longer cables will result in erratic operation.

is je kabel langer dan 61cm ?
zal wel niet maar je weet nooit

In een elektuur tijd schipt heb ik ergens een schema staan van hoe je makelijk een oneinge grote vu meter kan maken. Was dat niet makelijker geweest dan hoe je het nu heb gemaakt ?
Het scheeltje wat ic's en programeer werk.

quote:

Soul_ schreef op 08 februari 2004 @ 18:48:
een wilde gok maar
dit staat op die site (http://www.finitesite.com/d3jsys/) van die programmer

WARNING!!!
This programmer currently only works with a short parallel cable. I advise not using a cable more than 2 feet in length. Longer cables will result in erratic operation.

is je kabel langer dan 61cm ?
zal wel niet maar je weet nooit

m'n kabeltje is een meter of 2

maar als ik read doe geeft ie keurig aan dat het ding nog niet geprogrameert is dus hij kan het ictje wel lezen alleen proggen niet... bagger

k gebruik zelf een bandkabel van +- 90 cm. De signaaldraden zitten dan tussen 2 draden met gnd in (weet niet of dat nog wat uitmaakt verder). T werkt iig perfect.

Dat fpp de pic wel kan "readen" zegt verder vrij weinig. Als je namelijk niks aansluit op de parallele poort gaat t readen ook goed (komt dan gewoon "blank" te staan.

Maaruh, begin ns met de kabel inkorten, misschien dat dat helpt.
k zal zo ff een plaatje posten met een wat duidelijkere pinlayout van de kabel, kan je ff controleren of ie wel klopt.

Voor de rest kan er weinig fout gaan, op het weerstandsnetwerkje op de controllerprint. Zit de gnd van dit weerstandsnetwerkje goed (dus niet verkeerd om) ?

edit:
Zo zou de kabel inelkaar moeten zitten (hoop dat t zo iets duidelijker is)
De nummering op de 25 pins sub-d male connector komt overeen met de nummering zoals deze normaal af te lezen is op de connector zelf.

(klik voor n groter plaatje)

Lone Gunman wijzigde dit bericht 08-02-2004 19:55 (86%)

Ik heb nog eens naar je PWM routine gekeken (zeer interessante oplossing, zie je echt het verschil tussen C en ASM 'denken'). Ik denk niet dat je hier veel aan kan veranderen zonder (te) grote impact. De afhandeling kan in principe wel (klein beetje) efficienter. Nadeel is dan wel weer dat de afhandelingstijd gaat varieren. Voor de leesbaarheid kan de gehele PWM-routine natuurlijk in een 'loop'

Mocht iemand iets groters/snellers willen implementeren heb je uiteraard nog de mogelijkheid om een 6-tal extra 'outputs' te gebruiken. Hier kunnen een aantal additionele ledbars op, of de schuifregisters kunnen sneller gevuld worden (hogere frequentie). De on-board programmer komt dan natuurlijk te vervallen.

Nog wat winst kun je halen door de seriele communicatie eens elke 5/10 cycles te pollen ipv elke cycle. De afwijking zal nauwelijks zichtbaar zijn. Volgens een snelle berekening kan je register met 115kbaud hoogstens in 3-5 cycles gevuld zijn. De marge is echter niet ZO groot. Wel is je programma dus nog steeds veel sneller dan de maximale updatesnelheid van je data.

laatste opmerking is dat je met de huidige code natuurlijk meer dan 64 bytes data kan versturen zonder foutmelding. Hierdoor zou (met veel pech) je volledige ram overschreven kunnen worden.

Leuk dat iemand de moeite heeft genomen om de code eens door te lopen

K ben trouwens begonnen in c (icm de hitech picc compiler).
De pwm routine was toen interrupt driven (dmv een timer), en de serieele ontvangst ook. Met die c code was 6 bits pwm @ 75 Hz het max haalbare iirc.
Daarna de pwm routine omgeschreven naar asm zonder gebruik te maken van interrupts (combo van asm en c dus), maar dat haalde niet zoveel uit als ik verwacht had.
Toen ben ik maar from scratch begonnen in asm. Scheelde wel iets, maar nog niet optimaal (k wilde perse 8 bits pwm krijgen ).
Maar op een gegeven moment viel met het volgende te binnen:
movf count, W
addwf led, W
rlf PORTA, F
Die routine zorgde er iig voor dat het afhandelen van de pwm snel genoeg ging om 8 bits pwm te krijgen (niet helemaal waar trouwens, als led 0xff is, wordt de carry flag niet geset... de intensiteit 0xff wordt dus niet vertaald naar 100% van de tijd vol aan). Als iemand hier een oplossing voor heeft die geen invloed heeft op de timing, post maar

Wat betreft de serieele routine:
Het afhandelen van de serieele routine duurt nou ~25 cycles; de pwm afhandeling neemt er 256 in beslag. Echt veel winst is hier niet te behalen dus (paar Hz meer of minder is niet echt interessant). De serieele routine om de x aantal keren laten draaien heeft dus niet echt veel invloed op de snelheid. Door de serieele routine te draaien op iedere pwm routine is het iig mogelijk om een continue datastroom @ 115200 kbps te verwerken zonder dat er een buffer overrun komt.
K ben wel van plan om dit enigzins te herschrijven, zodat er een "beter" protocol is.

Wat betreft de buffer van de leddata: er wordt idd niet gecontroleerd of er meer dan 64 bytes gestuurd worden. Het indirecte adres kan dus idd naar geheugen wijzen waar eigenlijk niet geschreven moet worden. Een check inbouwen zal ik wel doen als ik het nieuwe protocol maak (als iemand nog suggesties heeft mbt tot een efficient protocol... post hier maar ff ). In de praktijk blijkt echter dat het overschrijven geen invloed heeft op het draaien van het programma... als ik willekeurig meer dan 64 bytes data stuur naar de pic (geen 0xff), dan krijg je wel troep op je leds te zien, maar zodra je 0xff stuurt en daarna weer data, dan laat ie het weer goed zien waarom dat is weet ik niet (k neem aan dat het indirecte adres gefoldt wordt over de memorymap), maargoed

wbt meer leds aansturen:
k denk niet dat het met de huidige hardware mogelijk is om veel meer leds aan te sturen. Overstappen op een atmel is misschien een optie, je wint dan in snelheid (10/16 mips tov 5 mips) waardoor je gewoon meer leds aan kunt sturen... ~2-3 keer zoveel leds als nu het geval is.

Qua code-efficientie houdt t denk ik hier wel op, je zal dus echt naar iets anders moeten overstappen. Een fpga of een spld met sram zou een optie kunnen zijn, heb je relatief hoge snelheden ( >100 mHz). Maar dat is minder toegankelijk dan een mcu voor mensen die zelf zoiets willen nabouwen.

Lone Gunman wijzigde dit bericht 09-02-2004 16:10 (16%)

Zou iemand mij kunnen vertellen wat ik moet veranderen als ik in plaats van de gebruikte groene LEDs , blauwe LEDs wil gaan gebruiken.

Het lijkt mij dat de weerstanden voor de LEDs aangepast moeten worden,
maar mijn elektronica kennis gaan niet zover dat ik kan zien hoeveel ohm deze dingen moeten gaan worden.

Misschien moet er ook nog wel meer veranderd worden???

quote:

aragornholio schreef op 18 februari 2004 @ 20:45:
Zou iemand mij kunnen vertellen wat ik moet veranderen als ik in plaats van de gebruikte groene LEDs , blauwe LEDs wil gaan gebruiken.

Het lijkt mij dat de weerstanden voor de LEDs aangepast moeten worden,
maar mijn elektronica kennis gaan niet zover dat ik kan zien hoeveel ohm deze dingen moeten gaan worden.

Misschien moet er ook nog wel meer veranderd worden???

In principe hoef je alleen de weerstanden te veranderen...
Je moet weten hoeveel stroom die blauwe leds vragen en aan de hand daarvan reken je je voorschakelweerstand uit...
Kijk voor hoe en wat in de FAQ.

Heeft iemand intussen al iets dat werkt kunnen produceren?
Ik heb de meeste onderdelen al aangeschaft, enkel nog wat weerstandjes en condensatortjes en ik heb alles. Alleen ontbreekt de tijd me op dit moment een beetje.

hmm nu ik dit topic weer zie lijkt t me ook erg leuk om te gaan maken, op school kan ik dan (hopelijk) etsen. Kan ik eens wat beter kennismaken met een PIC enzo, op school doen we daar wel eens wat mee, maar dat is natuurlijk iets heel anders dan dit.