Complete And Proper Description of Serial Port Behavior on Series 2 BASIC Stamps
D. Castagna
Posts: 2
I've been having a serious problem getting my Basic Stamp 2 to work with the Visual Basic MSComm serial port driver.
I specifically created a simple STAMP program to send a debug message out the serial port every second. The MSComm object is supposed to generate a software interrupt whenever data is received on the port and that event is never generated which means the PC never receives bytes from the STAMP.
Also, I can send (and receive) bytes with the BASIC Stamp Editor, Hyperterm and a second VB application that I wrote some time ago which also uses the MSComm control. These all work perfectly. I coped all of the settings I could find over to my test program and still no luck.
I seriously doubt it's as simple as setting 9600,8,N,1, then opening the port and you're done.
I suspect that one of the following two problems is true:
1) A specific combination of serial port pins is keeping the STAMP in reset and that's why I cannot communicate with it. The STAMP also resets every time I start hyperterm. So there must be some serial port behavior that causes a STAMP reset. I could not find anything about this in the documentation that came with it. What would really help alot is a description of how the STAMP ends up being reset by the serial port.
and
2) There is a specific sequence of pin settings that must be used to signal proper operation to the STAMP. Any timing diagrams that show the different serial port operational modes would be immensely helpful to debug this problem.
NOTE: In all of my STAMP code, I've been using "DEBUG" and "DEBUGIN". I have not been using the direct serial commands. This shouldn't matter however since 3 out of 4 programs work with "DEBUG" and "DEBUGIN". I have also tried slowing down the data transmission on both sides with delays. This also did not work.
I specifically created a simple STAMP program to send a debug message out the serial port every second. The MSComm object is supposed to generate a software interrupt whenever data is received on the port and that event is never generated which means the PC never receives bytes from the STAMP.
Also, I can send (and receive) bytes with the BASIC Stamp Editor, Hyperterm and a second VB application that I wrote some time ago which also uses the MSComm control. These all work perfectly. I coped all of the settings I could find over to my test program and still no luck.
I seriously doubt it's as simple as setting 9600,8,N,1, then opening the port and you're done.
I suspect that one of the following two problems is true:
1) A specific combination of serial port pins is keeping the STAMP in reset and that's why I cannot communicate with it. The STAMP also resets every time I start hyperterm. So there must be some serial port behavior that causes a STAMP reset. I could not find anything about this in the documentation that came with it. What would really help alot is a description of how the STAMP ends up being reset by the serial port.
and
2) There is a specific sequence of pin settings that must be used to signal proper operation to the STAMP. Any timing diagrams that show the different serial port operational modes would be immensely helpful to debug this problem.
NOTE: In all of my STAMP code, I've been using "DEBUG" and "DEBUGIN". I have not been using the direct serial commands. This shouldn't matter however since 3 out of 4 programs work with "DEBUG" and "DEBUGIN". I have also tried slowing down the data transmission on both sides with delays. This also did not work.
Comments
And unless you're using any sort of handshaking, you only need 3 wires to talk/listen to your stamp.
So, build a cable using just pins 2, 3 and 5. This avoids any issues with the stamp being reset while starting up Hyperterm or any other program holding the DTR (can't remember the actual pin) in a state of reset.
This may not be your end all cure, but it'll let you know if a reset is giving you grief!
The Debug command will automatically send serial data out pin 16 (it's programming port) at a proper RS232 level....so you shouldn't have to worry about anything else there.
If you were to use the SERIN/SEROUT command, you'd need to set the baud rate (true or inverted), and the pin you're using (can use any of the other I/O pins). So debug should be fine for what you're trying to do!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·
Steve
"Inside each and every one of us is our one, true authentic swing. Something we was born with. Something that's ours and ours alone. Something that can't be learned... something that's got to be remembered."
Basically, the IDE uses "DTR" 'active' to reset the BS2. Hyperterm keeps DTR active all the time. So, the BOE board has a couple of 0.1 uF capacitors (one in series, one in parallel) with this signal to 'decouple' it. The result of this is every time you bring up Hyperterm, it resets the BS2 ONCE, then lets it run until you take down Hyperterm and bring it up again. If you're not using the BOE board, and you haven't put these capacitors in your own circuit, Hyperterm WILL hold the BS2 in reset.
In your own VB program, if you do: MSComm.DTREnable = FALSE, then VB won't raise the DTR signal, and the BS2 should run.
Also, note that the BS2 RS232 circuitry is wired such that it uses the voltage on the TX line coming from the PC. It 'modulates' that signal with it's "RX" data (which comes FROM the BS2 TO the PC). So you MUST connect the TX line from the PC, even if you're not sending data on it.
This also means anything you send on TX will immediately be echo'ed back to you by the BS2 232 circuitry, whether the BS2 code itself actually gets it or not.
Note also all of this assumes you have a 'common signal ground' between your PC and the BS2. That means pin 5 of the DB-9 connector (ground) MUST be connected both to your PC and the BS2.
Addendum:· I've now attached a very simple example that demonstrates both sides in both VB and BS2.
Addendum2: Having looked at my code, I find you MUST do:
MSComm1.RThreshold = 1·· ' 0 (default) == NEVER kick off OnComm RX event
if you want to use 'event driven' reception in VB.
Post Edited (allanlane5) : 10/3/2005 1:38:51 PM GMT
The trickier part about using the programming port with an external applications (VB or otherwise) is that the programming port echoes everything sent to it.· So, if you send "ABC" in your application you can expect to find "ABC" in your input buffer ahead of any response from the BASIC Stamp.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax
Nice to know that it is supposed to be that way. I didn't understand much when there suddenly was a lot of stuff in the input buffer. Is there any way of getting past this problem, other than deleting the number of bytes you send from the input buffer?
This .. anomaly (if you will) ONLY occurs on Pin Port 16 (the DEBUG and programming port). So, if you stay with Pin Port 16, the answer is no, there is no way to turn it off.
However, nothing prevents you from using any of the other Pin Ports with SERIN/SEROUT. It will work equally well (but without the echo) on any Pin Port 0 ==> Pin Port 15.
Regards,
Bruce Bates
http://www.parallax.com/detail.asp?product_id=29120
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax