Um, I’ve made a minor tweak to the firmware to extend the stepper pulses from about 2.5us to a good 5us. There is method to the madness. I am trying to get the controller to drive a microstepping driver (opto-isolated), but the 2.5us pulses are just not quite enough to trigger the driver Im trying to add for a rotary axis (yeh I know I should just buy the perfectly decent SM one, but Im feeling hacky!). So, I’ve added another 20 ticks to the minimum pulse width definition - \Marlin\module\stepper.h line 170.
It seems to build ok in the GD32F105 environment, and succeeds, but the resultant .bin file is about 240kB, and then when I compile it through Luban firmware tool the result is 1kB. Ermmmmmmm, whats up there?
Hi. Its a DM542T microstepping driver - so the level translator on the controller board is driving an opto-isolator in the input of the stepper driver via the add-on 2 port on the SM2.
I’d consider solving this problem with a PAL or maybe a small CPLD. It’d be pretty straightforward to build a pulse extender device to sit between the SM controller and your driver.
There’s a tradeoff, as always, which in this case is software vs. hardware. Normally software wins, but that may not be true in this case. The controller code is hacked-up mess and just keeps getting worse. I considered doing firmware development, but it was clear to me even a year ago that the programmers of the firmware just don’t really know what they’re doing. @brent113 went down this road where I didn’t; he posted on it recently and may want to chime in. I think I can safely summarize, though, that his experience was far less than positive.
So anything you can do to avoid touching that code in even the smallest of ways is something to consider. It’s not that you couldn’t make one small change. It’s that it won’t be one small change now, it’s an ongoing burden of changes from this point forward. For my part, I’m voting with my time and declining to participate. I’ve been looking, admittedly in a rather desultory way, at alternate firmware foundations and starting over entirely.
Don’t use the Luban tool. Instead use the ‘pack’ in vs code via platformio gd32 action list. That will output the minor and major firmware packages to a new build some directory and you’ll need to grab the major one to load. It’s the one with the version name in it that matches version.h. don’t forget to change the version inversion.h otherwise the controller will reject the upload silently and you won’t be able to test your changes which is maddening.
@eh9 I think as long as modifications are mostly limited to Marlin it’s more positive and in this case I think this would be a strictly Marlin change so might not be too bad. The laser power changes in the stepper module and the planner were pretty straightforward. The problems started arising with getting the snapmaker specific tools to integrate with that and it felt like such a hack. One of my favorite things I found is there’s three separate one line functions that all set the same variable given the parameter provided but each one is only used once and they’re called from different places because I guess apparently three different people worked on that particular file and they never talk to each other I guess?
