ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to #rust-embedded:matrix.org and logged at https://libera.irclog.whitequark.org/rust-embedded, code of conduct at https://www.rust-lang.org/conduct.html
cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #rust-embedded
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
cr1901 has quit [Ping timeout: 255 seconds]
cr1901 has joined #rust-embedded
DepthDeluxe has joined #rust-embedded
DepthDeluxe has quit [Ping timeout: 255 seconds]
Foxyloxy has quit [Quit: Textual IRC Client: www.textualapp.com]
Foxyloxy has joined #rust-embedded
<re_irc> < (@texitoi:matrix.org)> Félix | Totem: It mostly mean that the speaker is connected to A5 and A4. You can then do whatever you want, the simpler thing to test it putting one pin to ground, and the other to pwm at something like 440Hz, and you should be able to listen to a A square wave! You can also do more complicated stuff including playing with DAC if available on these pins.
<re_irc> < (@texitoi:matrix.org)> Some fun with pwm https://github.com/TeXitoi/softsynth/blob/master/bluepill-player/src/main.rs
IlPalazzo-ojiisa has joined #rust-embedded
starblue has quit [Ping timeout: 268 seconds]
starblue has joined #rust-embedded
<re_irc> < (@bugadani:matrix.org)> Hi! Does anyone know if its possible to preserve the stack trace when a panic happens? I'm not able to figure out how I can break on rust_begin_unwind but I can put breakpoints into the panic handler just fine (which isn't very helpful because opt-level 1 seems to optimize out the panic info for me...)
<re_irc> < (@bugadani:matrix.org)> * frames
<re_irc> < (@jamesmunns:beeper.com)> Other folks probably know more, but I know there's some weird optimization stuff with divergent functions "like fn panic(...) -> !" that clobber the LR.
<re_irc> Not sure what you're trying to do, but defmt does do stack unwinding (host side) on panics, it might be a good place to look on how to do that?
<re_irc> < (@jamesmunns:beeper.com)> * like "fn
<re_irc> < (@bugadani:matrix.org)> Unfortunately, my mcu is not yet in probe-rs, so anything related (I think that includes defmt) is a chore. All I want is to see what panicked (in this case, I spent an hour finding a todo!()).
<re_irc> < (@marmrt:matrix.org)> https://docs.rs/panic-persist/latest/panic_persist/ might help you
<re_irc> < (@bugadani:matrix.org)> +defmt is also not my current priority (its literally the next item i want to tackle) but maybe I'll just have to reprioritize
<re_irc> < (@marmrt:matrix.org)> Should give you line number and panic msg, at least
<re_irc> < (@bugadani:matrix.org)> : Thanks!
<re_irc> < (@mabez:matrix.org)> : I'm inferring Xtensa here so correct me if I'm wrong. There is an ABI specified frame pointer for Xtensa, so if the frame exists you should be able to read panic info. Perhaps with opt-level = 1 the frame never exists?
<re_irc> < (@bugadani:matrix.org)> : not xtensa this time :)
<re_irc> < (@bugadani:matrix.org)> +MAX32660, just waiting for a stable release
<re_irc> < (@mabez:matrix.org)> Ah gotcha, maybe "-Cforce-framepointers=yes" might help
<re_irc> < (@mabez:matrix.org)> It's been a while since I've touched arm stuff, but that might already be enabled by default IIRC
<re_irc> < (@bugadani:matrix.org)> thank you, but unfortunately it has no effect
<re_irc> < (@bugadani:matrix.org)> * effect, at least not on my problem
<re_irc> < (@dirbaio:matrix.org)> make sure you're not building with build-std-features=panic_immediate_abort
<re_irc> < (@bugadani:matrix.org)> that would also prevent the panic handlers from being called, wouldn't it?
<re_irc> < (@dirbaio:matrix.org)> yea
<re_irc> <Félix | Totem> : Oh, that looks simple
<re_irc> <Félix | Totem> What can be the reasons why writing on a serial crashes? This makes my code crash: "cx.local.serial.write([0, 0, 0x10, 0, 0, 0, 0, 0].as_ref())"
<re_irc> <Félix | Totem> Can it be that's because I send something invalid? From my understanding, it shouldn't matter from the chip side
IlPalazzo-ojiisa has quit [Quit: Leaving.]
<re_irc> < (@jamesmunns:beeper.com)> is that a usb-serial or UART serial?
<re_irc> <Félix | Totem> : usb-serial
<re_irc> < (@jamesmunns:beeper.com)> I don't think there's anything wrong with the _content_ you send. Hard to tell why the USB is upset, buffer could be full?
<re_irc> <Félix | Totem> I don't think so, this is sent once. So there must be something wrong with my USB bus setup
<re_irc> < (@jamesmunns:beeper.com)> Could be! If you link the code I can take a quick peek if there's something obvious
<re_irc> It's fairly simple, I got the pins from the example. Anyway, with the "UsbBusType", it shouldn't compile if there is an error.
<re_irc> <Félix | Totem> It's a pure copy/paste, I don't understand a thing about the code :D
<re_irc> <Félix | Totem> But the type system is so good that until now, I wasn't afraid of any misconfiguration
<re_irc> < (@jamesmunns:beeper.com)> So, total guesses, but:
<re_irc> < (@wassasin:matrix.org)> You do not seem to be polling the USB device
<re_irc> < (@jamesmunns:beeper.com)> - I don't see any interrupt or timer for servicing the USB events
<re_irc> - You may not be able to "send" data until the connection has been established
<re_irc> <Félix | Totem> : Hum, alright, I'll go back to the example to look if I can see those parts.
<re_irc> < (@jamesmunns:beeper.com)> Here's an example on the STM32F4xx-hal of a 1ms periodic poll: https://github.com/jamesmunns/pretty-hal-machine/blob/f1a2ef7cbb62722ee9eb4f288da3559f9b11ad14/firmware/blackpill-phm/src/main.rs#L161-L202
<re_irc> < (@jamesmunns:beeper.com)> (it's doing a lot of other stuff you probably don't need, but the "usb_dev.poll(...)" part is the important one.
<re_irc> < (@jamesmunns:beeper.com)> That services any incoming/outgoing requests.
<re_irc> <Félix | Totem> : Why do I need a poll if it's write-only?
<re_irc> < (@jamesmunns:beeper.com)> you're talking to the host (a PC), and the way USB works, the host drives the communication.
<re_irc> < (@jamesmunns:beeper.com)> Devices (at least in FS mode) "only speak when spoken to".
<re_irc> <Félix | Totem> Oh, that's why…
<re_irc> < (@dirbaio:matrix.org)> why poll every 1ms, and not on irq?
<re_irc> <Félix | Totem> That makes a ton of sense, actually
<re_irc> < (@jamesmunns:beeper.com)> : Honestly I don't remember. If you have an interrupt, that's probably better honestly.
<re_irc> < (@wassasin:matrix.org)> You also may want to poll on your own initiative; not just when you are given an interrupt?
<re_irc> <Félix | Totem> Can I poll right before writing in the bus each time I want to?
<re_irc> < (@jamesmunns:beeper.com)> Yeah, depends on the hardware. USB FS hosts _will_ poll every 1ms or so, different USB devices have different ways of operation
dc740 has joined #rust-embedded
dc740 has quit [Remote host closed the connection]
emerent_ has joined #rust-embedded
emerent is now known as Guest8075
emerent_ is now known as emerent
<re_irc> <Félix | Totem> : I came up with:
<re_irc> #[task(binds = USB_LP, shared = [usb_device, usb_class])]
<re_irc> (cx.shared.usb_device, cx.shared.usb_class).lock(|usb_device, usb_class| {
<re_irc> fn usb_poll(cx: usb_poll::Context) {
<re_irc> <Félix | Totem> I need mu class to implement this trait now: https://docs.rs/usb-device/latest/usb_device/class/trait.UsbClass.html
<re_irc> <Félix | Totem> * my
<re_irc> < (@jamesmunns:beeper.com)> Iirc, keyberon has a builtin hid class
<re_irc> <Félix | Totem> : I'm writing that to learn how to embedded develop, so I'll try to do everything by myself. The task doesn't seem to be too hard (maybe that's me underestimating it, tho :P).
<re_irc> There is some documentation about HID online, that's doable. The main issue is that I don't understand what the trait methods are used for, for now.
<re_irc> < (@jamesmunns:beeper.com)> Ah, I cant help you with that then. You certainly can reinvent the wheel if you'd like! Just pointing out that you don't have to.
<re_irc> < (@jamesmunns:beeper.com)> The trait methods look fairly 1:1 with the USB FS protocol spec.
<re_irc> <Félix | Totem> : I got that, thanks for mentioning it :)
<re_irc> Maybe you're right, that doesn't look like an interesting part, only giving the right codes to the host.
DepthDeluxe has joined #rust-embedded
IlPalazzo-ojiisa has joined #rust-embedded
<re_irc> < (@diondokter:matrix.org)> Hey all, don't know if recruitment is allowed here (so remove this if not), but we have an open vacancy!
<re_irc> Not fully remote! (Expected to be at our office in Nijmegen regularly) But lots of embedded Rust!
<re_irc> Knowing more about hardware than I do is a big plus. (And I know just a little bit)
<re_irc> Do you want to be my colleague?
<re_irc> < (@diondokter:matrix.org)> If you want to know something you can me or dm me. That way I'll get a notification 🙂
<re_irc> < (@jamesmunns:beeper.com)> My $0.02 (not official policy), I think occasional (once every few weeks/months?) promos are fine. If it gets overwhelming (relative to the rest of the traffic here), it might be worth a more specific policy/suggestion for where/how to do things, but I bet it's well received by most folks here :)
<re_irc> < (@jamesmunns:beeper.com)> I'd say if anyone disagrees, feel free to propose it to discuss at the weekly meeting :)
<re_irc> < (@yatekii:matrix.org)> Can only get behind that :) Also, this is a 100% clean offer and highly on topic from what I can tell, so should be fine imo :)
<re_irc> <Félix | Totem> What's the easiest way to use to get a repr(C) struct as a slice of bytes? I know that I can transmute, but I'd like to not use unsafe.
<re_irc> BTW, I don't understand why it'd be unsafe, since AFAIK, every data can be gotten as slice of bytes, by definition.
<re_irc> I like the way that C can write bytes after being given any data.
<re_irc> <Félix | Totem> -use
<re_irc> < (@jamesmunns:beeper.com)> What about padding bytes?
<re_irc> < (@jamesmunns:beeper.com)> e.g:
<re_irc> #[repr(C)]
<re_irc> struct Example {
<re_irc> a: u8,
<re_irc> <Félix | Totem> Oh, can it be C + packed?
<re_irc> <Félix | Totem> I assumed (wrongly, it seems) that repr(C) didn't add padding bytes.
<re_irc> There are some crates to do it to avoid the pitfalls (mostly around padding, and alignment)
<re_irc> < (@jamesmunns:beeper.com)> AFAIK - you can't get turn a struct (and back) into bytes without unsafe.
<re_irc> < (@jamesmunns:beeper.com)> You can! But then you run into alignment issues. You can't (directly) access/reference a "u32" on an unaligned address, which a packed struct might give you.
<re_irc> < (@jamesmunns:beeper.com)> (Rust references are guaranteed to be aligned correctly)
<re_irc> < (@jamesmunns:beeper.com)> Usually - we reach for explicitly serializing/deserializing things instead.
<re_irc> < (@jamesmunns:beeper.com)> like an "into_bytes()" function.
<re_irc> <Félix | Totem> : Unless I read it a bunch of times / µs, it's not an issue, is it?
<re_irc> < (@jamesmunns:beeper.com)> Yes. On Cortex-M, unaligned reads cause a CPU fault
<re_irc> <Félix | Totem> : OK, I think I'll do that, then.
<re_irc> <Félix | Totem> : What? Alright 😆
<re_irc> < (@jamesmunns:beeper.com)> x86 with microcode "fix" this (sometimes with perf penalty), but that's specific to that CPU
<re_irc> < (@jamesmunns:beeper.com)> err, architecture rather.
<re_irc> <Félix | Totem> I assumed that every CPU could do that… Thanks for the tip.
<re_irc> < (@diondokter:matrix.org)> : Cool, was planning on putting it out just once here and couldn't find anything in the CoC that goes against it other than that it could be spam.
<re_irc> < (@diondokter:matrix.org)> : Even when you do "ptr.read_unaligned()"?
<re_irc> pub trait BytesWriter {
<re_irc> fn write_bytes(&self, writer: impl std::io::Writer) -> std::io::Result<usize>;
<re_irc> <Félix | Totem> : With std, I would do it that way:
<re_irc> I wonder how you'd write such a trait within a RTIC project. With "DescriptorWriter"? Is there a more general struct/trait?
<re_irc> }
<re_irc> < (@jamesmunns:beeper.com)> : yes, that's allowed, because you are doing byte-aligned reads, not word (or halfword) reads.
<re_irc> < (@jamesmunns:beeper.com)> "ptr.read_unaligned()" basically casts both pointers to "u8" ptrs and memcpys.
<re_irc> < (@jamesmunns:beeper.com)> (not exactly, but kinda)
<re_irc> < (@diondokter:matrix.org)> Félix | Totem: You can use Serde on no-std just fine
<re_irc> < (@jamesmunns:beeper.com)> Félix | Totem: I gotta run, but I write a lot of code that looks like:
<re_irc> impl Whatever {
<re_irc> fn to_bytes(&self, buf: &mut [u8]) -> Result<&mut [u8], Error> { todo!() }
<re_irc> // on success: returns the portion that was written to. Errors if insufficient space
<re_irc> < (@jamesmunns:beeper.com)> I gotta run, but I write a lot of code that looks like:
<re_irc> impl Whatever {
<re_irc> fn to_bytes<'a>(&self, buf: &'a mut [u8]) -> Result<&'a mut [u8], Error> { todo!() }
<re_irc> }
<re_irc> // on success: returns the portion that was written to. Errors if insufficient space
<re_irc> < (@diondokter:matrix.org)> : Yeah, I've written this as a trait many times! This should become a crate IMO
<re_irc> <Félix | Totem> : Pretty sure it already exists, if everyone keeps writing it
<re_irc> <Félix | Totem> * keep
<re_irc> < (@jamesmunns:beeper.com)> I dunno what a trait would get you, they signature is simple and concrete enough. But it's essentially a distilled serialize interface
<re_irc> < (@jamesmunns:beeper.com)> * the
<re_irc> < (@jamesmunns:beeper.com)> I can't even consistently decide whether to return the written slice, the remainder slice, or both. It depends I guess :)
GenTooMan has quit [Quit: Leaving]
GenTooMan has joined #rust-embedded
<re_irc> <thejpster> Or a usize indicating how much of the buffer was used
<re_irc> <thejpster> Or that remains free ;)
<re_irc> < (@jamesmunns:beeper.com)> I usually prefer a slice because you get it "for free" with split_at_mut, but honestly it's probably all about the same after opt
DepthDeluxe has quit [Ping timeout: 256 seconds]
<re_irc> < (@dirbaio:matrix.org)> serialize/deserialize from rust structs to bytes usually leads to much worse code size than repr(c) transmutes though
<re_irc> < (@dirbaio:matrix.org)> so much worse that I wouldn't call it "best practice"
<re_irc> < (@dirbaio:matrix.org)> imo you should always prefer "repr(C)" / "repr(packed)" if you can (ie if the wire format you're using fits that nicely)
<re_irc> < (@dirbaio:matrix.org)> only if it doesn't (uses clever encoding like varints, has variable length stuff...) then write code to serialize/deserialize
<re_irc> <thejpster> and your wire format always matches System endianness
<re_irc> < (@dirbaio:matrix.org)> true! nowadays almost everything is little endian though
<re_irc> <thejpster> And almost all wire formats are big endian
<re_irc> < (@grantm11235:matrix.org)> Aren't there also some other cases where one systems "repr(C)" is different to another "repr(C)"?
<re_irc> <thejpster> Yes types can have different alignment
<re_irc> <thejpster> You can have a 4 byte aligned u64, for example
<re_irc> <thejpster> Can’t say I’ve made a System where serialisation performance mattered much. The one I week one where code space matters I designed the protocol to be mainly bytes anyway.
<re_irc> <thejpster> * work
<Lumpio-> I have a feeling that a lot of modern wire formats might be little endian
<re_irc> < (@dirbaio:matrix.org)> it's pretty much only ietf stuff that's big endian
<Lumpio-> Which only makes more sense because all new hardware is little endian too.
<re_irc> < (@dirbaio:matrix.org)> as a real-world example: bluetooth HCI is designed to be usable as repr(C) structs, little endian.
<re_irc> < (@dirbaio:matrix.org)> the "bluetooth_hci" crate defines repr(Rust) structs and enums for all the HCI events. The root is "event::Event"
<Lumpio-> Protobuf is little-endian it seems
<re_irc> < (@dirbaio:matrix.org)> The function "Event::new(packet)" deserializes an HCI event from bytes to the Rust enums/structs. It is *35 kilobytes* when building with optimizations
<re_irc> < (@dirbaio:matrix.org)> 35kb for deserializing events alone
<re_irc> < (@dirbaio:matrix.org)> while if you work with pointers to repr(C) structs, the deserialization code is *zero*
<re_irc> < (@dirbaio:matrix.org)> 35kb is comparable to the code size for a whole (but quite feature-light) bluetooth host stack
<re_irc> < (@dirbaio:matrix.org)> and that's not counting code for serializing messages
<re_irc> < (@dirbaio:matrix.org)> yuo can easily get _double_ the code size with "repr(Rust) + de/serialize" vs with "repr(C)"
<re_irc> < (@yatekii:matrix.org)> has anyone ever measured the impact of smallish code changes in FW onto the binary layout?
<re_irc> <Félix | Totem> I think I'll use something like that for the serialization: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=281825f3996e4bbd1ceb814b7d5331f7
<re_irc> With a proc macro to handle the trait impl, it should be much less error prone.
<Lumpio-> To me it feels odd to have the length for a bytewriter as a const
<Lumpio-> Because it would be implemented for both constant and unknown size arrays.
<Lumpio-> s/would/could/
<re_irc> <Félix | Totem> Lumpio-: Well, I don't need it to handle unknown size arrays. I use it to serialize structs with known layout. The issue you talk about will be fixed once the const generics are more featureful.
<re_irc> <Félix | Totem> Also, if the "as_array" func is removed, I don't need the const generic
<re_irc> <Félix | Totem> * generic, which may indeed be better…
<re_irc> <Félix | Totem> There is this too: https://crates.io/crates/ssmarshal, but the numbers are little-endian only.
DepthDeluxe has joined #rust-embedded
<re_irc> < (@dirbaio:matrix.org)> is there some magic method to chunk a range? like "(15..42).chunks(10)", which would return an iterator yielding "15..25, 25..35, 35..42"
<re_irc> < (@ryankurte:matrix.org)> : "encdec::Encode" (https://docs.rs/encdec/latest/encdec/trait.Encode.html) ? :-{
<re_irc> < (@ryankurte:matrix.org)> * :-P
<re_irc> <Félix | Totem> : I don't understand that part:
<re_irc> > If you don’t need to control the encoded layout directly you might like to look at serde
<re_irc> < (@grantm11235:matrix.org)> : Do you need an iterator of ranges specifically, or would an iterator of some "impl Iterator" work?
DepthDeluxe has quit [Ping timeout: 260 seconds]
<re_irc> < (@dirbaio:matrix.org)> I need start,len for each subrange, i'm not going to iterate them
<re_irc> < (@dirbaio:matrix.org)> it's quick enough to put together with ".step_by()", I was just wondering if there was some magic method I've missed
<re_irc> <bitts> I am struggling a bit with the sdram/fmc on a stm32H750 discovery board. I used the fmc example in stm32h7xx-hal as a starting point, but adjusted the pins (only 16 data lines) and chip. It is almost working, but every second index is always 0 when read. So with a buf: &mut [u16], writing to and reading from buf[0], buf[2] etc is just fine, but buf[1] and buf[3] etc are always stuck at 0. Any ideas on what I should...
<re_irc> ... check?
DepthDeluxe has joined #rust-embedded
<re_irc> < (@adamgreig:matrix.org)> Sounds like the bus isn't configured right and is perhaps trying to access a 32 bit external memory
<re_irc> <bitts> yeah, sounds reasonable. is there a parameter or something to the fmc crate I've missed then, or is that setup elsewhere? (New to rust - but loving it so far)
steew has quit [Ping timeout: 246 seconds]
steew has joined #rust-embedded
<re_irc> <bitts> I do find: mt48lc4m32b2.rs: memory_data_width: 32, // 32-bit
<re_irc> <bitts> will dig a bit more
steew has quit [Remote host closed the connection]
steew has joined #rust-embedded