davidmolony / mesc_firmware

FOC library for BLDC/PMSM compatible with all STM32 targets with FPU.

davidmolony.github.io/MESC_Firmware/

Documentation will be gradually created/migrated to github pages.

View the book here

MESC_Firmware

MESC is a project for embedded BLDC FOC, serving a number of purposes

1. Easy to follow and learn FOC
2. Easy to port to other platforms
3. High performance motor control offering all the FOC goodies: Sensorless, HFI, Encoder, Hall, (and combinations of), Field weakening, MTPA, Torque, Speed and Duty control.
4. Permissive licensing making commercial use easy (Additional conditions attached to integration into other open source projects).

Targets/Hardware

MESC runs primarily on any STM32 target with an FPU. Tested with the targets in the repo, but easily portable to any other STM. Compatibility with other MCU brands TBC.

The reference hardware is now the MP2 ESC, since it allows testing with many targets by simply swapping the MCU pill. It also offers adequate performance for most light EV applications (high power scooters and ~10kW E-motorbikes.

The original hardware based on F303 target MESC_FOC_ESC will be supported for some time, but not encouraged.

All STM32F405RG hardware (AKA VESC compatible hardware e.g. Trampa, SHUL, Triforce, FSESC and many others) compatible with MESC_firmware.

With thanks to all that have helped in the creation of MESC.

Happy spinning!

mesc_firmware's Issues

Request for CAN improvements

See: https://github.com/davidmolony/MESC_Firmware/blob/FW_ADC_sampling/MESC_RTOS/MESC/MESCinterface.c

starting around line 493

At present when we perform data logging, we export all these values:

1. mtr[0].Conv.Vbus , "vbus"
2. mtr[0].FOC.eHz , "ehz"
3. mtr[0].Conv.MOSu_T , "TMOS"
4. mtr[0].Conv.Motor_T , "TMOT"
5. mtr[0].FOC.Idq_req.q , "iqreq"
6. mtr[0].FOC.Idq_smoothed.d , "id"
7. mtr[0].FOC.Idq_smoothed.q , "iq"
8. mtr[0].Raw.ADC_in_ext1 , "adc1"
9. MESC_errors , "error"
10. mtr[0].FOC.Vdq.q , "Vq"
11. mtr[0].FOC.Vdq.d , "Vd"

I believe only 1-5 are available through CAN, could you send the additional variables? An slight alternative is to basically send the same content as what is transferred with "status json".

Please consider creation of CAN commands to:

• reset MESC_errors to zero without power-cycling the board
• control the kill switch function (possibly independent of the kill switch tied to hardware).
• change state of the LED
• set "slambrake"
• store odometer readings

General code clean up

• Create a consistent coding style. Current style is error-prone and needs to be addressed.

• Implement automatic code style parser for all contributors.

• Function names, variables and constants require addressing according to coding style.

• Functions require documentation headers.

• Code requires UML execution diagram for easier understanding of how it works.

Tracealyzer integration

Need to integrate tracealyzer in the code to allow better insight into how it works. It should also help with tracing existing bugs.

Documentation for porting to other boards.

where you can read how to make an identification of the motor? There are GUI or CLI Tools for your project.
Is there a control of CAN BUS? DroneCan or so? You write that MESC work to 100 kHz.
I am interested in this now. I have controllers working with the VESC. VESC does not work more than 45 kHz PWM.

Request: enable sending log data via the term.

Suggestion two levels of complicity for this.

FIRST VERSION:
User select items for configuring the payload with a command like
status log init
To configure:

• frequency the payload is sent
• output format (e.g., "json", "csv") of payload
• values to send, where the values correspond to what's available from get

json format is shown below. Then when the user makes the call:
status log send

the device starts sending the payload.

Also: get should show board temp, motor temp and vbat_volts. :-)

SECOND (EASIER) VERSION:
If all of that is too complicated for now, much simpler, create a print statement that prints:

{"amps": 10, "volts": 20, "rpm": 30, "btemp": 40, "mtemp": 50}

and I'll just configure the print to send whatever I need.

Sweep entire codebase for obvious syntax and formatting caused bugs.

Stray source code in project root directory.

There are .c and .h files in the root of the project that should have better documentation and need to be tucked away in a separate folder.

Code formatting rules

@Netzpfuscher, hi. David asked me to have a chat with you regarding code clean up. He's aware that he writes horribly formatted code and wanted to pull some resource to have code a bit more maintainable. Since you are a very active contributor, I thought it makes sense to have a discussion with you first before anything is done to find out your opinion and preferences.
I suggest that this issue be dedicated to ironing out two questions:

• format of the code that we should strive towards
• manner in which changes to the code formatting should be made

Under format of the code I mean things like naming convention for variables, functions, constants, etc. #define vs. static const. Tab vs. spaces. Brace position. Once those decisions are made quite a bit of that can be automated.

As far as implementation goes I see two options: wait until code reaches reasonable stability and do entire codebase in one hit, or introduce rules and enforce them with every merge request, thus allowing code to morph into acceptable format gradually. I am not sure how confident you are with code stability and whether David and you are happy to stop development to do all changes in one. It introduces certain difficulties in tracing bugs back beyond the formatting changes since diffing becomes much trickier. If this was production grade code for a commercial enterprise I would advocate gradual changes. This is where your input is paramount.

Let me know what you think.

Its posible to create step/dir interface also??

Hi sir.
It posible to add strp/dir interface also? Soa will posible to used bldc on cnc.
Iam plan to used stm32f401.
An make mybe 70v20A or bigger volt.