Interpriting DEBUGIN with raw serial

Mike K

I will start off this post with a quick overview of what i am trying to do. I have my programmed to accept serial communications from a host pc, react to them and continue to confirm the reaction with a debug statement. For example, my basic stamp starts up, sends in plain text "all clear" through use of the debug command, and then receives inputs with the debugin command and saves the value to a variable, once the stamp has reacted to the values it has received it prints the values
it has set for the variables to conform it received the correct values (wheww). plain text example of a debug terminal session on the pc side.

from stamp     all clear
to stamp         1
to stamp         1
to stamp         32
"the stamp then reacts based on what it recives"
from stamp     I got 1,1,32

Ok, now this all worked fine and dandy in the Parallax IDE debug terminal, so my friend and I wrote up a quick C script that would feed the basic stamp commands through its serial cable via the DEBUGIN command.
We tested tested the C script to see if it could see the all clear signal the stamp was sending, it could, so we tried sending data to the stamp, but at this point the stamp was not getting the data. We scrutinized the script for errors and admittedly we found some, but with some elbow grease, and a few quick command syntax checks, we satisfactorily fixed the script, but alas, the stamp still did not receive the data. This brings me to my question, I belive my problem has to do with the DEBUGIN command, so in order to take input from a serial cable with the C script, do i need to use SERIN and use one of the stamps pins as a serial port, or is there some trick to getting DEBUGIN to work with a C script, i.e. anything not the Parallax IDE debug window?
Thanks in advance, and if more information is needed I can elaborate,
Mike

Bruce Bates

Mike -

Although you didn't include a copy of your program which makes it a bit difficulkt to troubleshoot, if you are indeed sending all of the characters "all clear" I suspect that's the problem. It would take NINE bytes of storage to contain that entire character string. Even then, PBASIC has no direct method for making string comparisions. You may want to reduce that to (say) one character, and one that won't be found in your data stream. As a for instance send an explaination point (!) which can be stored in one byte, and one which you can check for with a single byte compare.

Regards,

Bruce Bates

Post Edited (Bruce Bates) : 6/21/2007 8:52:56 AM GMT

Mike K

Thanks for the reply, but thats actually not where my problem lies, I will try to explain this the best I can. The most basic description of what I am trying to do is have the stamp send me all clear when it is ready to receive data, then my C script
sees all clear and starts to send data to the stamp, for example 3 integers. The stamp then verifies it has received this data by sending the data back through the debug command followed by the data it has received. Now this entire setup works in the Parallax IDE Debug Terminal, I can receive the data from the stamp, send it 3 integers, and have it send me back the integers, but when i try using my C script to communicate with the stamp, it can only receive from the stamp, when it tries to send the data to the stamp, for some reason or another the stamp doesn't get it. Now just for arguments sake lets pretend that the C script could not possibly be the problem as my friend and I are perfect coders. This indicates that there must be a problem with the stamp code, so, at this point i believe that the DEBUGIN command is something that only works with the Parallax IDE Debug terminal, and with nothing else such as my C script or hyper terminal. So if my assumptions are correct how can send serial data to the stamp not using the DEBUGIN command, or better yet, what syntax does the computer send data in, to the stamp through the Parallax IDE debug terminal.
Here's the business end of the code if it helps.

DO   '--------{This is where the computer talks to the pic :)
start:
    DEBUG "all clear", CR
    DEBUGIN DEC color
    DEBUGIN DEC ud
    DEBUGIN DEC value

    IF color = 1  THEN
    GOSUB red
    ENDIF
    IF color = 2  THEN
    GOSUB blue
    ENDIF
    IF color = 3  THEN
    GOSUB green
    ENDIF
    IF color = 4  THEN
    ENDIF
    GOSUB white

'------{ this is where the pic reacts to the commands}
red:
IF ud = 1  THEN
LOW redud
ELSE
HIGH redud
ENDIF

  FOR counter = 0 TO value
  PULSOUT 5,1
'--- must add pause variable
  NEXT
'----this is where the pic reiterates the variables it has recived
  DEBUG DEC color
  DEBUG DEC ud
  DEBUG DEC value
  GOSUB start

I do apologize for my code, it is very messy and inefficient, and I am open to any suggestions to optimize/simplify it.
Thanks For your help,
Mike

Post Edited (Mike K) : 6/21/2007 7:23:46 PM GMT

Mike Green

The IDE sends information from the debug window as plain text. There are no extra characters or formatting involved.
This may be a problem with timing or the actual format of information sent by your script.

The Stamp does not have buffered serial I/O, so the DEBUG command sends the "all clear" and the CR. It takes a little while for the DEBUG command to finish and for the DEBUGIN command to start. It also takes a little bit for the DEC to get set up by the Stamp. During this time, the Stamp is not listening to the debug input line and will miss any characters that are sent. Also, the definition of the DEC formatter is that it ignores any non-numeric character until the first one, then it parses a number terminated by a non-digit and throws away the non-digit character. You didn't indicate whether your script puts enough non-digits between the numbers to serve as the expected delimiters.

Anyway, you may need to slow down your script and/or add some spaces or other extra delimiters.

allanlane5

Also, if you are NOT using a "BOE" board, you should be aware that the IDE does not hold the DTR signal high. Holding the DTR signal high will hold the BS2 in 'RESET', and it won't do anything until you drop the DTR line. Note the default state for the DTR line is to go high when you open the port.

UNLESS you are on the BOE, in which case there's two capacitors which 'decouple' the DTR line. In this case, the BS2 will 'reset' when the DTR line first goes high, then continue to run.

I think using DEBUGIN it's also necessary to add a CR (CHR(13), '\n') or LF after each value sent to the BS2, otherwise the DEBUGIN statement won't end.