<re_irc> <@y​atekii:m​atrix.org> that way you can set multiple bits in just one write. arguably you can do that with a struct too, but like this you can't do it wrong
fabic_ has joined #rust-embedded
<re_irc> <@y​ruama_lairba:m​atrix.org> ok! this is just to ensure bit are writted just once
starblue3 has joined #rust-embedded
starblue2 has quit [Ping timeout: 265 seconds]
Yruama has quit [Quit: Leaving]
<re_irc> <@j​ohn_socha:m​atrix.org> Thanks to everyone for the help. I have the keypad and LCD display working with Rust!
emerent has quit [Ping timeout: 256 seconds]
emerent has joined #rust-embedded
fabic_ has quit [Ping timeout: 268 seconds]
radens has quit [Quit: Connection closed for inactivity]
<re_irc> <@m​arcuss2:t​edomum.net> john_socha: What display is that?
Shell has quit [Quit: ZNC 1.8.2 - https://znc.in]
Shell has joined #rust-embedded
Shell has quit [Remote host closed the connection]
Shell has joined #rust-embedded
<re_irc> <@m​riise:m​atrix.org> adamgreig: I'd like to get probe-rs working with LPC55S2x and will have list of questions about errors, sequences etc. Would here work, or would a github issue be better?
<re_irc> <@9​names:m​atrix.org> There's also #probe-rs:matrix.org
starblue3 has quit [Ping timeout: 265 seconds]
starblue3 has joined #rust-embedded
<re_irc> <@m​riise:m​atrix.org> 9names: ooh, thanks I will use that for more probe-rs related things
<re_irc> <@y​ruama_lairba:m​atrix.org> f*** lost 2 hours just because i forgot to remove a "debug::exit_success" from the original example
dcz_ has joined #rust-embedded
fabic_ has joined #rust-embedded
fabic_ has quit [Ping timeout: 240 seconds]
<re_irc> <@a​damgreig:m​atrix.org> mriise: yea, #probe-rs:matrix.org is definitely the place to ask! I don't really know anything about LPC chips or probe-rs's new sequences stuff...
<re_irc> <@j​amwaffles:m​atrix.org> How do we feel about moving HAL crate examples from GDB to probe-run?
<re_irc> <@t​herealprof:m​atrix.org> jamwaffles: I feel more than great about that.
<re_irc> <@h​enrik_alser:m​atrix.org> I hope i never have to touch GDB again in my life
<re_irc> <@h​enrik_alser:m​atrix.org> Life is too short
<re_irc> <@j​amwaffles:m​atrix.org> PR for the stm32l0xx-hal: https://github.com/stm32-rs/stm32l0xx-hal/pull/184 if anyone wants to take a look
<re_irc> <@j​ohn_socha:m​atrix.org> I tried to find a crate for this display, but didn't find anything that would work. So I wrote my own code based on the Arduino library from Waveshare. I'm planning on turning this code into a crate. It is not processor specific.
fabic_ has joined #rust-embedded
fabic_ has quit [Ping timeout: 258 seconds]
<re_irc> <@d​aja_2:m​atrix.org> henrik_alser: ... what's wrong with GDB 😱?
<re_irc> <@t​halesfragoso:m​atrix.org> Ai Maiga (dajamante): For one, it doesn't really work on any project that needs real timer or near real time behavior
<re_irc> <@j​duchniewicz:m​atrix.org> I wish there was a good alternative for GDB which would work out of the box with everything
<re_irc> <@j​duchniewicz:m​atrix.org> We deserve a good debugger in 2021
<re_irc> <@d​aja_2:m​atrix.org> Is there anyone building one?
<re_irc> <@a​damgreig:m​atrix.org> I guess these days lots of the work is in microsoft DAP for VS code
<re_irc> <@j​duchniewicz:m​atrix.org> Not a specialist on debuggers but it sounds like a TON of work
<re_irc> <@a​damgreig:m​atrix.org> probe-rs is gaining a lot of support for it
<re_irc> <@n​ewam:m​atrix.org> jduchniewicz:
<re_irc> <@n​ewam:m​atrix.org> Are there any good probe/debugger combos out there?
<re_irc> <@n​ewam:m​atrix.org> I have used the enterprise probes/debuggers at work, and I much prefer GDB/OpenOCD/anything else.
<re_irc> <@n​ewam:m​atrix.org> * The ARM DStreams require constant power cycling to remain connected.
<re_irc> <@n​ewam:m​atrix.org> * The GreenHills probes/debugger are locked down to encourage vendor lock-in, also no headless API.
<re_irc> <@j​duchniewicz:m​atrix.org> I am working with JLink + GDB (might try the OZONE debugger)
<re_irc> <@a​damgreig:m​atrix.org> the jlink ones are pretty annoying if you don't also use segger's own debug software, because the part of the USB API they allow other software to access is much slower
<re_irc> <@t​aunusflieger:m​atrix.org> What about an OSS approach based on Pico probe https://github.com/raspberrypi/picoprobe
<re_irc> <@a​damgreig:m​atrix.org> picoprobe invented their own new usb protocol seemingly needlessly and it only works with their fork of openocd so
<re_irc> <@a​damgreig:m​atrix.org> my feeling is that cmsis-dap probes are the way to go - it's a standard protocol that's good at what it does, is open to implement, and a lot of hardware already implements it
<re_irc> <@n​ewam:m​atrix.org> I generally avoid Pi's for projects I intend other people to use, they're fun for hacking stuff, but they have supply chain issues, and they EOL products pretty quickly.
<re_irc> <@d​irbaio:m​atrix.org> there's a cmsis-dap firmware for the pico https://github.com/majbthrd/DapperMime/
<re_irc> <@a​damgreig:m​atrix.org> e.g. all the atmel probes use it even for avr, nxp's debugger uses it, micro:bit, anything with DAPlink, plus hs-probe
<re_irc> <@a​damgreig:m​atrix.org> yea, cmsis-dap firmware for pico is much more compelling than picoprobe imo
<re_irc> <@a​damgreig:m​atrix.org> but also it should be just as easy to buy an actual debugger with the right connectors and everything
<re_irc> <@d​irbaio:m​atrix.org> the problem is not the probe, the problem is the software support on the host
<re_irc> <@d​irbaio:m​atrix.org> cmsis-dap probes work just fine
<re_irc> <@a​damgreig:m​atrix.org> hs-probe hopefully soon, and in the meantime the mcu-link from nxp is really good and cheap and available from all the big distributors
<re_irc> <@a​damgreig:m​atrix.org> dirbaio: i agree but I think this is only the case because cmsis-dap exists and is ok
<re_irc> <@d​irbaio:m​atrix.org> the thing is cmsis-dap / swd protocols are super low level, converting that to "useful" stuff like flashing or debugging is ultra hard
<re_irc> <@a​damgreig:m​atrix.org> if you haven't already seen it ( jduchniewicz / Michael Zill / Ai Maiga (dajamante) ) then https://probe.rs/ (#probe-rs:matrix.org ) is the big rust project that more or less means you don't need to use openocd at all, it covers flashing and debugging and all sorts of other access (like RTT for debugging) for a...
<re_irc> ... lot of supported chips (mostly risc-v and cortex-m)
<re_irc> <@a​lmindor:m​atrix.org> Riscv is really slow with probe-rs tho atm. At least for me.
<re_irc> <@t​herealprof:m​atrix.org> Re debugger, there's not too much around. It's a pity that https://headcrab.rs/ has stalled out, that sounded like a fun project.
<re_irc> <@t​herealprof:m​atrix.org> (If you could call debugging fun)
<re_irc> <@t​aunusflieger:m​atrix.org> adamgreig I’m aware of probe-rs I was referring to the USB API limitations of commercial hw probes which you pointed out - addressing those by using an OSS hw based approach- but maybe be I’m wrong
<re_irc> <@a​damgreig:m​atrix.org> Yea, I think that's where cmsis-dap is nice and just good enough
<re_irc> <@a​damgreig:m​atrix.org> And hs-probe is an example fully oss probe with rust firmware for it, but there are others too
GenTooMan has quit [Ping timeout: 240 seconds]
GenTooMan has joined #rust-embedded
<re_irc> <@t​aunusflieger:m​atrix.org> adamgreig thanks will give rs-probe a try
crabbedhaloablut has quit [Ping timeout: 244 seconds]
crabbedhaloablut has joined #rust-embedded
<re_irc> <@e​milgardis:m​atrix.org> Thank you adam for the post <3, we should make an entry in https://users.rust-lang.org/t/twir-call-for-participation/4821 and make a reddit post
<re_irc> <@a​damgreig:m​atrix.org> good idea, leaving a reply on that TWIR thread
<re_irc> <@a​damgreig:m​atrix.org> I don't have a reddit account, does anyone else who could post it?
<re_irc> <@j​ohn_socha:m​atrix.org> Since I'm new to embedded rust, I had to look up probe-rs, which looks pretty cool. But, what I can't find the answer to my usual question: why would I want to switch from OpenOCD to probe-rs? Sure, it's using DAP, and I use VS Code. But how is that better than what I have working today? All I could find...
<re_irc> ... seemed to assume that you already know why you would want to use it. I don't. Is that information out there somewhere?
<re_irc> <@a​damgreig:m​atrix.org> mainly because it means you don't need to use openocd!
<re_irc> <@a​damgreig:m​atrix.org> but it's also shockingly convenient and useful, it has a lot of integration with rust projects and stuff like RTT built in is really nice
<re_irc> <@a​damgreig:m​atrix.org> (maybe the new openocd release actually has rtt built in now too?)
<re_irc> <@j​ohn_socha:m​atrix.org> Ah, RTT sounds cool. I had to look that up. Regarding OpenOCD, given that I'm using VS Code, I don't interact directly with it. So I get a familiar UX for debugging and don't really see OpenOCD. Are the objections to OpenOCD for when you're not using something like VS Code? Or are there other issues?
<re_irc> <@a​damgreig:m​atrix.org> if it's working nicely for debugging and programming from vscode for you now, I guess you might as well stick with it
<re_irc> <@a​damgreig:m​atrix.org> openocd didn't have a new release for years, so many users had to build it from source (or more likely, tried using their distribution's package and reported bugs and errors) which was a pain, and it can be fiddly to get it working with your probe and target
<re_irc> <@a​damgreig:m​atrix.org> now that they've finally had a new release it's a lot easier to have it be up-to-date and support newer targets and probes, but nevertheless I find it pretty clunky to use in comparison
<re_irc> <@a​damgreig:m​atrix.org> still, it's mature software that's well tested with vscode, so if that's working OK for you... maybe give probe-rs a try sometime when you're bored
<re_irc> <@a​damgreig:m​atrix.org> RTT is _extremely_ cool and useful though, that's definitely worth investigating sooner rather than later
<re_irc> <@j​ohn_socha:m​atrix.org> OK, those are all compelling reasons. I'm using a Nucleo board, so I may have gotten lucky. I'm going to give it a try--but I like to understand what the advantages are of one over the other.
<re_irc> <@j​ohn_socha:m​atrix.org> And RTT sounds very useful.
<re_irc> <@a​damgreig:m​atrix.org> if you're not already using them, either cargo-embed or probe-run are popular ways to integrate probe-rs and rtt into your cargo workflow, too
<re_irc> <@a​damgreig:m​atrix.org> I mostly am running cargo from the command line, so i don't know much about the state of integrating everything into vscode, but there's been a lot of recent work on it
<re_irc> <@r​icharddodd:m​atrix.org> I think there are interesting similarities between RTT and io_uring: using queues in buffers reduces the amount of context switching/SWD routines in linux/embedded respectively.
<re_irc> <@r​icharddodd:m​atrix.org> (Please correct me if I'm wrong)
<re_irc> <@n​ewam:m​atrix.org> That's accurate, you see that pattern a lot these days.
<re_irc> <@n​ewam:m​atrix.org> If you take a look at the NVMe spec it is all submission queue / completion queue based as well.
<re_irc> <@r​icharddodd:m​atrix.org> and vulkan?
<re_irc> <@n​ewam:m​atrix.org> no experience with that personally
<re_irc> <@r​icharddodd:m​atrix.org> I think the general rule is: if you queue up a load of tasks in a buffer and then switch to the other context it can handle them in batch, rather than having to switch context for each separate operation.
<re_irc> <@r​icharddodd:m​atrix.org> which seems like a good trade if you have the memory
GenTooMan has quit [Ping timeout: 250 seconds]
<re_irc> <@r​icharddodd:m​atrix.org> vulkan has command queues: you send over a list of commands in the render pipeline to the GPU and then say "go". Compare to OpenGL 2, where each draw required syncronization between GPU and CPU.
<re_irc> <@r​icharddodd:m​atrix.org> (again I might be misunderstanding)
<re_irc> <@r​icharddodd:m​atrix.org> I do love spotting patterns :)
GenTooMan has joined #rust-embedded
<re_irc> <@r​icharddodd:m​atrix.org> I got to use my "the hardest 2 things in computer programming are cache invalidation, naming things, and off-by-one errors" quote on a tis100 reddit the other day, which I think I stole from here :)
GenTooMan has quit [Excess Flood]
GenTooMan has joined #rust-embedded
<re_irc> <@e​milgardis:m​atrix.org> @adamgreig Ill do the reddit post, title same as github issue
GenTooMan has quit [Ping timeout: 255 seconds]
GenTooMan has joined #rust-embedded
<re_irc> <@a​damgreig:m​atrix.org> thanks!
<re_irc> <@j​amesmunns:m​atrix.org> Up on twitter now too!
<re_irc> <@j​amesmunns:m​atrix.org> https://twitter.com/rustembedded/status/1419432128954122253
fabic_ has joined #rust-embedded