Are there any less expensive alternatives to STM32F40X? How about F3 or F2 series? Yes these are not as fast as F4,have less memory, but...they are less expensive.
The F2 cannot work, it is based on a ARM Cortex M3 chip design. So only options are F3 & F4.
What is the price of an STM32F4? 10EUR? So in order to save a few bucks you want to potentially create a different software branch with pin mappings plus the risk that something is not working today or tomorrow? And that even assumes the F3 you are using has the same basic capabilities, FPU support, # of ADC converters, ....
So yes, if you plan so sell 10'000 of your hardware boards, then it might make sense but else....
As you see, from my experience I hate it when boards have a limited MCU. You want to do something later...but can't.
No,they are not, but I did not say anything about power. For example, MINI4 is not exactly for a 3kW motor. Not everything needs power. And it is easy to redesign the power stage. A bit harder to deal with microcontroller.
Generally it's near impossible to port VESC to other MCUs in general, its dependent on chibiOS which does not seem to get ported to many MCUs. Secondly much of the VESC motor code is intertwined with stm32f405 specific code. I have been thinking about this a little, there's various projects where the STM32F405 presents a limitation, either lacking features such as sigma-delta support, high res PWM or in other cases its overly expensive compared to other MCU options.
While porting the entire VESC + chibiOS is a huge task, perhaps making a lightweight portable version of the core VESC features could be done? I have seen a similar solution in example projects from some other MCU manufacturers. The sensorless observer, control loops etc, were abstracted into modules with no MCU specific code. All the PWM, ADC and interrupt settings were kept separate from FOC code. Some of the VESC is also very complex in order to make it very user friendly, for heavily customized projects being able to flash firmware via VESC tool, unused BLDC code and many other things are probably largely not needed.
A rough estimation of code that could probably be turned into modules abstracted from MCU specific code
-Current control code that converts raw current sense into the battery and motor current readings as well as imposing separate motor and battery limits
- Control loops for RPM and current modes.
- A basic API to enable limited communication with VESC tool.
Where things get a little complicated is determining which features rely heavily on the chibiOS RTOS, I know firmware flashing and USB communication rely on it but I'm unsure how much of the actual motor control code uses the multitasking aspects. Additionally there's not much documentation for the VESC code and few other comparable open source projects to study it would probably require Benjamin having time to answer some questions about certain sections. There would still be many MCU requirements, 3x linked PWM with centre aligned mode+ ability to send interrupts, 2x ADC and a FPU, porting it would involve configuring all those settings in addition to anything needing clock settings. However I have found most MCUs you would want to use for motor control have code examples set up for this, its the sensorless control, control loops and motor detection algos they generally refuse to share.
No, the instaspin sensorless code is hidden in a read only part of certain Ti MCUs. It's annoying as they only offer a few of the lowest end c2000 MCUs with the instaspin rom. Matlab has a portable FOC thing for many MCUs but it's basically just a collection of MCU agnostic code that you join up with a GUI but it's basic compared to the VESC software without motor detection and many other features.
There's no good option to start with if you're trying make a FOC controller, if there were a series of modules based off the VESC as I explained above they could be used to rapidly develop controllers on anything that meets the hardware requirements.
Not possible unfortunately, different clockspeed and other minor hardware differences mean its not software compatible, a port would be relatively easy compared to some other MCUs but it would still take a significant amount of change to the code. Last time I checked there was no chibiOS port but I think I saw one exists now so it might have become simpler to do it.
Hi guys. hexakopter user asked me in this thread if it was possible to use the STM32F4 Discovery board, which has a STM32F407 MCU. The answer is yes: I've been able to program the board with the ST-Link utility the first time, and then via VESC Tool. You need to create a new hardware profile and select the pin assignment, with special care of not using pins that are already used in the board (for example, some pins are used for audio, IMU, etc. and even though they can be physically conected, you should not use them). More detailed info on that thread.
Regarding MCU families, as far as I know, the VESC code should run on every MCU on the F4 family. It uses ChibiOS (which is available on almost all ST MCUs) for most things. However, some specific parts of the code use the STM34F4xx peripheral library (things like ADC). My guess is that Benjamin needed more control and a lower level of programming that ChibiOS provides (which is a generic hardware abstraction layer for many different architectures). Things like ADC might be too generic in ChibiOS and VESC requires precise control of all conversion parameters. That's the reason why the code can't be easily ported to different families (e.g. F3, F2...). It would require significant effort to switch to the other library and an exhaustive analysis of needed hardware resources. I think it's not worth the effort, given the small difference in price.
If you use a STM32F4xx, you should be good to go. As I said, I'm prototyping on a STM32F407 and plan to make the final design with the STM32F405RGT6TR.
i found this thread and wanted to ask if anyone tried to use vesc with a STMF446. I thought it is possible to run on every F4 microcontroller. Is that right? Or do I have to change e.g. clock settings because it runs with 180Mhz?
Plenty of people use different MOSFET drivers and MOSFETs in their custom VESC-based ESCs. And considering that you need 6 or more MOSFETs, any savings you make by choosing different MOSFETs quickly gets multiplied. Savings on the MCU costs are usually eclipsed by the effort taken to port the very specific STM32F405 code to the new MCU.
Please feel free to port the code yourself if you feel that saving a couple of dollars is worth it.
The F2 cannot work, it is based on a ARM Cortex M3 chip design. So only options are F3 & F4.
What is the price of an STM32F4? 10EUR? So in order to save a few bucks you want to potentially create a different software branch with pin mappings plus the risk that something is not working today or tomorrow? And that even assumes the F3 you are using has the same basic capabilities, FPU support, # of ADC converters, ....
So yes, if you plan so sell 10'000 of your hardware boards, then it might make sense but else....
As you see, from my experience I hate it when boards have a limited MCU. You want to do something later...but can't.
Makes sense in most cases. Which means that VESC can't be used for relatively inexpensive products.
Thanks!
Inexpensive and 3kW brushless motors aren't really in the same category are they.
No,they are not, but I did not say anything about power. For example, MINI4 is not exactly for a 3kW motor. Not everything needs power. And it is easy to redesign the power stage. A bit harder to deal with microcontroller.
Generally it's near impossible to port VESC to other MCUs in general, its dependent on chibiOS which does not seem to get ported to many MCUs. Secondly much of the VESC motor code is intertwined with stm32f405 specific code. I have been thinking about this a little, there's various projects where the STM32F405 presents a limitation, either lacking features such as sigma-delta support, high res PWM or in other cases its overly expensive compared to other MCU options.
While porting the entire VESC + chibiOS is a huge task, perhaps making a lightweight portable version of the core VESC features could be done? I have seen a similar solution in example projects from some other MCU manufacturers. The sensorless observer, control loops etc, were abstracted into modules with no MCU specific code. All the PWM, ADC and interrupt settings were kept separate from FOC code. Some of the VESC is also very complex in order to make it very user friendly, for heavily customized projects being able to flash firmware via VESC tool, unused BLDC code and many other things are probably largely not needed.
A rough estimation of code that could probably be turned into modules abstracted from MCU specific code
- sensorless sliding mode observer + BEMF tracking and hall/encoder modes
- Motor detection code
-hall/encoder detection
-SVM (uncertain if this is MCU specific.)
-Current control code that converts raw current sense into the battery and motor current readings as well as imposing separate motor and battery limits
- Control loops for RPM and current modes.
- A basic API to enable limited communication with VESC tool.
Where things get a little complicated is determining which features rely heavily on the chibiOS RTOS, I know firmware flashing and USB communication rely on it but I'm unsure how much of the actual motor control code uses the multitasking aspects. Additionally there's not much documentation for the VESC code and few other comparable open source projects to study it would probably require Benjamin having time to answer some questions about certain sections. There would still be many MCU requirements, 3x linked PWM with centre aligned mode+ ability to send interrupts, 2x ADC and a FPU, porting it would involve configuring all those settings in addition to anything needing clock settings. However I have found most MCUs you would want to use for motor control have code examples set up for this, its the sensorless control, control loops and motor detection algos they generally refuse to share.
Isn't most of the sensorless and FOC algorithms taken from TI's InstaSPIN?
No, the instaspin sensorless code is hidden in a read only part of certain Ti MCUs. It's annoying as they only offer a few of the lowest end c2000 MCUs with the instaspin rom. Matlab has a portable FOC thing for many MCUs but it's basically just a collection of MCU agnostic code that you join up with a GUI but it's basic compared to the VESC software without motor detection and many other features.
There's no good option to start with if you're trying make a FOC controller, if there were a series of modules based off the VESC as I explained above they could be used to rapidly develop controllers on anything that meets the hardware requirements.
Not drop in replacement but with change to board STM32F446 should probably work and it's faster!
15/202 http://www.st.com/content/ccc/resource/technical/document/datasheet/65/c...
Not possible unfortunately, different clockspeed and other minor hardware differences mean its not software compatible, a port would be relatively easy compared to some other MCUs but it would still take a significant amount of change to the code. Last time I checked there was no chibiOS port but I think I saw one exists now so it might have become simpler to do it.
Hi guys. hexakopter user asked me in this thread if it was possible to use the STM32F4 Discovery board, which has a STM32F407 MCU. The answer is yes: I've been able to program the board with the ST-Link utility the first time, and then via VESC Tool. You need to create a new hardware profile and select the pin assignment, with special care of not using pins that are already used in the board (for example, some pins are used for audio, IMU, etc. and even though they can be physically conected, you should not use them). More detailed info on that thread.
Regarding MCU families, as far as I know, the VESC code should run on every MCU on the F4 family. It uses ChibiOS (which is available on almost all ST MCUs) for most things. However, some specific parts of the code use the STM34F4xx peripheral library (things like ADC). My guess is that Benjamin needed more control and a lower level of programming that ChibiOS provides (which is a generic hardware abstraction layer for many different architectures). Things like ADC might be too generic in ChibiOS and VESC requires precise control of all conversion parameters. That's the reason why the code can't be easily ported to different families (e.g. F3, F2...). It would require significant effort to switch to the other library and an exhaustive analysis of needed hardware resources. I think it's not worth the effort, given the small difference in price.
If you use a STM32F4xx, you should be good to go. As I said, I'm prototyping on a STM32F407 and plan to make the final design with the STM32F405RGT6TR.
Hello,
i found this thread and wanted to ask if anyone tried to use vesc with a STMF446. I thought it is possible to run on every F4 microcontroller. Is that right? Or do I have to change e.g. clock settings because it runs with 180Mhz?
see https://github.com/UNIMOC-Universal-Motor-Control/vesc-software. runs on f446
So it seems like the VESC software is tied to tools from ST for specific MCU's and will not port to other MCU's without modification.
I am new to the project so excuse my ignorance, but i was doing research on other brand MCU's specifically the Infineon's line
https://www.infineon.com/cms/en/product/microcontroller/embedded-power-i...
most include the MOSFET driver including charge pump and built in power regulator and they are inexpensive TLE9873QXW40 is $5 US (arrow)
also the infineon MOSFET's themselves are inexpensive and available in the 1-2 USD range (depending on current)
current BOM using ST parts and MOSFET's is much more expensive and requires more IC's than going with another vendor
so i guess my question is this project married to the ST line of products?
Thank you tecnologic! I will compare and try this.
@vFalcone Yes this software is for STM products. The compatible ones are specified in the code
Plenty of people use different MOSFET drivers and MOSFETs in their custom VESC-based ESCs. And considering that you need 6 or more MOSFETs, any savings you make by choosing different MOSFETs quickly gets multiplied. Savings on the MCU costs are usually eclipsed by the effort taken to port the very specific STM32F405 code to the new MCU.
Please feel free to port the code yourself if you feel that saving a couple of dollars is worth it.