clkfreq Problem
Farmer Scott
Posts: 30
I'm having a problem with serial communication between a Propeller demo board and NetBurner SB70.· I've been beating my head on this thing for two days, and am at a total loss.· I've figured out what (at least) part of the problem is, but don't know why the Propeller is behaving the way it is, or how to correct it, so if someone can offer somehelp, I'd be greatly appreciative...
I've posted a code example below.· You'll notice two lines adding the received character to a buffer and incrementing the buffer pointer are commented out.· With these lines commented out, things seem at least somewhat okay.· However, when I uncomment these two lines, things go awry...especially with timing.· I've added the command to display the clkfreq setting on the debug terminal, which was very telling.· For some reason, when those two lines are· processed, the clkfreq slows significantly.· I comment them out, it is okay.· Anybody that can offer some insight, I'd greatly appreciate it.· I can post outputs if someone is interested as well...
You'll notice this code is modeled after the PinkV2 object written by Peter Verkaik.· The software running on the NetBurner is likewise modeled to communicate much link the PINK, with the goal of making communication as simple as possible.· As you can see, that didn't necessarily happen.· If there's any value in seeing the code for the NetBurner, I'd be more than happy to post that as well.
Thanks,
Scott
'' Prop-NB Comms2.spin
CON
· _clkmode = xtal1 + pll16x
· _xinfreq = 5_000_000
VAR
· byte buf[noparse][[/noparse]64]
· long c
· long i
OBJ
· DEBUG· : "FullDuplexSerial"
· SERIAL : "FullDuplexSerial"
· FloatS : "FloatString"
·
PUB Main
· waitcnt(clkfreq * 5 + cnt)
· DEBUG.start(31, 30, 0, 9600)
· SERIAL.start(7, 6, 0, 9600)
· repeat
··· i := 0
··· DEBUG.str(FloatS.FloatToString(clkfreq))
··· DEBUG.str(string(13, "Sending STATUS command...", 13))
··· SERIAL.rxflush
··· SERIAL.str(string("STATUS"))
··· SERIAL.tx(0)
··· c := -2
··· repeat while (c <> -1) and (c <> 0) '//keep reading until CLS, even if not stored in buf
····· c := SERIAL.rxtime(1000)
····· if (c <> -1) and (i < 64)
······· DEBUG.str(string("Received character "))
······· DEBUG.tx(c)
······· DEBUG.str(string(13))
······· ''byte[noparse][[/noparse]buf+i] := c
······· ''i++
··· DEBUG.str(string("Done with status routine.", 13))
···
··· waitcnt(clkfreq * 5 + cnt)
··
·
I've posted a code example below.· You'll notice two lines adding the received character to a buffer and incrementing the buffer pointer are commented out.· With these lines commented out, things seem at least somewhat okay.· However, when I uncomment these two lines, things go awry...especially with timing.· I've added the command to display the clkfreq setting on the debug terminal, which was very telling.· For some reason, when those two lines are· processed, the clkfreq slows significantly.· I comment them out, it is okay.· Anybody that can offer some insight, I'd greatly appreciate it.· I can post outputs if someone is interested as well...
You'll notice this code is modeled after the PinkV2 object written by Peter Verkaik.· The software running on the NetBurner is likewise modeled to communicate much link the PINK, with the goal of making communication as simple as possible.· As you can see, that didn't necessarily happen.· If there's any value in seeing the code for the NetBurner, I'd be more than happy to post that as well.
Thanks,
Scott
'' Prop-NB Comms2.spin
CON
· _clkmode = xtal1 + pll16x
· _xinfreq = 5_000_000
VAR
· byte buf[noparse][[/noparse]64]
· long c
· long i
OBJ
· DEBUG· : "FullDuplexSerial"
· SERIAL : "FullDuplexSerial"
· FloatS : "FloatString"
·
PUB Main
· waitcnt(clkfreq * 5 + cnt)
· DEBUG.start(31, 30, 0, 9600)
· SERIAL.start(7, 6, 0, 9600)
· repeat
··· i := 0
··· DEBUG.str(FloatS.FloatToString(clkfreq))
··· DEBUG.str(string(13, "Sending STATUS command...", 13))
··· SERIAL.rxflush
··· SERIAL.str(string("STATUS"))
··· SERIAL.tx(0)
··· c := -2
··· repeat while (c <> -1) and (c <> 0) '//keep reading until CLS, even if not stored in buf
····· c := SERIAL.rxtime(1000)
····· if (c <> -1) and (i < 64)
······· DEBUG.str(string("Received character "))
······· DEBUG.tx(c)
······· DEBUG.str(string(13))
······· ''byte[noparse][[/noparse]buf+i] := c
······· ''i++
··· DEBUG.str(string("Done with status routine.", 13))
···
··· waitcnt(clkfreq * 5 + cnt)
··
·
Comments
Your "byte[noparse][[/noparse]buf+i]" is overstoring this value. This needs to be "byte[noparse][[/noparse]@buf+i]" instead.
Thanks, you've helped me out of a jam again.· Things look like they're working pretty good now, so I'll move on.
However, you mentioned I'm "overstating" the value.· Any chance you could explain that just a bit more, and why it works in PinkV2 object, and not mine?· Sorry if it's a hassle...
Scott
"buf" is the contents of the first byte of the byte array. "@buf" is the address of the byte array. "byte[noparse][[/noparse]@buf+i] := c" takes the address "@buf+i" and stores the value of "c" there.
What's probably happening is that "buf[noparse][[/noparse] 0 ]" contains a zero value. "byte[noparse][[/noparse]buf+i]" initially is the same as "byte[noparse][[/noparse] 0 ]" which is the first byte of the long value where CLKFREQ is stored and you're changing it to whatever is in "c".
Andy
Is there any way that you still have your SPIN code for PINK? I have the kit, and also set up my network with the web configuration instructions, but I am completely lost as far as getting communication to my p8x32a quickstart board.
I have tried to pick apart the PinkV2 code just as you did, but I have had no luck deciphering the code.
I just need them to communicate in any way, and to get the components to do ANYTHING together.
PLEASE let me know if you have the code, and could possibly share it so I could build off of it.
OR if anyone knows alternative code out there for the PINK NetBurner I would greatly appreciate being informed of it.
Thanks!