05:23 <re_irc> <heksa> chemicstry: Hehe, we just did that on our chip. It was a good facepalm moment. Uart got very broken after we edited a linker script to give more memory, and accidentally placed the program on top of our Uart buffer.

18:00 <re_irc> <ryan-summers> I personally have fallen in love with https://github.com/korken89/smlang-rs for state machines

18:01 <re_irc> <ryan-summers> But always love to see new state machine concepts :) Rust makes them so much nicer than C

18:02 <re_irc> <ryan-summers> There's not many embedded options currently

18:03 <re_irc> <ryan-summers> One important aspect is allowing the state machine to have underlying data it can manipulate, so e.g. you can perform actions on transitions

18:03 <re_irc> <ryan-summers> It makes things very self-contained and well-controlled

18:04 <re_irc> <ryan-summers> I like smlangs approach where the statemachine macro generates a trait that you can impl on a struct. Then, that struct operates as _the_ state machine, which is powerful

18:05 <re_irc> <ryan-summers> Because then you can wrap up complex objects as "the whole state machine" instead of implementing variables within it to do state management

18:07 <re_irc> <ryan-summers> The one thing that I'd really like is to have the state machine automatically check certain conditions to generate state transitions

18:08 <re_irc> <ryan-summers> I'd prefer to not have to manually implement a "poll()" function that checks external parameters to generate update requests, since that's all boiler plate

18:08 <re_irc> <ryan-summers> The state machine itself should be able to implement some type of transition checks

20:04 <re_irc> <762spr> Still working on getting my developer environment dialed in. I got probe-rs set up and was happy that I just hit run in VSCodium and it builds and deploys it to my board. Awesome! But apparently debugging with breakpoints isn't supported? I did a quick Google and it seems the other option is cargo-embed. Any pros/cons on using one vs the other?

20:04 <re_irc> It sounds like cargo-embed uses gdb for debugging which has me worried that the same connection issue that led me to use probe-rs (couldnt connect open ocd and gdb server) will rear its ugly head again... or do I have unreasonable expectations of hitting the debug button in VSCodium and having it deploy and launch debugging with breakpoints and stepping in the IDE?

20:16 <re_irc> <jacobrosenthal> 762spr: They both use probe-rs, not gdb. probe-run is designed for println debugging. probe-rs can do step debugging, see the vscode plugin on the probe.rs website

20:24 <re_irc> <jacobrosenthal> cargo-embed comes from the probe-rs people, probe-run comes from the knurling people. I think its fair to say cargo-embed hasnt gotten a ton of love recently, Ive personally switched to probe-run

20:24 <re_irc> <762spr> OK thanks, I saw GDB on the cargo-embed GitHub page and was like oh no! Haha

20:24 <re_irc> I was actually just reading the probe.rs website and looking at their plugin page! So just so I am understanding correctly, the vscode plugin Is basically a third option compared to probe-run and cargo-embed?

20:26 <re_irc> <jacobrosenthal> 762spr: kinda? it also uses probe-rs. you could use it as a cli but I dont think its common, you use it through the vscode plugin

20:27 <re_irc> <jacobrosenthal> personally i use probe-run to see some logging, or cargo-flash to just flash the binary with logging off, and debug with the vscode plugin occasionally if I want to see registers or step a bit, but thats pretty rare frankly

20:28 <re_irc> <jacobrosenthal> cargo-embed lets you do a lot more configuration than probe-rs, mess around with rtt channels and things, have a configuration file

20:28 <re_irc> Cargo-embed also uses probe-rs and can do some more features like step debugging but users don't like it so much.

20:28 <re_irc> <762spr> So probe-run is uses probe-rs and can only do prints, sort of like the arduino ide.

20:28 <re_irc> Vscode plugin is a third option based on probe-rs that allows working with velariables and registers and step debugging in the ide

20:29 <re_irc> <jacobrosenthal> eh, I guess probe-run is like serial monitor, sure, but not really though, because its using debugger hardware not serial, so it doesnt affect performance, and doesnt require you to have working serial comms or pins dedicated

20:30 <re_irc> <762spr> I think for most of what I do, my workflow will be like yours where it is mostly print based so probe-run will suffice but every once in a while I need more so I was worried when I saw probe run didnt support that

20:30 <re_irc> <762spr> OK got it I think I understand now.

20:30 <re_irc> <jacobrosenthal> very very rarely, i still do load up full gdb for better or worse. the probe-rs debugger is still a little beta

20:31 <re_irc> <762spr> Can the vs code plugin also do debug prints? Now I am curious why not just use it all the time vs probe-run?

20:32 <re_irc> <corecode> jacobrosenthal: my man! long time

20:32 <re_irc> <corecode> ryan-summers: i think the poll -> event route can be done in a separate macro

20:33 <re_irc> <corecode> ryan-summers: would be great if you could try my crate and give me some feedback

20:34 <re_irc> <corecode> ryan-summers: right now you can attach a context (trait) to the state machine, but the plan is that this is only used to talk to the outside world. if you need to maintain extended state (say some integer), then the state should maintain this state itself. that's not implemented yet though