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
Foxyloxy_ has quit [Ping timeout: 265 seconds]
<cr1901> jamesmunns: I'll take you up on that another day. Trying to get the API finalized tonight so I can stop code churning LOL
rardiol has quit [Ping timeout: 264 seconds]
<re_irc> <@jamesmunns:beeper.com> Congrats on getting it working :)
<cr1901> This was SUPPOSED to be easy. But this may be the most difficult Rust crate I've written yet
<cr1901> Big shocker: ~~Rust~~ Programming becomes a lot less pleasant once you leave the realm of "everything fits into a contiguous memory"
<cr1901> Rahix (if you're here): Is it possible to get a release of avr-hal-generic? I need to treat avr specially in one of my crates and I'm looking into making it ergonomic for the end user
<cr1901> Specifically EEPROM access
rardiol has joined #rust-embedded
<re_irc> <@jamesmunns:beeper.com> Still, there's something to be said about picking (and winning) fights that were bigger than you originally thought they would be!
<re_irc> <@halfbit:matrix.org> what do you mean by fits into contiguous memory?
<cr1901> The data you're trying to manipulate is stored off-device and you can only have portions of it in memory at once
<cr1901> I wanted similar functionality in smoltcp at one time, to support being able to use the ENC28J60 with smoltcp (for e.g. msp430, which doesn't have much RAM), but I never pursued it.
fabic has joined #rust-embedded
Foxyloxy has joined #rust-embedded
starblue has quit [Ping timeout: 252 seconds]
starblue has joined #rust-embedded
<re_irc> <@jaxter184:matrix.org> i've been having an issue with i2s communication using the SAI peripheral on an stm32g4, and I'm hoping someone has run into this issue before (or a similar one) and can help me out:
<re_irc> <@jaxter184:matrix.org> In short, I think I'm having trouble with the data size configuration (DS bits in SAI_ACR1). I'm only getting the last (least significant) 8 bits to show up in my output, no matter what value I change the bits to.
<re_irc> <@jaxter184:matrix.org> and the current output, as read by a logic analyzer
<re_irc> <@jaxter184:matrix.org> I think i'm still not fully understanding slots, but from what I can tell, i should be setting it to 2 slots, with size value 0 (to match data), though i've also tried setting it to 0b10 (32 bits wide)
<re_irc> <@jaxter184:matrix.org> i've also tried changing FBOFF, and it doesn't truncate off the bits outside the first 8, so I think the slot configuration is correct
<re_irc> <@jaxter184:matrix.org> everything i do, it seems like the data size is set to 8 bits, but in my configuration, i set it to 24 bits, and when I read it back, it shows the correct values
<re_irc> <@jaxter184:matrix.org> is it possible that the svd files are wrong or something? the stm32-rs repo is a little opaque to me, but I'm sure i could parse through it if i try hard enough
<re_irc> <@jaxter184:matrix.org> i have an f429 board somewhere, so trying my code out with that is probably my next course of action
rardiol has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
<re_irc> <@firefrommoonlight:matrix.org> Not sure. Of note, that config is a valid I2C config
<re_irc> <@firefrommoonlight:matrix.org> * I2S config, GJ
<re_irc> <@firefrommoonlight:matrix.org> This stuff is tricky
<re_irc> <@firefrommoonlight:matrix.org> Your DS setting of "0b110" is valid (for standard I2S)
<re_irc> <@firefrommoonlight:matrix.org> Have you confirmed your clock settings are correct? That's the other tricky part
<re_irc> <@firefrommoonlight:matrix.org> You are also correct on 2 slots (For standard I2S)
<re_irc> <@firefrommoonlight:matrix.org> I haven't QCed The SVDs for SAI G4, but H743 and H753's are correct
<re_irc> <@firefrommoonlight:matrix.org> Since the SAI periph is (near?) identical, you could QC those if you sus that
<re_irc> <@firefrommoonlight:matrix.org> But there's so much that can be misconfigured with audio
<re_irc> <@firefrommoonlight:matrix.org> Here is the config struct I use as a baseline for I2S, but it mainly just confirms what you posted:
<re_irc> /// Default configuration for I2S.
<re_irc> pub fn i2s_preset() -> Self {
<re_irc> // Use our default of 2 slots, and a frame length of 64 bits, to allow for up
<re_irc> Self {
<re_irc> // to 32 bits per slot.
<re_irc> // We also use our default fifo thresh of 1/4 of the total size of 8 words,
<re_irc> // ie 1 word per channel
<re_irc> // Note that we include some settings here that are present in default,
<re_irc> // for explicitness. (ie required by I2S, but perhaps arbitrary in default)
<re_irc> first_bit: FirstBit::MsbFirst,
<re_irc> // H743 RM: Frame schronization offset: Depending on the audio protocol targeted in the
<re_irc> // application, the Frame synchronization signal can be asserted when transmitting
<re_irc> // the last bit or the first bit of the audio frame (this is the case in I2S standard
<re_irc> // protocol and in MSB-justified protocol, respectively)
<re_irc> fs_offset: FsOffset::BeforeFirstBit,
<re_irc> // RM: this bit has to be set for I2S or MSB/LSB-justified protocols.
<re_irc> fs_signal: FsSignal::FrameAndChannel,
<re_irc> protocol: Protocol::Free,
<re_irc> datasize: DataSize::S24,
<re_irc> frame_length: 64,
<re_irc> num_slots: 2,
<re_irc> // From the INMP441 datasheet: The default data format is I²S (two’s complement), MSB-first.
<re_irc> // In this format, the MSB of each word is delayed by one SCK cycle from
<re_irc> // the start of each half-frame
<re_irc> // Note that this is already handled by by `fs_offset`.
<re_irc> first_bit_offset: 0,
<re_irc> fifo_thresh: FifoThresh::T1_4,
<re_irc> pdm_mode: false,
<re_irc> ..Default::default()
<re_irc> }
<re_irc> }
<re_irc> <@jaxter184:matrix.org> yeah, i think i ran into that at some point when i was looking for existing implementations
<re_irc> <@jaxter184:matrix.org> you maintain stm32-hal2, right?
<re_irc> <@jaxter184:matrix.org> i tried to compile an example, but i got a flood of errors
<re_irc> <@jaxter184:matrix.org> blinky was the only one that compiled at all if i remember right
<re_irc> <@jaxter184:matrix.org> do i need more than "--features=g4rt,g431" when im running the regular (non-crate) examples?
<re_irc> <@jaxter184:matrix.org> also, ill take another look at the clock, thanks
<re_irc> <@codec_abc:matrix.org> Hello !
<re_irc> <@codec_abc:matrix.org> Rust emmbedded newbie here. Is this the right place for asking for help?
<re_irc> <@jamesmunns:beeper.com> codec_abc: Yup!
<re_irc> <@codec_abc:matrix.org> So here it goes, What I am trying to do is to build a controller (ie a gamepad) using Rust and a STM32F. I followed the book and managed to read logic (for buttons) as well as analaog input (for analog triggers). Now, what I would like is that the board could be seen as a controller and send the value as a controller. I saw examples regarding USB but they seems out of date and seems to be only for having a serial bus...
<re_irc> ... over USB. Do you have tips for me?
<re_irc> <@9names:matrix.org> well, there is no USB game controller support in any Rust crate at the moment that I'm aware of
<re_irc> <@codec_abc:matrix.org> Bummer, then I guess the easiest way is to use the USB a serial bus and fake the controller directly with an app that does the comunication and create a fake Xinput device.
<re_irc> <@9names:matrix.org> maybe? I can't say what's going to be simplest. maybe it wouldn't be too hard to add gamepad/joystick support to https://github.com/dlkj/usbd-human-interface-device?
<re_irc> game controller HID is very similar to mouse HID.
<re_irc> <@codec_abc:matrix.org> Seems promising. Thank you !
<re_irc> <@9names:matrix.org> building a usb-device XInput driver might be easier in it's own way, since there's only one configuration to support instead of configurable numbers of buttons and axes
<re_irc> <@9names:matrix.org> feel free to ask questions if you get stuck, this is one of those things that has been on my project list forever. would be happy to help out to get a working driver
<re_irc> <@codec_abc:matrix.org> Well I think there is many libraries on the PC side that enable to create a virtual gamepad (not necesserarly in Rust). So I guess I will proprotype the thing this way and maybe go down on a lower level after
<re_irc> <@9names:matrix.org> sounds like a good idea :D
<re_irc> <@jamesmunns:beeper.com> Yeah! Maybe start making a keyboard to start (do simple mapping, maybe buttons only, no joystick) for you learning the rust side of things first, then implement the controller hid class and switch to that for getting full/"correct" support?
<re_irc> <@jamesmunns:beeper.com> (I mean: have your gamepad "lie" and say it is a keyboard at first, then fix that later, most of your code will be similar)
<re_irc> <@jamesmunns:beeper.com> (not sure how far along you are at learning rust/rust-embedded!)
<re_irc> <@codec_abc:matrix.org> The thing is that I am building the controller for the analog triggerS and while keyboard can emulate some buttons it will not fit my use case
<re_irc> <@codec_abc:matrix.org> * triggers
<re_irc> <@jamesmunns:beeper.com> Yeah! I just mean it as one option for learning and making incremental progress, not as a total solution! Feel free to ignore if that doesn't match how you'd like to proceed instead :)
<re_irc> <@jamesmunns:beeper.com> I benefit a lot from having tangible progress, and "change keyboard hid to controller hid once you have a controller hid class" should hopefully be a pretty incremental, smaller step!
<re_irc> <@codec_abc:matrix.org> No problem. That is actually decent advice. But I know right from the start that if I start with a keyboard I will have to throw it out later. Surely the knowledge earned will stay.
<re_irc> <@codec_abc:matrix.org> But you are right. Because it should be straightforward enough to not make too big of a detour
<re_irc> <@jamesmunns:beeper.com> You know your needs best :) just sharing how I would approach the problem to not get frustrated, and always have a "well THAT worked" case to compare back to :)
<re_irc> <@codec_abc:matrix.org> Greatly appreciated. I am just starting and I expected the road to be rough so taking a step back and looking at the big picture is good. And if some of you did work on the book, just know you did a hell of work. I did not know it would be that easy to start
fabic has quit [Ping timeout: 255 seconds]
<re_irc> <@burrbull:matrix.org> codec_abc: Possibly this could be helpful for you? https://github.com/TeXitoi/keyberon
<re_irc> <@codec_abc:matrix.org> Can someone help me to figure out how to use this library: https://docs.rs/stm32-usbd/0.6.0/stm32_usbd/ ?
<re_irc> <@9names:matrix.org> have you started from the example in the stm32_usbd repo?
<re_irc> <@codec_abc:matrix.org> this one: https://github.com/stm32-rs/stm32-usbd/blob/master/examples/hal.rs ?
<re_irc> <@9names:matrix.org> yes
<re_irc> <@codec_abc:matrix.org> Not really, since I don't understand what is going on in this example
<re_irc> how about the usb-serial example in stm32f1-hal? have you looked at that?
<re_irc> <@9names:matrix.org> hmm yes, that example does not really demonstrate much does it.
<re_irc> <@codec_abc:matrix.org> It is not compatible with my board. I have a STM32F303
<re_irc> <@9names:matrix.org> oh sorry, i thought you said f1 earlier for some reason :/
<re_irc> <@codec_abc:matrix.org> No problem :)
<re_irc> <@9names:matrix.org> looks like the f3-hal version is basically the same though?
<re_irc> <@codec_abc:matrix.org> I don't manage to compile it. Seems like some API have changed. For instance the calls of dp.GPIOX.split() which now take argument
<re_irc> <@codec_abc:matrix.org> I think I need to rethink my approach. Copying/pasting random lines don't seem a good idea
<re_irc> <@jamesmunns:beeper.com> codec_abc: Split usually takes &mut RCC. Not at a PC, but maybe check the docs? Something like https://docs.rs/stm32f1xx-hal
<re_irc> <@jamesmunns:beeper.com> (ignore me, I made the same F1/F3 mistake, shouldn't read quickly on the go :| )
<re_irc> <@codec_abc:matrix.org> Seems like the issue arise from the pin configuration
fabic has joined #rust-embedded
mightypork has quit [Ping timeout: 255 seconds]
mightypork has joined #rust-embedded
IlPalazzo-ojiisa has joined #rust-embedded
starblue has quit [Ping timeout: 268 seconds]
starblue has joined #rust-embedded
<re_irc> <@codec_abc:matrix.org> With a lot of fighting here is what I managed to do. The program compile, and start, but I am not even sure how I should test the USB stuff. https://github.com/codec-abc/RlRustController/blob/usb_test/src/main.rs
<re_irc> <@codec_abc:matrix.org> Note that I used the af_push_pull pin type because I didn't manage to compile it otherwise
madb has quit [Quit: Leaving]
<re_irc> <@jamesmunns:beeper.com> were you using the F3 for your keyboard work as well? Any chance you can share some fresh wisdom with codec_abc ?
<re_irc> <@codec_abc:matrix.org> The stm32f3xx-hal-0.9.2 contains a exmaples for usb_serial that I am able to compile
<re_irc> <@codec_abc:matrix.org> But no luck getting it working
<re_irc> <@firefrommoonlight:matrix.org> : No. What were the errors?
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
<re_irc> <@codec_abc:matrix.org> I made some progress, I can see it now:
<re_irc> <@htms:matrix.org> codec_abc: years ago I had a problem with usb_device and compiling with "--release" solved it, did you try it?
<re_irc> <@codec_abc:matrix.org> Nope, will try that right away
<re_irc> <@htms:matrix.org> it was exactly wrong descriptors IIRC
<re_irc> <@codec_abc:matrix.org> It works !!! Thanks a lot
<re_irc> <@rmja:matrix.org> Hi all, I have a question on the intended behavior of embedded-io::Write::flush() when implemented for a TcpSocket. Should I let the promise complete when they are "sent to the modem" - or when they are "sent to the server"?,
<re_irc> <@rmja:matrix.org> Answering my own question: This should mean "sent to the modem" to avoid deadlocks.
<re_irc> <@sourcebox:matrix.org> : Regarding this function for writing multiple pins of a GPIO port: I wrote this function and it works as expected, so maybe you can have a look here for eventually integrating it. Use cases are e.g. display drivers, keyboard matrix scanning and selecting mux channels.
<re_irc> /// Sets a range of pins on a port simultaneously.
<re_irc> /// - `port`: GPIO port.
<re_irc> /// - `pin_count`: Total number of pins.
<re_irc> /// - `value`: Value to write.
<re_irc> /// - `pin_offset`: First pin in the range.
<re_irc> #[inline(always)]
<re_irc> pub fn set_bus(port: Port, pin_offset: u8, pin_count: u8, value: impl Into<u32>) {
<re_irc> // Sanity checks, compiler will remove them in release mode
<re_irc> // when function is called with valid const arguments.
<re_irc> if pin_offset > 15 {
<re_irc> panic!("Pin offset out of range.");
<re_irc> }
<re_irc> if pin_count == 0 || pin_count > 16 || pin_offset + pin_count > 16 {
<re_irc> panic!("Pin count out of range.");
<re_irc> }
<re_irc> let mask = (1u32 << pin_count) - 1;
<re_irc> let value = (value.into() & mask) << pin_offset;
<re_irc> let reg_value = (mask << (16 + pin_offset)) | value;
<re_irc> unsafe {
<re_irc> let dp = Peripherals::steal();
<re_irc> match port {
<re_irc> Port::A => dp.GPIOA.bsrr.write(|w| w.bits(reg_value)),
<re_irc> Port::B => dp.GPIOB.bsrr.write(|w| w.bits(reg_value)),
<re_irc> Port::C => dp.GPIOC.bsrr.write(|w| w.bits(reg_value)),
<re_irc> Port::D => dp.GPIOD.bsrr.write(|w| w.bits(reg_value)),
<re_irc> Port::E => dp.GPIOE.bsrr.write(|w| w.bits(reg_value)),
<re_irc> };
<re_irc> }
<re_irc> }
<re_irc> <@sourcebox:matrix.org> For scanning a keyboard matrix, the corresponding read function needs to be done.
<re_irc> <@firefrommoonlight:matrix.org> Looks solid. The thing I'm uncertain about of if it's in scope or not, since it's effectively a higher level built on GPIO reads and writes
<re_irc> <@firefrommoonlight:matrix.org> I'm open to suggestions from anyone who's used these interfaces
<re_irc> <@firefrommoonlight:matrix.org> It's a grey area
<re_irc> <@firefrommoonlight:matrix.org> Could also make sense as something like the stm32-rs USB and CAN libs. Ie standalone to be used on conjunction with a HAL
<re_irc> <@htms:matrix.org> Is there any recommended ways for unit testing platform independent code on host machine besides ferroes systems one?
<re_irc> <@htms:matrix.org> * ferrous
<re_irc> <@sourcebox:matrix.org> : To me writing parallel busses is a common thing, what should be high-level about that? The talk we had some days ago was if this could be defined as trait in embedded-hal, but it turned out that not all devices can do it. On a very small chip in an SO-8 package, it naturally makes no sense ;-)
<re_irc> <@sourcebox:matrix.org> Just imagine how to scan a 8x8 keyboard matrix. Do you think it's a good solution to write and read all pins separately?
<re_irc> <@jamesmunns:beeper.com> codec_abc: General note, "debug mode" is WAY more expensive (CPU, code size, ram usage) than "debug mode" in C. Lots of things like iterators have deep call trees that don't get flattened until "opt-level = 1" or higher in Rust.
<re_irc> moooooost people spend all their time in release mode on embedded, but you can still usually get good debug experience (e.g. with opt, but no lto, and debuginfo turned on) when needed, and there are more tricks if you need them, just ask again here and I can run down the laundry list (we should probably turn this into a doc or blog somewhere...)
<re_irc> <@jamesmunns:beeper.com> this is 10x more true with anything timing critical like USB, wifi, or bluetooth comms where it is very easy to "time out" otherwise.
<re_irc> <@jamesmunns:beeper.com> If you're using "probe-run" or generally "log debugging" instead of "gdb debugging", there's generally no reason ever NOT to be in release mode, either at the default "opt-level = 3", or a size optimized mode like ""s"" or ""z"".
<re_irc> <@sourcebox:matrix.org> I also stay in release mode as often as possible. Code size in opt-level 1 is really exploding, so the code does not even fit in the flash very quickly anymore.
<re_irc> <@sourcebox:matrix.org> * 0
<re_irc> <@jamesmunns:beeper.com> Yeah, opt level 1 gets you a lot of the REALLY low hanging fruit, like basic inlining and stuff, but certainly 2/s/z/3 get you even more. Rust relies pretty heavily on things like inlining and optimization to get speed despite expressive code (like iterators, etc.)
<re_irc> <@jamesmunns:beeper.com> turning on codegen-units = 1 and lto = false tend to have the best impact on "gdb still works" at any optimization level, in my experience. lto just breaks debuginfo in most cases.
<re_irc> <@dirbaio:matrix.org> rust's "zero-cost abstractions" are only zero cost with optimizations
<re_irc> <@jamesmunns:beeper.com> (and also debug = true)
<re_irc> <@jamesmunns:beeper.com> anyway, this is all vibes, and not prescriptive/cited data, but yeah, if you need something to work good and fast, you will generally require optimization in Rust is the general take away.
<re_irc> <@htms:matrix.org> : Does it affect RTC from LSE also?
<re_irc> <@jamesmunns:beeper.com> Depends on what you mean! The clock won't change rates based on your optimization level, but if you are handling an interrupt every tick of the RTC (so 32.768kHz), and your interrupt function isn't fast enough to keep up, you will have problems.
<re_irc> <@jamesmunns:beeper.com> it's mostly "can the software keep up with what the hardware or protocol needs". Expect your code to be 10x-100x slower than release mode in some cases (not exaggerating)
<re_irc> <@jamesmunns:beeper.com> but if USB requires you to answer messages every ms, and in release mode your USB ISR takes 50us (totally fine), but in debug mode it takes 5000us/5ms (definitely not fine!), that's where things can go wrong.
fabic has quit [Ping timeout: 248 seconds]
<re_irc> <@therealprof:matrix.org> : In general code slowness doesn't affect hardware. Reading might be slow, writing might be slow, the hardware will just it's thing nevertheless.
<re_irc> <@therealprof:matrix.org> Of course if buffers run full, you're violating some protocols by missing the timing or don't get to pet the watchdog in time, then all bets are off. 😉
emerent has quit [Ping timeout: 260 seconds]
emerent has joined #rust-embedded
IlPalazzo-ojiis1 has joined #rust-embedded
IlPalazzo-ojiisa has quit [Ping timeout: 255 seconds]
m5zs7k has quit [Ping timeout: 264 seconds]
m5zs7k has joined #rust-embedded
<re_irc> <@jaxter184:matrix.org> : It looks like its mostly failed imports and stuff. For example, pretty much all of the examples use defmt, but the Cargo.toml doesn't have any mention of it.
<re_irc> <@jaxter184:matrix.org> here's the full error output
<re_irc> <@jaxter184:matrix.org> im on the commit tagged 1.6.2 btw
dc740 has joined #rust-embedded
dc740 has quit [Remote host closed the connection]
dc740 has joined #rust-embedded
dc740 has quit [Remote host closed the connection]
dc740 has joined #rust-embedded
dc740 has quit [Remote host closed the connection]
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded