Does reading from the serial port work?

With a fresh crop of beginning programmers on our team this year, we decided EasyC was what we’d use. Alas, a lot of my accumulated tools and tricks didn’t quite make the transition, and I’m trying to reimplement a few of them.

Specifically, I want to implement something like the menus in Kevin Watson’s “Bells & Whistles” camera code last year. I’ve found references to ReadSerialPortOne() and tried to use it, but it doesn’t seem to work. Here’s the code I put in a fresh OperatorControl function:


unsigned char keypress;
keypress = ReadSerialPortOne();
if (keypress != 0)
{
   WriteSerialPortOne(keypress);
}

I expect that to echo anything I type at the terminal. What I get is nothing. I’ve tried HyperTerminal instead of the EasyC Pro Terminal window, with no change. I know the terminal itself is working, as I can see the IFI> prompt show up when I reset the Robot Controller. I have the RC and OI tethered. While trying to figure out what wasn’t working, I added a timer and called WriteSerialPortOne(65) every 100 milliseconds, and saw an “A” show up ten times a second, so I know the code is running.

What am I doing wrong?

Alan -

I’m at home and don’t have access to a robot controller here. But, one question… were you using the IFI loader terminal window or the easyC terminal window to try to talk to the serial ports? I’m wondering if the easyC version will listen for keyboard input.

You might try the other one. In any case I can give it a try sometime tomorrow to see what’s up. I know that the code works, at least for port 2 because all the camera routines use reading and writing to the serial ports.

Have you tried a while loop instead of and if just too make sure it is not a timing problem.

I’ve done a custom echo terminal and usually I start with a while() loop that constantly reads the serial port and then writes back when the input is none null. If the while loop works, you might want to consider putting timestamps to see if there is a latency wait before checking the ReadSerialPort

Can you rephrase that? I can’t tell what you mean.

As I understand it, the OperatorControl() function is already inside a while loop.

I’ve done a custom echo terminal and usually I start with a while() loop that constantly reads the serial port and then writes back when the input is none null.

I thought that’s exactly what I did (assuming you mean “not zero” where you wrote “none null”).

If the while loop works, you might want to consider putting timestamps to see if there is a latency wait before checking the ReadSerialPort

Could you elaborate on that?

Sorry about the rather vague post,

I understand now that you are running in the OperatorControl while loop,
that was my original question.

I’m still not getting what I expect from ReadSerialPortOne(). It always returns zero, no matter how I try to send characters from the computer to the program port. Can someone point me at some working code, so I can rule out issues with hardware or terminal emulation software on the PC?

easyC’s terminal window doesn’t accept data. I’ll make a program and check it out I had it working a few months ago.

What does it do? I would expect the purpose of a “terminal window” would be to act like a terminal, i.e. to send typed data and display received data. But that’s not important right now, since I’ve been using HyperTerminal and other programs to send characters out the serial port with no effect on the ReadSerialPortOne() result.

I look forward to seeing EasyC serial port code that’s supposed to work, so I can figure out what I’m doing wrong. (I just hope that what I’m doing wrong isn’t something silly like expecting things to act in a way other than how they are designed.)

Here you go this is the basics. If you want it to echo the actual character used use WriteSerialPortOne(unsigned char). Other wise you get the ascii byte code. If you compare byte == “X” for instance it will work.

**EDIT: DON’T USE THIS, IT DOESN’T WORK, I WAS A DOLT! SEE BELOW ** :frowning:


void main ( void )
{
      unsigned char byteswaiting; 
      unsigned char byte; 
      unsigned char x; 

      while ( 1 )
      {
            byteswaiting =  GetSerialPort1ByteCount( );
            if ( byteswaiting != 0 )
            {
                  PrintToScreen ( "Output: " ) ;
                  for ( x = 0 ; byteswaiting == x ; x++ )
                  {
                        byte = ReadSerialPortOne( );
                        if ( byte == 13 )
                        {
                              PrintToScreen ( "
" ) ;
                        }
                        else
                        {
                              PrintToScreen ( "%d" , byte ) ;
                        }
                  }
            }
      }
}



Whoa, this is a lot weirder than I expected.

Is there some “magic” involved in this line?


for ( x = byteswaiting ; byteswaiting == x ; x++ )

Its purpose is not at all obvious. Regardless of the value of byteswaiting, the code in braces following the line will be executed exactly once. The variable x appears to have no function inside the braces. I’ll do it that way, but I have to assume there’s something happening behind the scenes that isn’t being explained.

I was always told that the %d format specifier expects an int variable, and that you had to cast chars with (int) in order to avoid problems. Is this not the case with EasyC’s PrintToScreen() function?

I’m also confused by the fact that you’ve named the function main(). I thought that name was already taken. Is this another “magic” feature of EasyC that does something undocumented, or am I completely misunderstanding what’s going on here?

for ( x = 0 ; byteswaiting == x ; x++ )

This for line contains no magic I just threw this together in a rush. I’m not going to lie to you Alan, while I’m an ok programmer most of what I know has been through trial and error, research PID for instance and web programming html/php/cgi. I just bought a Microchip PIC kit to learn more about the lower lever programming.

In PrintToScreen %d does expect a integer, I’ve never had a issue using %d with int or char without casting data types. I have have had problems with mixing data types for instance %ld with a int or %d with long.

My function is in main() because that was the only function of the whole program. I wrote it in VEX without a competition template in FRC it’s called a Standalone Project in the File menu.

I had a hard time making it work and Brad sent me a program like a year
ago to me and this is how it worked for the most part.

1.) Call GetSerialPort1ByteCount( ) to see if there are any bytes waiting in the buffer.

 byteswaiting =  GetSerialPort1ByteCount( );
            if ( byteswaiting != 0 )

2.) Create a for loop to empty out the buffer and load it into a array, struct,
or single variable

for ( x = 0 ; byteswaiting == x ; x++ )
                  {
                        byte = ReadSerialPortOne( );

3.) Do as you will with the data you just received
In this case check for return or print the ASCII code for the keypressed

Did you test the program you posted? Does it do what you think it’s supposed to? If there’s nothing unobvious about this line of code, then it looks to me like its only effect is to waste time. If you intended for this example to help me, I must disappoint you. It raises more questions than it answers.

I won’t apologize for sounding frustrated here, because I am frustrated.

My function is in main() because that was the only function of the whole program. I wrote it in VEX without a competition template in FRC it’s called a Standalone Project in the File menu.

I’m afraid that’s not going to be very useful for me. I’m not trying to communicate with a VEX system, and my goal is to use serial port I/O in a competition program.

I don’t yet fully regret making the decision to use EasyC this year, but I’m getting close. As I keep finding out, simple stuff is simple, but anything that doesn’t fit the predefined blocks seems several times more difficult than straight C coding. If I keep running into these roadblocks I’m going to have to tell our software group to throw away everything we’ve done so far and go back to the MPLAB environment before the month is out.

I did test it and it did work with no issues. The serial port works the same in FRC/VEX and Competition vs Non-Competition.

FOUL!

You’ve edited the code you posted originally, without telling anyone you did it. Now I think I see the purpose of the for loop. Before you changed it, it would obviously not have worked as intended. It still looks wrong, but in a completely different way. Is it perhaps supposed to be this?


for ( x = 0 ; x < byteswaiting; x++ )

I don’t believe you did it on purpose, but I feel like I’ve been tricked into quoting the modified line and commenting on it as if it were still the original.

So if I want to test this in an FRC competition project, I can just put it in the OperatorControl() function, right? And if I do that, it doesn’t need the outer while(), right? I’ll be trying this out first thing tomorrow when the team meets again.

I tried the example code provided, and never saw GetSerialPort1ByteCount( ) return a nonzero value. I ran equivalent code that I wrote and compiled using MPLab, and it worked exactly as I expected.

I’m done with EasyC. I can’t do what I want using it.

So, everyone knows I screwed up on this one by rushing. It shows what happens with a “QUICK” fix. My mistake here was my own and not a reflection on intelitek or as we don’t even support WPILIB functions that are not in the tree.

My orginal For Loop was:

 for ( x = byteswaiting ; byteswaiting == x ; x++) 

While this printed a byte at a time it was only by shear luck. After Alan made a comment I quickly changed it to:

 for ( x = 0 ; byteswaiting == x ; x++) 

I was not trying to hide anything as it says in chief I have edited the post. The trouble is this doesn’t work either hence Alan’s frustration. I just didn’t see it and didn’t test this “QUICK” fix.

Now having had time to look at it again. I saw my problem and have fixed
it. This version will accept 4 keystrokes “bytes” and then print them to screen. Please let me know if you see an issue. The function must be call
in a while loop and added to userincludes.h.

serial_read.c (1.73 KB)


serial_read.c (1.73 KB)

Well if it’s any consolation, one of my students was trying to interface a custom vision board using EasyC and we’ve been following this thread. We’ve got ours working last night. We used an example C File, customized it some from a vendor and managed to read bytes coming from the custom camera controller. We’ll let me correct that, my student manage to get it to work, not “we”. He is using the TTL rs-232 port on the RC to a DB-9 port on the camera board. So far all is well.

EasyC has been good to us, sorry it hasn’t worked out so good for you. However knowing you Alan, I can understand you’d like more freedom in coding your custom code. Our programming team has found Mr. Millers WPILIB pdf handy, we’ve read it through and through and understand what built in functions we can use. We’ve tried to use what is available. Our custom RS-232 interface parser was the first time we added our own C File to EasyC, and included it for compile. Doing it this way, gave the “old” school feel and allowed for the flexibility of customized functions we needed to create to interface to the vision board. Maybe you can take the same approach. Write your own custom C Files outside EasyC in notepad or I prefer NotePad + +, and include your header files etc, but allow the C Code blocks for your beginner programs and let yourself and advance programmers code in the C File with custom functions.

Of course there will be some overhead as if you’re doing your own functions you’re not using utilizing the WPILIB.

Anyway, I just wanted to give our perspective on EasyC. I am sure we could share what we have, but I’ll have to check with Nathan first if he wants to allow it now (week 3 in build season). Nathan: our master programmer, which BTY, I am in dear now to chant “Nathan is the man”, a young bright home schooler I hope you can chat with some day.

Chris - THRUST : 1501 : Huntington, Indiana