I'm trying to read from a sensor that sends ASCII data, with each packet delimited by a new line. I created a while loop with a serial port read in it. Based on my reading of the serial port docs, if I set a termination character of a new line, it would wait until the newline was received and then give me the full set of data. This is all working, however, when I do this, I see CPU usage of around 50% (as reported by the driver station). I've disabled everything else, and still see 50% CPU usage.
I've tried adding a wait to my loop, and it doesn't change the CPU usage. I've played with the baud rate, and it doesn't seem to change anything. Is the serial port really inefficient on the cRIO?
I wouldn't expect just a serial port yo use 50% CPU usage. Do you see the same CPU usage if you take your serial code out of the FRC framework and just run it by itself on the cRIO - if you do this you will need to monitor the CPU usage using another tool such as the Distributed System Manager (which should be installed with LabVIEW Real-Time). In the FRC framework are you reading the serial port in a loop parallel to the main execution of the framework or inline to the framework?
I had the serial port code in a parallel loop. I had actually made a seperate program like the FRC examples with just the driver station comm and saw the same result. I'll look into the Distributed System Manager.
The serial port is known to be more inefficient than expected on the cRIO-FRC due to it trying to exactly emulate the behavior of more standard seiral ports. Are you using the 8-slot cRIO-FRC?
I tested with a 4 slot cRIO and had the same result. I've attached a simplified example VI that shows the high CPU usage.
I could not get the distributed system manager to connect to the cRIO. I tried following the instructions here: http://www.ni.com/gettingstarted/setuphardware/compactrio/systemmanager.htm. After I add the system, it doesn't connect (but doesn't give any error messages). Is there anything else I need to do?
In order to free up CPU usage, check how many bytes are available to read and only perform your read once you get up to a certain number of bytes. Checking how many bytes are available takes less computational energy than reading the bytes.
Also, loop timing really helps! Be sure to add a delay in your loop.
When I first ran your code, my CPU was railing at 100%. I added some loop timing and logic for when to read the bytes and the CPU was down to 20% See the attached VI and let me know if these changes are helpful to you.
In order to see these statistics in the Distributed System Manager, make sure you have installed the System Update Service on your cRIO. You should also be able to monitor CPU usage from the Driver Station under Charts.
I had assumed that it would not chew CPU time while waiting for data (like the UDP VIs). That appears to be false.
I added a delay and a check for bytes availible before reading. When my sensor sends data at low data rates, this significantly decreases CPU usage. However, when it sends at the maximum data rate (100 hz), I still see CPU usage of 50%. I set the delay to 5 ms, so that I can handle a case where I get several packets in the buffer and need to get them cleared faster then incoming packets. I haven't done a detail profile of how much time it's still spending in the read, but my assumption is that it is spending more then 5ms in the read to read 34 bytes, based on the CPU usage.
Not sure where you got with this, but when I implemented the Black Jaguar serial code, I decided to skip the library code implementation for sending and talk to the peripheral bare metal because of high CPU load. You can see that here:
Given that you were mostly having issues with receive, this may not really help you. Just FYI.
I gave up on the serial port this year. I'll try again with the RoboRIO. I noticed that people on the FIRST Forums have reported serial port issues with both Java and C++ too.
firstforge says I don't have access to that file when I use your link. When I start at the project and navigate to it, it works, however. Wierd.