01:00 <re_irc> < (@alex:matrix.sempto.net)> So the embedded book says about allocators:

01:00 <re_irc> > However, we strongly suggest you use a battle tested allocator from crates.io in your program instead of this allocator.

01:00 <re_irc> Does anybody have a recommendation for a battle tested allocator?

02:04 <re_irc> < (@sparky:matrix.possumlodge.me)> : well, it doesnt appear to be working despite compiling with instructions like telling the display to clear or draw a rect. we can make the display swap its backlight on and off, but thats controled by a chip external to the LCD display and thus doesnt involve that driver

02:04 <re_irc> as far as we can tell, weve done nothing wrong outside of fighting a lot with it to get it to this point (including apparently needing a small edit to the esp-idf-hal due to what appears to my uneducated eyes as weird trait bounds in your driver where its trying to ensure our input only GPIO Pin 38 satisfies the Output trait), and basically... nothing we do makes it display a thing. any ideas? https://git.avii.nl/AviiNL/esp-test

02:05 <re_irc> < (@duskmoon:matrix.org)> Maybe this: https://crates.io/crates/buddy_system_allocator

02:05 <re_irc> Though I think it depends on what you expect

02:09 <re_irc> < (@duskmoon:matrix.org)> It is used in rCore (a toy OS used in courses), oreboot and some other toy os. Might fit your need for a "tested allocator"

02:14 <re_irc> <AviiNL> o/

02:14 <re_irc> < (@alex:matrix.sempto.net)> : It is a hobby project, so I don't expect much. I was concerned that I would pick something not suitable for embedded

02:16 <re_irc> < (@almindor:matrix.org)> : How is the spi configured? I only see you use spi2 but is it MODE_0, MODE_3 etc.

02:16 <re_irc> <AviiNL> How would I check that?

02:30 <re_irc> < (@almindor:matrix.org)> One other thing you can try is using v0.3 of mipidsi. I did a ton of refactoring and i don't have this model. It's possible i broke something.

02:32 <re_irc> <AviiNL> 0.3.0 doesnt have the model for ILI9342c

02:33 <re_irc> < (@almindor:matrix.org)> Oh, 0.4 then :)

02:33 <re_irc> <AviiNL> oh, via tags it does lol

02:34 <re_irc> < (@almindor:matrix.org)> As for the spi, no idea. I can have a look at the hal tomorrow to see what they use. It needs to match the mode the display expects

02:35 <re_irc> < (@almindor:matrix.org)> Generally mode0 is used. Also the spi speed needs to be below the max treshold for the display. This depends on variants too.

02:38 <re_irc> <AviiNL> What struck me as weird, that I just noticed, I'm using the M5Core2, in their docs they specify that the display is a ILI9342C, but in the c++ source they distribute with it, the display driver references ILI9341

02:39 <re_irc> < (@almindor:matrix.org)> O.o

02:39 <re_irc> <AviiNL> https://github.com/m5stack/M5Core2/blob/master/src/utility/ILI9341_Defines.h

02:40 <re_irc> <AviiNL> vs https://docs.m5stack.com/en/core/core2

02:41 <re_irc> <AviiNL> They may have just grabbed the sources from Bodmer/TFT_eSPI and changed the values from their ILI9341 without changing the variables names

06:59 <re_irc> < (@shrek_3:matrix.org)> Is avr-hal still the way to go for working with avr in rust? Currently trying it and it seems like a storm of shit.

07:09 <re_irc> < (@shrek_3:matrix.org)> The library itself is great. But working with it within the rust ecosystem is just a mess it seems? Maybe it’s just me but I feel like it’s such a hack job to try to get this compiled.

07:13 <re_irc> < (@ryan-summers:matrix.org)> Honestly IMO the reason is that AVR isn't really actively building new things since they got acquired by Microchip a number of years ago, so the professional need for AVR libs is low

07:13 <re_irc> < (@ryan-summers:matrix.org)> But that's 100% my opinion

07:14 <re_irc> < (@ryan-summers:matrix.org)> They're also generally older chips that conform less with current norms, hence why the tooling and usage in Rust is hard. Atmel chips generally pre-date embedded Rust by a number of years

07:15 <re_irc> < (@ryan-summers:matrix.org)> And honestly if there's little industry interest in using the chips in products, I suspect that will lead to continued lack of interest in professional development of the tooling etc.

07:15 <re_irc> < (@ryan-summers:matrix.org)> A lot of stuff using AVRs has likely been in production for years and they're not actively developing new code for it, but just my two cents as I noted above

07:16 <re_irc> < (@shrek_3:matrix.org)> : Makes sense. Thanks for the response.

08:46 <re_irc> < (@therealprof:matrix.org)> : It's a rather outdated 8-bit architecture and great for building simple applications, possibly even in handwritten assembly. Not so great for modern compilers though since they have been developped for mainstream 32+ bit processors and are struggling quite a bit with the pecularities of those traditional architectures like AVR/PIC8/PIC12/PIC16/8051...

11:31 <re_irc> <murat_ursavas> Hey Folks. I'm new here and hope not to step on some rules :)

11:31 <re_irc> I need to check out some of the Special Function Registers of an RP2040 MCU. I'm used to do that in Eclipse and C/C++ environment but never done for Rust on VSCode. Is there a way to do that?

11:31 <re_irc> Thanks in advance.

11:31 <re_irc> < (@k900:0upti.me)> What do you mean by "check out"?

11:32 <re_irc> <murat_ursavas> Reading current values of them.

11:32 <re_irc> < (@k900:0upti.me)> You can run GDB commands from the VScode debug console

11:33 <re_irc> <murat_ursavas> I'd appreciate an example command.

11:33 <re_irc> < (@marmrt:matrix.org)> "x 0xADDRESS"

11:33 <re_irc> < (@k900:0upti.me)> "-exec info registers" should work

11:34 <re_irc> < (@k900:0upti.me)> Or "-exec print 0xDEADBEEF" for MMIO

11:35 <re_irc> <murat_ursavas> Thanks for your effort. I'm getting "Architecture of file not recognized. (from interpreter-exec console "exec info registers")" response for "exec info registers" command.

11:35 <re_irc> < (@k900:0upti.me)> It's "-exec"

11:36 <re_irc> <murat_ursavas> I previously got "Undefined MI command: exec (from exec info registers)" for it.

11:36 <re_irc> <murat_ursavas> Maybe running in wrong place.

11:37 <re_irc> <murat_ursavas> I'm entering these commands into "Debug Console", is that correct tab?

11:37 <re_irc> < (@k900:0upti.me)> Yes

11:37 <re_irc> < (@k900:0upti.me)> Are you doing "-exec exec info registers" or something?

11:37 <re_irc> < (@k900:0upti.me)> Can you post a screenshot of the exact command you're running and the error message?

11:37 <re_irc> <murat_ursavas> Nope, just the one you have written.

11:37 <re_irc> <murat_ursavas> OK.

11:37 <re_irc> < (@k900:0upti.me)> Also, what debugger extension are you using?

11:38 <re_irc> <murat_ursavas> https://psion.agg.io/_matrix/media/r0/download/matrix.org/DAUbVZsXoTawDDkIFiobvtLJ/image.png

11:38 <re_irc> <murat_ursavas> It should be cortex-debug. Let me check the version.

11:39 <re_irc> < (@k900:0upti.me)> Then it probably needs GDB commands directly

11:39 <re_irc> < (@k900:0upti.me)> As in just "info registers"

11:41 <re_irc> <murat_ursavas> That could be the correct usage. It says "Selected thread is running. (from interpreter-exec console "info registers")"

11:41 <re_irc> < (@k900:0upti.me)> You need to do it when it's stuck on a breakpoint

11:41 <re_irc> <murat_ursavas> Oh, OK. You're right :)

11:42 <re_irc> <murat_ursavas> "info registers 51-interpreter-exec console "info registers" {"output":"","token":51,"outOfBandRecord":[],"resultRecords":{"resultClass":"done","results":[]}}"

11:42 <re_irc> < (@k900:0upti.me)> I'm honestly not sure what that extension is diong

11:42 <re_irc> < (@k900:0upti.me)> * doing

11:42 <re_irc> <murat_ursavas> 51-interpreter-exec console "info registers"

11:42 <re_irc> {"output":"","token":51,"outOfBandRecord":[],"resultRecords":{"resultClass":"done","results":[]}}`

11:43 <re_irc> < (@k900:0upti.me)> And what its gdb is doing

11:43 <re_irc> < (@k900:0upti.me)> Maybe you can read them from memory with "print 0xSOMEADDRESS"

11:43 <re_irc> < (@k900:0upti.me)> Assuming they are memory mapped

11:43 <re_irc> <murat_ursavas> No worries, this could lead me to a solution. Thanks a lot, I appreciate it. 👍️

11:44 <re_irc> <murat_ursavas> : That could be pretty manual, but it's at least a solution.

11:47 <re_irc> <murat_ursavas> if of course I can get some useful information back :) Looks like the output is very similar for random addresses. I'll try to find a valid SFR address from the datasheet.

14:42 <re_irc> < (@simon:delire.party)> in case anyone’s curious about my issue from yesterday about spike and pipes, I think I found the cause: https://github.com/riscv-software-src/riscv-isa-sim/issues/1134#issuecomment-1293605169

17:53 <re_irc> < (@xiugaze:matrix.org)> Hi all,

17:53 <re_irc> struct PA0 { _0: () }

17:53 <re_irc> impl PA0 {

17:53 <re_irc> ... long message truncated: https://psion.agg.io/_matrix/media/r0/download/psion.agg.io/C8LEzdbBrlaaAwTheZCXutMZCVi48Swo (23 lines)

17:53 <re_irc> have a quick question about something in the "svd2rust" docs.

17:53 <re_irc> < (@xiugaze:matrix.org)> The reference to "*GPIOA" is on line 5

17:54 <re_irc> < (@xiugaze:matrix.org)> Is there a way to get that pointer without first calling "Peripherals::take()"

17:54 <re_irc> < (@jamesmunns:beeper.com)> Yes, the "GPIOA" type will be exported by the generated code

17:55 <re_irc> < (@xiugaze:matrix.org)> In that case, what should my import for that file look like

17:55 <re_irc> < (@xiugaze:matrix.org)> to import the GPIOA type

17:55 <re_irc> use your_pac::gpio::GPIOA;

17:55 <re_irc> let gpioa: &GPIOA = unsafe { &*GPIOA::PTR };

17:55 <re_irc> < (@jamesmunns:beeper.com)> you should be able to do something like:

17:55 <re_irc> < (@jamesmunns:beeper.com)> the path depends on the crate. you can usually use rust-analyzer or rustdoc/cargo doc to help you find that struct

17:56 <re_irc> < (@xiugaze:matrix.org)> got it, that worked

17:56 <re_irc> < (@xiugaze:matrix.org)> thank you

17:56 <re_irc> < (@jamesmunns:beeper.com)> that being said, the REASON that the "configure" functions take ownership is that you SHOULD only call that method once

17:56 <re_irc> < (@jamesmunns:beeper.com)> and taking ownership enforces that rule.

17:57 <re_irc> < (@xiugaze:matrix.org)> so in the PAC i'm using, rust-analyzer finds GPIOA in two places: pac::GPIOA and pac::gpioa::GPIOA

17:57 <re_irc> < (@xiugaze:matrix.org)> what's the difference here

17:57 <re_irc> < (@jamesmunns:beeper.com)> Otherwise you might configure it differently somewhere else, and invalidate the "safe" code that depends on that

17:57 <re_irc> < (@jamesmunns:beeper.com)> : it depends on your crate. one is probably just a re-export of the other.

17:57 <re_irc> < (@jamesmunns:beeper.com)> you'd have to look at the code to figure out what is different.

17:58 <re_irc> < (@orclev:matrix.org)> at the end of the day all these things are just pointers, requiring ownership and making wrappers around them them is leveraging the ownership model in Rust to enforce safe access patterns. You can bypass those mechanisms as is done in that snippet above if you're sure it's safe, but you should probably take a very hard look at what you're doing if you find that you need to do that often.

18:03 <re_irc> < (@firefrommoonlight:matrix.org)> At the core of this is the beauty of Rust's safety system. It's as power and as flexible as you need, but those unsafe blocks should be a caution, and the first place to look if weird stuff happens!

18:07 <re_irc> < (@jamesmunns:beeper.com)> Unrelated , is your name a pun on "shoegaze", like the music?

22:49 <re_irc> < (@almindor:matrix.org)> AviiNL: any luck?