Setting microstepping resolution via UART

[Pato-99]

Hi Christian,
I've been experimenting with your library and I found out something odd about set_microstepping_resolution method.

#setting all bits to zero
chopconf = chopconf & (~tmc_reg.msres0 | ~tmc_reg.msres1 |
                        ~tmc_reg.msres2 | ~tmc_reg.msres3)

I would this to set bits on positions corresponding to MRES to 0 (bit positions 24, 25, 26, 27) as the comment says. But it does not affect the value of CHOPCONF register at all.

See:

~tmc_reg.msres0 = 0b11111110111111111111111111111111
~tmc_reg.msres1 = 0b11111101111111111111111111111111
~tmc_reg.msres2 = 0b11111011111111111111111111111111
~tmc_reg.msres3 = 0b11110111111111111111111111111111

~tmc_reg.msres0 | ~tmc_reg.msres1 | ~tmc_reg.msres2 | ~tmc_reg.msres3
=
0b11111111111111111111111111111111

Isn't it a typo? | instead of an &?

But this next line is a complete mystery for me:

chopconf = int(chopconf) & int(4043309055)

Why there is that hardcoded value? It could overwrite CHOPCONF settings prior to this method call.

Permalink to the snippet:

https://github.com/Chr157i4n/TMC2209_Raspberry_Pi/blob/8e3a695c61803b03ce32a49b6617e79265f6993e/src/TMC_2209/_TMC_2209_comm.py#L592C4-L598C44

[Chr157i4n]

This is definitely a bug.
I'll take a closer look at it tomorrow.

It looks to me as if lines 593-594 and 597 should do the same thing.
4043309055 is the same bitmask as above (just not readable as such).

But I think the function should still work. Does it?

[Pato-99]

Yes you are right.
4043309055
is indeed
11110000111111111111111111111111
in binary.

Line 597 actually applies the correct mask. Lines 593-594 should do the same thing but do not. I guess that is the reason why might the line 597 be there. 🤔

Well then i suggest to replace | with & and delete the line 597. The output should be the same and readability would increase.

I found out about this when I was trying to interface TMC2209 from RPi Pico running micropython using snippets from this library. I was just setting the microstepping resolution and reading back the chopconf in a while loop and read backs were somewhat inconsistent. That was possibly due to copypasting few snippets and not using the library as a whole. I guess that the function still works and this finding is a pure coincidence 😄