4 ms·

The encoder / motor controller logic is a bit more complex than that. Because the encoders are analog / digital hybrid they generate far more data than standard

The encoder / motor controller logic is a bit more complex than that. Because the encoders are analog / digital hybrid they generate far more data than standard quadrature encoders. The FPGA is doing huge table lookups, ATAN2, PID, Dithering the motor driver, and all of that at 5 MHz end to end, so we have a 200ns response.

chaboud 8y ago
How huge is huge? The rest of the chain sounds pretty straightforward, even at 5MHz. That's not to say that an FPGA is wrong for the application, but nothing in that list screams "must use FPGA" to me. However, the whole program screams "get to market, then iterate" to me, which is a very effective way to move forward with a product like that. Note: I've shipped products doing continuous signal processing on DSP, GPU, CPU, SoC, and FPGA. (MCU eventually... Give me time.) I did the mental swag on the described processing chain... Out of curiosity, how big is your FPGA?
- CamperBob2 8y ago
  It could probably be handled by the realtime cores on the BeagleBone Black's SoC, or perhaps by an XMOS part, but if someone already knows how to develop for FPGAs there's not much of an incentive to try to shoehorn the task onto a microcontroller. Anything that involves reading from moderately-to-insanely fast ADCs is a natural FPGA application, especially if multiple channels are involved.
  - chaboud 8y ago
    I hear that. I'm working on multi-channel ADC hardware right now, and there is no way that we're going to use an FPGA (per unit cost). At my last gig, we used FPGA's for several low-volume products.
    - cbames89 8y ago
      One of the founders wrote a FPGA language. I suspect it's the tool the team knows the best, but may not be the most price optimized. I think that's fine for now, especially since it's still one of the most affordable arms available.

4 ms·

The encoder / motor controller logic is a bit more complex than that. Because the encoders are analog / digital hybrid they generate far more data than standard

by JamesMNewton 8y ago

chaboud 8y ago
How huge is huge? The rest of the chain sounds pretty straightforward, even at 5MHz. That's not to say that an FPGA is wrong for the application, but nothing in that list screams "must use FPGA" to me. However, the whole program screams "get to market, then iterate" to me, which is a very effective way to move forward with a product like that. Note: I've shipped products doing continuous signal processing on DSP, GPU, CPU, SoC, and FPGA. (MCU eventually... Give me time.) I did the mental swag on the described processing chain... Out of curiosity, how big is your FPGA?
- CamperBob2 8y ago
  It could probably be handled by the realtime cores on the BeagleBone Black's SoC, or perhaps by an XMOS part, but if someone already knows how to develop for FPGAs there's not much of an incentive to try to shoehorn the task onto a microcontroller. Anything that involves reading from moderately-to-insanely fast ADCs is a natural FPGA application, especially if multiple channels are involved.
  - chaboud 8y ago
    I hear that. I'm working on multi-channel ADC hardware right now, and there is no way that we're going to use an FPGA (per unit cost). At my last gig, we used FPGA's for several low-volume products.
    - cbames89 8y ago
      One of the founders wrote a FPGA language. I suspect it's the tool the team knows the best, but may not be the most price optimized. I think that's fine for now, especially since it's still one of the most affordable arms available.