Port to F411 ?

[akunadze]

Hi,

You've mentioned in our previous conversation that you were planning to port to the Black Pill. Any idea when that might happen? I'm starting to run out of flash space with -O0 flag, which forced me to switch to -Og, which in turn makes debugging much more difficult. I've tried switching over to F411 headers, but it seems you've made some modifications to the blue pill headers so the code doesn't readily translate.

[prototypicall]

Hi there,

Sorry for the delay. Eventually I will switch to another board (quite possibly a set of boards which will include the F4x1) but for that I will be switching to a different-ish register abstraction so it will be some time till that happens, I am afraid.

However I started working on the current firmware today and will have some updates in the dev branch in a couple of days hopefully.

Sorry about the debug issues. It is really tricky to debug the microcontrollers. If you build without -O2 or -Os there will be some additional clutter which will definitely impact the timing of things. Having a debugger attached also puts the microcontroller in a different run state in which some of the peripherals (like timers) work differently (or don't work). I would suggest that you consider using a logic analyzer (and putting pin flipping ops here and there) to try and debug things. The very low cost usb logic analyzers are adequate for this job.

[akunadze]

Cool, I'm really curious what lib you end up with. Is it your own creation you've mentioned before? Hopefully it'll have some HAL-like macros to reduce the need for bit-banging somewhat. Also, I took a look at Kvasir git, it's been dead since 2017...

As for debugging, I'm just trying to debug UI code, nothing time-critical. It's just frustrating without -O0, half the lines and vars are optimized-out. I found a workaround for now, I just disable the code that it not relevant to what I'm debugging and I get just enough room. F411 would solve that properly, but for now it's working well enough.

And I took your advice and ordered an Owon scope (I know you suggested a logic analyzer, but this looked more fun). Should be interesting to play with.

[akunadze]

An unrelated question: how do you envision switching ratios on the fly would work? I'm trying to implement it in feed mode, where I don't really care if I miss steps, but simply calling gear::configure() seems to confuse the algorithm and it stops step generation for a while. I tried adding encoder::update_channels() right after, and even tried disabling tim1 while updating all that, but it didn't seem to help much.

[prototypicall]

Hi. First off, despite my intentions I unfortunately didn't have any time work on the project this week so no updates on the code yet.

I am glad you got a scope :)

Yeah, Kvasir is dead, that's one of the motivations. Imho the API is pretty good but there are some things that need improving. Especially on the code generator part to compensate for the low quality SVD files from vendors like ST.

This is indeed a low level API so I get the need for a higher API but for certain applications (like this where we want to use the hardware to it's fullest) this is good enough. It's definitely better then the error prone manual bit manipulations to read/write the registers.

An unrelated question: how do you envision switching ratios on the fly would work? I'm trying to implement it in feed mode, where I don't really care if I miss steps, but simply calling gear::configure() seems to confuse the algorithm and it stops step generation for a while. I tried adding encoder::update_channels() right after, and even tried disabling tim1 while updating all that, but it didn't seem to help much.

I am surprised. I recall that part working without any issues in my tests (should be on the video as well?). Are you sure the pulse ratio you calculate is valid? I will make sure to test this once I get back into it.

[akunadze]

I think I've fixed the on-the-fly gear change issue, at least somewhat. Instead of changing gear::state immediately when a different ration is selected I save it into a temp var and apply it on the next interrupt. That way any potential timing issues are avoided (perhaps an interrupt between encoder::get_count() and actual refresh of gear::state, or between assignments to state::N , D and err).

Changes work fairly smoothly now, but there's still some sort of a timing glitch. Once in a while when changing on the fly the stepper would just stop completely and it would take a few seconds and a couple of gear changes to revive. I'll try to dig in some more into it and I'll post a video of it happening tomorrow.

And, of course, one new issue, this one more of a limitation: I found that with a direct-drive stepper and 4096ppr encoder, the stepper is really limited to 8x micro-stepping. At 16x it wouldn't be able to do even a 10tpi thread. Do you think it's possible to extend the algorithm to generate more than one step per encoder pulse? Maybe interpolate based on current speed? It wouldn't be exact, but should still be fairly smooth.

Also, I've created a fork to keep my changes somewhat organized (https://github.com/akunadze/Didge), in case you'd like to see. Most of them are UI-related, but there's some control flow reordering that you might find useful.

[akunadze]

Found the cause of the issue: step_gen::set_delay(phase_delay(encoder_pulse_duration::last_duration(), range.next.error)); I'm using a rickety old dc motor to drive the encoder for testing and its RPM is not very stable. I think what happens is the delayed steps collide with next steps in sequence, especially in the face of ratios changing on the fly. I removed the delay and it's much more reliable, though obviously the steps are not as smooth.

I also ran into resource exhaustion while trying out 16x microstepping. Somewhere around 0.040in/rev feed and 700rpm UI stopped updating and steps began to falter. Upping the RPM resulted in the stall happening at lower ratios. Black pill would really be nice here...

[prototypicall]

Hi there. I've been busy with the library that I've mentioned so could not respond sooner :(

I think turning off the optimizations might be culprit here. With libraries like Kvasir, the optimizer is essential to eliminate the 'fluff'. Interrupt service routine is sensitive to the runtime / code size. If the next jump comes while we are still in the ISR the main thread will never have time to do anything for instance or lower pri interrupts will not be handled. Please give -Os a shot.

Re: gear changes - I think it's a good idea to have an intermediate storage for the gear status like you mention. You may still run into the case where you are midway through the temp struct update and the ISR gets executed. This needs an atomic operation to do it without any glitches. This is on my must have list.

Re: tpi limitation. Well hopefully with the switch to the black pill, there will be more 3 timers to work with so yes I think it's definitely possible.

[akunadze]

Yes, I realized I had -O0 flag on and since tried -O2 and -Os. It did improve things, I was able to get to 0.1in/rev feed, but there was still an occasional glitch at lower feeds. Looking at it in the scope I noticed that sometimes the step signal remains high for a long time, and sometimes stays long for a while. Could it be that something is masking the interrupts? According to the docs, the timer needs them to work reliably. Either way, there's definitely a timing issue there somewhere, it's just easier to hit with optimization turned off.

[WildPoYo]

@akunadze Sorry not related but are you by any chance Alex Kunadze who developed CuteFTP? 😄

[akunadze]

@WildPoYo Haha, yes that's me. I'm surprised anyone remembers that one, it's been a few decades :)

[WildPoYo]

@akunadze It was the first ever FTP tool I used back in my high school times. Which is almost two decades ago :)

[oyvindkinsey]

@prototypicall , any news on the port, and perhaps on moving off Kvasir? I've been trimming down/refactoring Didge to get familiar with the system, and will try to migrate to direct register manipulation to remove the Kvasir dependency (mostly to make it easier to port/combine with additional logic), but if there's something already done in this space, I'd love to take advantage of that as well.

My plan is to use one STM32 to power the main synchronization, while operating as an I2C slave. A separate unit will be the master, and interface with any displays, pendants and so on.

[prototypicall]

@oyvindkinsey Sorry about the delay. I had to unfortunately put the 'moving off of Kvasir' to a long halt. Lost my SSD drive to a corruption last year with significant portion of the new library and some additional projects for generate SVD files from the ST reference manuals with it. Was really disappointing. Anyway, I am not sure when I will be able to get back to this project - hopefully in a not so distant future but don't know yet.

[oyvindkinsey]

No worries, I already ported it to CMCIS and have everything working. Almost done with the i2c slave implementation now, where a master will be able to read rpm, set the ratio, set limits, and initiate rapids etc.

Fun starter project for the stm32 :D

On Thu, Jan 5, 2023, 10:01 PM prototypicall @.***> wrote:

@oyvindkinsey https://github.com/oyvindkinsey Sorry about the delay. I had to unfortunately put the 'moving off of Kvasir' to a long halt. Lost my SSD drive to a corruption last year with significant portion of the new library and some additional projects for generate SVD files from the ST reference manuals with it. Was really disappointing. Anyway, I am not sure when I will be able to get back to this project - hopefully in a not so distant future but don't know yet.

— Reply to this email directly, view it on GitHub https://github.com/prototypicall/Didge/issues/5#issuecomment-1373179912, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAA2MARRHKTDGEF4OIMRF33WQ6YNDANCNFSM4XS6EM5A . You are receiving this because you were mentioned.Message ID: @.***>