[PASM] Trying to use POSEDGE counter - turn on a LED if freq threshold exceeded
Cabbage
Posts: 37
I'm trying to measure a variable frequency 50% duty cycle square wave on pin P0 (physical pin 1 on the P8x32A-D40 package).
I'm feeding a square wave into P0, and I put an LED on P1. There are no other connections.
If the detected frequency (sampled over 1 second intervals, resetting PHSA each time) exceeds 100 Hz then I want to turn the LED on.
But it's as if the counter isn't running or something, I can't figure out why this isn't working. The signal into the pin is definitely toggling at something around 1500 Hz (it varies with ambient light levels).
The muxnc never turns the led on, even though the frequency is much higher than 100 Hz. If sample is 1500 then the cmp 1500, 100 WC should clear the C flag and the LED should always be on, right?
CON
_clkmode = xtal1 | pll16x
_xinfreq = 5_000_000
PUB Main
coginit(0, @PASM, 0)
DAT
org 0
PASM
or dira, LED 'output
mov sample, #0 'clear the sample cache
'start the counter
mov CTRA, CTRA_MODE
mov FRQA, #1 'each detected rising edge adds this number to PHSA
mov time, CNT
add time, ONE_SECOND
:sample_period_start
mov PHSA, #0 'reset the count
'examine the previous cached sample
cmp sample, INTENSITY_THRESHOLD WC
muxnc outa, LED 'if (sample >= INTENSITY_THRESHOLD), turn on the LED
waitcnt time, ONE_SECOND
'when we get here, exactly 1 second has passed, so cache the sample
mov sample, PHSA
jmp #:sample_period_start
ONE_SECOND long 80_000_000
'PLL div/1, POSEDGE detect single ended, pin P0 input
CTRA_MODE long %0_01010_111_00000000_000000_000_000001
INTENSITY_THRESHOLD long 100 'Hz
SAMPLE_PIN long |< 0
LED long |< 1
time res 1
sample res 1
fit
I'm obviously being a bonehead, can anyone find the problem?
Comments
Set ctramode to:
the Apin of the ctr mode needs the number of the port-pin, not a pinmask, or the phyical pin of the package.
Andy
As Andy pointed out, your mode value needs the pin #, not a mask. This is the PASM for the attached test program. I made the code work like a traditional object (even though it's embedded in the app) so you can change IO in your project without having to dig into the assembly to update it.
dat org 0 entry rdlong onesec, #$0000 ' read clkfreq from system mov t1, par rdlong t2, t1 ' get freq in pin or t2, POS_EDGE ' configure for pos edge count mov ctra, t2 mov frqa, #1 mov phsa, #0 add t1, #4 rdlong t2, t1 ' get led pin mov ledmask, #1 shl ledmask, t2 andn outa, ledmask ' configure led pin or dira, ledmask add t1, #4 rdlong frlimit, t1 ' get frequency limit mov t1, cnt ' start timer add t1, onesec :loop waitcnt t1, onesec ' wait one second mov t2, phsa ' capture edges mov phsa, #0 ' reset wrlong t2, par ' write to hub cmp t2, frlimit wc ' check frequency muxnc outa, ledmask ' led on if >= frlimit jmp #:loop ' ------------------------------------------------------------------------------------------------- POS_EDGE long %01010 << 26 onesec res 1 ledmask res 1 frlimit res 1 t1 res 1 t2 res 1 fit 496Ah yes. Thank you, I think I got fixated on the physical pin numbers. Of course pin 40 wouldn't fit into 5 bits! My code works like a charm now.
Thanks to Jon also, I'm not sure what a "traditional method" is in terms of Propeller PASM but your code sample is something I'll have a closer look at.
Cheers.
p.s. By the way these sensors I'm using are pretty great for rapid and precise light sensing without needing ADCs or indeed any external hardware beyond the sensors themselves...
Part number TSL235R "Light Intensity to Frequency Converter" get them while you can!
Hello!
Yes the TSL235R device is an interesting and even amazing device, I started using that one, and several others in the family when they were a part of the TI linecard. Why don't you present us with a schematic of what you're working on? That way we'd be better able to grok exactly what you're going for here.
Mascot present but not involved.
Jon? What's that xenomorph doing by your offices? It seems to be trying to get to a movie studio.
"Get them while you can!" No kidding! I've had it with AMS. Ever since they took over TAOS, they've been a totally unreliable supplier, EOLing everything in sight.
-Phil
Hello!
They are?!? That's not good. Phil try Sparkfun, and if they need (or demand) a reference tell them that I sent you. I found and bought a batch of the things from regarding that sensor.
But are you looking for a different one from those dunderheads?
Mascot present.
Yes, according to DigiKey:
https://www.digikey.com/en/products/filter/optical-sensors-ambient-light-ir-uv-sensors/536?s=N4IgTCBcDaIC4GcA2YDMBWATiAugXyA
The SMD parts are obsolete, and the thru-hole parts are NRND.
AMS is not to be trusted as a reliable supplier. I'm so glad that Parallax did not go with them for the P2 fab, as was the plan at one point, IIRC.
-Phil
Sorry, typo on my part -- I meant to say traditional object (with start and stop methods). For my own testing I added the ability for the high-level code to read the frequency; this is easily removed.
Hello!
That's why I suggested to look to Sparkfun for buying the sensors in quantity. As far as I am concerned that firm is destroying the legacy behind the original TI division that got spun off into TAOS.
Mouser says 9500 ea by Aug.
Yes, it's a real shame.
-Phil
Hello!
I can well imagine that.
Hello!
Okay, for laughs, I promptly found a wandering QS board, it's a Rev-A one, and promptly set things up accordingly. And found that the board does work, first I loaded back the classic button demo, and it worked. Then I loaded the example that you wrote, @JonnyMac and found that it works. In fact I have it running right now. And with the sensor sending stuff into p0, and the blue LEDs at work on the p26 and p27 settings I found that promptly started with the LED glowing.
Showing a light from one of those White LED flashlights that Harbor Freight are famous for, it caused the blue ones to go out.
Oh and @JonnyMac I found your code to be an amazing thing to read, all the parts to it.
Mascot asleep.
Oh and that xenomorph that was by space of yours left. It must have gotten the ride.
Sorry, I haven't drawn a schematic yet, will update the thread in a few days, but in the mean time, I've actually got 2 projects in mind for the TSL235R sensors...
The first is a device to assist in the archival of old punched-paper data tapes (e.g. from the 1940s-1970s era mainframes). This will use 10 of the sensors (8 data bits, one clock bit and an end-of-tape bit) to read the tape passively as it is flying through the actual computer at something like 25 mph!
I need to make sure these sensors can respond to changes in light intensity fast enough for this purpose. I'm pretty sure they can, according to my Saleae logic analyser they easily pickup the PWM pattern that my flashlight outputs on low power mode, which is a few kilohertz. I'll need it to work at something like 15 kH for the tape reader to discriminate between a hole and a no-hole.
Since these sensors don't require ADCs to read them, I'm hoping this will be more immune to RF interference from the very electrically noisy mainframe computer! Plus the circuit will be much simpler.
The second project is just a bit of fun really - a device that tracks the position of the sun during the day and then records that to a file. Do that every day for a year and then run the machine at night in "fast replay" mode using a laser pointer to draw the paths in the night sky. But the fun part is to use a DSLR camera to take a long-exposure photo of that light pattern to show how much the sun's path changes over the seasons. Kind of a practical, hands-on teaching-aid for astronomy I guess. This project will use 4 of the TSL235R chips arranged in a "+" shape with the laser in the centre. The sun will illuminate one of the sensors more than the others and this will cause a pair of servos to move the device so that all 4 sensors have the same reading - meaning we're pointing directly at the sun - so we know its position which gets written to the file. Won't work so well on cloudy days but that might make for some interesting patterns when it hunts for the brightest spot in the sky instead of the sun! I suspect this might also work for tracking the full moon too.
(Before anyone complains, I do understand the repercussions of shining lasers into the sky regarding aircraft and safety. Full written permission will be obtained from the local aviation authorities before it happens)