View Single Post
  #234   Spotlight this post!  
Unread 24-04-2008, 17:16
dcbrown dcbrown is offline
Registered User
AKA: Bud
no team
Team Role: Mentor
 
Join Date: Jan 2005
Rookie Year: 2005
Location: Hollis,NH
Posts: 236
dcbrown has much to be proud ofdcbrown has much to be proud ofdcbrown has much to be proud ofdcbrown has much to be proud ofdcbrown has much to be proud ofdcbrown has much to be proud ofdcbrown has much to be proud ofdcbrown has much to be proud ofdcbrown has much to be proud ofdcbrown has much to be proud of
Re: NEW 2009 Control System Released

If I understand correctly, to eliminate software from having to deal with hardware latency issues, the majority of the software that was implemented as an ISR within the PIC is implemented within the FPGA.

So for example, a quad encoder ISR on the PIC that had phase A/B input and tracked a count would be implemented within the FPGA and could have the added value of dealing with all four phase transitions on multiple encoders. Each encoder would have its own dedicated FGPA hardware to process it. The resulting exported data would be a h/w register with the current count.

Or the GTS sensor which had major latency issues a couple years ago due to the small time differential between forward and reverse pulse widths (<50us)? Implement the servicing in hardware and the software latency issue is no longer a problem, a good count can be maintained.

By committing the time critical processing to hardware, this eliminates the need for interrupts to service the hardware events and makes time sliced multitasksing that polls & processes the data viable.

You can then create independent tasks that poll, combine, and process the data for each of the various devices you want to use. With fast task switching time and task priorities of the RT/OS, the different data flow processing within the different task trees appears to be simultaneous. So, you could have one set of independent tasks integrating sensor information in an inertial navigation system to determine position and a different set of tasks "simultaneously" working on motor control, and a third set of tasks operating on operator input for control of a manipulator.

???

Not sure I like it, but I can see how you'd shift your design viewpoint to program such a system. For example, take the polling of each device out of the main interrupt routine of the PIC and create a separate polling task tree for each, then schedule them to run every so often as needed to initiate processing of the data...

The biggest plus is also the biggest minus:

+ the hardware servicing is committed to the FPGA - once the bugs are worked out it will work for all teams the same way.

- the hardware servicing is committed to the FPGA - if you want to tweak the servicing of the hardware or integrate data differently or add some weird/unusual sensor that isn't already allowed for, you're pretty much stuck as the FGPA is off-limits to teams. The whole lower level hardware layer has been abstracted and put off limits as a result.

Not a big minus. (I could whine about this, but it is what it is - learn, adapt, overcome.) I'll miss it, but can still teach how it works at the lowest levels.

Ok, so I'm babbling... Traditionally, interrupts are used for servicing hardware events, for time-based integration of data, and initiating event processing due to some hardware or software event (IR sensor detects wall in front of robot, stop!?!) The first two are very time critical, the last is mostly a convience of the interrupt structure and is less time critical.

The FPGA seems to address the first, and the 2nd *IF* that integration is implemented in the FPGA too, and event processing can be simulated by running independent polling tasks on a fixed schedule. The result is not exactly the same, but is probably close enough to work ok. I'm beginning to wonder if the new processor is fast enough

Last edited by dcbrown : 24-04-2008 at 17:19.
Reply With Quote