Chief Delphi - New Serial Port Driver

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)

- Programming (http://www.chiefdelphi.com/forums/forumdisplay.php?f=51)

- - New Serial Port Driver (http://www.chiefdelphi.com/forums/showthread.php?t=31931)

New Robot Controller Serial Port Driver

I've written a proper serial port driver from scratch that can be downloaded here: http://kevin.org/frc. The main source file, serial_ports.c, consists of just over a thousand lines of code, comments and documentation. The code implements a fully buffered, full duplex, interrupt driven serial port driver for the FRC and EDU robot controllers. I've included the readme.txt text below. Have fun.

Edit: This project was built using MPLAB 6.60. If your version of MPLAB complains about the project version, the best thing to do is just create a new project with MPLAB's project wizard. Include every file except: FRC_alltimers.lib, ifi_alltimers.lib, printf_lib.c and printf_lib.h and you should be able to build the code.

-Kevin

Code:

The source code in serial_ports.c/.h contains a software 

implementation of a fully buffered, interrupt-driven, full-

duplex serial port driver that can be used with either or both 

on-board serial ports. Also included is a modified version of 

IFI's original printf() software that supports the use of both 

serial ports. Unlike the IFI code, this driver is non-blocking, 

which means that you can send a byte of data without having to 

wait around to make sure it gets sent before sending another. 

This is the same way operating systems, like Linux and Windows, 

handle serial data reception and transmission in the background 

for application software.

The source code in serial_ports.c/.h and printf.c/.h will work 

with the Robovation (A/K/A EDU-RC) robot controller and the 

FIRST Robotics robot controller without modification.

 

Because you can now easily receive data from another computer, 

you can interact with your nifty IFI robot controller in real-

time to change operating parameters on-the-fly using common 

terminal emulation software, or send real telemetry to custom 

applications written with Visual Basic, Visual C++, MATLAB, 

etc... Don't want to drag a long serial cable behind your 'bot? 

Well, check-out the nifty SMiRF radio modem from SparkFun 

Electronics (http://www.sparkfun.com). Would the coolness 

factor of your 'bot be elevated if you had a LCD mounted on 

board to display diagnostics (yes, this is a rhetorical 

question)? How about using one of the serial LCDs that can be 

found on the 'net? I've had success using Scott Edward's 

Electronics (http://www.seetron.com) serial LCDs. The TRM-425L 

will work with the TTL-level serial port two and also includes 

a keypad interface. I've been mostly using the BPP-420L on 

serial port one. To use the above devices you'll need to build 

a simple three or four conductor cable. Disclaimer: Other than 

being a satisfied customer, I have no interest (financially, or 

otherwise) in the companies mentioned above.

 

By default, serial port one will operate at 115200 baud, which

is compatible with InnovationFIRST's terminal program, and 

serial port two will operate at 9600 baud, which will work with 

the above mentioned peripheral devices. these values can be 

easily changed by modifying the serial port initialization 

functions mentioned below.

 

For an example of how to use this software, see the code

in Process_Data_From_Master_uP(), which demonstrates how to

properly use this new functionality.

 

 

***************************************************************

 

Here's a description of the functions in serial_ports.c:

 

Init_Serial_Port_One()

Init_Serial_Port_Two()

 

These functions initialize the serial ports. This is where 

you will enable or disable the serial port's receive and/or 

transmit circuitry and set the baud rate at which it will 

operate. One or both of these functions must be called before 

any serial port operations can take place.

 

 

Serial_Port_One_Byte_Count()

Serial_Port_Two_Byte_Count()

 

These functions will return the number of bytes present in

their respective received data queues. Because there might

not be any data in the queues, these functions must be called 

before you can read any data from a serial port.

 

 

Read_Serial_Port_One()

Read_Serial_Port_Two()

 

These functions will return the next byte from the received

data queue. If no data is present in the queue, the function 

will return the number zero, which could cause problems if

your incoming data can also contain a zero. This is why the

Serial_Port_xxx_Byte_Count() functions must be called first.

 

 

Write_Serial_Port_One()

Write_Serial_Port_Two()

 

These functions put a byte of data on the serial port transmit 

queue. If the queue is full, the function will make you wait

until a storage slot becomes available before allowing your

code to execute again.

 

 

Rx_1_Int_Handler()

Rx_2_Int_Handler()

 

When a new byte of data is received by the serial port, the 

microcontroller will automatically call these functions to

get the new data and place it in the received data queue for

you. You shouldn't have to call these functions yourself.

 

 

Tx_1_Int_Handler()

Tx_2_Int_Handler()

 

When the serial port is ready to start sending a new byte of 

data, the microcontroller will automatically call these 

functions to get the next byte of data from the transmission 

queue and give it to the serial port for transmission. You 

shouldn't have to call these functions yourself.

 

***************************************************************

 

Five things must be done before the serial port driver will 

work correctly:

 

1) You must add the serial_ports.c/.h source files to your

MPLAB project.

 

2) The interrupt handlers must be installed in the

InterruptHandlerLow() function located in the

user_routines_fast.c source file. See the accompanying 

copy of user_routines_fast.c to see how this is done.

 

3) Init_Serial_Port_One() and/or Init_Serial_Port_Two()

must be called from the User_Initialization() function 

located in the user_routines.c source file.

 

4) As this software is intended to replace the default

serial port software, the call to Initialize_Serial_Comms()

in User_Initialization() should be removed or commented

out. The User_Initialization() function can be found in

the user_routines.c source file.

 

5) A #include statement for the serial_ports.h header file

must be included at the beginning of each source file that

uses the serial ports. The statement should look like this:

 

#include "serial_ports.h"

 

In addition, these five things must be done before the

modified printf() function will work correctly:

 

1) You must add the printf.c/.h source files to your MPLAB

project.

 

2) As this software is intended to replace the default

printf() function, the printf_lib.c/.h files need to be

removed from your MPLAB project.

 

3) All #include references to printf_lib.h must be commented 

out or removed.

 

4) A #include statement for the printf.h header file must

be included at the beginning of each source file that uses

the printf() function. The statement should look like this: 

 

#include "printf.h"

 

5) To support terminal emulation software, \r\n should 

be used instead of just \n in the printf() format string.

 

As mentioned above, this version of the printf() function can 

send it's output to either of the serial ports by altering the 

value of the global variable "stdout" before calling the 

printf() function. Setting the value to "ONE" will send the 

output to serial port one. Likewise, setting the value to 

"TWO" will send the output to serial port two (these are 

#define'd in printf.h).

 

As an example,

 

        stdout = ONE;

        printf("Hello");

        stdout = TWO;

        printf("World!");

 

will send the text "Hello" to the peripheral device attached 

to serial port one and the text "World!" to the device 

attached to serial port two. By default, output is sent to 

serial port one.

 

 

Kevin Watson

kevinw@jpl.nasa.gov

Re: New Serial Port Driver

Kevin, this sounds AWESOME!
I downloaded the zip and extracted it. Then, I tried to open up the project file and I got the error:

Unable to load the project because the format of the project file has been changed.

The project immeditaely gets closed. Any ideas?

Re: New Serial Port Driver

Quote:

Originally Posted by MikeDubreuil

I'd forgotten what a hassle this was last year. It seems that just about every version of MPLAB creates project files that aren't compatible with other versions of MPLAB. As it would be a pain to distribute examples with multiple versions of MPLAB project files, the best thing to do is just rebuild the project and exclude FRC_alltimers.lib, ifi_alltimers.lib, printf_lib.c and printf_lib.h from the build. You can also just add serial_ports.c/.h and printf.c/.h to any existing project by following the steps listed in the readme.txt file.

-Kevin

Re: New Serial Port Driver

Good GOD! I was just wishing such a thing existed this morning and SHAZZAM, Watson does it again.

Re: New Serial Port Driver

Just an idea... you could add a definition to disable the second serial port... so that way if someone doesn't use the second one, you can just define DISABLE_PORT_TWO and it wouldn't try to compile that section using conditional statements...

Code looks like a good idea though... nice :)

Re: New Serial Port Driver

Quote:

Originally Posted by randomperson

Yes, I'd considered that. The way I look at it, I'd rather just publish the least convoluted, easiest to understand raw code that I can and let you guys cut and paste it the way you want.

-Kevin

Re: New Serial Port Driver

Quote:

Originally Posted by Kevin Watson

Yes, I'd considered that. The way I look at it, I'd rather just publish the least convoluted, easiest to understand raw code that I can and let you guys cut and paste it the way you want.

-Kevin

I suppose. I went ahead and made those modifications myself, if anyone is interested in doing it quickly. It really doesn't make it TOO convoluted... ;)The source is attached.

Re: New Serial Port Driver

Quote:

Originally Posted by randomperson

I suppose. I went ahead and made those modifications myself, if anyone is interested in doing it quickly. It really doesn't make it TOO convoluted... ;)The source is attached.

Random,

Feel free to use my code for your own use. I do, however, ask that people please not modify my code and make it available elsewhere on the web. I ask this for two major reasons: (1) As code gets updated, I need to have one source for that code on the web so that there will be no question of its "freshness" or validity. (2) Time permitting, I'm happy to answer questions about my code (that's why I include my e-mail address in the header), but as I'm the sole support person for my code, and I have a family and a day gig, I'd rather not have to deal with questions regarding code that's been modified by others. Yes, I'm a knuckle-head for not spelling this out in the readme.txt. I'll also look into adding the functionality you've requested, but make it more general. Something like #define USE_SERIAL_PORT_ONE, etc...

Thanks,
Kevin

Re: New Serial Port Driver

Kevin, this is awesome... great work. I'd really like to implement your code to drive an LCD for debugging and diagnostics on our robot this year, so I'll let you know if/when we do. Thanks for your contributions to the community... not just this code, but all of the stuff you've writted for us. :)

Re: New Serial Port Driver

Quote:

Originally Posted by randomperson

...you could add a definition to disable the second serial port...

I've updated the code to do this and more. There are now four definitions that will include/exclude code at the individual serial port receiver/transmitter level. See serial_ports.h and readme.txt for details. The code can be found here: http://kevin.org/frc.

-Kevin

Re: New Serial Port Driver

I have just posted the following on the Spark Fun Electronics Technical Forum... I am posting here as well in case one of you have seen this problem.

Quote:

Hi,

I recently purchased a SMiRFv2 and am having problems getting into the configuration utility.

I am running Hyperterminal V5.1 under XP home SP2.

First of all, I get two New Hardware Found dialogs when I first connected the SMiRFv2 to my PC. The first was for the CP2101 and the second for the SFE RS232 controller. This does not concern me too much. I mention it because a double install dialog was not mentioned in the PDF documentation.

I have insured that HT and the SFE device driver are both configured for 9600, 8, N, 1 (I am on COM6).

The multiple control S command does not bring up the SFE configuration screen as described in the PDF data sheet. I have tried this with the remote SMiRF powered and unpowered.

I then ran some user code for the remote SMiRFv2 (I am connected to a PIC18C) and was initially unable to establish communications.

While I was looking at my user code, I noticed that communications had been established with the remote and I was getting data on HT.

About a half hour later, the communications halted and HT is, once more, dead. I have nor been able reestablish.

When I plug in the USB part of the SMiRFv2 pair, the status light is lit for about a minute and then goes out. When I run the remote, the remote status LED blinks once a second which is consistant with my PIC18C code (sends 30 to 50 ASCII data characters once per second).

I am mostly concerned about not being able to access the SMiRFv2 configuration via multiple control S keystrokes as per the data sheet.

Any ideas?

By the way... Thanks to Kevin for the printf utility code... For the half hour it worked, it worked really well!

I will post here if I get good feedback from the SFE site.

Re: New Robot Controller Serial Port Driver

I was under the impression that the "usart" files included with the compiler provide serial port functions. Can someone tell me the difference?

Re: New Serial Port Driver

Quote:

Originally Posted by Mike Betts

I have just posted the following on the Spark Fun Electronics Technical Forum... I am posting here as well in case one of you have seen this problem.

By the way... Thanks to Kevin for the printf utility code... For the half hour it worked, it worked really well!

I will post here if I get good feedback from the SFE site.

I've never had a problem bringing up the configuration screen. Hyperterm, umm..., has problems. Can you try another terminal program? I use Van Dyke's SecureCRT and haven't had any problems. I used it just this morning for a kick-off class. I would just send an e-mail to Nathan at SparkFun and ask him directly. He's a good guy (and FIRST alumnus too) and will get back to you promply.

-Kevin

Re: New Serial Port Driver

Quote:

Originally Posted by Kevin Watson

Kevin,

Thanks for your reply... I dusted off my Visual Studio and compiled the Visual Basic program VBTerm.vbp (from the MSDN library). Ran VBTerm and can get into the SMiRFv2 config... So far, so good... I haven't got the pair to recognize each other yet ("Remote Configuration Change Failed!"), I'm making progress...

[EDIT] Update: Everything is working fine now that Hyperterminal is not in the loop. Thanks again.[/EDIT]

Thanks for your help.

Re: New Serial Port Driver

Sorry for a Stupid question;

I have added the printf.c/.h and the serial.c/.h (or whatever its called) to last years code. I added the following line to my user_routines (we call ours user_routine_1):

printf("hello world");

and got a syntax error.

then I added:

stdout = TWO;
printf("hello world");

and still got a syntax error, but on the printf line, not the stdout line.

Help

Re: New Serial Port Driver

#include, not include, DUH

Re: New Serial Port Driver

Ok, a question for Mr. Watson,

in your printf.c file there is the function parsing. What screen were you using when you parsed these.

I ask because while looking at the website you linked to, I was intrigued by the large letter screen, but I assume I would have to re parse?