View Single Post
  #3   Spotlight this post!  
Unread 25-03-2014, 21:19
Greg McKaskle Greg McKaskle is offline
Registered User
FRC #2468 (Team NI & Appreciate)
 
Join Date: Apr 2008
Rookie Year: 2008
Location: Austin, TX
Posts: 4,751
Greg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond repute
Re: Real time versus normal timing

To reenforce what Kevin said .. the cRIO product allows for a combination of hard and soft realtime operation. But for FRC, that division has already been defined, and compiled into the image. Until the FPGA tools better support partial reconfiguration, it isn't really feasible to allow for FPGA modification and ensure safety of outputs.

So in the RT palette, the timers and such are referring to realtime implementation of those concepts. These will attempt to minimize latency and jitter at the expense of efficiency. They are more likely to use spin-lock instead of messaging or signaling. They are more likely to run at elevated priorities.

What I'd suggest is identifying the elements of your code that are causing your CPU usage to be high. They may not be the same as the ones causing the jitter in timing. It would also be helpful for you to describe your usage of CAN. What CAN messages are being sent to how many controllers? You may also want to measure just the CAN nodes and see if they are the big pole in the tent.

Greg McKaskle
Reply With Quote