Hello all,
Op m'n werk ben ik een beetje naast mijn vakgebied aan't wandelen. Normaalgezien ben ik mechanisch ontwerper, maar ben altijd geïnteresseerd geweest in elektronica. Voor een proef die ik wil uitvoeren, dacht ik even snel een eenvoudige fansturing ineen te steken met een 89c664-controller van Philips.
Twee van de drie kerntaken heb ik apart reeds aan de praat gekregen, maar de twee samen laten werken lukt voorlopig maar matig. De fan sturen met een PWM-signaal lukt perfect en als ik de fan stuur met een labovoeding lukt het toerental meten ook feilloos. Maar de combinatie van beide lukt voorlopig niet, omdat de dalende flanken van het PWM-signaal ook dalende flanken zijn op de sensing lead van m'n fan.
Na een beetje rekenen aan een RC-schakelingetje (in alle mogelijke positie's), waaruit bleek dat de karakteristiek daarvan afhankelijk is van de fan, heb ik nu het volgende bedacht:
Iedere seconde zet ik de uitgang van m'n PWM hoog, totdat ik 2 keer een dalende flank heb gezien. Hieruit kan ik perfect de periode van het telsignaal en dus het toerental berekenen. Dit blijkt redelijk goed te werken, maar nu blijkt dat de resultaten onbetrouwbaar zijn ...
De oorzaak hiervan is dat de PWM-module niet onmiddellijk reageert op het zetten van de duty cycle. Dat is 'intended by design', maar nu dus erg storend ...
In de datasheet van de controller staat (op p 58) dat de waarde die je schrijft in het CCAPxH-register bij een overflow van de 8-bit teller wordt geschreven in het CCAPxL-register, dat bepaalt wanneer de uitgang togglet. In mijn toepassing wil ik nu echter rechtstreeks 0x00 schrijven in CCAPxL, net om de PWM-uitgang meteen hoog te krijgen. Wanneer ik dit echter doe, blijkt gans de teller-module van het IC vast te lopen ... Het IC draait nog (seriële communicatie werkt nog), maar de tellers blijken zich vreemd te gedragen ...
Iemand gelijkaardige ervaringen met gelijkaardige componenten?
Alvast bedankt!
Fietsventje
Arco
Special Member
Arco - "Simplicity is a prerequisite for reliability" - hard-, firm-, en software ontwikkeling: www.arcovox.com
Het is bij een PWM module meestal logisch dat de nieuwe PWM waarde ingaat bij het beeindigen van de huidige cycle. (Het heeft meestal geen zin om een lopende PWM cycle af te breken. Een afgebroken PWM cycle geeft een PWM puls van onvoorspelbare lengte)
En om naar een register te schrijven wat niet de bedoeling is, is ook vragen om vreemde resultaten...
Het is wel te doen met een uP met Enhanced PWM module, zoals bv de PIC16F684.
Kun je niet ergens terug vinden wat je status van die PWM is? Wachten tot het is waar je zijn wilt en dan meten. De manier die jij gekozen hebt, is zeker niet de juiste (sorry 
). Zo zou je er wellicht wat mee kunnen.
Andere manier is de PWM even 'uit' zetten, de uitgang 'aan', meten, uitgang weer 'uit' en PWM weer aan. Als je inderdaad slechts 2 pulsen nodig hebt, is dat snel genoeg.
Ook zou je eens naar je PWM frequentie tov. je tact frequentie kunnen kijken. Geen idee hoe dat nu zit, maar als je fPWM lager ligt dan je tact moet de situatie voorkomen dat je 2 tactpulsen hebt terwijl de motor gewoon 'aan' is. Als je nog 2 interruptlijntjes vrij hebt, lukt meten dan ook wel (in het kort: op een tact interrupt start je een meting. Op de volgende tact interrupt stop je die. Op een PWM interrupt (evt. gewoon 'buiten om', IRQ lijn aan PWM output) reset je een evt. lopende meting. Als de meting niet gereset is, is-ie goed en store je de waarde. Waarschijnlijk gaan er een hoop de mist in, maar ik gok erop dat als je 1 geslaagde meting per seconde of zo hebt je genoeg weet. En dat moet als de frequenties binnen je draaibereik onderling niet al te beroerd liggen lukken)
Je zou (als dat tot de mogelijkheden behoort) die fan kunnen modden. De tact generatortjes zijn doorgaans HALL sensortjes. Als je mazzel hebt, wordt deze niet gebruikt voor de sturing van het geheel. Je zou 'm dan separaat kunnen voeden om er wel wat 'moois' van te maken.
Als dat niet lukt, zou je er ook een HALL sensortje bij kunnen klussen. Die ruimte heb je vaak nog wel in die dingen.
Overstappen op een andere μC is zonde van je tijd / werk, zeker als het een pic-ding betreft.
Bedankt voor jullie antwoord.
Arco, idd, zoals ik in mijn post al zei is het gedrag dat er nu is 'intended by design'; 't staat zelfs expliciet in de specsheet dat het feit dat die high-byte naar die low-byte wordt geschreven bij overflow van de teller bedoeld is om glitchless PWM toe te laten. Maar nu is dit dus niet het gewenste gedrag. 't Feit dat die lage byte schrijven niet werkt (in andere modes van de PCA-module is dit wel toegelaten) blijf ik wel vreemd vinden ...
Marco69, je suggestie om de uitgang zelf hoog te forceren is idd iets wat ik nog ga proberen. Ik hoop er de PWM niet voor uit te moeten zetten, maar de kans bestaat dat dat nodig is, idd. De status van de PWM uitlezen kan, maar pollen is niet echt elegant, vind ik, en de interrupt van de PCA-counter vangen lukt blijkbaar niet. Wat betreft de frequentie van de PWM, daar heb ik ook al mee gespeeld. Nu zit ik op ongeveer 50 Hz, zowat het laagste dat de fan toelaat (100 Hz is ideaal), maar dat komt overeen met een toerental van 3000 of 1500 rpm, waar ik dus boven zou moeten blijven. Dat lijkt me niet aanvaardbaar.
Ik ga nu dus twee zaken proberen: ten eerste wachten tot ik drie pulsen heb gezien (en dus de eventueel foute eerste puls oversla) en ten tweede ga'k proberen de PWM-pin handmatig hoog te zetten.
Ik laat weten hoe dit afloopt.
Bedankt voor de feedback!