dsmith_ has quit [Remote host closed the connection]
dsmith has quit [Ping timeout: 260 seconds]
majors has joined #rust-embedded
danielb[m] has joined #rust-embedded
<danielb[m]>
<firefrommoonligh> "Or, actually, probably the..." <- The one time I asked copilot why my code wasn't working, it pointed at the incorrect line and told me it's fine and it's how I should do what I want. You can just never predict if you trying to save time will end up costing more than trying to look for an answer by yourself
<badyjoke[m]>
Hello ! I'm having a strange issue and don't know how to solve it. I'm still a newbie in embedded dev. My issue is the following :
<badyjoke[m]>
I'm doing some SPI communication with a IAM-20680 trying to read the who_am_I register with a ATSAM3X8E microcontroller. When I inspect the SPI Receive Data Register in debugging mode with probe-rs I get the expected value that who_am_I register sends. But when I read the SPI Receive Data Register I dont get the same value.
<badyjoke[m]>
This is what I get from the debugging view :
<dj2v65fnvh[m]>
<dirbaio[m]> "and if you uncomment config.rcc..." <- Unfortunatelly I coudn't uncomment this line.
<JamesMunns[m]>
so rcc.sys and sys::Clk...
<dirbaio[m]>
dj2v65fnvh[m]: why not?
<dirbaio[m]>
make sure you're on latest embassy-stm32 from git
<dj2v65fnvh[m]>
dirbaio[m]: I just posted the screenshot above, let me try to switch to the main branch
<dj2v65fnvh[m]>
I switched to the git version of embassy and for now I am be able to uncomment config.rcc.mux.clk48sel = mux::Clk48sel::PLL1_Q; but unfortunately it doesn't help :(
<dj2v65fnvh[m]>
Maybe it's cause of windows 11?
<dj2v65fnvh[m]>
Maybe I need to solder something on a board?
<dirbaio[m]>
it's probably a problem in the firmware
<dirbaio[m]>
the PC is trying to read descriptors, but the firmware logs show it's stuck in "SETUP waiting"
<dirbaio[m]>
ie waiting for a SETUP packet
<dirbaio[m]>
so the packets the PC is sending don't reach the firmware at all
<dirbaio[m]>
this typically happens when there's something wrong with the clocks, or with the PHY setup, or the pins or the wiring
<dirbaio[m]>
probably related to using OTG_HS in FS mode, which is a quite rare thing to do so it makes sense it's broken and has stayed unnoticed until now
<dirbaio[m]>
i'm officially out of ideas though, and unfortunately I don't have any board with OTG_HS in FS mode. all nucleos just use OTG_FS
<dirbaio[m]>
you've found it also doesn't work in stm32f4xx-hal, which uses the synopsys-usb-otg crate, which I referenced heavily when writing the embassy-stm32 usb driver... so maybe they both have the same bug
<dj2v65fnvh[m]>
thank you, for support, I am new in embedded world so these things a bit hard for me to catch all at once.
<dirbaio[m]>
you might want to take a look there if you want to debug this yourself
<dirbaio[m]>
comparing the bits with the Reference Manual, or maybe with ST's C HAL which is supposed to be working
<dirbaio[m]>
or just change things randomly until it works, I do that often and it's surprisingly effective ... 🙈
<dj2v65fnvh[m]>
by the way ST examples for usb also didn't work (
<M9names[m]>
not a good sign
<JamesMunns[m]>
dj2v65fnvh do you need THIS board to work for your company? There are likely other boards that will work, if you just need a demo
<JamesMunns[m]>
like, it'd be good to fix the "fs on hs" stuff, but it might be easier to order a different $10-$20 dev board instead of spending more time on this right now :p
<dirbaio[m]>
<dj2v65fnvh[m]> "by the way ST examples for usb..." <- now *that* is suspicious. same windows enumeration error?
<dj2v65fnvh[m]>
JamesMunns[m]: Yeah I already ordered other board, but it's more about time
<dj2v65fnvh[m]>
dirbaio[m]: nope it didn't even showed for windows
<dj2v65fnvh[m]>
dj2v65fnvh[m]: I mean with default examples
<JamesMunns[m]>
It's a good day for embassy USB, I'm troubleshooting a lockup that doesn't repro with `DEFMT_LOG="trace"` 🙃
<ryan-summers[m]>
Maybe check the control pipe processing against usb-device?
<JamesMunns[m]>
At least one nice sign: If I replace all trace!() logs with core::sync::atomic::fence(core::sync::atomic::Ordering::AcqRel); it still repros, so PROBABLY only a race and not creepy UB
<ryan-summers[m]>
I fought a lot of this recently w.r.t race behavior
<ryan-summers[m]>
Word to the wise, trace the whole USB control pipe transfer process. It can be really helpful to see the OS aborting transfers and stuff early
<JamesMunns[m]>
ryan-summers[m]: you mean host side?
<ryan-summers[m]>
No, add the traces on the micro to see what your device is seeing the host do to it
<paumanok[m]>
I'm having trouble getting it working as it takes a pointer to a mutex which gets really tricky with lifetimes.
<ryan-summers[m]>
The OS can do some really funky things in control transfers, like ending them early etc. This previously was causing usb-device to stall a lot more often than it should have
<ryan-summers[m]>
I.e. it can ask for 64 bytes, read 8, and then initiate a STATUS transaction to end the transfer. If your control logic doesn't handle that properly, you may unintentionally stall the control pipe etc. which can cause errors to propogate tot he OS
<ryan-summers[m]>
Specifically look at points where the EP0 gets stalled
<ryan-summers[m]>
I found that usb-device was being a bit trigger happy in stalling EP0 and that was causing havok based on how transfers were getting processed
<JamesMunns[m]>
much appreciated!
<ryan-summers[m]>
* getting processed, end result was that sometimes it worked and sometimes it didn't, and tracing had an effect on timing how the transfers were processed when they arrived on the device so could make the bug appear/disappear as well
<paumanok[m]>
<ryan-summers[m]> "> <@paumanok:matrix.org> has..." <- I apologize if this is something really simple I'm not getting, but could you elaborate on "static container"? do you mean like storing the pointer in a Box<'static>?
<ryan-summers[m]>
I mean that the Mutex usually will exist in some static mut object
<ryan-summers[m]>
Or at least static, not sure if it needs to be mut
<ryan-summers[m]>
For example, in firmware applications, I would store the synchronization primitive into something like a `let mutex: &'static Mutex = cortex_m::singleton!(: Mutex = Mutex::new()).unwrap();`
<ryan-summers[m]>
But this depends entirely on your application. You may not need static lifetimes at all here
<ryan-summers[m]>
static would primarily be needed if you i.e. we using the MutexDevice in multiple contexts, like in the main loop and in an ISR
<ryan-summers[m]>
Essentially, if you need to write the lifetime of the borrowed Mutex as a non-generic parameter, it's going to have to be static
<paumanok[m]>
ryan-summers[m]: Its a somewhat frustrating edgecase, where the end of the lifetime the compiler is complaining over, is the end of main(), ideally I'd like to not care about it
<ryan-summers[m]>
Yeah, but that makes sense. Once main ends, the mutex is dropped
<ryan-summers[m]>
If your object is living outside of main, that then becomes problematic. This sounds very dependent on how you structure your code though
<ryan-summers[m]>
What are you doing (in a simple case) and what error is getting thrown?
<paumanok[m]>
I'm attempting to share an I2cDriver handle between multiple threads, such that I can pass the handle to a service routine that initializes the driver and uses it in its own loop
<ryan-summers[m]>
Yeah, that sounds like exactly a case where the main lifetime is insufficient, since the service routine loop would live outside of main's lifetime
<ryan-summers[m]>
I.e. it sounds like your mutex needs to be in some static variable to solve things here
<ryan-summers[m]>
probably need some unsafe in there
<ryan-summers[m]>
I think you can use as_ref() instead of as_mut() too? Not sure
<JamesMunns[m]>
(please stop recommending static mut to people who are new, please recommend them static cell or singleton or anything else)
<ryan-summers[m]>
What would it be again? Just a Cell or a RefCell? I remember fighting some issues about Sync from what I remember previously
<paumanok[m]>
from the docs, RefCell is used within a single thread iirc
<ryan-summers[m]>
Ah I think we ended up with UnsafeCell
<paumanok[m]>
<ryan-summers[m]> "probably need some unsafe in..." <- that does indeed get into unsafe territory
<JamesMunns[m]>
paumanok you say "multiple threads", are you on esp32 using `std`?
<JamesMunns[m]>
or what CPU + libraries (e.g. embassy, rtic, etc) are you using?
<paumanok[m]>
JamesMunns[m]: Correct
<paumanok[m]>
I know my current design is a little uh, over engineered, but I wanted a greater learning experience than another superloop project
<JamesMunns[m]>
Gotcha, you might be better off putting things in an `std::sync::Arc<std::sync::Mutex<I2cDriver>>`
<dirbaio[m]>
If you do have alloc use Box::leak
<JamesMunns[m]>
then it'll be thread safe, and you won't have to worry about sharing.
<dirbaio[m]>
If you don't, use StaticCell
<JamesMunns[m]>
dirbaio[m]: ...or just Arc, but leak and Arc aren't that far from each other
<dirbaio[m]>
To use Arc we'd need an ArcMutexDevice in e-h-b
<dirbaio[m]>
MutexDevice takes &Mutez
<dirbaio[m]>
s/Mutez/Mutex/
<JamesMunns[m]>
Do they even need MutexDevice if they can just put the driver in an Arc Mutex?
<JamesMunns[m]>
like, I'm saying "don't use MutexDevice at all if you're on std"
<paumanok[m]>
JamesMunns[m]: MutexDevice has the benefit of implementing the bus traits so it can be handed to existing drivers, or at least that's how I was understanding it
<JamesMunns[m]>
but im maybe ootl, maybe leak + mutexdevice is better
<JamesMunns[m]>
makes sense!
<paumanok[m]>
i'm basically trying to avoid constructing and deconstructing the drivers continually with the MutexDevice
<dirbaio[m]>
<a data-mention-type="user" href="https://matrix.to/#/@paumanok:matrix.org" contenteditable="false">@paumanok</a> are you sharing the i2c bus between multiple drivers?
<paumanok[m]>
dirbaio[m]: yes, right now i'm trying to get this to work with a single driver
<dirbaio[m]>
If you aren't, you can just pass the entire owned I2cDriver
<paumanok[m]>
but the goal is for others
<dirbaio[m]>
Okay, then try Box::leak or StaticCell
<paumanok[m]>
I'll look into those
<dirbaio[m]>
(or implement ArcMutexDevice and send a pull request to embedded-hal, heh....)
<paumanok[m]>
dirbaio[m]: That would surely get me out of my newb stage!
<dirbaio[m]>
ArcMutexDevice, RcRefCellDevice would be nice additions... They're missing right now because it's rare to use alloc/std for this, esp-idf-hal is the only major platform that has it (other than embedded Linux ofc)
Amnesia has joined #rust-embedded
<Amnesia>
Is there anyone over here who's played with an ESP board? I've got a C3, which I'm trying to flash, but my linux machine isn't coming up with a file handle for it in /dev
GregBodnar[m] has joined #rust-embedded
<GregBodnar[m]>
Amnesia: Do you see it on the USB bus? Does it show up with `lsusb`?
<Amnesia>
can't imagine it needs a custom driver?
<Amnesia>
GregBodnar[m]: yep, `Espressif USB JTAG/serial debug unit`
<paumanok[m]>
<dirbaio[m]> "Okay, then try Box::leak or..." <- I think box::leak might work, at least it compiled with a single driver
<GregBodnar[m]>
Amnesia: If you're using `probe-rs`, does it show up with `probe-rs list`? I typically use stlink devices and don't need to reference a dev node for that to work.
<paumanok[m]>
<Amnesia> "Is there anyone over here who'..." <- unsure about the C3 but for the first-flash for the S3, you need to bring both RST and boot to ground
<paumanok[m]>
paumanok[m]: Time to port the Max170xx driver to Hal 1.0
<Amnesia>
GregBodnar[m]: Nope, I'm using `cargo-espflash`, but I doubt probe-rs will work, since there's no file descriptor it can target
<Amnesia>
paumanok[m]: does "to ground" mean the buttons need to be pressed :D?
<paumanok[m]>
haha yes, sorry. I did this on my own pcb where one wasn't a button, so I was using tweezers on first boot to bring it low
<paumanok[m]>
sometimes the dev boards don't properly debounce the boot/reset buttons which can cause issues. I've had to bodge a capacitor to one to get it to only semi-reliably flash
<Amnesia>
wtf
<Amnesia>
You'd say this'd be the bare minimum for a dev board
<paumanok[m]>
When I dealt with that it was literally just 1/3 from the amazon wemos store. I'm unsure if they actually skimped out, or if one ic was more sensitive than the others. The other two were flawless and the third would only flash 1/5 times.
<paumanok[m]>
Oh sorry, it was a capacitor across Enable to ground, just found the board.
<Amnesia>
that did the job \o/ tyvm <3
<firefrommoonligh>
<danielb[m]> "The one time I asked copilot why..." <- Try ChatGPT4
<vollbrecht[m]>
Amnesia: if you are using the usb/jtag connection the board itself will present you as an ttyACM device not a ttyUSB device.
<vollbrecht[m]>
* will present itself to you as
<vollbrecht[m]>
* Amnesia: if you are using the usb/jtag connection the board will present itself to you as an ttyACM device not a ttyUSB device.
<xiretza[cis]>
(it will shop up with a descriptive, stable name in /dev/serial/by-id/ either way)
crabbedhaloablut has quit []
IlPalazzo-ojiisa has joined #rust-embedded
crabbedhaloablut has joined #rust-embedded
Curid[m] has quit [Quit: Idle timeout reached: 172800s]
<Amnesia>
vollbrecht[m]: yep, can confirm. I had to due what paumanok[m] described first though
jakzale_ has joined #rust-embedded
Allie_ has joined #rust-embedded
AdamHord- has joined #rust-embedded
diondokter[m]1 has joined #rust-embedded
xiretza[cis]1 has joined #rust-embedded
firefrommoonlig4 has joined #rust-embedded
Allie has quit [Ping timeout: 268 seconds]
jannic[m] has quit [Ping timeout: 268 seconds]
ryan-summers[m] has quit [Ping timeout: 268 seconds]
ni has quit [Ping timeout: 268 seconds]
jakzale has quit [Ping timeout: 268 seconds]
AdamHorden has quit [Read error: Connection reset by peer]
firefrommoonligh has quit [Ping timeout: 268 seconds]
diondokter[m] has quit [Ping timeout: 268 seconds]
xiretza[cis] has quit [Ping timeout: 268 seconds]
HumanG33k has quit [Ping timeout: 268 seconds]
Allie_ is now known as Allie
jakzale_ is now known as jakzale
HumanG33k has joined #rust-embedded
ni has joined #rust-embedded
ryan-summers[m] has joined #rust-embedded
jannic[m] has joined #rust-embedded
barafael[m] has quit [Quit: Idle timeout reached: 172800s]
khionu[m] has joined #rust-embedded
<khionu[m]>
I'm a little confused by the terminology used around std in the context of esp-idf, does it somehow make the actual standard library work, or do you still have to use other APIs instead?
<dirbaio[m]>
yes, it makes the actual standard library work
<dirbaio[m]>
not all of it, but most
<khionu[m]>
Enough for Tokio + HTTP/WS?
<khionu[m]>
I'm stuck between hoping that can work nearly OOTB, or reimplementing a subset of a very large API
<dirbaio[m]>
hmm not sure if the whole tokio
<khionu[m]>
As long as tokio::{net, io} work, it likely will be enough
<dirbaio[m]>
i think they were focusing on smol+async-io. there's some forks adapting them to esp-idf here https://github.com/esp-rs-compat/
<dirbaio[m]>
but I dont know what the latest status is
<dirbaio[m]>
you might want to ask in #esp-rs:matrix.org
<khionu[m]>
Will do!
<khionu[m]>
Thanks!
<dirbaio[m]>
there's also bindings for their C libs to do HTTP etc
AtleoS has joined #rust-embedded
burrbull[m] has quit [Quit: Idle timeout reached: 172800s]
mistermuki has joined #rust-embedded
<mistermuki>
hello!
mistermuki has quit [Client Quit]
mistermuki[m] has joined #rust-embedded
<mistermuki[m]>
trying this again lol but this time in matrix
<mistermuki[m]>
Been playing around with using an array (instead of the Vec) for backing the String implementation in heapless. It allows Copy + it ends up being a bit faster than the current Vec backing (from the little benchmarking I did).
<braincode[m]>
I think I'm looking for something similar to defmt-tests but for AVR and ultimately just run cargo build|run|test transparently as with any non-multi-target Rust project?
<dirbaio[m]>
there's embedded-test too
<dirbaio[m]>
I don't know how well it works with avr but might be worth a look
<braincode[m]>
Says ARM and RiscV explicitly in the README but I'll try, thanks!!
zagura has quit [Ping timeout: 246 seconds]
zagura has joined #rust-embedded
IlPalazzo-ojiisa has quit [Quit: Leaving.]
<paumanok[m]>
<paumanok[m]> "Time to port the Max170xx driver..." <- box::leak did not in fact work alone once I wanted to use the second driver