Beyond Weird

CannibalRobotics

Anybody have any idea why this peice of code sends out a pulse on AxCmDat pin but not the AxcCS pin? (8 & 10 respectively)
It get's better. I have the code deployed over multiple cogs. This code will work fine in other cogs so I know its not the hardware. This is where it gets really strange. I can switch the values of two variables 8 <->10 and the working pulse will change lines.

================================================
··· Dira[noparse][[/noparse]AxcCS] :=1·············· ' AXc Chip Select High·····
··· DIRA[noparse][[/noparse]AxCmDat] :=1············ ' Shift Data line to output
······························································
··· Outa[noparse][[/noparse]AxcCS] := 0···············' AXc Chip Select low
··· waitcnt((1_000 + cnt))······· ' Wait t_sucs
··· Outa[noparse][[/noparse]AxcCS] := 1··············· ' AXc Chip Select low

··· Outa[noparse][[/noparse]AxCmDat] := 0············' AXc Chip Select low
··· waitcnt((1_000 + cnt))······· ' Wait t_sucs
··· Outa[noparse][[/noparse]AxCmDat] := 1··········· ' AXc Chip Select low
================================================

================================================
·CON
······· AxCmDat = 8·· ' [noparse][[/noparse]Dxx] Data I/O line for compass and axcelerometer
······· CmEN· = 9···· ' [noparse][[/noparse]~EN] Compass Enable Line
······· AxcCS = 10··· ' [noparse][[/noparse]~CS] Axcelerometer Chip Select
······· AxcZG = 11··· ' [noparse][[/noparse]ZG] Axcel Zero G indicator - Free Fall
================================================
·

Phil Pilgrim (PhiPi)

Try a larger delay in your WAITCNTs (~10000), and see what happens. I have a feeling 1000 is right on the border line for being too short to work in Spin.

-Phil

Graham Stabler

I think we will need to see more code to see the problem, can you attach a minimal test program that you have tested not working.

Graham

CannibalRobotics

The timing issue has merit but in it's actual application it stays low for probably 10 mSec.

Phil Pilgrim (PhiPi)

10ms is awfully long. What clock speed are you using? (Did you remember to specify the crystal and PLL settings at the top of your program?)

-Phil

CannibalRobotics

OK, it's a compiller issue.
In a moment of pure despiration I moved the AxcCS out of the CON section, created a byte variable named AxcCS, set it equal to 10 and everything is working - go figure...

CannibalRobotics

PS: it was 1.0 mSec, my typing is a little off at times.
Thanks

Graham Stabler

So are you saying the con section doesn't work and that is the IDE's fault?

waitcnt((1_000 + cnt))

Gives a delay of 0.0125ms if you are running at 80MHz

CannibalRobotics

The waitcnt((1_000 + cnt)) is actually a delay on the clock pulse, which works quite well on both the accelerometer and the ADC0838. It scopes out to 24uSec.
The 1.0 mSec number I tossed out is actually the time the enable line goes low to activate communication with the accel and A/D converter. I actually measured that one out to. It's roughly 1.7 mSec.
The code above (very top) was really not about delay issues, more about how the compilor seems to be misplacing data.

You've got to admit that if you are using an OUTA[noparse][[/noparse]pin] command and you change 'pin' from a constant ( in the CON section) to a varriable (in the VAR section) and it changes the behavior of the program, something is amiss in the code interpretation process, right?

Mike Green

It's probably not the compiler or the interpreter. Phil mentioned that "waitcnt(1_000 + cnt)" is right on the edge. What he meant is that the amount of time required to compute "1_000 + cnt", then start the WAITCNT instruction is very close to 1000 clock cycles. If the WAITCNT is not initiated before the time passes, the cog will stall until the system clock wraps around at 32 bits which is just under a minute. The surrounding instructions (outa[noparse][[/noparse] ... ]) may influence the timing of the WAITCNT enough to shift the threshold over or under the 1000 clock cycle time. Changing the pin number to a variable or using different constant values changes the number of bytes used and the execution time of the out[noparse][[/noparse] ... ] assignments. The way to fix this is to use a longer WAITCNT period or change to the use of assembly language.

Graham Stabler

I think Mike has it!!



Graham

CannibalRobotics

OK, so I upped all of the times to 2_000 then to 5_000, no change.
Riddle me this? When I "compile top", the code below in one of the objects does not work.
When I "compile current" the code works fine.
Now, I know the cog is running in both compiles bc the call to this routine is in a loop which is reading and updating other AD and axcelerometer data without problems.

PUB PulseCompass
'

---

Test Pulse

---

waitcnt((5_000 + cnt)) ' Wait
OUTA[noparse][[/noparse]CmEN] := 0 ' Enable Down
waitcnt((5_000 + cnt)) ' Wait
OUTA[noparse][[/noparse]CmEN] := 1 ' Enable UP

Phil Pilgrim (PhiPi)

I think it's time you posted all of your code. You've got us peeping through keyholes here, and we're missing the big picture. Also, please show us which object is the top object and which object you're compiling standalone.

-Phil

Mike Green

Can you attach your whole program or archive to a message. This piecemeal sort of stuff is not very helpful. Your observation about "compile top" vs. "compile current" doesn't help either. Most likely what you've got as "top" is not what you think.

You need to remember that many people have posted errors like this and, on further examination, almost all of them have resulted from a problem in the program, either some kind of timing problem or a stack overflow or other situation where one part of a program is writing into a memory area used by another part. I think there was one true compiler error discovered since the Propeller was released and it was fairly subtle.

CannibalRobotics

OK,
here tiz. I just want to say thanks in advance for your help.
Jim-

CannibalRobotics

Also, so you can see what I am seeing. The two pics are scope dumps. Note the Yellow trace. It's the CmEN line.
In one pic it's flat - that's the compile top.
The red line is clock, the green is the AxcCS chip select for the axceler. The blue is the sharred data line between the compass and axceler modules. The data are the conversation between the prop and the axc.

Mike Green

With just a cursory glance, I can see at least two things that need correcting.

1) In ADC0838_Axc, you're setting up a bunch of I/O pins as outputs in the init method, then setting
up the same pins in another cog in the Main method. When two cogs attempt to control one I/O pin,
the output state is the OR of the values in that bit of the OUTA register in each cog. Except in very
specific circumstances, you never want to use the same I/O pin in more than one cog.

2) In ADC0838_Axc, you use COGINIT to start a 2nd cog (#6). Generally it's not a good idea to use
COGINIT unless you're restarting a specific cog. It's usually a bad idea to mix COGINIT and COGNEW
in the same program since it makes it easier to try to use the same cog for two different things when
that's not what you're expecting.

Phil Pilgrim (PhiPi)

Okay, thanks.

I do see one thing for certain: you're using coginit in your ADC object. That's pretty much a no-no. How do you even know that cog 6 is available? That might be why your code is failing when run from the top object but not when running just the ADC object.

If fixing that doesn't solve anything, can you come up with a minimal program, testable on a Demo board, say, that exhibits the same failure modes as your magnum opus? It would help to isolate the problem and help the forum volunteers if they don't have to wade through so much code.

-Phil

CannibalRobotics

Item 1 fixed the problem.
I'm going to look into item 2 over the weekend.
I'm still fightling my way out of the linear programming model and thought process.
Thanks and have a great weekend.
J-