Programming Port

[GreenDice]

Does anyone know what pin is used for programming/debug on the Basic Stamp module?

Thanks in advance.

[Greg Ross]

Originally posted by GreenDice
Does anyone know what pin is used for programming/debug on the Basic Stamp module?

Thanks in advance.

I'm having a hard time imagining what information you're tyring to discover.

If I remember right, the programming cable had to be modified for the pre Innovation First control system by removing a pin. Is this what you're thinking of? I don't believe this is necessary any more.

Alternately, are you wanting to know which of the DB9 pins is used to transmit/receive data? Why? Are you planning on doing something real esoteric with your custom PCB?

Be a little more specific, and maybe we can help.

[GreenDice]

I am trying to output debugging information to the programming port without using Debug statement. That is, use SEROUT command to output the current values of the variables to the laptop.

[Greg Ross]

Near the end of the documentation pages for the DEBUG command, it states:

DEBUG is actually a special case of the SEROUT instruction. It is set for inverted (RS-232-compatible) serial output through the programming connector (the SOUT pin) at 9600 baud, no parity, 8 data bits, and 1 stop bit. For example,

DEBUG "Hello"

is exactly like:

SEROUT 16, $4054, ["Hello"] ' like DEBUG for BS2

in terms of function (on a BS2). The DEBUG line actually takes less program space, and is obviously easier to type.

That given, the only reason I can think of to use SEROUT instead of DEBUG, would be to use a higher baud rate than 9600 -- an interesting idea, though I am not sure how valuable that would be.... BUT to answer the original question, the pin is 16

[GreenDice]

I am thinking about outputting binary data stream, containing values of all my internal variables right before sending commands to the master uP. It is very similar to the dashboard port; except this will have useful info.

[Lloyd Burns]

Did you ever luck out - Innovation First will soon announce what the jumper is for, and as I understand it, it will allow the dashboard port to show the OI's about-to-be-transmitted values.

Is that what you wanted ? Me too! :-)

[GreenDice]

That will be perfect. I better go home and try out the jumper. I can add code to my Dashboard Monitor program to process two different data streams. I can record and playback the data to really debug the control system.

[Lloyd Burns]

They said they'd publish the new spec soon.

Maybe we'll catch you at the Canadian Regional in Toronto.

[Joe Johnson]

You may not be able to switch the OI to RC data packets on the fly.

My understanding is that you would be able to get EITHER the OI data OR the RC data not both.

I don't know whether the jumper can be switched on the fly or do you have to reset the OI to get the data packets to switch.

Also, even if you could, I don't think that you could do it legally (during a competition I mean) with a PC driving the switch as that seems to conflict with the rules for using PCs.

Joe J.

[GreenDice]

I just tried it. You can switch it anytime and it just keep running. Since it is for display only, I think you can use the laptop to show the status during the match. Personally, I think it is much more useful than what it used to output.

[Adrian Wong]

How did you confirm the output changed? Did you reverse engineer the packet data or develop a program of some sort to interpret the stream?

[GreenDice]

Since the output from Pbasic uP to Master uP is also 26 bytes and follows the same message format as the normal dashboard port output, my Dashboard Monitor program can decode the messages. Although the locations of the bytes are different, I can move the joystick and see a byte changes values.

I am going to add another feature into my Dashboard Monitor to display the 16 relay output bits and the 16 PWM output.

[GreenDice]

The data is not what the Pbasic uP going to send to the master uP to control the PWM output and Relays. Instead, it is some variation of the joystick data sent to the Pbasic uP.

IMO, so the best way to test you control program is to output your debug data via the programming port. Record it and analyze it using Excel or other software.