Measuring series of pulses with basic stamp, possible?
CuriousOne
Posts: 931
Here's the input:
pulse with duration of 1ms, pause 3ms, 2nd pulse with duration 1-5ms. This is the input. it should be measured, and with beginning of the 2nd pulse, output pulse should be sent.
There's command PULSIN for that, but it has two states, when it measures high or low pulse, but how to switch it on the fly, in sequence?
Here's the code, is it correct?
The syntax might be not exactly of basic stamp, but this is just demonstartion of the algorithm, will it work?
pulse with duration of 1ms, pause 3ms, 2nd pulse with duration 1-5ms. This is the input. it should be measured, and with beginning of the 2nd pulse, output pulse should be sent.
There's command PULSIN for that, but it has two states, when it measures high or low pulse, but how to switch it on the fly, in sequence?
Here's the code, is it correct?
STATE=1 DURATION=0 DO PULSIN 1,STATE,DURATION ' READ THE FIRST PULSE IF DURATION> 450 AND DURATION<550 THEN STATE=0 ' FIRST PULSE CAUGHT, LET'S MEASURE PAUSE PULSIN 1,STATE,DURATION ' READ THE PAUSE BETWEEN PULSES IF DURATION>1450 AND DURATION<1550 THEN STATE=1: PULSOUT 2,1000 ' PAUSE MEASURED, DO OUTPUT LOOP
The syntax might be not exactly of basic stamp, but this is just demonstartion of the algorithm, will it work?
Comments
PULSIN 0 is for measuring time LO when the previous state is HI: established state = HI, input goes LO then back HI. To do a PULSIN 0, the input must be HI to begin with.
we have two inputs, one "waits" for high, another for low signal
"first" pulsin waits for high signal, as signal of specific duration arrives and ends, the "second" pulsin is started, which measures the duration of the low signal, if that low signal completes within required timeframe, and we already have the "proper" high pulse measured, we can fire output
right?
The Stamp does one thing at a time.
It doesn't make a difference if it's branched to two input pins.
What matters is the PULSIN pin's state when the instruction is initiated.
So, to start, the initial PULSIN 1 is completed (satisfied) when the pin goes LO again.
The next thing to do is a PULSIN 0, but the trouble is that that pin is LO already.
See?
If it is LO already then it will have to wait for the pin to go HI and then on the following falling-edge it will begin the timing (provided that occurs before it times out.)
After first pulse completes, counter is launched, which increments untill the 2nd pulse begins, so we analyze timing of counter and use it to determine whenever the pulse between the impulses was of the correct duration.
Sounds like it's -- Propeller Time!
No propeller
And counter can be simple FOR-NEXT with adequate number of digits to count.
Another solution will be to loop the signal from built-in oscillator to input and use COUNT command ?
No interrupts either.
I have to agree with PJ. It's Propeller time.
Propeller at $7.99 not affordable?
And shipping.
Start-up costs, man.
Or get a QuickStart.
http://www.parallax.com/Store/Microcontrollers/PropellerDevelopmentBoards/tabid/514/ProductID/748/List/0/Default.aspx?SortField=ProductName,ProductName
Nothing else (much) to buy.
I second PJ's suggestion.
If you don't have other things you want to purchase from Parallax, it might be less expensive to buy a QuickStart from PropellerPowered or GadgetGangster. They both have really low shipping costs (IIRC about $4). If you get if from PropellerPowered, you might want to consider also getting one of the inexpensive ultrasound sensors at the same time (for a fun reason to measure pulses).
Jim
In late 80s, I was doing a lot of coding on Sinclair ZX Spectrum, using various BASIC language dialects and assembler as well. So, in general I have idea what is the machine code, structure of MCU and so on. Some of my code was so effective, that a scrolling marque generator, built with my Z80 code, was used by local tv studio for two decades, untill fire occured and it burned down
So, now I decided to go back to programming, but as hobby. I started looking around, for various possibilities market offers these days. I've checked a lot of possibilities, picaxe, arduino, microbasic, avr studio, mikroe, propeller, basic stamp, etc. Amongst these, basic stamp looked more appealing than others, so I decided to stick with it. The main reason why I dislike propeller, is it's syntax and code appearance, looking like C, which I hate most.
Regarding the current issue, what if do it in a such way?
The syntax is still weird, but doable, what do you think?
1. I already studied a lot in basic stamp.
2. When I look at basic stamp code at first time, I easilly can "see" what this code does. This never happened with Propeller or C, or some others.
3. The main reason why I'm doing this is to push things (and myself) to the edge. I mean, to do "undoable" things on simple hardware. This is much more exciting than just including readily available libraries and busting out ready code.
4. To be even more specific, all I'm trying to do, is to build a custom slave flash, which will only trigger after specific flash series received from the main flash. The factory-made unit which has all these functions, costs $39.99 on amazon, so instead of buying propeller, I can go and buy that flash directly, but I don't think this will be a fair move.
I can appreciate that motivation!
Look at the RCTIME command. It sort of provides the timer you are looking for. Your program might execute a PULSIN to capture the initial 1ms, then execute an RCTIME to find how long it takes to the next edge. The difficulty with that the timer is not launched right at the end of the previous PULSIN, rather, it takes some time for the interpreter to fetch and execute the RCTIME command. Not to mention the math that tests the length of the first pulse. You would have to add those fixed times to the result returned. How much? The times you are looking at are at the edge of the BASIC Stamp universe. Leave out the math for the moment. The RCTIME command itself eats up about 220µs. So the 3ms rising edge should happen with a count value of between 1340 and 1540. The math can eat up a lot more time, about 500µs for one IF THEN statement, and more when there are multiple conditions. What is more, the time for an IF THEN is different depending on whether the conditions are true or false. There is a table of approximate times for different Stamp instructions posted here. Note that the BASIC Stamp p or px would be quite a bit faster.
If all the conditions are met, how quickly does the slave flash have to fire? It is challenging, but don't let that stand in your way! If a delay of a few milliseconds is okay, then all the math could be done after the rising edge of the second pulse.
Why not try that and see how it goes?
While I haven't read Phil's "excellent remarks" thread, I thought I would throw this out.
When I was starting with the Propeller, I was drawn to the BS2 Funtions Object.
It allowed me to make the transition from BS2 to Propeller very smoothly and quickly.
I learned a lot from that Object.
Give it a look see.
In the process I found little use for PULSIN for such task.
http://www.mikroe.com/forum/viewtopic.php?f=97&t=50923&p=198310#p198255
There will be time lags for the interpreter to do its work, but the delay in the propeller will be 10s of microseconds as opposed to 100s of microseconds as it is on the Stamp. And there are easy ways to tighten it up on the Prop. Is that too unreadable, CuriousOne?
Below I'll try to illustrate, how above code (without description) will look for me (line by line):
Declare array of variables
xt variable equals cnt variable
declare another array of variables
pulse variable equals (yt-xt)/80
zt variable equals cnt variable
space1 variable equals (zt-yt)/80
below code seems to be what it actually does (understandable)
The above code was implemented (with corrections, of course), and it seems to be working - tested with pushbutton as input pulse generator. In nearest days, actual hardware will be connected to try and measure real signals.