What version of the firmware are you using?
Git commit cc78ba3afa65deaa809b5f6f59f85237cd10d13b (Last for Devt)
Is the problem repeatable?
Yes
Under what conditions does the bug occur?
When the step pins should be inverted – setting $2
The value of “memblocknum` in `rmtconfigt` should be 1. A memory block can hold 64 items. When specify a number of 2 the memory block of the next channel is used. Not really a big issue as per channel less than 64 items required. It only matters when the last channel is used - channel 7 can only have `memblocknum` value of 1. The definition of `XBRMTCHANNEL` and `YBRMTCHANNEL` is missing, should be channel 6 and 7.
The step invert isn't correctly masked and should have a shift for the axis number:
`C++`
rmtConfig.txconfig.idlelevel = bitistrue(settings.stepinvertmask, 1<
`
The STEPPULSEDELAY` doesn't respect the step invert, inverted pins have no delay but an extended pulse width. Inverted pins will have an initial tick (with random direction) when the steppers are enabled in function `stwakeup()`. When use RMT the the setp outbits must be set to 0 (this was already mention in issue #302 )
`C++“
#ifdef USERMTSTEPS
// Initialize stepper output; invert is done in RMT cycle
st.step_outbits = 0;
#else
// Initialize stepper output bits to ensure first ISR call does not step.
st.stepoutbits = stepportinvertmask;
#endif
评论 (2)
#2 – khnrchs 于 2020-01-19
You are right, the pulse delay works correctly. I’m sorry for this.
Seems, I mixed this up with the invert not properly masked.
#1 – terjeio 于 2020-01-18
I guess am partly to blame for this, at least the
memblocknumwrongly set to 2, see issue #115. Note thatrmtfilltxitems(...)call should be changed tormtfilltxitems(rmtConfig.channel, &rmtItem[0], 2, 0);as well if I understand the docs correctly. It may not matter if the RMT RAM block is cleared per default, but better be safe.Step pulse delay works correctly for inverted signals when I look at the output from my version on a scope – and I can’t immediately see any reason for why this should behave differently.
Since I do not have a compatible toolchain set up I am not able to test this version, sorry about that.