Does reading from the serial port work?

[Alan Anderson]

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?

[BradAMiller]

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.

[lynca]

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

[Alan Anderson]

Originally Posted by lynca

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

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?

[lynca]

Sorry about the rather vague post,

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

[Alan Anderson]

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?

[Kingofl337]

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.

[Alan Anderson]

Originally Posted by Kingofl337

easyC's terminal window doesn't accept data.

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.)

[Kingofl337]

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

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 ( "\n" ) ;
                        }
                        else
                        {
                              PrintToScreen ( "%d" , byte ) ;
                        }
                  }
            }
      }
}

[Alan Anderson]

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?

[Kingofl337]

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

[Alan Anderson]

Originally Posted by Kingofl337

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

This for line contains no magic I just threw this together in a rush.

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.

[Kingofl337]

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.

[Alan Anderson]

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.

[Alan Anderson]

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.