The 2004 Edubot includes two serial ports (USART): USART1 is the programming port which has voltage conversion for interfacing with an RS-232 port, and USART2 is the TTL port on the Edubot. No dedicated handshaking line is available on the TTL port, although Innovation FIRST states that any of the digital I/O pins could be used for this purpose.
Has anyone succeeded in modifying the code to make use of the TTL USART2 port? I have a USART compatible sensor, but am just beginning to learn C and the Microchip 18F8520.
I miss the days of just hooking up a pot or analog sensor (gyro) and being able to read the value of a byte directly. Mechanical engineers get spooked around all this programming/computer science stuff.
Yes, i have some experience with the USARTs. What kind of sensors are you using?
If u need some code i can do that. I can give you some code i wrote to read these sensors.
I can see using those modified sensors with a Stamp that has no ADC, but why not just buy the GP2D12 and use the ADC on the RC? They’re charging you twice as much to make it twice as hard to use.
I am also interested in using the TTL port on the EDUBOT to communicate with another micorprocessor. If anyone has some code to do this I would really appreciate seeing a copy.
We’re trying to use a digital compass (available from Digikey) Honeywell model HMR3100. See the datasheet at: Navigation & Sensors
The ini_aliases.h header file has the following line: #define usart2_RX PORTGbits.PORTG2
However, whenever I try to build the project with “usart2_RX” in my user code, I receive the following error:
Executing: “c:\mcc18\bin\mcc18.exe” -p=18F8520 “user_routines.c” -fo=“user_routines.o” /i"C:\mcc18\h" -Ou- -Ot- -Ob- -Op- -Or- -Od- -Opa-
C:\EduCode\user_routines.c:328:Error [1205] unknown member ‘PORTG2’ in ‘__tag_43’
Does anyone know what “unknown member” or “__tag_43” means and how I can resolve this issue?
James,
Thanks for the info, but it brings a few more questions. You’ve obviously used this code with the Edubot since you have references to “ifi_…” and “rc_dig…”. Where exactly does this code belong? Do I copy it to the user_routines.c file or somewhere else? Also, you use the include directive for “sensors.h” but this doesn’t seem to be in one of the directories with the Edubot sourcecode or /mcc18/h folder. If this is a separate header file, can you please post it as well?
The digital compass we are trying to use sends three bytes through the USART. Will these correspond to sensors[1], sensors[2] and sensors[3] directly, or is this just a coincidence?
the code i posted previously could be put in user_routines.c, but we have it in a seperate file, sensors.c
I will give a breif description of how this code works:
First let me explain exactly how this code works. We actually have 3 sensors multiplexed to the serial port through some buffer ICs, which are controlled by digital outs 14-16. The output from these three sensors are stored in sensors[1] sensors[2] and sensors[3]. The distance sensors we are using send a 3 byte packet. The 1st byte is always 01010101 the reamaining 2 bytes are ASCII characters, which contain the distance in cm.
The first important thing this code does it to configure the buffers i described above. The majority of the code is in a loop, which runs three times. The first time it reads the first sensor, the second time the second sensor… since you are only using one sensor you can kill the whole loop thing as well as the buffer code.
We are trying to read in a three byte packet. The problem is we have no way to syncronize when we start recieving and when the sensor starts transmitting. The solution is to read in 5 bytes:
gets2USART(input_buffer, 5); /*Read in data from sensors*/
Somewhere within these 5 bytes there will always be one whole packet.
since the first byte is always 01010101 we can look for that:
for (signature_pos=0; signature_pos<3; signature_pos++) {
if (input_buffer[signature_pos] == SENSOR_SIGNATURE) {
break;
}
}
the rest of the code just converts the ACSII string into decimal, so we can do useful stuff with it and then stores that value in sensors]
I hope this makes even the slightest inkling of sense. If it does i am glad i was able to help. O am always happy to answer questions.
James,
This actually makes quite a bit of sense. Even though we have only have one sensor, it too sends three bytes in a row. If the digital compass has a clk, it will send data in sync with the clk signal. If we tell it to operate in conitunous mode, it sends the three bytes and then waits 480ms before sending the next packet.
I’ll try adding the sensors.h file to our workspace.
The error just doesn’t show up if you don’t use usart2_RX because the preprocessor doesn’t insert PORTGbits.PORTG2 anywhere in the code and the compiler never sees it.
You’re right. Innovation First corrected this in their latest release of the Edubot sourcecode posted on their website (12/8/2003). They responded back to an email I sent and acknowledged the error. Rolling out a new control system with so many new features and having to write new code for the more powerful chip was no small task. All in all, I think they did an outstanding job (as always).
First, thanks to all that have posted to this thread, it has helped us greatly. We are still having one problem though. Our code works great on the EDU Bot controller but will not work on our Robot Controller. We have looked at the signals with a scope and think there might be something wrong with our controller(it appears there is something driving the line from the controller). Our question is this! Is there any differences in using the TTL port on the EDU Bot controller and the Robot Controller?
