Driver for stm32F401 - BlackPill

[shaise]

Hi @terjeio , I am in the process of adding a new driver for STM32F401 board - BlackPill. This is a $2.7 very hi performance board:

1. 84Mhz with hardware floating point!
2. Almost 0 wait state running code from flash (using pre-fetch accelerators)
3. USB C connector.
4. No need for special programmer to upload firmware! (have built in DFU)
5. No jumpers... I have more or less finished the driver, and it seem to work. Most of it is copy-paste from the srm32f103 driver. However, this processor is 84Mhz, and the 103 is 72Mhz, so I guess some timing adjustments must be done to work correctly. I could not find where these timings are referenced in the code. Can you point me where to look for timing constants? (or maybe it is done automatically?) I can later PR this driver if you like. Thanks! shai

[terjeio]

Great!

The clock used by the step pulse generator (in stepper.c) is set here:

https://github.com/terjeio/grblHAL/blob/efb083085669dafe11da9cb934b671b5e79cd876/drivers/STM32F1xx/Src/driver.c#L931

So automatic unless you configure the stepper timer to use a prescaler. If so divide SystemCoreClock accordingly. SystemCoreClock is set by the STM startup code.

I initially check this by issuing a G0X0 followed by G1X100F100 and time that with a stop clock (on my phone). I use a ~10000 line program to verify as well, this with default grbl settings. It should complete within a reasonable time difference compared to other grblHAL drivers (or vanilla grbl).

Spindle PWM clock is set in a similar way but uses prescaling:

https://github.com/terjeio/grblHAL/blob/efb083085669dafe11da9cb934b671b5e79cd876/drivers/STM32F1xx/Src/driver.c#L555-L563

Check with a scope or frequency counter.

The systick interval is set by the STM startup code to 1ms, I would guess it is the same for your version?

I veryfy this by checking the time taken for a G4P10 command.

A PR would be nice.

[terjeio]

Can the driver be used for the STM32F411 Black pill as well? Seems like it should, but perhaps the spindle PWM prescaler must be changed?

[shaise]

Hi! Thanks for the fast reply. I will do the timing tests and let you know my findings. regarding the STM32F411 version of the black pill, the main difference is 100Mhz clock and twice (512K) flash memory. There is no reason it will not fit both. When I complete the timing tests I will see if maybe an extra #define is needed to fit the F411 as well. There is one big issue for both chips, though. The eeprom emulation is very wasteful. I don't know why ST decided to go this path, but the minimum page size is 16K. and what is even worse is that only the first 4 pages are 16K. If you want to use the last page for it, it is a whooping 128K(!) In my implementation I used the second 16K page from the beginning, and set the linking process to bypass it when generating code. The downside of it, is that when you upgrade the firmware, it will erase the "eeprom" content. Still thinking for solutions to it.

[terjeio]

Still thinking for solutions to it.

Why not use an external I2C EEPROM (or FRAM)? The F103 driver already has support for that. I will modify the plugin code later to better support FRAM - no need to wait for the write cycle to complete.

[shaise]

I am trying to keep things simple. I want users to have as less hardware setup as possible. (by the way, the black pill can have on board eeprom, the footprint exists on the bottom side)

I have just updated to you latest code so I can start tests. I have several issues though:

1. in cnc3040_map.h,

   #define BOARD_NAME "CNC 3040 5-axis"
   #endif
   #if N_AXIS == 4
   #define BOARD_NAME "CNC 3040 4-axis"

   should be changed to:

   #define BOARD_NAME "CNC 3040 5-axis"
   #elif N_AXIS == 4
   #define BOARD_NAME "CNC 3040 4-axis"

   otherwise there is board_name is not defined correctly. this is true also for stm32f103

2. for f401, there are no __HAL_AFIO_REMAP_SWJ_ENABLE() and __HAL_AFIO_REMAP_SWJ_NOJTAG(). so I commented them out. What are they used to? reassigning the debug pins? in which case?

[terjeio]

1. Sorry about that, will fix.

2. For reassigning debug pins. First case is if not done coolant outputs are not working - (B3 and B4), second is it is required for enabling pins for the SD-card plugin if that is used.

[shaise]

basic version is now working and tested on my CNC. No sdcard support as I have no way of testing it. parameters are still on second 16page of flash. Not sure how to make a PR. My forked version have too many changes, and github won't let me fork another version. I can upload a zip file of the folder, or any other suggestion you may have.

[terjeio]

Upload a zip as a start and I'll take a look before I decide. I suppose this going to be a new driver.

[shaise]

Hi, Yes. New driver on a separate directory. One thing though, many files are similar to the F103. This means any fix on on F103 should probably be implemented on F401 and vice versa. But I guess that after some time everything will stabilize, and this issue will be minor. BTW Kudos for the cubic spline implementation! just found out about it. GrblHal is really going professional.

[phil-barrett]

I am thinking of making a breakout board for the F4xx, Not the black pill but with the processor on the base board. So maybe it's a motion controller and not a breakout. Anyway, is the F411 the best choice for this? I'm just getting up to speed on STM32 so am not sure what makes sense.

[shaise]

I did not have much experience with the F411 but I think both 401 and 411 are more then adequate for the job. Both have hardware floating point, and plenty of program memory. The only small downside is that writing into the flash is very wasteful as the erase blocks are too big, so perhaps consider adding an external eeprom / flash.

[phil-barrett]

Yes, I've been following the discussion of NV storage. My basic design for iMXRT1062/Teensy 4 has an EEPROM footprint and grblHAL support works pretty well so it's pretty easy to toss in. I still have a lot to learn about the STM32 family - it's a bit like drinking from a fire hose.

[terjeio]

Anyway, is the F411 the best choice for this?

Which processor is best suited for grbl depends on the target application and also commercial considerations. If the target is the average hobbyist then cheap is the mantra? If for the serious user then features is likely to be the most important. Noise immunity beeing one?

Some random thoughts:

I have made a controller with a Texas Instruments TM4C123 MCU for my CO2 laser, a very noisy environment. To avoid ground loops I used a FTDI232 USB <> serial converter with ADuM1402 digital isolator. Ethernet comes with isolation as default, I run a SmoothStepper connected to a second network card to ensure that no other traffic can interfere.

A controller with a display option makes sense? Perhaps with a second MCU for handling the display?

Is grblHAL closing in on LinuxCNC and could become an option for those that find vanilla grbl lacking in features and LinuxCNC somewhat complex to set up?

Time for breakfast...

[phil-barrett]

The assembly service I'm using has some pretty good prices on STM32 chips in single quantities. Half of what a US or EU disti would charge. (I'm pretty sure they aren't counterfeit.) There are STM32 clones like GigaDevice that are even cheaper - it might be worth trying them at some point. My point here is I think the processor cost is a very small part of the equation. A low end hobbyist can appreciate the higher end features. Probably the biggest electronics cost items are stepper motors and drivers.

How would you use a display? For DRO? "Offline" operation? (the cheap Chinese CNC machines have that feature though it seems to not work for a lot of users). Could be pretty easy with a very cheap processor.

Interesting point about LinuxCNC. There was a time when I thought I would try to use it but quickly realized it is a dead end. It requires too much Linux expertise to be a mainstream product. Is grblHAL closing in? Yeah, I think it is. GRBL is popular because it's easy and runs on widely available and cheap hardware. Popular even with it's limitation. Today, if a GRBL user wants to move up to a 4 or 5 axis machine, their only real choice is something like smoothstepper or mach or ucccnc (and on up into the stratosphere). This is where grblHAL fits. I think there is a ready market there but we need to have HW to run it and easy to configure software (to avoid the linuxCNC problem). We are getting closer but not quite there yet. But I'm confident it will happen.

Time for bed!

[terjeio]

How would you use a display? For DRO? "Offline" operation?

Yes, grblHAL has a plugin for streaming G-Code from a SD card so offline operation is possible. I have quite a bit of the code needed already running in my MPG & DRO.

A potential problem may be that if you make a controller that is successfull in the marketplace you can be pretty sure that Chinese clones will appear. Open sourcing is an open invitation for that. And guess who will need to handle the support... A bit scary.

[phil-barrett]

I think if the Chinese cloners pick up a design, it's a good thing as it broadens the base. I'm not in it to make money. Maybe to make back some of my costs...

As to support, making it really simple to use is important. Having a good community will help. There are several out there.

[shaise]

I have made A dongle that plugs directly to any parallel-port based CNCs, and is dead cheap ($4 altogether): https://github.com/shaise/GrblCNC/wiki/Hardware-Setup In fact I really hope the Chinese will pick up one of the designs and market it, as @phil-barrett said, it will be easier for many to switch to GRBL.

[phil-barrett]

On the STM32, I'm looking at 64 vs 100 pin packages. The 64 pin packages generally have about 50 GPIOs which should be enough. Based on the builds I've done, I think 256K flash and 256K ram should be enough. The F411 series has 128K. Are these reasonable assumptions?

One confusing data point - my iMXRT1062 5 Axis build uses 124K of ram. Yet, there are builds for the F103 that work and yet those have considerably less ram - 20K, based on the data sheet.

I'm putting together a comparison spreadsheet. One thing that has jumped out is the F412 is a bit cheaper than the F411 yet has 2X the ram. I need to look a bit deeper to see more differences.

[phil-barrett]

@shaise. Have you thought about also uploading your design to OSHPark? They allow sharing and you supply a link to the design on OSHPark. People can then order that one without having to upload anything. Pretty easy.

[shaise]

Hi @phil-barrett, I was not familiar with OSHPark. I will take a look. They are rather expensive though. Seeed gives you 10 copies of 16 square inch boards for $5 (as opposed to 3 copies of 1 inch square) But, I guess that for US citizens, it can be a better choice.

[terjeio]

One confusing data point - my iMXRT1062 5 Axis build uses 124K of ram.

Code is copied from flash to RAM in iMXRT1062 for faster execution. It is possible to flag code to be executed directly from flash. The map file for MSP432 shows what is perhaps a better measure of what may be required in extreme cases:

******************************************************************************
                  TI ARM Linker PC v18.1.5                     
******************************************************************************
>> Linked Sat Jun  6 09:15:31 2020

OUTPUT FILE NAME:   <GRBL Driver MSP432.out>
ENTRY POINT SYMBOL: "_c_int00_noargs"  address: 00012b45

MEMORY CONFIGURATION

         name            origin    length      used     unused   attr    fill
----------------------  --------  ---------  --------  --------  ----  --------
  MAIN                  00000000   00040000  000131e8  0002ce18  R  X
  INFO                  00200000   00004000  00000000  00004000  R  X
  SRAM_CODE             01000000   00010000  0000372d  0000c8d3  RW X
  SRAM_DATA             20000000   00010000  0000372d  0000c8d3  RW  

0000372d -> ~14K, this is with some large debug buffers for spindle sync logging

20K RAM/128K flash is sensible minimum for a fairly complete configuration. A bit more RAM/flash may be required for ethernet capable drivers but those MCUs are likely to have plenty.

The 16-bit MSP430F5529 driver has a basic configuration with reduced serial buffers:

           name            origin    length      used     unused   attr    fill
----------------------  --------  ---------  --------  --------  ----  --------
...
  RAM                   00002400   00002000  00001c71  0000038f  RWIX

00001c71 -> ~7K

So a basic configuration should require less than 10K even for a 32-bit processor.

[shaise]

@phil-barrett , thanks for the tip! Files uploaded to OSHPark and mentioned in the wiki

[phil-barrett]

@phil-barrett , thanks for the tip! Files uploaded to OSHPark and mentioned in the wiki

Great! Yes, they are expensive per square inch but when you factor in shipping from china (to the US at least) they are cheaper up to about 5 sq in. (around 30 cm sq). I use them for small stuff like test fixtures and such. My bare Teensy 4.1 board is $62 USD from them delivered for 3. From JLCPCB it's around $23 USD for 10.

[phil-barrett]

Yeah, I knew about the 1062 using ram for execution, This is what confused me from the link report:

Sketch uses 93536 bytes (1%) of program storage space. Maximum is 8126464 bytes. Global variables use 123572 bytes (23%) of dynamic memory, So, they must preallocate space for the code. Based on that the program uses around 30K for declared variables.

[phil-barrett]

On a related point. It seems there are several STM32 clones out there. The blue pills I just bought apparently have a CK device on them (seems a bit of a ghost company) and there is GigaDevices. Apparently there are several others, too. Does grblHAL run on them? At least on their F103 clones? Probably not enough info at this point. I will give it a try when I get my "blue pills".

By the way, the blue pill with a genuine STM device on it looks to be hard to find. All the Chinese companies are selling ones with counterfeit STM32F103s.

[shaise]

Yes, the counterfeit STM32 is a big issue. It looks like if the counterfeit STM32 is 128K (and most are) the firmware will work fine. However, if you want to debug the firmware, the debugger will detect its not genuine STM32 and will not work. It took me some time to find a seller that sells genuine BluePills, but even him, in the last batch I got counterfeit ones (with fake ST markings on the chip). I really don care paying twice for a real one. Anyway, regarding the blackpill, for now it is genuine.

[phil-barrett]

Well, if grblHAL always works on the fakes, then it's not so bad. But if even the vendors don't know what they are actually selling, it makes it hard for the average system builder to buy with confidence. With the arduinos, there is a lot of confidence that an Uno is an Uno.

grblHAL needs a target platform that the average builder can purchase the parts for with full confidence that it will work. I am beginning to think that the STM32 may not be it. Maybe if the Black Pills don't get counterfeited it will be ok. Though, trying to find a seller in the US is hard. On ebay, they come from Canada or China.

I think my first run at making an STM32 board will be a dongle for an MPG based on a F103. Then I'll move to a full grblHAL board.

[shaise]

Nope. Sorry. Am looking for it myself.

[terjeio]

@shaise Is this the correct one?

[shaise]

Looks like it, yes! thanks!

[hdo]

I also have some of those BlackPills with STM32F411 chips. Can't wait to try those out :-) However don't have the lower spec STM32F401 though