Difference between revisions of "Talk:Optical tracking system for amateur rockets"

From ElphelWiki
Jump to: navigation, search
 
Line 4: Line 4:
  
 
We have some un-populated 10369 boards that you may use for prototyping.--[[User:Andrey.filippov|Andrey.filippov]] 17:47, 12 March 2009 (CDT)
 
We have some un-populated 10369 boards that you may use for prototyping.--[[User:Andrey.filippov|Andrey.filippov]] 17:47, 12 March 2009 (CDT)
 +
 +
Hi Andrey,
 +
 +
Sure, using the camera CPU and FPGA can be the ultimate goal in integration.
 +
But I have some concerns about the real-time capability of the CPU running
 +
a general purpose Linux.
 +
 +
 +
I'm the most capable member of the team concerning hardware and low-level
 +
software and I must admit I'm a little afraid by the idea of developing FPGA
 +
code, it's something I've never done. And, in the same time, it is quite tempting!
 +
 +
 +
About the 10 FPGA available GPIO, it may be just enough because we need :
 +
- 2 x 2 inputs for motor quadrature decoders,
 +
- 2 x 3 outputs for H-bridge driving (PWM, 2 enables 1 for each half bridge)
 +
and, in this case, I make the assumption the GND is available.
 +
 +
 +
Well, while writing this comment, I must admit your proposition seems to be the way
 +
to go.
 +
First step would be full software handling, but meaning driver development for quadrature
 +
decoder.
 +
Then little by little replacing software modules by FPGA module.
 +
 +
 +
I'll discuss about this solution with the team.

Revision as of 07:41, 14 March 2009

Did you consider using camera CPU to control H-bridges? With 10369 board you can use any of i2c or usb to control the motors. There are several GP I/O going directly to the FPGA available, so you can flip those bits by software initially and then add some FPGA module (i.e. PWM) so these outputs will be run w/o CPU overhead.

It is also possible to design custom extension board to sit right on the 10353 board - in that case you have all the 12 FPGA I/O available (still it is better leave 2 of them for i2c that is used to read board identification EEPROM

We have some un-populated 10369 boards that you may use for prototyping.--Andrey.filippov 17:47, 12 March 2009 (CDT)

Hi Andrey,

Sure, using the camera CPU and FPGA can be the ultimate goal in integration. But I have some concerns about the real-time capability of the CPU running a general purpose Linux.


I'm the most capable member of the team concerning hardware and low-level software and I must admit I'm a little afraid by the idea of developing FPGA code, it's something I've never done. And, in the same time, it is quite tempting!


About the 10 FPGA available GPIO, it may be just enough because we need :

- 2 x 2 inputs for motor quadrature decoders,
- 2 x 3 outputs for H-bridge driving (PWM, 2 enables 1 for each half bridge)

and, in this case, I make the assumption the GND is available.


Well, while writing this comment, I must admit your proposition seems to be the way to go. First step would be full software handling, but meaning driver development for quadrature decoder. Then little by little replacing software modules by FPGA module.


I'll discuss about this solution with the team.