BOOSTXL-DRV8323RS With DRV8323R and Teensy 4.0

Anyone willing to collaborate / help on making it work with SimpleFOC?

I have ordered the evaluation kit as part of an internal dev effort.

I saw across the board some mention DRV8323R but nothing concrete.

Since it’s an evaluation board, hooking up a 3-rd party MCU is trivial. I usually go for Teensy 4.0.

Naturally the code / mods will be made public.

Intended HW/SW stack:

Teensy 4.0
AS5047P-Hall sensor or simple Honeywell 3-Hall sensors
Motor is simple 3-Hall Sensored or AS5047P-Hall Sensored
SimpleFOC/Arduino IDE
Win2019 Server Dev environment

If needed, I have access to industrial grade CAD design, 3D printing, as well as PCB design and fabrication. Hope we won’t need it ($$$$$).


Hi Valentine,

I would be very happy to help in ways that I can - I think I can be of good help on the software/driver side. On the hardware side I’d like to learn more about higher powered ESC designs. :slight_smile:

What would be your ultimate goal? To create a hardware design compatible with SimpleFOC and based on the DRV8323R?



Hi @Valentine,

Truly interested in the result you can get. This DRV is one of the ones that I considered for a design and finally I opted to use the DRV8305 since I had no references of any design that had used DRV8323RS

@runger ,

That is correct. I have evaluated a number of boards (btw, o-drive failed :face_with_symbols_over_mouth: )

The end design would be rather strange. Small footprint, high-powered dual-MCU board. Dedicated MCU for driving the motor and another for comms+physics. Loading comms and external physics and other sensors on top of SimpleFOC (or any other driver algorithm) by coding “stuff” inside the loop while moving the motor AND receiving telemetry at the same time (especially if some telemetry is interrupt driven) creates high risk which makes it unsuitable for critical tasks. The two MCUs will communicate with each other. This current effort is to select a driver to move the mosfets, I’ve converged on 8323R. If I make it work, next step is to frankenstein a bolt-on board with two teensies (or two whatever, not constrained to Teensy) as a POC where I pick a high level external protocol to talk with the logic MCU, which will talk to the motor MCU.

I don’t think it is strange at all… it’s the kind of design I’m slowly working towards, although I don’t think I’m as far along as you in the journey yet :slight_smile:

I agree completely with the need to separate the higher level control from the motor driving, I arrived at the same conclusion. I think there’s a lot you can do with ESP32 and presumably the new RP2040 - as they are dual core. And the more you can offload to dedicated peripherals and driver chips etc, the more headroom you have on the MCU, of course. But in the end you just don’t want any interference with the FOC driving, especially for higher speeds. So a 2-MCU design makes perfect sense to me.

Why not go directly to RaspiPi as the second “MCU”? I was thinking about that, but I come to the conclusion that:

  1. there is still quite a need for low level stuff (e.g. reading sensors, controlling LEDs, CAN-bus, etc…) beyond the motor driver. RaspiPi is very cool, but not really that low-level
  2. it uses waaay more power
  3. it would be hard to integrate on a motor driver PCB. and a “Hat” solution would be awkward (and big).

Have you taken a look at the Arduino Portenta H7? I know it’s expensive, but it has a powerful STM32H747 chip - which has a M7 and an M4 core on the same chip. There’s a breakout board for it now, which makes it actually useable for prototyping.

But may I ask why you would want a second MCU on each motor board? Almost all robots need more than one motor - would you have physics calculations to do on each motor seperately? Or do you plan for a main dual-mcu controller, and separate “satellite” controllers, perhaps with only one MCU, for the other motors?

Coding user-space is not mission critical. RPi is running plain Linux underneath. You don’t really have control. Also it cannot be PCB-ed on the board. RPI was a no-go from the beginning. I spoke at length with a PhD who worked embedded design for a certain corporation that shall not be named. RPi targets a completely different segment. I am assuming you talk RPi 4 for example.

That’s comparable to a Teensy’s 4.0 MCU. Both are M7. If I overclock, the teensy will beat it for the cost of a heat-sink. I can get 5 teensies and heat-sinks for that price.

Correct. Plus once you have a “Director” you can stack extra motor MCUs connected to the same director and you talk only to the Director. If you have a device (i don’t like to call it a robot that’s a misnomer) with say 4 groups of independently controlled manipulators, each manipulator is say 6 DOF, you don’t want to control all 24 motors real time, just delegate tasks to each of the 4 directors and receive back telemetry for high level functions. The directors will talk to each other completing the task while the main processor does high level logic (am I really going in the right direction) while the four directors perform the repetitive task of “going in the direction”. One of the manipulators fail? Cut it out and keep moving. Divide and conquer.

I am modifying the design. Unfortunately due to silicon shortage some of the parts are on back-order well into 2022. The new design is temporarily using 8302 driver, some mysterious Chinese dual-mosfet [HSCA2030 HuaShuo Dual N-Channel Fast Switching MOSFET] whose only good thing is that it’s stocked :frowning: and an allegro ACS780xLR inline current sensor. The MCU is probably STM32F4xx, or whatever is in stock. The dual-MCU design will be achieved by stackable driver boards with a back-plane board and canbus comm.

I will post the progress.