knipperen met een aflopende frequentie

ik heb een app dat werkt zolang er een logisch signaal op een PIC poort beschikbaar is. Als het signaal langer dan een bepaalde tijd aan een wegvalt (zeg 2 minuten) schakelt eea zich automatisch uit.

Zolang het signaal beschikbaar laat de PIC een ledje continue branden. Deze begint snel te knipperen zodra het signaal wegvalt. naar mate dit langer duurt moet ie steeds langzamer gaan knipperen totdat de maximum tijd is verstreken.

Het blijkt dat het programmeren van dit knipperen me wat meer hoofdbrekens kost dan ik aanvankelijk inschatte.

Stel dat de begin freq 1x aan\uit per 20msec is en dit lineair afloopt naar 1x per sec over die 2 minuten. Dan blijkt dat ik dit allesbehalve als lineair ervaar als je er naar kijkt en het er knap onlogisch uitziet :(

Is er iemand die hier toevallig een algoritme oid voor weet of wordt dit een (ietwat tijdrovende) kwestie van proefondervindelijk acceptabele 'trapjes'(bv t0:20msec,t1:35msec,t2:80msec, t3:200msec, etc) vaststellen oid...

Gooi een aantal van die stappen in een grafiek, dan zie je snel genoeg wat voor verband er tussen zit.

Ipv. domweg te knipperen, kan je ook het volgende doen:

Korte tijd geen signaal: aanhoudend knipperen.
Langere tijd geen signaal: 10 x knipperen met tussenpause.
Nog langer: 9 x knipperen met tussenpause.
enz...
Bijna 2 minuten: 1 x knipperen met 1 sec tussenpause.

Als je naast het aantal knipperpulsen ook de tussenpause stelselmatig langer maakt, krijg je een betere indicatie. Denk ik.

@kif om een grafiekje te kunnen maken moet je toch wel voldoende punten hebben die je experimenteel moet vaststellen. vermoedelijk heb je er dan al zoveel dat het het berikte effect er wel ongeveer is en het inzicht in het werkelijk onderling verband er niet zo heel veel meer toe doet.

@pros da's een goeie, dit ga ik proberen!! Ik zag de bui al een beetje hangen dat het symetrische knipperen op een heel lage en vervolgens op een nog lagere (etc)knipperfrequentie ook al niet zo geweldig toont.

kan je niet gewoon een poort aansturen die "toggled"?

signaal weg ==> start counter (die je op een variable COUNTER _TIJD opslaagt)

als counter een bepaalde waarde heeft bereikt ==> gaat die een andere waarde selecteren voor te wachten om de poort te toggelen...

(ik geef mij idee in bascomversie, ik ken de pic niet goed)


config portd.0 as input   'om het signaal te detecteren

dim COUNTER_TIJD as Byte  'wachttijd moet veranderen
dim LED as byte           ' de led die moet gaan vertragen

do

IF portd.0 = 0 then
     
     incr COUNTER_TIJD   

   select Case COUNTER_TIJD
     
     case 1 : Wachttijd = 100   
     case 20 : Wachttijd = 200   
     case 40 : Wachttijd = 300   
     case 80 : Wachttijd = 900   

   end select

   waitms Wachttijd 
   
   toggle LED
END IF   

loop

probleem de led gaat wel vertragen mar wanneer je moet gaan uitvallen moet je berekenen met tijden en daar heb ik geen tijd voor :p

Probeer het eens met dat ie de tijd steeds met 20% verlengd, i.p.v. een paas milliseconden erbij.

Op 13 november 2007 16:29:04 schreef pros:
Ipv. domweg te knipperen, kan je ook het volgende doen:
<knipperdeknip>
, krijg je een betere indicatie. Denk ik.

Ja, of knipper in morse hoe lang het signaal al weg is. ;-)

Met op het einde: ...---... ...---... :-)

ik denk dat die knipperdeknip een uitermate korte samenvatting van de (1e) oplossing van pros is... :)

De oplossing van dizze komt een beetje neer met wat ik bedoel met 'de trapjes'. De normale processing van de PIC moet overigens gewoon doorlopen dus ik kan niet werken met delays etc.

Voor de oplossing van Pros zal ik dan iets doen in de trend van:

1. mbv interrupts\timers een soort 'kloksignaal' voor de knipperfrequentie genereren icm een klokpulscounter.

indien 'ingangssignaal' beschikbaar kloksignaal= '1'

2. indien geen 'ingangssignaal' beschikbaar
in een herhalende cycles met een teller na 'x' pulsen van dit kloksignaal (mbv de clockpulsecounter) een led-disable signaal op '1' houden gedurende 'y' klokpulsen.

3. indien geen 'ingangssignaal' beschikbaar
periodiek 'x' verlagen en 'y' wat verlengen (dit kan dan gewoon met een vaste interval)

a. zodra signaalwegvalt: start een timer en initieer timers\counters
b. bij timeout van deze timer stoppen met de handel

het aan\uit zetten van de led wordt dan
ledOn= (clock_high & signal_available & !led_disable);

[edit]
aldus wat c-routines gemaakt en in de simulator lijkt het perfect te werken zo!
bedankt

Op 14 november 2007 10:44:39 schreef frrrrrd:
... De normale processing van de PIC moet overigens gewoon doorlopen dus ik kan niet werken met delays etc. ...

misschien de WatchDog Timer eens bestuderen. ik weet alleen niet hoe die werkt in proton.
zoals de WatchDog timer werkt zou jou algoritme ook kunnen werken.

grt piet

bedankt voor je reactie. ik werk niet met proton maar met boostc. heb eea gecodeerd en het werkt uitstekend op die manier.