I would like to connect two micro controllers for my robot. I would like to do this by connecting them with pwm wires in the Tx and Rx ports. What does the code to transmit data between the controllers look like? And what kinds of data can be sent?
Are you talking about the Tx/Rx ports at the end of the analog/digital I/O connector bank? If so, those are serial rather than pwm. Here is an example of how to wire two controllers via serial, and some sample code for EasyC.
If you want to use pwm (or ppm) to communication between processors, you can do that too, but it is harder and not as effective. Here is some code for that.
Cheers,
- Dean
That can be done with Male to Male PWM Wires and the Vex Programming Kit.
The Code can look like this, **Simple RX/TX Port Example ** for EasyC Pro.
The Code can look like this, Vex On-Line Controller Code v2.x (Available Source Version 0.81ß) for MPLAB.
The EasyC Pro example above just opens the Com Ports and Receives and Sends data.
The MPLAB Example above is designed to interact with the Vex On-Line Window in the Intelitek Downloader for EasyC 2.
Any kind of Data can be sent, you will need to develop a protocol to exchange data with each Vex Controller…
If you need assistance, just ask… Quazar or myself are very knowledgeable about such things… 
There are many other people here that can assist you as well…
mmm I forgot to mention that Im using robotC. Is that going to kill this idea?
It shouldn’t… Quazar and I have done more work with EasyC and MPLAB, so we have Code Examples… We both have RobotC as well…
I was kinda trying to refer to the question. How does the code change for robotc?
That is the Hard Part…
First, a little “Computer” and “Serial Port” Terminology for this discussion here… Not trying to overwhelm you, but we are trying “set a solid foundation”.
A Computer (generic) is any Computing Device. It can be your Desktop, Laptop, Palm Pilot, LEGO Mind-Storm, Vex Controller or a Boeing ScanEagle UAV.
To Output Data from a computer, is to Transmit, abbreviated “TX”.
To Input into a computer is to Receive, abbreviated “RX”.
(I have a tendency to use the “synonymous terms”, interchangeably.)
Bi-Directional means that something goes Both Directions, or with Serial Communication means that each computer can both Transmit and Receive. The new Vex Transmitter/Receiver using VEXNet are setup this way, Data goes from you (The Vex Transmitter) to the Vex Controller, and Data also goes from the Vex Controller to the The Vex Transmitter, thus Bi-Directional.
Uni-Directional means that something goes Only One Direction, or with Serial Communication means that One computer can Transmit and another computer can Receive. The original Vex Transmitter/Receiver using the 75Mhz Crystals are setup this way, Data ONLY goes from the you (The Vex Transmitter) to the Vex Controller, thus Uni-Directional.
Mode is “a distinct setting within a computer program or any physical machine interface, in which the same user input will produce perceived different results than it would in other settings.”, (see Mode (computer interface)).
Data Path or Data Stream, is “a sequence of digitally encoded coherent signals (packets of data or datapackets) used to transmit or receive information that…” (see Data Stream).
Many parts of ROBOTC are very vague… I have been instructed by the members of the ROBOTC Forums, “to look at the Example Programs”, which most are written for the LEGO NXT Mind-Storms Controller, and I would think not always applicable to the IFI/Vex platform.
The ROBOTC v1.97b help, says this in the Section, “[FONT=Arial][FONT=Arial]**Debugger Vs. **[/FONT][/FONT][FONT=Arial][FONT=Arial]Traditional Methods[/FONT][/FONT]”:
There seems to be no documentation on the “[FONT=Arial][FONT=Arial]Traditional Methods[/FONT][/FONT]”, other than the phrase, “have to add “print” statements to your program code”. There, also is no mention of a way to make the Vex Controller “Receive Data”, in the Non-Debugger Mode. So even if One Vex Controller was to Output some Data, there might not be a way for the Other Vex Controller to Input some Data, and then Act on It.
It seems obvious to me that the ROBOTC Debugger Mode is Bi-Directional, But most Debugger Systems, for simplicity, have only a Host Mode and only a Target Mode. In ROBOTC, as the Debugger seems to be Documented, the PC is the Host, and the Vex Controller is the Target.
Loading the ROBOTC System on both Vex Controllers would make them Both “Target Mode”, and unless this “communication protocol” was designed for selecting a Mode of Host or Target, they would be unable to communicate with each other, even though each is able to both Transmit and Receive Data.
To get Full Functionality, you need to have a “Bi-Directional Data Path”, for Communication between your two Vex Controllers…
EasyC and MPLAB both allow a “Bi-Directional Data Path”. ROBOTC might allow this in Debug Mode, and does not seem to allow this in the “Traditional Mode”, but the Documentation being what it is, I would not be discouraged, yet…
I will setup my “Serial Port Data Tap” and see what is “communicated” between the ROBOTC Debugger and the Vex Controller when in Debug Mode.
Yes, it is possible to do what you want using RobotC. I haven’t personally done serial I/O under RobotC yet, but it should be just as easy.
When I get some time over the next few days, I’ll try to port my example to RobotC. Until then, have a look at the file “RobotCIntrinsics.c” which is installed under Includes. Starting around line 700 are the definitions for using serial.
The important functions are:
[INDENT]setSerialPortMode();
setBaudRate();
[/INDENT]for initializing the port, and
[INDENT]getChar();
sendChar();
[/INDENT]for receiving and sending data one character at a time.
I think the following code would generate a constant stream of ‘V’ characters:
// Warning! Untested code below:
task usercontrol()
{
setSerialPortMode(uartTwo, portModeUser);
setBaudRate(uartTwo, baudRate19200);
while (true)
{
sendChar(uartTwo, 'V');
while (!bXmitComplete(uartTwo)
{
// Wait for transmit to complete
}
}
}Cheers,
- Dean
I keep forgetting that the ROBOTC people included a whole bunch of ‘C’ code files…
I need to go take a look at “RobotCIntrinsics.c”.
I couldn’t find anything in the documentation or forums about these functions; I found them by searching the file contents of the Includes folder.
(This is the same way I found the serial functions in EasyC … undocumented functions in a header.)
Fortunately, they look pretty straight forward. A bit of experimentation will be very educational.
Cheers,
- Dean
I cant tell you how helpful this is. I cant test it yet as I dont yet possess two micro controllers, I am in the process of figuring out if I really need two (but I think I might). I will have a look around the header files though, might find something useful (like a way to turn sensors on and off).
But once again thank you for this info.
Excellent - glad to hear it. Using serial for Vex-to-Vex communication is an idea that comes up regularly on the forum, but there are no posts that I’ve seen that describe exactly how to do it or how to make the two microcontrollers cooperate. That is why I posted the simple serial example. If you manage to get such a setup working, please post back with what you did and how you did it.
Actually, you can test a little bit. You can connect the Tx port of of your microcontroller back to its Rx port. If you do that, every char that you send will be received back almost immediately. This way, you can at least verify that you are able to send and receive from a program running on one Vex.
Glad to be of help,
- Dean
I may just test that as soon as I get the extra piece for the end of the serial wire.