Communications via the Programming Port

[Larry Barello]

Anticipating more autonomous stuff next year, I thought now would be a good time to develop the basics for an off-board processor.

In 2003 we used the PWM out and Analog inputs to communicate between the processor and the basic stamp. Decoding the PWM values to get an ~8 bit value and setting a hardware PWM to perform and DAC function to send ~8 bits back.

This year I would like to use the Programming port for two way communications. The question: Has anyone done that? And how/what was your algorithm? What processor did you use, etc.

Thanks.

[rbayer]

I've done it to talk to a PC, but never another uP. If you're interested in that, check out RoboCon at my website (www.robbayer.com). The included bsx file may be useful in writing the PBASIC side of things...

[Larry Barello]

With the number of bytes you are passing with RoboCon, 37, your main loop takes well over the 26ms between radio packets. You also put in a bunch of bytes for headers, etc. I like the use of control bytes to cover the 0xFF and 0x00 cases. I do something similar in as much as I serout/serin with timeout. I do not use a header or 0x00/0xFF checking as the micro doesn't care and the link seems pretty reliable.

One area I am having trouble with is every so often the basic stamp loses one (or more, there is no way to tell) charactors and times out of the serin. I am struggling to figure that one out. One packet every couple seconds probably isn't worth too much effort, but I do want to understand why. Re-synching is't a problem as the co-processor is already waiting for the next packet when the basic stamp times out. So far the co-processor always gets it's packet w/o error.

Cheers!

[JLambert]

Our robot from this year had an external circuit using a Microchip microcontroller. The microcontroller collected wheel rotational data, and the robot controller would send a request every loop to the circuit. Upon the request, the circuit would send data collected so far.

The chip was programmed in C, so it's not excessively complicated. We primarily had trouble just getting the two to talk at the same baud rate. I'm honestly not sure of how exactly it was done, because I was more involved with the primary programming of the robot, but I'll find out more later.

[Rickertsen2]

Originally posted by JLambert
Our robot from this year had an external circuit using a Microchip microcontroller. The microcontroller collected wheel rotational data, and the robot controller would send a request every loop to the circuit. Upon the request, the circuit would send data collected so far.

The chip was programmed in C, so it's not excessively complicated. We primarily had trouble just getting the two to talk at the same baud rate. I'm honestly not sure of how exactly it was done, because I was more involved with the primary programming of the robot, but I'll find out more later.

What compiler did u use? What was your experience with it? I have been looking for a C compiler for Pics. Also what Pic did you use?

[JLambert]

Originally posted by Rickertsen2
What compiler did u use? What was your experience with it? I have been looking for a C compiler for Pics. Also what Pic did you use?

We used a compiler called C2C, I'm not familiar with where we got it from, but it was a basic C compiler, but we had to have another program to load the assembled code to the PIC.

I honestly did not use it very much myself. As I said, I was more focused on the main PBASIC code of the robot, and did not deal a whole lot with the PIC coding.

I know it was a 16 series, I have it written down somewhere, I'll let you know when I find it.

[Matt Reiland]

Cool Deal JLambert

I am experimenting right now with a PIC and was looking for some code snipets to get it talking with the Robot Controller. Any help on the C portion of the code and the request in PBasic would be a great help to all of the teams.

Hint, Hint This would be a great White Paper!

[JLambert]

Originally posted by Matt Reiland
Cool Deal JLambert

I am experimenting right now with a PIC and was looking for some code snipets to get it talking with the Robot Controller. Any help on the C portion of the code and the request in PBasic would be a great help to all of the teams.

Hint, Hint This would be a great White Paper!

Well, I'm by no means any expert on the matter. I'm just learning a lot of it myself from the couple of mentors on my team who really knew what they were doing. The C stuff is all basics. If you learn C, which is fairly easy compared to a couple other languages out there, all you really need to know is how to integrate it with your application. My only real suggestion is to FIRST learn a language (wether C or another that can be used) and find out all the info you can from the manufacturer. I know Microchip has lots of PDF Docs on every single chip they make. Make sure you read these all over very thouroughly before hand so you know exactly what your chip can/can't do.
Once I learn a little bit more, I'll be more than happy to post a white paper and help anyone with problems that I may be able to solve.

[JLambert]

Originally posted by JLambert
We used a compiler called C2C, I'm not familiar with where we got it from, but it was a basic C compiler, but we had to have another program to load the assembled code to the PIC.

I honestly did not use it very much myself. As I said, I was more focused on the main PBASIC code of the robot, and did not deal a whole lot with the PIC coding.

I know it was a 16 series, I have it written down somewhere, I'll let you know when I find it.

The C compiler we used was the C2C compiler from a company called PicAnt. It also requires that you install the MPLAB IDE from Microchip, INC. as well.

From what I can gather, our chip was a 16F864, but don't pin me to that.

[Larry Barello]

In response to my own question, above, I implemented a fairly powerful IFI co-processor that uses the debug port. I found out that by carefull processing you can transfer data between the Basic Stamp and an outboard processor at 28.8kb - fast enough to transfer 33/45 possible bytes (26 inputs and 18 outputs + LEDS) while maintaining the IFI 26ms cycle time. You could transfer all 45 variables, but would extend the cycle time to 35ms or so. The entire project can be seen here http://www.barello.net/FIRST Look at the last two items.

Note, I don't have the board made yet. The plan is for 8 channels of 10bit high speed ADC and 16 bits if general I/O (user defined in code). The current code base has 3 channels of Quadrature decoding (for wheel position, motor velocity, whatever: It keeps up with 20krpm and a four slot encoder) Gyro code that tracks absolute theta from the start and a second serial port for debugging.

The actual board is on hold for the next month or two until I find out what IFI has in store for us (they are re-vamping the RC, apparently).

Cheers!