How do you use "PUB Start : OK"?
lardom
Posts: 1,659
I'm debugging an RF project on a single Propeller. So far I have successfully controlled one servo with a potentiometer but when I tried to control two servos using code I have successfully used in the past it fails. ...I think it's because I have run out of cogs. I created a test to check if the syntax, and logic, was correct using a single Propeller and it worked.
I am going to re-test with two Propellers and I don't expect a major problem.
If I knew how to use "PUB Start : okay" I could save myself some grief. How do I do it?
I am going to re-test with two Propellers and I don't expect a major problem.
If I knew how to use "PUB Start : okay" I could save myself some grief. How do I do it?
Comments
You know, of course, you are going to be asked to supply the offending code. : )
This is the method
PUB Start : result stop cog := cognew(Main, @Stack) + 1 'calibrate bits result := cogThis is the object tree:My naming conventions don't make sense to anyone else but me so I'll save that for the final step but if you need more code to understand what I'm asking I'll do it.
if (myobject.start() == false) ' Houston, we have a probemThis assumes, of course, that one has been added to the cognew return value and then returned to the caller.It seems like you should have a multi-servo driver cog for your project; there is no need to have a new cog for each servo.
Look for: Servo32v7_RampDemo.spin that uses Servo32v7.spin in the library...
As Jon pointed out this is a small trick used in most P1 examples.
The cognew() call returns -1 on failure or 0 to 7 as ID of the cog started.
To stop a cog later you might need its ID and need to now if it is started.
if you directly save the return value you will need to compare it with -1 for failure and >-1 for SUCCESS
if you save the return value with a added 1 then you can compare like Jon showed.
Because 0==false <>0 == true
Mike
When I got back I was prepared to separate the tx half from the rx half. I tested it one more time and this time it worked.
I'm actually disappointed that I didn't have a genuine issue: Maybe I should have given it one more day but when I get stuck I think it's better to ask for help even if I look stupid.
On the positive side, I'm almost there in terms of what I wanted to accomplish.
Maybe a title that goes "how to use "PUB Start : okay" would be more suitable, and also some code.
Wow, I screwed that up.
You really need to post your code or a lot more detail but if you are worried about anyone copying it, I wouldn't be. You can always pm the code to someone whom you trust though.
P.S. Even your questions are cryptic
I'm not so concerned about keeping my code secret. My goal is to share it 'but' I 'am' concerned about asking someone to wade through a whole project which is still largely unreadable. It's a big 'scratch pad'.
OTOH, when I have a working demo I really would appreciate if a professional member of this forum would proofread it so I could present it to the rest of the community. That's asking a lot but I want it to be 'headache free' if someone downloads it from the OBEX.
edit: Yeah, my questions are "cryptic". Learning to ask the right questions is a skill in itself. Very often I have to work at defining a problem.
I have my local Dropbox folders that I work from which are synched across my computers through the cloud and to which I share the link for anyone who wants to wade through at their leisure. What they do with it is up to them.
This looks like you are adding 1 to the COG ID.
That would make it a bit hard to communicate with the cog you started.
Variables in the VAR section get initialized to 0 on program load.
so this
VAR long cog PUB stop if (cog) cogstop(cog-1) cog := 0 PUB start stop cog := cognew(Main, @Stack) + 1 'calibrate bits result := cog PUB doSomething if start … … stopNow doSomething calls start and start
will have cog as 0 when loaded so the first stop inside of start will not try to stop any cog since cog is 0 and 0 is false
then start will try to start a cog and if successful write the cogID+1 into cog and result. On failure it sets both values to 0.
if start was successful doSomething does something and calls stop. if not then doSomething does nothing.
now compare to using the cogID as is.
First you need to make sure that at program start cog is -1. So you need to put it in the DAT section to initialize it at program start.
DAT cog long -1 PUB stop if (cog>-1) cogstop(cog) cog := -1 PUB start stop cog := cognew(Main, @Stack) 'calibrate bits result := cog PUB doSomething if start>-1 … … stopNow doSomething calls start and start
will have cog as -1 when loaded so the first stop inside of start will not try to stop any cog since cog is -1 and cog>-1 is false
then start will try to start a cog and if successful write the cogID into cog and result. On failure it sets both values to -1.
if start was successful doSomething does something and calls stop. if not then doSomething does nothing.
as you might see both variants do basically the same, but the second one is slightly larger (4 subtraction vs 1 subtraction and on addition)
Enjoy!
Mike
Maybe the OP does too?
The problem was just bad code. It does take me a while to spot bugs but finding the solution is something I enjoy a lot.
I'm going to take a short break and then jump right back in. I want to start work on the second mode of operation.
There is a lot in it that I learned from you such as the receiver object listens to pin 1, which is controlled by the tx object.
When I run it with the 433Mhz modules the rx values are exactly the same as cog-to-cog. That is huge.
It's set up to run on the serial terminal.
The high-wait-low strategy will always be off just a bit due to the Spin instruction fetch/decode overhead. Let me illustrate.
First, let me show you how to time-test a section of code. Note that there is a - 544 in the mix to remove Spin overhead from the test result.
Now, let's update that to generate a 1ms pulse in the manner you're using. The result is 81488, not 80000 which would be exactly 1ms. No, it's not a big error, but when dealing with servos, this could make a difference. This is why I uses the counter modules for servo pulses. I've attached a simple 2-channel servo driver to show you how that works. The driver even includes simple ramping.
You may remember that I set out to do the same thing with IR. The IR signal is a bit tougher to work with. Combined with my failure to get the dual-servo driver to work I put the IR version aside. I'll get back to it when I'm done with the RF version.
A precision servo pulse for an IR driver is even more critical because the IR detector is finicky.
39000 := zero ( adjust simply for scope timing instead of 48000 ) zero 2* := one one 2* := start CLKFREQ 50 / := pause pub SendCode ( code -- ) 1 HIGH start WAITX 1 LOW zero WAITX 8 FOR 1 HIGH zero WAITX DUP 1 AND IF zero WAITX THEN 1 LOW zero WAITX 2/ NEXT DROP pause WAITX ;BTW - You top file has multiple repeat loops as if you were testing but of course only the first one gets to loop.
Here's the Tachyon code for your incrementing code loop Original Spin code:
repeat number := index++ Tx.SendCode(number) if index > 255 index~Then I type "$71 SendCode" and this is what I got:
IR in and out is pretty straightforward. Your statement vis-a-vis a servo pulse for an IR driver makes no sense to me? Do you mean a precision pulse for gating? Easy to do, and more than one way to skin that cat. Please understand, I'm trying to be helpful. I think the most difficult part of this process is explaining exactly what you're after, and not holding back details that would allow others to assist.
Great, you will have lots of interactive fun. But try this in Tachyon: You will see a steady 3kHz square wave on P1 using a counter.
After I got things working I wired up two DC motors to a second Propeller and it stopped working. All I could think of was that the 433Mhz modules were the problem. I did a number of tests and finally I said "I'm gonna connect the pin of the first Prop directly (through a resistor) to the pin of the second Prop and see if that solves the problem.
I still could not get it to work. I posted my test code. TX side:
CON _CLKMODE = XTAL1 + PLL16X _XINFREQ = 5_000_000 'start_bit = 191008 'equals 192000 minus overhead start_bit = 192000 '192992 = overhead one = 96000 OBJ 'pst : "Parallax Serial Terminal" PUB Pulsewidth_test dira[1]~~ 'pst.Start(115_200) 'waitcnt(clkfreq*2+cnt) repeat outa[1]~~ waitcnt(one + cnt) outa[1]~ 'pst.Str(String(pst#NL, "start_bit = ")) 'pst.Dec(start_bit) 'waitcnt(clkfreq/10+cnt) waitcnt(clkfreq/5+cnt)RX side:CON _CLKMODE = XTAL1 + PLL16X _XINFREQ = 5_000_000 VAR long TPulse, Time_one, Time_two OBJ pst : "Parallax Serial Terminal" PUB Main | pulse_size pst.Start(115_200) waitcnt(clkfreq*2+cnt) { repeat repeat until ina[1] == 0 Time_one := cnt repeat until ina[1] == 1 Time_two := cnt pulse_size := Time_two - Time_one pst.Str(String(pst#NL, "pulse_size = ")) pst.Dec(pulse_size) } repeat waitpeq(%010,%010, 0) 'waitpne(%010,%010, 0) Time_one := cnt waitpne(%010,%010, 0) 'waitpeq(%010,%010, 0) Time_two := cnt pulse_size := Time_two - Time_one pst.Str(String(pst#NL, "pulse_size = ")) pst.Dec(pulse_size) {ctra := (%01000 << 26) | 1 'pos detector frqa := 1 repeat phsa := 0 ' clear accumulator waitpeq(%010,%010, 0) ' wait for high waitpne(%010,%010, 0) ' wait for pulse TPulse := phsa pst.Str(String(pst#NL, "TPulse = ")) pst.Dec(TPulse) }