Thread: FRC hardware design
View Single Post
  #1   Spotlight this post!  
Unread 22-08-2005, 08:28
Gdeaver Gdeaver is offline
Registered User
FRC #1640
Team Role: Mentor
  
Join Date: Mar 2004
Rookie Year: 2001
Location: West Chester, Pa.
Posts: 1,363
Gdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond repute
FRC hardware design
I've been looking at the IFI FRC hardware and software and wonder if anybody else has questioned why they designed it as they did. What I don't like about the current programming model is the 2 threads of execution. We have the main loop and the fast user loop. This ties up a timer and results in a high priority interrupt. The 2 things that drive this are the processor to processor communications and the servo output refresh. The other thing is the I2c and SPi port are not available for our use. There are allot of sensors that could use this port. The whole programing model just seams to complex for what it has to do. I bet the easy c people had a good time making sure they could model it.
I've looked at some other robot controller designs. Nobody else has gone down this path that I have seen. Most are a master proc with a coprocessor bus.
Wouldn't the hardware software model be easier if the FRC had one main processor and a buss (rs485,can,rs232, etc.) There are 2 async. ports on the current processor. One port could be used for the programming and tether. The other would be for the coproc buss. There are several companies that have programed pic 16 or 17's as servo chips with 8 or 9 servo outputs. They are controlled by simple 3 or 4 byte commands and can be cascaded. The main proc doesn't have to generate the pulses or worry about timing. This would also open up the possibility of using a motor drive coprocessor with feed back Incorporated in the coprocessor. The other thing that would need to be addressed is the modem. If the modem has built in CRC error checking the main proc could just form the packets and send and receive them async. If necessary another small pick could be added to make a modem coprocessor. This would allow future coprocs to be added to the buss for other functions and the MSSP would be available for sensors. This would allow a single threaded control structure and I believe simplify the programming and make the FRC more expandable. Any body else have an opinion on this. Maybe there is a good reason IFI did what they did but, I don't understand why.