Help with TMC2130Stepper library on STM32F103

Hi all,

I hope you guys can help!

I’m using the TMC2130Stepper library to set various parameters of the amazing Trinamic TMC2130 stepper motor driver in my sketch.
It’s a one-shot config via SPI that sets a bunch of registers on the driver, then the driver uses the classic step/direction control afterwards.

TMC2130Stepper lib wasn’t written for the STM32, but I managed to get it to compile and does work.

https://github.com/teemuatlut/TMC2130Stepper

Originally it didn’t compile because of datatype constexpr being used in TMC2130Stepper_REGDEFS.h.
I renamed every instance of constexpr to const, and it compiled and works.
Here’s a response from the author of the library about it: https://github.com/teemuatlut/TMC2130Stepper/issues/54

But as soon as I initialise the tmc2130, it kills the STM32’s speed and it starts to crawl.
driver.begin(); // Initiate pins and registeries

Can you show us your code for constructing the stepper object?

PS, see this -> https://forum.arduino.cc/index.php?topic=384478.0

[BennehBoy – Thu Jan 10, 2019 2:11 pm] –
Can you show us your code for constructing the stepper object?

Thank you, I’ll check out the link.

Here is the contsructor:
TMC2130Stepper driver = TMC2130Stepper(EN_PIN, DIR_PIN, STEP_PIN, TMC_CS_PIN);


OK, well that’s first step out of the way, I was wondering if you were using sw spi, but nope.

Perhaps follow up on the constexpr reading, not sure which core you are using but Roger’s uses GNU11 standards.

Thank you.

I’ll try to get constexpr and the original version of the library to work in arduino.

If you use a newer compiler, arm-none-eabi-gcc 7.3.1 for example, it compiles the code. The constexpr stuff is fully supported in the newer version. However, of course the current Arduino_STM32 has errors with the __always_inline thing. Also it probably hasn’t been tested that much with the newer gcc. Also, you have to hack up the platform.txt to have it use the newer compiler.

Just another data point.

Actually the example TMC2130Stepper programs compile just fine with arm-none-eabi-gcc 4.8.3. …

Wonder if OP is using an alternate IDE… might explain why he had compilation issues…

Well I’ll be damned!

I’m using the standard Arduino IDE on my dev machine but it must be out of date. I’ve amassed a huge amount of libraries on it, so always a bit wary about updating, they often break more than they fix!

I’ve just fresh installed on a new machine the newest arduino, Roger Clark stm core, TMC2130 library, and it does indeed compile without the need for any hacking.

I’ll test it on the device in the next few days and will report how it goes.

Cheers guys!

[AS_Motion_Lab – Fri Jan 11, 2019 1:18 am] –
…
I’m using the standard Arduino IDE on my dev machine but it must be out of date. I’ve amassed a huge amount of libraries on it, so always a bit wary about updating, they often break more than they fix!
…!

A universal problem; I solved it here by purchasing two (2) identical off-lease business class notebooks. I installed a medium size SSD in both and Linux Mint, my OS of choice. The total expense was half the cost of a new (1) Dell notebook with lower specs! An old desktop (also refurb) acts as the lab server on which all versions of all source code resides (working directories of source is zipped before any editing sessions.) I also keep matching zip of the various cores and tools. Terabyte drives are priced such that I highly suggest two (2) … one primary and one USB hosted back-up. If you have never lost source code, you are living on borrowed time, statistically speaking

Ray

Thanks for the info Ray

Unfortunately the problem has evolved somewhat.

I uninstalled/reinstalled my Arduino IDE, rogerclarke STM32 core, tft, touch, TMC2130 libraries, and indeed the TMC2130 library compiles in it’s standard form with no errors due to -std=gnu++11 being used – hooray.

But now when the TMC2130 library is initialised with driver.begin(), instead of the STM32 just performing very slowly, it performs slowly and the TFT screen updates are screwed up. It seems that the TMC2130 library does something to the SPI bus which is incompatible with the other devices on it.

I am able to reproduce this on demand – if I comment out the driver.begin(), TFT screen updates quickly and outputs based on touch input react instantly.
If I uncomment driver.begin(), the tft screen updates are strange (new data makes a few lines flash on/off), and the outputs are laggy/delayed, but the stepper behaves as expected, with the TMC2130 varying current, stealth chopping, etc, as expected.

I had some problems ILI9341-spi-tft-display and MCP48x2 (SPI-DAC) and a MCP6S2x ( SPI amplifier) on the same SPI-bus.
I changed the MCP48x2 to SPI2 and the problem was solved.

[mausi_mick – Sun Jan 13, 2019 1:49 pm] –
I had some problems ILI9341-spi-tft-display and MCP48x2 (SPI-DAC) and a MCP6S2x ( SPI amplifier) on the same SPI-bus.
I changed the MCP48x2 to SPI2 and the problem was solved.

As you posted this, I was just hitting upload after doing something very similar

And I think it might be working now!

I was digging through the tmc2130 library folder and found SW_SPI.cpp and SW_SPI.h files, and upon further digging found a lot of class definitions and includes of sw spi files.
There were a few lines of architecture checks and comments about clock speeds, so I thought the tmc2130 library is initializing on the HW spi pins and probably overwriting SPI speed or clashing with the other devices.

And then I discovered a longer constructor in one of the example sketches which includes mosi, miso and sck pins – so this means the library runs on any pins you specify, as it’s designed for software spi!
TMC2130Stepper driver = TMC2130Stepper(EN_PIN, DIR_PIN, STEP_PIN, TMC_CS_PIN, TMC_MOSI_PIN, TMC_MISO_PIN, TMC_SCK_PIN);