Beste lezer,
Ik ben bezig de 10 kanalen ontvanger van Frits K. (www.picbais.nl)
te verbouwen naar een 16F628A PIC met als doel deze ook met PWM te gebruiken. De toggle versie werkt inmiddels met een 4Mhz kristal maar ik zou graag de frequentie opvoeren naar 10 of 20 Mhz.
Wie kan mij uitleggen (mogelijk Frits K.) hoe de delay lussen in dit project in elkaar zitten het gaat volgens mij om de delay in het hoodfprogramma (DELAYUS 600 ;900 - 300: Header van RC5 vermijden).
Waar komt die 900 resp. die 300 vandaan ik zie niet de link naar de timer tijden van het RC5 signaal 14X1778ms
thanks 4 ever
Als picbasic een beetje goed in elkaar steekt
(en volgens mij doet het dat) maakt de routine
delayms en delayus gebruik van een XTAL waarde
om de delays uit te rekenen.
Het verhogen van de XTAL waarde naar 10 danwel 20
zorgt er dus voor dat delayus(1) een micro-seconde
delay veroorzaakt.
klopt
Met Xtal 10 of 20 en het juitse kristal blijft 1Ms 1Ms
maar de rest van de code gaat veel sneller bv loop BitOphalen en Start Glitch deel.
Met name het deel bij BitOphalen wat wacht op niveau verandering, is afhankelijk van de waarde (Ok) en de klok snelheid en het punt voor de flank verandering in het IR signaal.
En dan loop ik vast want ik zie een delay van 600 (900-300)en 1000 en 500 en een (Ok) waarde van 50 ( die wel klok afhankelijk is)
bedankt voor het mee denken.
Sorry, nu begrijp ik je vraag.
Volgens mij zit het zo:
Start bit:
----
| |
| |
----
Lengte = 1.778 msWacht op opgaande flank
WHILE IR_Ontvanger = UIT : WEND ;Wacht op ontvangstResterende tijd = 1.778 - 0.889 = 0.889 ms
BD1 = 0
WHILE IR_Ontvanger = AAN AND BD1 < Glitch
INC BD1
WEND
IF BD1 < Glitch THEN Start ;Error in ontvangst (Geen RC5 code of glitch)50 maal herhalen voor goede ontvangst,
totale tijd ongeveer gelijk aan 300us
Er worden 4 clockcycli gebruikt voor één operatie
(50 * 4 * aantaloperaties)/frequentie = 300us
Resterende tijd van start bit = 0.889 - 300 = 600us, daarom:
LED = ON ;IR-signaal ontvangen
DELAYUS 600 ;900 - 300: Header van RC5 vermijdenEdit: ubb code voor picbasic toegepast.
Hi Jan
Ik vrees dat jou theorie niet helemaal klopt.( of ikke snap het nie hetgeen niet geheel ondenkbaar is)
Als ik de code lees wacht de hoofdlus tot de IR nul wordt laten we dit T1 noemen vervolgens gaat er gekeken worden of signaal gedurende waarde Glitch (52) laag blijft < T2 > dan gaat de ontvangs led On < T3 > dan een wachtlus 600us < T4 > de tekst zegt dat dit is om de header van RC over te slaan (lees eerste bit) volgens de code zitten we nu ergens, in tijd gezien in het command.6 bit ik vermoed net voor het midden (halverwege dus) dan is het wachten ( Ok waarde 50 )op flank up of down. In tijd zitten we dan ergens halverwege command.6 bit dan delay van 1000us (?) en return.
Volgens mij is de volgende flank nu 1.788 verder dus 1.788 min 1000 is 788 nu zal de volgende wachtloop in de BitOphalen lus over die 788 moeten gaan om deze uit te kunnen lezen vervolgens herhaald dit feestje zich tot alle bitje zijn ingelezen.
Ho kom jij aan die instructie/clockcycli tijden want die lijken hier erg van belang.
ik kom niet op 300 met 50*4*aantaloperaties
Ik hoor graag van je wat je van mijn vehaal vind.