Mike, when I tell the Stamp to give me the time, I expect something like:
11:05:35
What the VGA displays is:
1L:>5:N
where both the "L" and ">" are inverted.
The controlling methoid is "recdatag". Line 213
This furthers my belief that something in OS is corrupting the text return from the Stamp.· And, the recdatag method never executes the "waitcnt" command.· It locks up after the dispaly and I have to reboot.
Sid,
The recursion in your start1 routine (and other routines) is scribbling all over the OS's work area including the font tables. I'm not surprised that there are unexpected characters on the display. I had this happen once when I was developing the OS. I had not moved the font tables to high memory, tried to load a new SPIN program and it overlaid the font table that was part of the vga driver in lower memory ... instant garbage on the screen.
Mike
Mike, I replaced all the methods in my hires program with the corresponding method in your download.· It made no change in the display - still garbage.
On the get the time thing, I finally figured out that that program was waiting for a sixth byte.· I changed line 224 to read:
elseif x == 5· '6·
Now it waits 3 seconds, then goes back to the menu.
Sid,
Please recompile your program, make an archive, and post the archive here in a reply so I have everything you're working with. I can't duplicate your hardware, but I'll change the I/O pins and use a USB2SER adapter hooked up to my Mac to emulate the Stamp to see if I can duplicate what's happening. Fortunately, it's supposed to be a rainy weekend, just right for debugging!
Mike
OK, Mike.· Here is the archive.· I think everything is in it.· The top file
- New_Prop_hires_New - has the modified methods in your last post.· If I have left anything out let me know.
Mike, did I mention that all the "local" Prop routines such as· Check Inventory and Identify Devices work just fine.· It is only those commands involving the Stamp that give me a problem.· And I still can't toggle the VGA - I can turn it off but I can't turn it back on.· By the way, when I turn it off, I get a little "Self Diagnosis" window on the VGA and the VGA power LED flashes on and off at a slow rate.
When you turn off the VGA, you would get a "self diagnosis" type window and the power LED would flash. Essentially, as far as the VGA is concerned, you've sort of turned off the power to your PC. In the case of the Propeller Demo Board, the LEDs and their resistors provide a high impedance pulldown for the VGA leads. I think you've just got the resistors and the socket and those would float.
Ah! The hires vga driver and the plain vga driver are very very different. The plain vga driver is more like the tv driver in its operation and there is a way to temporarily turn off the plain vga driver without stopping the cog (look at vga.spin in the comments near the end). There isn't any such feature currently in the hires vga text driver.
Mike, I changed the Stamp response to the commands "A" and "C" to a single byte instead of a string.· Now the VGA displays a bit of garbage, but it pauses for 3 seconds, then returns to the menu, which it is supposed to do.· When I had the Stamp programmed to return a string, it would read a random line from a DAT list, then lockup.
It probably wouldn't make any difference (except for memory usage), but, when you changed the OS_vgaHiresText module and renamed it OS_vgaHiresTextA, there were several other modules that still referenced OS_vgaHiresText. I've got your program compiled and loaded on my Demo Board. I've got a simple simulator for both the Stamp and the RFID and the main menu and simulator messages display. I'll let you know if I find anything as I try things out. I have had some bizarre behavior that may be due to downloading errors. With only a simple checksum, some errors could occur when downloading a large program like this that might not be caught. It might also be some kind of weird compiler error. When I recompile and re-download, the weird behavior goes away. We'll see.
Attached is the current set of files I'm working from. I did find one "text.str" that should have been a "text.out". The bit-banged serial input routines from BS2 seem to not be able to keep up at 9600 Baud. They do better at 2400 Baud going Propeller to pseudo-Stamp. Coming back they don't work reliably. I don't know why yet. I probably will switch to using the FullDuplexSerial routines for further testing.
This set of routines uses the VGA for normal output and the TV for debugging output. It's set up now for the Demo Board with the TV on pins 12-15 and the VGA on pins 16-23. The Stamp connection is still on pins 0 and 1, but I changed the RFID connection to pins 2 and 3.
Mike, I downloaded your program to a new folder to keep it separate, but I didn't try to run it.
I tried to get my old program to talk to the Stamp at 2400 baud but it wouldn't work.· I seem to remember reading somewhere that the Propeller only operates at 9600 true.\
Did I mention that the Stamp does not get hot when I am running my old program?
Sid,
The "bit-bang" routines written in SPIN are supposed to operate up to 9600 Baud, but SPIN isn't fast enough for anything higher. They should work fine at any slower rate. I am seeing some odd behavior like one part of the program is overwriting another. That certainly was happening with the recursion, but now there's not an obvious cause. It might be a compiler bug ... I've seen that happen before and it's similar, but I don't want to claim that until I've eliminated other causes. It still might be a stack overwrite, but I'm watching free memory with my debugging code.
Anyway, once the program starts getting overwritten, anything can happen like setting an input pin to an output. Make sure you've got a protective series resistor on the serial input lines from the Stamp and RFID reader.
Mike, I tried to communicate with the Stamp at 2400 baud gain.· I set the Stamp baud to 396, and changed the baud rate in senddata2 and recdata2 to 2400.· I monitored the Stamp inoput, and when I sent "A" from the Prop, the Stamp received a hieroglyphic - looked like a token.
Sid,
Here's the lastest version of the stuff I've been testing. I rewrote the bit-bang serial routines so they do fixed delay timing for the serial bits. I also added some pacing delays (about 10ms) between characters. This may not be necessary with the real Stamp, but, with the SPIN simulated Stamp, the program would lose characters at 9600 Baud. All of the commands except the Toggle VGA command seem to work. I still don't know why the program would behave weirdly at times, but it's better behaved now. I did clean up some things a little like substituting a case statement for some if/ifelse/else statements. I also made sure the I/O pins were initialized properly. Have a look. I've removed the TV-based debug code so you only need the VGA display.
I will continue trying to find out why the VGA display doesn't turn on again. The VGA initialization routine is called and does something, but doesn't produce a display.
Mike
Mike, I'm using the files in your archive.zip.· Loaded them into a new directory.
The keyboard LEDs do not come on.· If I hit "A" the screen says "Received:· " and waits for a response from the Stamp that never comes.· I disabled all the lines with "debug" - there were a lot - and also the lines with "pause_us".
Sorry it took so long to get back to you.· Had to stop for a few mins and do something else.
Here it is again. I recompiled the program, checked to make sure it behaves the way I expected, then recreated the Archive under a slightly different name. You'll have to change the I/O pin definitions at the beginning of the program. I had set the VGA pins to 16, the Stamp I/O to 0/1, and the RFID I/O to 2/3. For trying it out initially, don't connect anything to 0/1/2/3. You can remove the calls to "sim.startStamp" and "sim.startRFID" (and the OBJ definition for "sim") if you want to use the actual hardware rather than the simple simulators.
Mike, it seems to be working OK now, although the keyboard LEDs still do not light up.· Why don't they·turn on?· If I press "A" the VGA displays "Received:· Cmd A".· I checked inventory and that works OK, too.
Now then, what do I have to do to use the Stamp?· Remove the simulation object and replace it with the BS2.functions object, then rewrite senddata2 and the recdata methods, then disable all references to "sim"?
Attached is the fixed version. There was a bug in the stop routine for the VGA driver. Now, when you type "T", the display turns off. Then, when you type any key, the display turns on again (blank) and the menu appears after a second or two.
There are only three references to the "sim" object: 1) the OBJ declaration for "sim", 2) the call to "sim.startStamp", 3) the call to "sim.startRFID". Remove all three lines, recompile and it should work. You will have to change the I/O pin constants for the RFID connections. The Stamp pin numbers are unchanged.
The BS2 serial routines are not used anymore and you don't need them unless you want to use something else from the BS2 object.
1) You don't have to add the BS2 object. I rewrote the serial input and serial output routines with a little better bit timing and they're included in the main program file just before the data tables. You had several senddata routines that were nearly identical and I combined them by using a parameter for the data to send. It's often clearer to use a parameter than a global value. It makes it clear at the point of call just what you're passing to the called routine. The recdata routines were also identical and I combined them. You may have some future reason to have had them separate, but, for now, they could be combined and it made it easier to debug.
2) I don't know why the keyboard LEDs don't come on. Mine flicker during initialization, then don't come on as well. I never thought about it since Mac keyboards only have a caps lock and that's handled differently. I hadn't changed the assembly keyboard driver at all. I'll have to look into it. Thanks for mentioning.
3) Without the BS2 object, you don't have a PAUSE routine. I just substituted WAITCNT statements since they're easy when you have a fixed wait time (like one second - WAITCNT(CLKFREQ + CNT)).
Loaded the program and pressed "A".· The red LED on the Stamp came on as it should but the Stamp response was garbled and the display froze.· I changed the response from the Stamp to a single byte "A" and the VGA displayed "Aa", the lower case a was inverted and the display froze.· What would you like me to try ntext?
Mike, I think I've solved the problem!· I added a 100ms pause between bytes to my Stamp program and now all the responses from the Stamp are perfect.· The 100ms is too long - the string sort of scrolls across the screen so I'll see how much I can shorten it.
Sid,
I did forget to mention that you should put constant definitions for Inv and NInv in your main program and take out the "sim#" prefixes.
Inv = 0 and NInv = 1. Then you can take out the OBJ sim: "Simulator".
Try adding the pace parameter on your Stamp SEROUT statements. Maybe start with 2ms and see what happens. If that isn't enough, increase it in 2 or 3ms steps to 10ms. I think the hires VGA routines are slow and the program just isn't getting back to read the next character fast enough and it's missing a bit or two. I had to insert a pause in the simulator routines after each character. You could also try buffering the received bytes before displaying them instead of adding pacing.
PUB recData | c, x
x := 0
repeat until (c := serialIn(1,stampBaud,Ninv,8)) == 10 or x == 31
buffer[noparse][[/noparse]x++] := c
buffer[noparse][[/noparse]x] := 0
text.str(string("Received: "))
text.str(@buffer)
text.out(13)
PUB recDatag | c, x 'For receiving time from Stamp
x := 0
repeat until (c := serialIn(1,stampBaud,Ninv,8)) == 10 or x == 31
buffer[noparse][[/noparse]x++] := c
buffer[noparse][[/noparse]x] := 0
x := 0
text.str(string("Time is : "))
repeat 2
repeat 2
text.out(buffer[noparse][[/noparse]x++])
text.out(":")
repeat 2
text.out(buffer[noparse][[/noparse]x++])
repeat while (c := buffer[noparse][[/noparse]x++])
text.out(c)
text.out(13)
waitcnt(clkfreq * 3 + cnt)
Mike
Post Edited (Mike Green) : 9/18/2006 3:55:33 PM GMT
Comments
11:05:35
What the VGA displays is:
1L:>5:N
where both the "L" and ">" are inverted.
The controlling methoid is "recdatag". Line 213
This furthers my belief that something in OS is corrupting the text return from the Stamp.· And, the recdatag method never executes the "waitcnt" command.· It locks up after the dispaly and I have to reboot.
Sid
The recursion in your start1 routine (and other routines) is scribbling all over the OS's work area including the font tables. I'm not surprised that there are unexpected characters on the display. I had this happen once when I was developing the OS. I had not moved the font tables to high memory, tried to load a new SPIN program and it overlaid the font table that was part of the vga driver in lower memory ... instant garbage on the screen.
Mike
On the get the time thing, I finally figured out that that program was waiting for a sixth byte.· I changed line 224 to read:
elseif x == 5· '6·
Now it waits 3 seconds, then goes back to the menu.
Sid
Please recompile your program, make an archive, and post the archive here in a reply so I have everything you're working with. I can't duplicate your hardware, but I'll change the I/O pins and use a USB2SER adapter hooked up to my Mac to emulate the Stamp to see if I can duplicate what's happening. Fortunately, it's supposed to be a rainy weekend, just right for debugging!
Mike
- New_Prop_hires_New - has the modified methods in your last post.· If I have left anything out let me know.
Sid
Sid
Sid
I finally got a toggle - of sorts.· I wrote:
if selection == "T"
········ text.out(0)
········ if key.getkey
·········· initialize
·········· next
That doesn't really turn the VGA off but it clears the screen until I need it.
Sid
Mike
Does this help?
Sid
·
Mike
This set of routines uses the VGA for normal output and the TV for debugging output. It's set up now for the Demo Board with the TV on pins 12-15 and the VGA on pins 16-23. The Stamp connection is still on pins 0 and 1, but I changed the RFID connection to pins 2 and 3.
I tried to get my old program to talk to the Stamp at 2400 baud but it wouldn't work.· I seem to remember reading somewhere that the Propeller only operates at 9600 true.\
Did I mention that the Stamp does not get hot when I am running my old program?
Sid
The "bit-bang" routines written in SPIN are supposed to operate up to 9600 Baud, but SPIN isn't fast enough for anything higher. They should work fine at any slower rate. I am seeing some odd behavior like one part of the program is overwriting another. That certainly was happening with the recursion, but now there's not an obvious cause. It might be a compiler bug ... I've seen that happen before and it's similar, but I don't want to claim that until I've eliminated other causes. It still might be a stack overwrite, but I'm watching free memory with my debugging code.
Anyway, once the program starts getting overwritten, anything can happen like setting an input pin to an output. Make sure you've got a protective series resistor on the serial input lines from the Stamp and RFID reader.
Why wouldn't my old program work at 2400 true?
Your VGA and TV modules will ship tomorrow - I'll PM you with the details.
Sid
Sid
Here's the lastest version of the stuff I've been testing. I rewrote the bit-bang serial routines so they do fixed delay timing for the serial bits. I also added some pacing delays (about 10ms) between characters. This may not be necessary with the real Stamp, but, with the SPIN simulated Stamp, the program would lose characters at 9600 Baud. All of the commands except the Toggle VGA command seem to work. I still don't know why the program would behave weirdly at times, but it's better behaved now. I did clean up some things a little like substituting a case statement for some if/ifelse/else statements. I also made sure the I/O pins were initialized properly. Have a look. I've removed the TV-based debug code so you only need the VGA display.
I will continue trying to find out why the VGA display doesn't turn on again. The VGA initialization routine is called and does something, but doesn't produce a display.
Mike
sim.debugStr(string("choice '"))·
Sid
Post Edited (Mike Green) : 9/17/2006 10:34:52 PM GMT
The keyboard LEDs do not come on.· If I hit "A" the screen says "Received:· " and waits for a response from the Stamp that never comes.· I disabled all the lines with "debug" - there were a lot - and also the lines with "pause_us".
Sorry it took so long to get back to you.· Had to stop for a few mins and do something else.
Sid
Now then, what do I have to do to use the Stamp?· Remove the simulation object and replace it with the BS2.functions object, then rewrite senddata2 and the recdata methods, then disable all references to "sim"?
Sid
There are only three references to the "sim" object: 1) the OBJ declaration for "sim", 2) the call to "sim.startStamp", 3) the call to "sim.startRFID". Remove all three lines, recompile and it should work. You will have to change the I/O pin constants for the RFID connections. The Stamp pin numbers are unchanged.
The BS2 serial routines are not used anymore and you don't need them unless you want to use something else from the BS2 object.
Mike
And my keyboard LEDs still don't come on, even though the program responds to keyboard entries.· Why is that?
Sid
2) I don't know why the keyboard LEDs don't come on. Mine flicker during initialization, then don't come on as well. I never thought about it since Mac keyboards only have a caps lock and that's handled differently. I hadn't changed the assembly keyboard driver at all. I'll have to look into it. Thanks for mentioning.
3) Without the BS2 object, you don't have a PAUSE routine. I just substituted WAITCNT statements since they're easy when you have a fixed wait time (like one second - WAITCNT(CLKFREQ + CNT)).
Mike
· 'sim.startStamp(0, 1, stampBaud, sim#NInv)
· 'sim.startRfid(2, 3, rfidBaud, sim#NInv)
Loaded the program and pressed "A".· The red LED on the Stamp came on as it should but the Stamp response was garbled and the display froze.· I changed the response from the Stamp to a single byte "A" and the VGA displayed "Aa", the lower case a was inverted and the display froze.· What would you like me to try ntext?
Sid
Finally!!
Sid
I did forget to mention that you should put constant definitions for Inv and NInv in your main program and take out the "sim#" prefixes.
Inv = 0 and NInv = 1. Then you can take out the OBJ sim: "Simulator".
Try adding the pace parameter on your Stamp SEROUT statements. Maybe start with 2ms and see what happens. If that isn't enough, increase it in 2 or 3ms steps to 10ms. I think the hires VGA routines are slow and the program just isn't getting back to read the next character fast enough and it's missing a bit or two. I had to insert a pause in the simulator routines after each character. You could also try buffering the received bytes before displaying them instead of adding pacing.
PUB recData | c, x x := 0 repeat until (c := serialIn(1,stampBaud,Ninv,8)) == 10 or x == 31 buffer[noparse][[/noparse]x++] := c buffer[noparse][[/noparse]x] := 0 text.str(string("Received: ")) text.str(@buffer) text.out(13) PUB recDatag | c, x 'For receiving time from Stamp x := 0 repeat until (c := serialIn(1,stampBaud,Ninv,8)) == 10 or x == 31 buffer[noparse][[/noparse]x++] := c buffer[noparse][[/noparse]x] := 0 x := 0 text.str(string("Time is : ")) repeat 2 repeat 2 text.out(buffer[noparse][[/noparse]x++]) text.out(":") repeat 2 text.out(buffer[noparse][[/noparse]x++]) repeat while (c := buffer[noparse][[/noparse]x++]) text.out(c) text.out(13) waitcnt(clkfreq * 3 + cnt)Mike
Post Edited (Mike Green) : 9/18/2006 3:55:33 PM GMT