RBE3002 Firmware Process Flow
From WPI Automation and Interventional Medicine (AIM) Robotics Laboratory
Contents |
Initialization
The first function in user code to be called by the Bowler Framework is the UserInit() found in InitializationCallbacks. This function is called once before the cooperative main loop is entered, but after the bowler stack is initiated. Be careful to never change the UART 0 settings or the timer 1 settings, as these are used by the bowler stack. UART 1 is used as a print terminal in debug mode.
Main
You may have noticed that there is a Main() missing out of the firmware code. This is intentional. The main must have a few functions running in a certain order, one of which is a callback to your code. This call back is the CoOpCallback. That function (UserRun()) will be called by main every iteration of the main loop. Since you do not know how long that will take, there is a scheduler framework set up.
Scheduler
The scheduler is a set of functions that allow you to do a few things that would otherwise not be possible. The first is it allows you to set up a set of 6 time steps, each taking 5ms, that will be executed close to real-time. I use the qualifier close, because if your running in debug mode or have some code that takes too long, it will not force you into real time.
The scheduler also provides a function (GetTimeMs()) that will return a float of the ms since the device started. Be careful to check for roll-over states on this value when you use it for extended periods of time.
* SchedulerGetStep * @param chan THis is the channel to test if it is time for it to run. This value is from 0-5 * @return This is a boolean that returns true if the channel is scheduled to run. * The time slices are 5ms each, and there are 6 of them in total. That means each slice runs every 30Ms. * If a time slice takes more then 10ms to execute, the next time slice WILL NOT RUN * Basic architecture is 6 blocks of 5 Ms, from 0-5, 5-10, 10-15, 15-20, 20-25, and 25-30, then loops over. * The GetStep function will check if it is within that channel's time slice AND that slice has not run yet this cycle. * If it is in the time slice and it has not run, the function returns true * If it is in the time slice, and the slice has run, the it returns false * If it is not in the time slice, it returns false
Packet Events
This last section holds the functions that the Bowler Framework calls when it gets a packet with an RPC that is not a default RPC. You will be expected to process packets and return from this function in less then 1ms (NO WAITING!!). This means you will need to be creative in accessing information that takes time to collect (like sweeping a sensor).
