wij zijn bezig met een project op school met de bitsim(verpicht:() en wij hebben bedacht om een led cube te gaan maken.
we hebben daar een 4 - 16 decoder (MC14515BCPG (dit ic omdat er een fout is geweest bij de bestelling het had de MC14514BCPG moeten wezen dus hebben we nu inverters erachter gezet staat niet in het schema)) bij gebruikt om meer outputs te krijgen.
we hebben de outputs van de 4-16 decoder aan de basis van transistoren gezet om de "kolomen" te kunnen schakelen en dat werkt tot nu allemaal das geen probleem alleen we zijn nu al een stuk verder en we hebben nu het probleem als we vanaf de bitsim alle codes van de waarheidstabel verzenden achter elkaar krijgen we bij de code 0000 en 1111 dat er 2 leds branden terwijl er maar 1 uitgang per keer 1 kan wezen bij de decoder die wij gebruiken.
(we hebben dit probleem zonder een weerstand naar de nul om de "zweef" stand te verhelpen alleen als we wel een weerstand gebruiken dan werken alle ledjes behalve de gene van de laatste code (1111) die gaat heel kort aan en ook bijna onzichtbaar aan (sneller dan de geprogrammeerde delay) en dan blijft het eerste ledje v/d code (0000) langer branden dan de rest (bijna 2 delay tijden)
en dan nog iets als we het zonder bitsim doen dus die codes gewoon met de hand maken (draadjes van de ingangen van de decoder naar de plus enzo) dan werkt het wel gewoon goed.
we hebben het ic al een keer vervangen, naar kortsluiting gezocht, transistoren gechecked of daar iets mee was etc. etc. etc. maar we kunnen niks echt vinden.
hoe kan dit??
en wat kunnen we eraan doen?? ideeën??
Een schemaatje zou helpen, met vermelding van de gebruikte IC's. Dan kunnen we hier precies zien wat je hebt gemaakt.
Arco
Special Member
Arco - "Simplicity is a prerequisite for reliability" - hard-, firm-, en software ontwikkeling: www.arcovox.com
En waar gaan L1.1....L4.1 naar toe???
L1.1, L2.1, L3.1, L4.1 komen vanaf de gezamelijke nul (v/d leds) van de lagen van de led cube en er zit dus 1 transistor tussen de gezamelijke nul (v/d leds) van elke laag en de nul.
Roland van Leusden
It's the rule that you live by and die for It's the one thing you can't deny Even though you don't know what the price is. It is justified.
en dan nog iets als we het zonder bitsim doen dus die codes gewoon met de hand maken (draadjes van de ingangen van de decoder naar de plus enzo) dan werkt het wel gewoon goed.
Lijkt me een bitsim probleem dan. Pak een logic analyzer en kijk of bitsim wel de juiste signalen stuurt.
en jij denkt dat school die heeft:);) maar maakt niet uit
we hebben wel gekeken of er goede singalen uit de bitsim kwamen m.b.v. een oscilloscope en dat klopte voor zover als wij weten en de bitsim geeft het ook aan als er een signaal op de uitgangen staan want dan gaan de "censim_out" leds aan in de code die verstuurdt wordt maar we kunnen morgen wel even kijken of we niet iets verkeerd gemeten hebben just in case:P
free_electron
Silicon Member
Professioneel ElectronenTemmer - siliconvalleygarage.com - De voltooid verleden tijd van 'halfgeleider' is 'zand' ... US 8,032,693 / US 7,714,746 / US 7,355,303 / US 7,098,557 / US 6,762,632 / EP 1804159 - Real programmers write Hex into ROM
fout in je programma code. als het correct werkt als je de ingange stuurt met de hand dan is je circuit correct.
waarschijnlijk rol je direct over van eindwaarde naar beginwaarde zonder te wachten. je loop constructie is verkeerd in je programmacode.
dit is het test programma hier loopt hij alle waarheidstabelcodes langs:
ORG 4000h
;
;PLACE PROGRAM CODE HERE
MOV A,#00001111B
START: CALL CENSIM_OUT
CALL DELAY
DEC A
JMP START
DELAY: PUSH DPH
PUSH DPL
PUSH ACC
MOV DPTR,#00FFFh
WAIT_LOOP: CALL DEC_DPTR
MOV A,DPL
ORL A,DPH
JNZ WAIT_LOOP
POP ACC
POP DPL
POP DPH
RET
;
;
;
;
; ORG 8000h
dit is het programma we hebben wel meerdere versies gehad alleen deze is de laatste (stelt niks voor ik weet het)
(btw nog een extra vraagje hoe kan je met een hexadecimale code de delay tijd in secondes uitrekenen op een makkelijke manier dus bijvoorbeeld 0FFFF = ....sec)
[Bericht gewijzigd door easgan op (12%)]