IlPalazzo-ojiisa has quit [Remote host closed the connection]
<re_irc>
<dngrs (spookyvision@{github,cohost})> impressive in its own way
starblue has quit [Ping timeout: 246 seconds]
starblue has joined #rust-embedded
<re_irc>
< (@762spr:matrix.org)> Is there a better way to do this? I'm using a heapless::String to gather 11 bytes from a 512 byte buffer. This works, but I was hoping to go straight from an array to the String without having to do the loop?
<re_irc>
let mut name: String<11>= String::new();
<re_irc>
for c in 0x47..=0x47+11{
<re_irc>
name.push(buf[c] as char).ok();
<re_irc>
};
<re_irc>
< (@762spr:matrix.org)> Is there a better way to do this? I'm using a heapless::String to gather 11 bytes from a 512 byte buffer. This works, but I was hoping to go straight from an array to the String without having to do the loop?
<re_irc>
let mut name: String\<11>= String::new();
<re_irc>
for c in 0x47..=0x47+11{
<re_irc>
name.push(buf\[c\] as char).ok();
<re_irc>
};
<re_irc>
< (@762spr:matrix.org)> Is there a better way to do this? I'm using a heapless::String to gather 11 bytes from a 512 byte buffer. This works, but I was hoping to go straight from an array to the String without having to do the loop?
<re_irc>
let mut name: String\<11>= String::new();
<re_irc>
for c in 0x47..=0x47+11{
<re_irc>
name.push(buf\[c\] as char).ok();
<re_irc>
};
<re_irc>
< (@jamesmunns:beeper.com)> "String::from_bytes(&buf[0x47..][..=11])?;" or something like that?
<re_irc>
< (@762spr:matrix.org)> I think I tried that but I must have done something wrong... let me try again 😅
<re_irc>
< (@jamesmunns:beeper.com)> Might not be the exact right method, but it probably has some kind of from slice/extend from slice checked method
<re_irc>
< (@762spr:matrix.org)> ah yeah, there's no from bytes method. just from iter and from str
<re_irc>
< (@jamesmunns:beeper.com)> From Str, or you can collect the slice into a heapless vec then convert to String from that? But from iter should work
<re_irc>
< (@jamesmunns:beeper.com)> Or "String::from_str(core::str::from(&buf[...])?)?"
<re_irc>
<thejpster> Does anyone in the UK have a Saleae Logic Pro 8 or Pro 16, and some time to debug some weird SPI issues?
<re_irc>
<thejpster> I only have a Picoscope 2205MSO and it's not fast enough. And I don't currently have the £750 I need to buy a Logic Pro 8. It's a fully open source project (I'm not asking you to do my job for me ...)
<re_irc>
<thejpster> I can post you a PCB and all the parts, but I'd rather not post it outside of the UK because shipping is expensive and the receiver will have to pay VAT and handling charges on import.
<re_irc>
<Félix | Totem> I'm fed up with "stm32f3xx-hal". I merely moved around a module (from inline to its own file) and everything crashes again after that. No unsafe code. There is something wrong with this crate.
<re_irc>
<Félix | Totem> That smells UB, so I guess that they messed up with their unsafe code.
<re_irc>
<thejpster> Félix | Totem: if you are working on a commercial project, there are people who can help with that sort of thing.
<re_irc>
<Félix | Totem> thejpster: No, I'm not. I'ts a hobby. I know that it's an open-source & free crate, so they're no hard feeling from myself, but:
<re_irc>
- I'm a noob, so I cannot really contribute, I think. I'm trying to look at where the issue is (installing the debugger right now), I'll see if it leads somewhere…
<re_irc>
- I do nothing fancy, so it's kinda weird that I'm the only one to encounter those weird behaviors.
<re_irc>
<Félix | Totem> From the beginning of my project, I need to move around a code to turn my leds on whenever I modify the code somewhere else (leds are in GPIOB). Otherwise, everything crashes.
<re_irc>
< (@k900:0upti.me)> That sounds like a compiler issue possibly
<re_irc>
< (@dirbaio:matrix.org)> though stm32f3xx-hal shouldn't be _that_ broken, as far as I know...
<re_irc>
<Félix | Totem> : Yeah, I think I'll go that path.
starblue has quit [Ping timeout: 260 seconds]
starblue has joined #rust-embedded
<re_irc>
<Félix | Totem> : Wow, you were right! I just updated the compiler, and the issues vanished :O Apologies to the crate maintainers :D
<re_irc>
I never think that there can be a compiler problem. I assume it's my fault by default (or the other devs' fault).
<re_irc>
< (@k900:0upti.me)> What compiler version were you on before?
<re_irc>
<Félix | Totem> : I went from "1.65.0 (897e37553 2022-11-02)" to "1.66.1 (90743e729 2023-01-10)"
<re_irc>
<Félix | Totem> OTOH, I removed the weird dance I do with leds initialization, and the program still crashes…
<re_irc>
< (@k900:0upti.me)> What dance, and how does it crash?
<re_irc>
<thejpster> This sounds like linker roulette
<re_irc>
<thejpster> That is: you have some issue with memory layout and the random order the linker lays things out in RAM means it either works or it doesn't work. So moving some code may look like it made it work, but it wasn't the code you moved, it was that the recompile randomly laid things out in another order.
<re_irc>
<thejpster> I'm not saying this is definitely your issue, but it reminds me of an issue I've seen several times before.
<re_irc>
<Félix | Totem> : I have a struct that holds the leds pins:
<re_irc>
let mut gpiob = cx.device.GPIOB.split(&mut rcc.ahb);
<re_irc>
< (@9names:matrix.org)> Are you doing release builds?
<re_irc>
<Félix | Totem> thejpster: What can I do if that's my issue?
<re_irc>
<Félix | Totem> : I use "cargo objcopy --release -- -O binary app.bin"
<re_irc>
<thejpster> Compare your device's _actual_ memory layout with your memory.x file, and the output of the linker map file (or the objdump -t output).
<re_irc>
<Félix | Totem> thejpster: You lost me, here…
<re_irc>
< (@k900:0upti.me)> Post your memory.x file
<re_irc>
<Félix | Totem> Just a minute, I need to rewrite the changes that made it crash. I rolled back
<re_irc>
<Félix | Totem> : Then, I made it crash again. How can I output this file?
<re_irc>
<thejpster> It's in your source tree.
<re_irc>
< (@k900:0upti.me)> OK, can you post the entire project?
IlPalazzo-ojiisa has joined #rust-embedded
<re_irc>
<thejpster> Also, the full part number of the STM32 chip you are using. Down to the last digit.
<re_irc>
I must have copy/pasted it from somewhere, but looks like it's OK
<re_irc>
< (@dirbaio:matrix.org)> Félix | Totem: what are you using for logging?
<re_irc>
< (@dirbaio:matrix.org)> or are you flashing the firmware through some USB bootloader and then running it "blind"?
<re_irc>
<Félix | Totem> : My keyboard rgb leds
<re_irc>
< (@jamesmunns:beeper.com)> : Not sure about the nrf91, but the nrf peripherals won't DMA out of flash (e.g. string constants).
<re_irc>
Using the embedded-hal methods should do a temp copy to memory, but you can try copying to a mutable buffer to ensure it is in ram
<re_irc>
<Félix | Totem> : Yeah…
<re_irc>
< (@dirbaio:matrix.org)> oof
<re_irc>
<Félix | Totem> But excepting that bug, that works fine for me, I already have several features working (the matrix, HID interface…)
<re_irc>
<Félix | Totem> I installed GDB, I'll run the firmware through it to see what really happens.
<re_irc>
< (@dirbaio:matrix.org)> you can't run gdb through usb
<re_irc>
<Félix | Totem> Oh.
<re_irc>
< (@dirbaio:matrix.org)> are you comfortable with soldering?
<re_irc>
< (@dirbaio:matrix.org)> there's typically pads for SWD near the microcontroller, even in retail products
<re_irc>
<Félix | Totem> : I'll know when I try for the first time.
<re_irc>
<Félix | Totem> +it
<re_irc>
< (@dirbaio:matrix.org)> if you hook up to those, together with a debug probe
<re_irc>
< (@adamgreig:matrix.org)> thejpster: I have a pro 16 and a separate 1.25Gs/s 16ch LA, what sort of debugging do you need?
<re_irc>
< (@dirbaio:matrix.org)> you can flash the chip directly, get logs from the firmware (with defmt/rtt with probe-run), get stack traces on panic (with probe-run), run GDB...
<re_irc>
< (@dirbaio:matrix.org)> I really recommend doing it
<re_irc>
< (@dirbaio:matrix.org)> writing firmware "blind" with no logs is a giant papin
<re_irc>
< (@dirbaio:matrix.org)> * pain
<re_irc>
<Félix | Totem> So, in layman's terms, I must buy some kind of module, then put it in between the computer and the keyboard, and I can read the console logs?
<re_irc>
< (@dirbaio:matrix.org)> yes
<re_irc>
< (@dirbaio:matrix.org)> like, maybe the crash you're seeing is a trivial mistake where it's panicking and the panic message clearly tells you what's wrong
<re_irc>
< (@dirbaio:matrix.org)> but without seeing the panic message, figuring it out is almost impossible...
<re_irc>
<Félix | Totem> : Can I use it for other chips, after that? I wanna write other projects, with maybe other chips.
<re_irc>
< (@jamesmunns:beeper.com)> Yes, the debugger will work with pretty much all cortex-m chips
<re_irc>
< (@dirbaio:matrix.org)> yeah
<re_irc>
< (@jamesmunns:beeper.com)> Depending on what you buy
<re_irc>
<Félix | Totem> Nice! Which one would you recommend me to buy?
<re_irc>
< (@dirbaio:matrix.org)> I recommend either a raspberry pi pico with the picoprobe firmware, or a stlink v2
<re_irc>
< (@k900:0upti.me)> Check if your keyboard is actually wired for one first
<re_irc>
< (@k900:0upti.me)> It's not something you just stick into a USB port
<re_irc>
< (@dirbaio:matrix.org)> both should be cheap (<$10) and widely available with decently fast shipping (like on amazon etc)
<re_irc>
<Félix | Totem> : Alright, that's where the soldering part comes
<re_irc>
< (@jamesmunns:beeper.com)> : Honestly if you could take/find images of the keyboard circuit board, we could probably help you find/verify
<re_irc>
<Félix | Totem> I'm opening it RN
<re_irc>
< (@jamesmunns:beeper.com)> At least if it's a standard connector, and not just an unlabeled set of test points :)
<re_irc>
<Félix | Totem> The manufacturers know that people will hack it so I expect it to be fairly standard
<re_irc>
<Félix | Totem> I mean, it's a QMK keyboard after all
<re_irc>
<Félix | Totem> : Even after changing the feature to "stm32f303xb", it doesn't work.
<re_irc>
<thejpster> C _ is 48 ping LQFP
<re_irc>
< (@k900:0upti.me)> You need to "cargo clean" first
<re_irc>
< (@k900:0upti.me)> And then rebuild entirely
<re_irc>
<Félix | Totem> I did that
<re_irc>
< (@k900:0upti.me)> So what exactly "doesn't work"?
<re_irc>
<Félix | Totem> Normally, the leds go off, then when I type I can see the letter on my computer, I can see on my board the state of the various key locks, etc.
<re_irc>
Also, the tool that I use to flash the keyboard logs: "Error while clearing the device status: libusb: i/o error [code -1]"
<re_irc>
< (@k900:0upti.me)> That looks like a flashing error
<re_irc>
< (@k900:0upti.me)> So maybe try restarting the keyboard and flashing again
<re_irc>
<Félix | Totem> This only happens after the crash
<re_irc>
<Félix | Totem> If I reset, I can flash it again
<re_irc>
< (@k900:0upti.me)> It is really hard to tell what the actual issue is without a debugger at this point
<re_irc>
< (@k900:0upti.me)> Can you check the bottom of the board for test pins?
<re_irc>
<Félix | Totem> : What are the risks? How can I screw things up?
<re_irc>
< (@k900:0upti.me)> The risks of what?
<re_irc>
< (@k900:0upti.me)> Taking a picture of the bottom of the board?
<re_irc>
<Félix | Totem> I dunno, static discharges, or something if I touch the pcb
<re_irc>
< (@k900:0upti.me)> Don't do it while it's powered and you should be fine
<re_irc>
< (@ryan-summers:matrix.org)> I've personally never blown a board due to ESD, but I know people that have. That's _most_ of the risk of touching it, so touch some big piece of ground to discharge static buildup and you'll probably be fine
<re_irc>
< (@ryan-summers:matrix.org)> A keyboard isn't high-powered/high-voltage, so probably very little risk of damaging it unless you get FOD (field-of-debris) on the board that shorts things out
<re_irc>
<Félix | Totem> Isn't the board attached somehow to the ports?
<re_irc>
< (@ryan-summers:matrix.org)> But even that risk is low
<re_irc>
< (@ryan-summers:matrix.org)> USB ports are 5V, super low power
<re_irc>
< (@ryan-summers:matrix.org)> And also generally have ESD protection built-in
<re_irc>
< (@ryan-summers:matrix.org)> If it's plugged in to the wall via a mains connection, be careful. Otherwise, you're fine
<re_irc>
<Félix | Totem> : I'm not sure to understand
<re_irc>
< (@k900:0upti.me)> Don't touch things that are connected to 220V power
<re_irc>
< (@k900:0upti.me)> (or 110V if you're in the US)
<re_irc>
<Félix | Totem> I'm talking about the USB & jack ports: the board is attached to them, right? So I cannot move it like that
<re_irc>
< (@k900:0upti.me)> You should be able to just pull it out of the case
<re_irc>
< (@marmrt:matrix.org)> Félix | Totem: If you're careful, you should be fine
<re_irc>
<Félix | Totem> I think I'll break everything. Also there is a bus for connecting the thumb cluster, I don't understand how to disconnect it
<re_irc>
< (@marmrt:matrix.org)> That said, if you have to apply excessive force, you should back off
<re_irc>
<Félix | Totem> : That doesn't really move when I apply a light pressure with my screwdriver
<re_irc>
< (@k900:0upti.me)> It's probably a latch
<re_irc>
<Félix | Totem> WTF?! After plugging the keyboard back, my firmware works. I tried again to verify: the behavior after the flashing & the behavior after unplugging then plugging it back are not the same 🤔
<re_irc>
< (@k900:0upti.me)> Sounds like a bootloader problem
<re_irc>
<Félix | Totem> That I cannot solve, I wager
<re_irc>
< (@k900:0upti.me)> The bootloader doesn't actually hard reset the hardware, so it might be leaving bits of state around
<re_irc>
<Félix | Totem> : That may explain everything.
<re_irc>
<Félix | Totem> i thought that soft & hard reset were functionally the same
<re_irc>
<Félix | Totem> There's nothing I can do, then. Thanks to everyone who've helped me.
<re_irc>
< (@dirbaio:matrix.org)> you can find out what that is, and have your firmware reinitialize it properly
<re_irc>
< (@dirbaio:matrix.org)> if the original firmware does it then a Rust firmware can do it too
<re_irc>
<Félix | Totem> : That seems easier said than done. How would you find where the issue is?
<re_irc>
< (@dirbaio:matrix.org)> dunno
<re_irc>
< (@dirbaio:matrix.org)> probably find out what's crashing, then go from there
<re_irc>
< (@ryan-summers:matrix.org)> ^ This. I've had the identical problem before and you just have to figure out where things break and look at why
<re_irc>
< (@ryan-summers:matrix.org)> Because ultimately if it doesn't crash, it doesn't matter if it's not initialized exactly as you expect - it's still working
<re_irc>
<Félix | Totem> Yeah, as I wrote earlier, I can make it work by moving the leds code around. Not ideal, but at least it works.
<re_irc>
< (@ryan-summers:matrix.org)> Do that and do a binary search for the line where it fails. Should isolate what peripheral init is breaking
<re_irc>
< (@ryan-summers:matrix.org)> It's not as tedious as it sounds once you get quick at it ;) I've done this often for work
<re_irc>
<Félix | Totem> : I don't think it works that way.
<re_irc>
<Félix | Totem> I hope you guys working in that field have a good salary, because it's so much harder than a regular dev job…
<re_irc>
< (@dirbaio:matrix.org)> it's hard because you're not using a debug probe :P
<re_irc>
<Félix | Totem> : But the code isn't supposed to break when I move the line to turn a led on around
<re_irc>
< (@k900:0upti.me)> It may
<re_irc>
< (@k900:0upti.me)> If it's sensitive to _some other timing_
<re_irc>
<Félix | Totem> It's all in the RTIC init function
<re_irc>
<Félix | Totem> * within
<re_irc>
<thejpster> The Rust compiler has enough users that we can say there’s a very good chance it’s not doing anything wrong here. The variables are the configuration and the hardware. And as someone who does this for a living, you need good quality tools to investigate. Like a debug probe. At this point I would suspect half your SRAM being bad before I would suspect the compiler.
<re_irc>
<thejpster> But I understand how frustrating it is when things don’t work. We’ve all been there and gotten that T shirt.
bjc has quit [Remote host closed the connection]
emerent has quit [Ping timeout: 256 seconds]
emerent has joined #rust-embedded
bjc has joined #rust-embedded
<re_irc>
<thejpster> : let me dm you
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
bjc has quit [Remote host closed the connection]
bjc has joined #rust-embedded
bjc has quit [Remote host closed the connection]
bjc has joined #rust-embedded
<re_irc>
<Félix | Totem> thejpster: What T-shirt?
<re_irc>
< (@jamesmunns:beeper.com)> it's a joke saying
<re_irc>
< (@jamesmunns:beeper.com)> "been there, done that, got the t-shirt"
<re_irc>
<Félix | Totem> Oh, right. I'm not a native English speaker (as you can see in my broken syntax), so I don't understand all the jokes/subtleties, which are arguably the hardest part of a language.
<re_irc>
<Félix the Newbie> +(Also, my first name has an accent, which is a giveaway)
<re_irc>
<Félix the Newbie> +dead
<re_irc>
< (@adamgreig:matrix.org)> hi room , meeting time again! agenda is https://hackmd.io/1WZOOH_qSriqSZYibzBZUA, please add anything you'd like to announce or discuss and we'll start in 5 minutes or so
<re_irc>
< (@jamesmunns:beeper.com)> I hope everyone had a good week!
<re_irc>
< (@adamgreig:matrix.org)> I learnt more about FET safe operating areas than I wanted to 😆
<re_irc>
< (@adamgreig:matrix.org)> anyway let's start, I don't have any announcements from the last week, does anyone else?
<re_irc>
< (@jamesmunns:beeper.com)> Certainly one kind of alternative to coffee!
<re_irc>
< (@korken89:matrix.org)> o/
<re_irc>
< (@adamgreig:matrix.org)> the SOA stuff is really boring, you can be well within the Vds limit and the Id limit but still blow the thing up with like a millisecond of too much current for the particular Vds, sigh
<re_irc>
< (@adamgreig:matrix.org)> oh, yea! and that includes cargo-flash and cargo-embed
<re_irc>
< (@dkhayes117:matrix.org)> : mentioned he thought embedded-alloc should be hal team, I think.
<re_irc>
< (@adamgreig:matrix.org)> yea, I've got that to discuss in the agenda
<re_irc>
< (@adamgreig:matrix.org)> we did briefly talk about it last week and concluded we'd leave it in cortex-m for the time being, but we can rediscuss
<re_irc>
< (@eldruin:matrix.org)> yeah it was brought up by some people
<re_irc>
< (@eldruin:matrix.org)> sounds good to keep it in cortex-m, just wanted to talk about it
<re_irc>
< (@jannic:matrix.org)> I know probe-run is a different organization, but does someone know if it can be updated to current probe-rs easily or if there are blockers?
<re_irc>
< (@eldruin:matrix.org)> I was not here last week
<re_irc>
< (@adamgreig:matrix.org)> I don't want the hal team to become the dumping ground for anything cross-platform
<re_irc>
< (@diondokter:matrix.org)> : Probably it's just work that needs to be done. Depends on the changed APIs really
<re_irc>
< (@adamgreig:matrix.org)> but we don't have a team for that sort of thing, and i'm also not sure it makes sense to make a new team
<re_irc>
< (@dirbaio:matrix.org)> : there's "probe-rs-cli run" which is similar but always-updated since it's part of probe-rs
<re_irc>
< (@therealprof:matrix.org)> : Probably not without finding more members...
<re_irc>
< (@adamgreig:matrix.org)> in my head the hal repos would ideally be the things that are cross-platform traits and the like, whereas embedded-alloc is an implementation.... but it's also really just a wrapper around the linked-list-alloc so it's not like it should be a significant maintenance overhead
<re_irc>
< (@adamgreig:matrix.org)> in practice I don't know how much difference it would make
<re_irc>
< (@adamgreig:matrix.org)> if you think it would be a good fit for the hal team I'm very happy to move it over, it obviously doesn't fit within "cortex-m team" either
<re_irc>
< (@eldruin:matrix.org)> keeping it where it is would ensure the maintainers are the ones that most know the history and background
<re_irc>
< (@adamgreig:matrix.org)> : does this do rtt?
<re_irc>
< (@eldruin:matrix.org)> it's fine with me
<re_irc>
< (@dirbaio:matrix.org)> : rtt, or defmt
<re_irc>
< (@dirbaio:matrix.org)> * defmt-rtt
<re_irc>
< (@adamgreig:matrix.org)> huh cool, I wondered but the help text/description doesn't seem to mention it, probably just missed it
<re_irc>
< (@adamgreig:matrix.org)> : ok, shall we just leave it with cortex-m for now then, and if it becomes an issue we can revisit it?
<re_irc>
< (@eldruin:matrix.org)> : yes, sounds good
<re_irc>
< (@adamgreig:matrix.org)> cool, thanks
<re_irc>
< (@adamgreig:matrix.org)> couple of other cortex-m things, first we've had a bug report about semihosting failing if it's called immediately before exiting under qemu, https://github.com/rust-embedded/cortex-m/issues/459, dunno if anyone's seen anything like that before
<re_irc>
<Ralph> : hm, so is there any point in using "probe-run" over this then? i'm currently using "probe-run" but would prefer to use something which would support a debugger...
<re_irc>
(not something which necessarily needs to be answered during the meeting, i'm AFK now anyway)
<re_irc>
< (@korken89:matrix.org)> : This was a bit weird, and that a well placed "nop" fixes it 😅
<re_irc>
< (@dirbaio:matrix.org)> probe-run still has more features: backtrace on control+c or crash, fancier colors, stack canaries
<re_irc>
< (@adamgreig:matrix.org)> yea... but I was expecting to see that both bkpts would be right next to each other in the failing case, but that's not true either
<re_irc>
< (@adamgreig:matrix.org)> it still jumps to the nop loop it seems?
<re_irc>
< (@korken89:matrix.org)> I've tried to isolate the cause more, but I've not been successful
<re_irc>
< (@thalesfragoso:matrix.org)> : Smells like a missing fence maybe ?
<re_irc>
< (@korken89:matrix.org)> I hope someone has seen something similar and might know what's up
<re_irc>
< (@adamgreig:matrix.org)> I don't think you're meant to need fence calls around bkpt though
<re_irc>
< (@korken89:matrix.org)> It only happens in QEMU though it seems
<re_irc>
< (@thalesfragoso:matrix.org)> Does rtic::pend has the correct fences ?
<re_irc>
< (@adamgreig:matrix.org)> I guess you can't test it on hardware because what would debug::exit do :P
<re_irc>
< (@korken89:matrix.org)> BKPT :D
<re_irc>
< (@k900:0upti.me)> QEMU definitely has some correctness issues emulating ARM over x87
<re_irc>
< (@k900:0upti.me)> * x86
<re_irc>
< (@k900:0upti.me)> I remember Go programs specifically exploding in very exciting ways because of all the stack trickery they're doing
<re_irc>
< (@korken89:matrix.org)> : Fences are not needed as the NVIC is direct in taking pending IRQs (unless IRQs are masked)
<re_irc>
< (@korken89:matrix.org)> So maybe it's just a QEMU bug
<re_irc>
< (@korken89:matrix.org)> That somehow is triggered
<re_irc>
< (@k900:0upti.me)> The QEMU people are usually pretty responsive to those kinds of bugs though
<re_irc>
< (@k900:0upti.me)> Even if you have no reliable repro case
<re_irc>
< (@thalesfragoso:matrix.org)> : I mean compiler fences
<re_irc>
< (@jamesmunns:beeper.com)> I also don't see a difference in the nop or bkpt asm, are those tests using the inline asm stuff these days?
<re_irc>
< (@jamesmunns:beeper.com)> (at least wrt any flags, etc.)
<re_irc>
< (@korken89:matrix.org)> On the issue, if you do "hprintln!" and directly after that "debug::exit" you get the same bug
<re_irc>
< (@korken89:matrix.org)> It's not dependent on the "rtic::pend"
<re_irc>
< (@adamgreig:matrix.org)> ah yea, I thought hrpintln->exit was the bug, was getting confused looking at the screenshot on the issue
<re_irc>
< (@thalesfragoso:matrix.org)> : Hmm, so maybe I got it wrong, I thought the bug was the pend wasn't getting called
<re_irc>
< (@korken89:matrix.org)> Yeah I saw that might confuse, so best to clarify :)
<re_irc>
< (@korken89:matrix.org)> For now we just slap a nop in there
<re_irc>
< (@thalesfragoso:matrix.org)> What is the bug then ?
<re_irc>
< (@korken89:matrix.org)> The statement before debug::exit does not seem to be called
<re_irc>
< (@korken89:matrix.org)> Not sure if that's true though, it seems to be more nuanced than that
<re_irc>
< (@korken89:matrix.org)> Something with how asm is laid out affects it
<re_irc>
< (@thalesfragoso:matrix.org)> I mentioned fenced because without then the compiler could move exit to above the other statements
<re_irc>
< (@thalesfragoso:matrix.org)> * fences
<re_irc>
< (@korken89:matrix.org)> Checking the asm the exit bkpt is in the correct place so I don't think that's the issue
<re_irc>
< (@thalesfragoso:matrix.org)> * them
<re_irc>
< (@korken89:matrix.org)> It's like that extra cycle is needed
<re_irc>
< (@adamgreig:matrix.org)> I wonder if the cortex-m bkpt method should have a fence around it even so
<re_irc>
< (@adamgreig:matrix.org)> but yea, this seems more like a qemu issue maybe?
<re_irc>
< (@korken89:matrix.org)> : I think probably
<re_irc>
< (@korken89:matrix.org)> We will probably poke it a bit more after the current development on RTIC 2 is done
<re_irc>
< (@adamgreig:matrix.org)> yea, I can't see anything about it in the relevant arm docs either
<re_irc>
< (@adamgreig:matrix.org)> we could add a nop in cortex-m-semihosting easily enough if it is a known qemu bug though, especially on debug::exit which is basically only used inside tests
<re_irc>
< (@adamgreig:matrix.org)> but it would be good to understand the cause a bit more first
<re_irc>
< (@korken89:matrix.org)> I just want to verify that it actually is a bug and not some other UB/sideeffect that is manifested
<re_irc>
< (@adamgreig:matrix.org)> indeed
<re_irc>
< (@korken89:matrix.org)> But lets keep it open and maybe revisit a bit later?
<re_irc>
< (@korken89:matrix.org)> A bit old though
<re_irc>
< (@korken89:matrix.org)> Maybe it's removed in newer specs?
<re_irc>
< (@adamgreig:matrix.org)> indeed
<re_irc>
< (@adamgreig:matrix.org)> so, it does seem like it's wrong in the riscv crate either way though
<re_irc>
< (@dkhayes117:matrix.org)> The latest ratified spec shows it as WPRI indeed
<re_irc>
< (@adamgreig:matrix.org)> cool, thanks for looking!
<re_irc>
< (@adamgreig:matrix.org)> back to embedded HAL stuff, does anyone want to talk about the pwmpin proposal or the gpio errorkind pr?
<re_irc>
< (@dirbaio:matrix.org)> about pwmpin: 's propoesed changes look good to me, I agree they're better
<re_irc>
< (@dirbaio:matrix.org)> if we get consensus i'll update the PR
<re_irc>
< (@adamgreig:matrix.org)> I was a bit concerned about it needing much wider multiplications
<re_irc>
< (@adamgreig:matrix.org)> and it might be worth still being more explicit about requiring 0=fully off and "max"=fully on
<re_irc>
< (@adamgreig:matrix.org)> but I think some of that concern was from the earlier sketch that had more u64
<re_irc>
< (@dirbaio:matrix.org)> if duty is u16, then it should require only u32 mult, right?
<re_irc>
< (@dirbaio:matrix.org)> no u64 stuff
<re_irc>
< (@adamgreig:matrix.org)> yea, I think it's been updated since my recollection
<re_irc>
< (@adamgreig:matrix.org)> in that earlier version it panicked on out of range duty, but I think maybe clamping would be more reasonable?
<re_irc>
< (@adamgreig:matrix.org)> previously there were no invalid values, whereas now you can specify a duty>max_duty, a denom of 0, a percent > 100, so probably the trait should say what to do about that
<re_irc>
< (@adamgreig:matrix.org)> but yea, the first design probably does often lead to doing calculations twice, so this is likely to be more efficient
<re_irc>
< (@grantm11235:matrix.org)> I'm not sure what should happen if you set the duty above max_duty, maybe just "whatever you want, as long as it isn't UB"?
<re_irc>
< (@adamgreig:matrix.org)> I guess percent>100 is the same as duty>max_duty so that can just be the same
<re_irc>
< (@adamgreig:matrix.org)> denom=0 can just do whatever /0 normally does?
<re_irc>
< (@grantm11235:matrix.org)> Oh, I didn't think of divide-by-zero. Maybe denom should be a NonZeroU16?
<re_irc>
< (@adamgreig:matrix.org)> does that end up being more annoying to use? I guess it's almost always going to be a constant so should be OK?
<re_irc>
< (@adamgreig:matrix.org)> hmm, you can't just pass it in, so it's a bit annoying I guess
<re_irc>
< (@grantm11235:matrix.org)> Yeah, it is probably more trouble that it is worth
<re_irc>
< (@adamgreig:matrix.org)> it'l panic on /0, but if the denom is a constant it should easily avoid any panicking code paths
<re_irc>
< (@adamgreig:matrix.org)> anyone want to briefly discuss anything else before we finish?
<re_irc>
< (@chrysn:matrix.org)> nothing to bring up before-we-finish-wise, but I'd like to make use of the post-meeting everyone-standing-in-the-hallway time to ask what's the way forward with https://github.com/rust-embedded-community/embedded-nal/pull/73 after having 2 ACKs (one of them recent)
<re_irc>
< (@eldruin:matrix.org)> I commented that it had some conflicts
<re_irc>
< (@eldruin:matrix.org)> at least that is what GH says, other than that it is good to merge
<re_irc>
< (@chrysn:matrix.org)> Oh sorry, how did I miss that there was a comment with that -- sorry, checking.
<re_irc>
The current "Controller::new_with_limits" would be fine with me - "Controller::with_capacity" would work as well. I don't have a clear preference.
<re_irc>
< (@chrysn:matrix.org)> I don't see any conflicts, though -- GH says "no conflicts", and given that master was merged in before adding the changelog, it's even fast forward from there.
<re_irc>
< (@eldruin:matrix.org)> for me it says "This branch cannot be rebased due to conflicts"
<re_irc>
< (@eldruin:matrix.org)> ah, I can squash and merge. I'll do that, thanks
<re_irc>
< (@eldruin:matrix.org)> done! thank you for your work!
<re_irc>
< (@chrysn:matrix.org)> Yeah, rebasing won't work when there are semantic merges in place; it's either squash-all or regular merge commit.
<re_irc>
< (@eldruin:matrix.org)> re. e-sdmmc: I think "Controller::new_with_limits" fits better with the default "Controller::new". "Controller::with_capacity" sounds to me a bit more like the builder pattern, where you add a bunch of "with_" options and then say "build()" or so, but that is not the case, it is just a constructor
<re_irc>
< (@eldruin:matrix.org)> "Controller::new_with_capacity" would also be fine
<re_irc>
< (@eldruin:matrix.org)> anyway just my opinion
<re_irc>
< (@chrysn:matrix.org)> capacity sound a bit confusing to me given that it's a term also used for storage capacity.
<re_irc>
< (@jannic:matrix.org)> But a) this isn't a container type, and b) is right, one could confuse the term with the capacity of the storage medium.
<re_irc>
<Milo Moisson> Hi, I have to build a system to communicate via Bluetooth with a micro controller. Is there a lib to build such custom protocols, or maybe a link to a post or a good implementation ?