ivche has quit [Remote host closed the connection]
ivche has joined #rust-embedded
ello has joined #rust-embedded
Darius has joined #rust-embedded
Foxyloxy has quit [Ping timeout: 252 seconds]
tschundler has quit [Remote host closed the connection]
tschundler has joined #rust-embedded
Artea has joined #rust-embedded
pavlebn[m] has joined #rust-embedded
<pavlebn[m]>
Hey, does anyone have any experience with writing stm32 bootloaders? I need to set up QSPI XIP, and for it to work with probe-rs if possible. Anyone up here that could help out?
jannic[m] has joined #rust-embedded
<jannic[m]>
<dirbaio[m]> "I wonder when rustc introduced..." <- It was made deny-by-default in https://github.com/rust-lang/rust/pull/112431, introduced with 1.73.0 about a year ago.
<JamesMunns[m]>
Should I have an interface descriptor, with a string descriptor that says "postcard-rpc" or something?
bpye has quit [Ping timeout: 248 seconds]
Koen[m] has joined #rust-embedded
<Koen[m]>
Normally, if you have a set of VID/PID pairs, I would set the InterfaceClass to 0xFF and signal the postcard-rpc through the subclass or protocol field.
<Koen[m]>
I remember hearing about some piece of software that would just probe all CDC-ACM interfaces across all devices to find the one it was looking for, would not recommend, but it is also an option :)
<JamesMunns[m]>
and then hope that my "ping" protocol message doesn't cause any devices that happen to have that same trio of values to misbehave :p
<JamesMunns[m]>
Koen[m]: yeah, for better or worse, I'm using "raw" bulk endpoints instead of CDC-ACM
<Koen[m]>
Essentially as long as nothing is standardised, you're trying to get sufficient entropy in the set of correlated values to decrease the number of false positives.
<Koen[m]>
I think it is an option to add a custom extra custom descriptor to the interface descriptor, but that's also just another set of bytes to make it more unique, but nothing guaranteed.
<Koen[m]>
A string descriptor might be your best bet, but I think under Linux I need root to also request those to be printed with `lsusb` (I think)
<JamesMunns[m]>
Ah interesting. It also appears that embassy doesn't seem to allow setting string descriptors at the moment either
<Lumpio->
The thing that liked to probe random CDC-ACM devices was ModemManager wasn't it
<JamesMunns[m]>
Yeah it definitely did that
<JamesMunns[m]>
"let's send modem garbage to every UART/USB-UART we find, do you like this? is this good?"
<Lumpio->
I *think* under Linux you are allowed to look under /sys/bus/usb/ without root
<Lumpio->
And it has the standard string descriptors
<Lumpio->
But I'm not entirely sure if that's the case on all systems.
<JamesMunns[m]>
yeah, I'm on Mac and I can definitely see them through USB, not sure if windows would do the same
<Lumpio->
If you're using your own VID:PID you will probably need your own driver, or use WinUSB
<Lumpio->
WinUSB is like a generic USB driver you can ask recent versions of Windows to load by having some magic Microsoft descriptors in your device
<JamesMunns[m]>
yeah, I send the "please use WinUSB" magic descriptors
<Lumpio->
And then there is a relatively reasonable API to talk to it (I think libusb supports it too)
<Lumpio->
ah okay
<JamesMunns[m]>
(and use nusb on the host side)
<Lumpio->
Sorry I just read "not sure if windows" as "didn't try anything on Windows yet"
<JamesMunns[m]>
<JamesMunns[m]> "Ah interesting. It also appears..." <- Update: someone showed me how to use the API right :)
<Lumpio->
If you have WinUSB you can request any descriptors you want, or in fact do any requests you want pretty much.
<JamesMunns[m]>
Lumpio-: yeah, I haven't tried anything on windows with this specific firmware, but I know for sure previous versions of postcard-rpc work on windows (I'm using it "in prod" with some customers)
<thejpster[m]>
TIL you can use s0 and d0 FPU registers even if you don't have an FPU. As long as you have Integer MVE; because it uses the same registers and hence provides all the FPU registers even though there's no FPU.
<dirbaio[m]>
lol that makes no sense :D
<dirbaio[m]>
they should call them "extra bonus registers" at this point, not "float registers" :D
<thejpster[m]>
they are basically float/simd registers.
<thejpster[m]>
s0:s1:s2:s3, d0:d1 and q0 are the same bits
<dirbaio[m]>
yep! I was also very surprised to see you can still use d0, d1... even if you don't have a double-precision fpu, because they're just aliases. d0=s0+s1, d1=s2+s3, ...
<thejpster[m]>
vmov is a CPU instruction and not an FPU instruction
<thejpster[m]>
but it makes the float functions slower because you need to vmov from d0 to r0:r1 in order to all the AEABI float implementations
<thejpster[m]>
s/all/call/
<thejpster[m]>
hard-float isn't a slam dunk if you only have SP. Except ... we only ship two pre-compiled libcores, and that really restricts your choices.
<thejpster[m]>
soft-float with FPU enabled is perhaps the best choice - but we don't offer it
romancardenas[m] has joined #rust-embedded
<romancardenas[m]>
I am substituting `static mut T`s with `critical_section::Mutex::RefCell<T>`s, but I wanted to double check with you in case there is another "official" approach
<romancardenas[m]>
Hi everyone! I'm updating some crates to new nightly clippy and now I'm dealing with `static mut` variables.
<dirbaio[m]>
depends on what you want to do, why were you using static mut
<romancardenas[m]>
s/::/</, s/>`/>>`/
<dirbaio[m]>
you can keep using static mut if you do `&mut *addr_of_mut!(MY_STATIC_MUT)` instead of `&mut MY_STATIC_MUT`
<dirbaio[m]>
then there's critical-section yep
<dirbaio[m]>
also static-cell
<dirbaio[m]>
critical-section allows sharing the data across priority levels, but it'll lock the critical section which will delay interrupts
<dirbaio[m]>
static-cell doesn't allow sharing the data between priority levels, so it doesn't need critical sections
<romancardenas[m]>
As it is, it calls to riscv::free to manipulate the variable, so it is kind of a critical_section without mutexes, so that is why I used critical_section
<romancardenas[m]>
In essence, the variable is an UART transmitter for sprintln! messages
<dirbaio[m]>
ahh yeah if you want to allow printing from any priority level (like, main and interrupts) you need a critical section
<dirbaio[m]>
and the refcell
<dirbaio[m]>
because I imagine you're calling into an arbitrary embedded-hal uart driver?
<romancardenas[m]>
yep
<dirbaio[m]>
if that's the case, the driver could try to print something itself
<dirbaio[m]>
which would call into sprintln! and then the driver again\
<dirbaio[m]>
s//`/, s/!/!`/
<dirbaio[m]>
so if you had "static mut + interrupt::free" before, that was unsound :)
<dirbaio[m]>
* interrupt::free" before, and no refcell, that was
<romancardenas[m]>
Is the Mutex necessary or I can live without it as it wraps a RefCell?
<dirbaio[m]>
Mutex ensures no races between priority levels (converts Send to Sync basically)
<dirbaio[m]>
RefCell ensures you can get a &mut to the interior but only once, it panics if you try to do recursive printing like that (convetrs & to &mut)
<dirbaio[m]>
you need both
<dirbaio[m]>
`Mutex<RefCell<WhateverUart>>`
<romancardenas[m]>
Thanks!
<thejpster[m]>
or, if you believe concurrent accesses are impossible due to system design, it's possible to make a type which only enters the crtiical section while it *checks the refcell borrowing* and unlocks it whilst you *actually use the value*.
<thejpster[m]>
The downside is that if you *do* concurrently access it from the interrupt, that second access has to fail because there's no way to "wait until the resource is free".
<thejpster[m]>
Or you use RTIC which blocks interrupts until resources are free automatically.
<thejpster[m]>
in particular, turning all interrupts off whilst you write to an unbuffered (or only lightly buffered) UART can be quite painful.
<romancardenas[m]>
Being a BSP crate, I think the wisest decision is using mutexes to make sure that users will not face issues with println!s
<dirbaio[m]>
defmt also disables all irqs when printing
<thejpster[m]>
<dirbaio[m]> "defmt also disables all irqs..." <- Yes but it prints to a ram buffer. A fully buffered UART is also no problem. A 16 byte FIFO is a problem, in my opinion for my usual use case. YMMV.
<sourcebox[m]>
So what would you set bcdUSB to when using a RP2040?
<jannic[m]>
It probably doesn't matter at all :-)
<jannic[m]>
But if I had to choose, I'd probably set it to 0x0110, as that seems to be the value to boot ROM uses.
<sourcebox[m]>
Good catch.
<jannic[m]>
But then, the Raspberry debug probe, which also uses the rp2040, sets it to 0x0210.
ithinuel[m] has joined #rust-embedded
<ithinuel[m]>
I use 2.00 for my keyboard without issues. I even used 2.01 (or 2.10 I can't remember which it is) for a while but the KVM wasn't handling some of the host requests properly (the device straight into the host was working fine).
<jannic[m]>
Probably there are so many devices that set arbitrary values that no driver relies on the field :-)
<ithinuel[m]>
s/01 (or 2.//, s/I can't remember which it is)//
<sourcebox[m]>
Despite from Linux, we don't really know what a host does with this value.
<ithinuel[m]>
Well, windows did behave differently depending on what that field had. Namely sending extra requests the higher you get.
<ithinuel[m]>
I wouldn't be surprised if Linux did too if only to discover if any extra features from the higher usb versions are supported.
<jannic[m]>
Yes - it may probe for higher speeds.
<jannic[m]>
The device will answer "sorry, can't do that" and all should be fine.
bpye has joined #rust-embedded
<jannic[m]>
But that's also a reason to set it to 1.1: That way the host doesn't need to send these requests that would fail anyway.
<sourcebox[m]>
I'm mostly unsure about macOS because Apple changed the USB implementation several times over the last years and always broke something.
<jannic[m]>
BTW the RP2350 sets it to 2.1 in its bootrom. Doesn't it have the same USB interface as the RP2040? That doesn't make sense.
<jannic[m]>
I don't have macOS device, so I can't try.
<sourcebox[m]>
Since it has changed in macOS over time, it even depends on the version you use.
<sourcebox[m]>
There have been reports a few days ago that some USB devices don't work anymore with the currently released macOS 15.
<sourcebox[m]>
But despite of that, I want to have the option to declare a device as USB 1.1, therefore my PR.
<jannic[m]>
Regarding your pull request: I think it would be good to at least give the firmware author the choice of specifying USB 1.1.
jasperw has quit [Ping timeout: 265 seconds]
<ithinuel[m]>
I do have a Macos device. I'm at eurorust though so I don't have my keyboard with me.
<ithinuel[m]>
But yeah, bootrom of rp2350 and rp2040 just work fine.
jasperw has joined #rust-embedded
<sourcebox[m]>
In my case with USB audio there could be a difference because there are 2 different versions of the audio class, UAC1 and UAC2. The latter requires high speed. And then there's the hole rabbithole of composite devices.
<jannic[m]>
For anything non-trivial, you should probably test your device with as many hosts as possible. Don't rely on drivers to conform to the spec.
<sourcebox[m]>
I'm doing this here with Windows 10, Linux, macOS 10.13 and macOS 14.7 right now. This is all I can do myself without having someone else involved.
<sourcebox[m]>
But it's a bit tedious because I can't run all these system at the same time.
<thejpster[m]>
Mostly just me going "ugh, who wrote this nonsense. Oh, past me. Well, let's fix it"
vollbrecht[m] has joined #rust-embedded
<vollbrecht[m]>
the host. For usb1.1. / usb2.0 stuff and macos testing that should work. And you can get easily macos 11 to 15 on the same machine.
<vollbrecht[m]>
<sourcebox[m]> "I'm doing this here with Windows..." <- i have a app where cross compilation is not possible for windows / macos and that's why i have to build nativly. For windows there exist "dockur" that gives you a fully automated windows system that also supports usb forwarding ( under the hoot is uses kvm) and for macos i am using osx-kvm. And for testing a iOS app i can forward that osx-kvm to the iphone via usb through
<vollbrecht[m]>
vollbrecht[m]: so everything can run off of one machine
<vollbrecht[m]>
* i have a app where cross compilation is not possible for windows / macos and that's why i have to build nativly. For a solution that runs on a linux host getting windows "dockur" exists. It gives you a fully automated windows system that also supports usb forwarding ( under the hoot is uses kvm) and for macos i am using osx-kvm. And for testing a iOS app i can forward that osx-kvm to the iphone via usb through the host. For
<vollbrecht[m]>
usb1.1. / usb2.0 stuff and macos testing that should work. And you can get easily macos 11 to 15 on the same machine.
i509vcb[m] has quit [Quit: Idle timeout reached: 172800s]
AlexKlemenchuk[m has quit [Quit: Idle timeout reached: 172800s]
jessebraham[m] has quit [Quit: Idle timeout reached: 172800s]