Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

step_pulse_time should be uint16_t instead of uint8_t #49

Open
mstrens opened this issue Jun 23, 2018 · 1 comment
Open

step_pulse_time should be uint16_t instead of uint8_t #49

mstrens opened this issue Jun 23, 2018 · 1 comment

Comments

@mstrens
Copy link

mstrens commented Jun 23, 2018

In file stepper.c, there is:
#ifndef WIN32
uint8_t step_pulse_time; // Step pulse reset time after step rise

For STM32, step_pulse_time is then filled with
#elif defined(STM32F103C8)
st.step_pulse_time = (settings.pulse_microseconds)*TICKS_PER_MICROSECOND;

As TICKS_PER_MICROSECOND = 72, it is not possible to assign more than 3 usec to the parameter pulse_microseconds because (settings.pulse_microseconds)*TICKS_PER_MICROSECOND would exceed 255.
To solve this, we should define step_pulse_time as uint16_t or we should apply a prescaler for the timer (for stm32F103).

@fenderrex
Copy link

Is not all operations do in 32-bit format? Wait for the hardware abstraction layer HAL runs 8bit in and out? or am I thinking about a different feature like the resolution of timers? grbl has a was to go in optimizations before it really makes much use of stm32 platforms tools like programmable clocks and direct memory access.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants