fabic has joined #rust-embedded
<re_irc> <@dngrs:matrix.org> jamesmunns:matrix.org: I have a log message for that that's not getting hit. But uuuhhmmmm I think an actual problem that leads to those mysterious hanging behavior I'm observing is ... maybe not enough available current. sending `/dev/zero` to the device seems to be stable. Yay hardware!
<re_irc> <@dngrs:matrix.org> (I am still losing data somewhere but still ... progress!)
<re_irc> <@dngrs:matrix.org> adamgreig: oh, now I get it - okay, will try that!
<re_irc> <@dngrs:matrix.org> hrmph, no luck
<re_irc> <@dngrs:matrix.org> that was definitely a bug to fix though, I am getting reading batches of 192 bytes now
<re_irc> <@dngrs:matrix.org> oh lol, even better, the problem wasn't current but *the program I used on the host side* (that explains no crashes with `dd`)
<re_irc> <@dngrs:matrix.org> ooooh, my missing byte problem goes away when I don't open+close the serial port on the host for every frame and instead always keep it open. well then!
<re_irc> <@adamgreig:matrix.org> :o I guess it hadn't finished flushing the buffer and perhaps was discarding it when you reopened or something
<re_irc> <@adamgreig:matrix.org> Maybe calling flush before closing would also work but just leaving it open seems most sensible
<re_irc> <@dngrs:matrix.org> it definitely does weird things after a while with repeated open+close, eventually I also get too many open files
<re_irc> <@dngrs:matrix.org> :shrug: blaming macos
<re_irc> <@dngrs:matrix.org> anyway, it *all works now*, wheeeeee, thanks again everyone
<re_irc> <@adamgreig:matrix.org> Btw I wouldn't pad your transfers to multiples of 64 bytes, it actually slightly hurts as usb will need to do a final 0 sized transfer to indicate the end after a full size transfer (and in any event it doesn't help it especially)
<re_irc> <@dngrs:matrix.org> oh!
<re_irc> <@adamgreig:matrix.org> You want them to be as big as possible (64b) each, to maximize efficiency, but if the final one can happen to be smaller that's even better, and also avoids transferrin the padding bytes too
<re_irc> <@adamgreig:matrix.org> You could even detect the smaller transfer as a start of frame and sync off that....
<re_irc> <@adamgreig:matrix.org> Uh, end of frame*
<re_irc> <@adamgreig:matrix.org> Glad to hear it's working though! Always annoying when the actual bug wasn't in the bit you were looking at
<re_irc> <@dngrs:matrix.org> RESULT! https://www.youtube.com/watch?v=hzoCXr67jVQ
<re_irc> <@dngrs:matrix.org> lousy downscaler in p5.js though, not exactly smooth scrolling the text here, rant rant
<re_irc> <@dngrs:matrix.org> adamgreig: oooh, now THAT'S an idea
<re_irc> <@dngrs:matrix.org> adamgreig: yeah, it did cost me too many hours, but I learned a lot and also it's kinda satisfying I did mostly get things right, except for not emptying the buffer properly
<re_irc> <@adamgreig:matrix.org> I dunno how well it would work, the usb driver might essentially combine the low level usb transfers so you don't see the smaller one or it happens at a different time or something... Safest bet is probably to do framing with something like cobs. But, it might be easy to try using the small transfer for signalling and it feels like timing-wise it should actually work well
<re_irc> <@dngrs:matrix.org> yeah, this was mostly an exercise in "can I do this with raw frames, and if not, why?"
<re_irc> <@adamgreig:matrix.org> Send the full 174 bytes or whatever in each write from the computer, the device should see three transfers inside that millisecond, and then you have 1/30 of a second to wait for the next transfer, so seems unlikely it will get merged 🤔
<re_irc> <@dngrs:matrix.org> agree!
<re_irc> <@adamgreig:matrix.org> That all said you shouldn't actually expect to see any dropped bytes at all, so it will probably work pretty well just as is
<re_irc> <@adamgreig:matrix.org> USB is a "reliable" transport lol
<re_irc> <@dngrs:matrix.org> 😬
<re_irc> <@dngrs:matrix.org> I was thinking about adding a simple checksum maybe, but then again, this doesn't save me from misaligned reads... I would have to keep shifting until I run into the correct frame start again and uuhh naw not feeling it
<re_irc> <@dngrs:matrix.org> (unless I'm again missing something)
<re_irc> <@adamgreig:matrix.org> USB already contains a reasonable checksum over your data, I'd definitely worry more about alignment than corruption
<re_irc> <@adamgreig:matrix.org> (you don't see the checksum but the usb peripheral in the stm32 handles it, it's a crc-16 over the frame data and crc-5 over the header)
PyroPeter has quit [Ping timeout: 265 seconds]
PyroPeter has joined #rust-embedded
<re_irc> <@ithinuel:matrix.org> So, the PIO I2C example from the datasheet (and pico-example repo) say:
<re_irc> <@ithinuel:matrix.org> > ; the data is immediately available in the OSR.
<re_irc> <@ithinuel:matrix.org> But I did not see in the datasheet something that links the type of writes to the TX FIFO and the availability of the data to the OSR.
<re_irc> <@ithinuel:matrix.org> > ; The TX FIFO should be accessed with halfword writes, to ensure
<re_irc> <@ithinuel:matrix.org> adamgreig: Behaviours with usb-serial varies by os ( https://github.com/ARMmbed/mbed-os/issues/4301#issuecomment-757924259 ).
<re_irc> <@ithinuel:matrix.org> Macos even seems to add an extra empty data frame when it reaches the end of the buffer.
<re_irc> <@ithinuel:matrix.org> openning & closing the usb-serial port also adds extra traffic on the bus as the host has to reconfigure the port's parameters (speed, flow control etc) even if it's not relevant in your case.
nexos has joined #rust-embedded
<re_irc> <@mathias_koch:matrix.org> Not sure if i am approaching this wrong, but perhaps one of you can help me?
<re_irc> <@mathias_koch:matrix.org> Hi guys,
<re_irc> <@mathias_koch:matrix.org> I would like to have some struct that implements `Iterator<Item = &'a [u8]>`, returning parts of a buffer owned by the struct itself. My issue is that i would like it to lazily read content into this buffer on `next()`, essentially requiring `&mut` access to the buffer, as
<re_irc> <@mathias_koch:matrix.org> ```rust
fabic has quit [Ping timeout: 252 seconds]
<re_irc> <@texitoi:matrix.org> tldr: you can't with core::iter::Iterator trait
<re_irc> <@ryan-summers:matrix.org> Heads up if anyone has auto-merge on approval running - there's a GHA vulnerability where someone with `write` access could approve their own PRs: https://portswigger.net/daily-swig/unresolved-github-actions-flaw-allows-code-to-be-approved-without-review
<re_irc> <@dngrs:matrix.org> adamgreig: yeah, my thinking was a checksum would alert me of lost bytes. Most primitive way of framing, or something. But I'm just making up things as I go without really looking into established work here. (and it's now all moot anyway)
cr1901 has quit [Read error: Network is unreachable]
cr1901 has joined #rust-embedded
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 260 seconds]
fabic has joined #rust-embedded
<re_irc> <@1c3t3a:matrix.org> Hey there! 👋 I am currently trying to use the UART interface on the nrf52840-dongle. I try to do UART over the pins 0_15 and 0_20, but I am struggling as the UART write function hangs forever on waiting till the transmission is finished. The board is set up and also has an allocator configured at the point of sending via UART.
<re_irc> <@newam:matrix.org> It shouldn't hang unless the TX buffer is filling up. I don't have any other ideas 🤔hopefully someone with more NRF experience can comment.
<re_irc> <@1c3t3a:matrix.org> Mhh yeah that's what I thought. I am using the nrf52840_hal for this. UART worked before under TockOS, but they use a deprecated version of the nrf52 crate
<re_irc> <@TimSmall:matrix.org> Bastian: You could also consider asking on #nrf-rs:matrix.org ...
<re_irc> <@1c3t3a:matrix.org> Ahh thanks!
<re_irc> <@jamesmunns:beeper.com> Bastian if you enable HWFC by giving cts and rts pins, you must have those pins active on the other side
<re_irc> <@jamesmunns:beeper.com> probably your adapter doesn't have them connected or enabled, so the driver is waiting until the hardware flow control says "go for it".
<re_irc> <@jamesmunns:beeper.com> (HWFC => Hardware Flow Control, the CTS and RTS pins, which are `Option`al.)
Foxyloxy has quit [Quit: Textual IRC Client: www.textualapp.com]
<re_irc> <@1c3t3a:matrix.org> James Munns: Nice! Yeah that was the problem. Didn't think about rts and cts. Thanks
<re_irc> <@jamesmunns:beeper.com> Nice! Glad you got it working :D
Foxyloxy has joined #rust-embedded
Foxyloxy has quit [Quit: Textual IRC Client: www.textualapp.com]
fabic has quit [Ping timeout: 252 seconds]
Foxyloxy has joined #rust-embedded
<re_irc> <@bradleyharden:matrix.org> My code depends on a crate that is fairly out of date and uses an old version of my PAC. But I also depend on a recent version of my HAL that uses the most up-to-date PAC. I only need a single peripheral from the old PAC, so I thought I could `Peripherals::steal()` from it and use that one peripheral. It passes `cargo check` but fails during linking with a duplicate symbol error.
<re_irc> <@bradleyharden:matrix.org> Is there a quick solution for this? The long term solution is to get rid of the out-of-date crate, but I can't do that right this second
<re_irc> <@dirbaio:matrix.org> without patching, no
<re_irc> <@dirbaio:matrix.org> what's the link error?
<re_irc> <@bradleyharden:matrix.org> warning: Linking globals named 'DEVICE_PERIPHERALS': symbol multiply defined!
<re_irc> <@bradleyharden:matrix.org> error: failed to load bc of "atsamd51n-c1943c88926f0aae.atsamd51n.9b5e4136-cgu.0.rcgu.o":
<re_irc> <@bradleyharden:matrix.org> Building in non-release mode gives more
<re_irc> <@dirbaio:matrix.org> okay, that's from `Peripherals::take()`
<re_irc> <@dirbaio:matrix.org> you can patch the old PAC to remove it
<re_irc> <@dirbaio:matrix.org> then obtain the peripheral with unsafe
<re_irc> <@dirbaio:matrix.org> the DEVICE_PERIPHERALS thing is set up to intentionally conflict, to prevent exactly this, using multiple PACs
<re_irc> <@dirbaio:matrix.org> because otherwise you could take() the peripherals with old and new pac, and obtain multiple handles to the same peripheral...
<re_irc> <@bradleyharden:matrix.org> error: linking with `rust-lld` failed: exit status: 1
<re_irc> <@bradleyharden:matrix.org> |
<re_irc> <@bradleyharden:matrix.org> = note: "rust-lld" "-flavor" "gnu" ...
<re_irc> <@bradleyharden:matrix.org> = note: rust-lld: error: duplicate symbol: DEVICE_PERIPHERALS
<re_irc> <@bradleyharden:matrix.org> Whoops, didn't see your reply
<re_irc> <@bradleyharden:matrix.org> Ah, ok, I think I understand
<re_irc> <@bradleyharden:matrix.org> Can I just remove `#[no_mangle]` from it?
<re_irc> <@dirbaio:matrix.org> that'd work too yeah
<re_irc> <@dirbaio:matrix.org> but then it's on you to ensure you don't conflict if you do ::take() on both pacs
<re_irc> <@bradleyharden:matrix.org> Ok. Just need to find the commit used to release the old version...
<re_irc> <@bradleyharden:matrix.org> Yes, I only call `::take()` during RTIC init
<re_irc> <@bradleyharden:matrix.org> Is there any way to tell from crates.io which commit was used for that release?
<re_irc> <@dirbaio:matrix.org> people usually make a corresponding tag in the repos
<re_irc> <@bradleyharden:matrix.org> 😬
<re_irc> <@dirbaio:matrix.org> otherwise you can download it https://crates.io/api/v1/crates/your_crate_name_goes_here/0.0.1/download
<re_irc> <@dirbaio:matrix.org> and if you untar it you get the commit in `.cargo_vcs_info.json`
<re_irc> <@dirbaio:matrix.org> or if not, you at least get the source :P
<re_irc> <@bradleyharden:matrix.org> I was just about to ask, what is a `.crate` file
<re_irc> <@dirbaio:matrix.org> it's a .tar
<re_irc> <@bradleyharden:matrix.org> tar then
<re_irc> <@bradleyharden:matrix.org> Got the commit
<re_irc> <@bradleyharden:matrix.org> Thanks
<re_irc> <@bradleyharden:matrix.org> Hmm, `fatal: reference is not a tree`
<re_irc> <@bradleyharden:matrix.org> Success. Removing `#[no_mangle]` worked. Thanks again
<re_irc> <@bradleyharden:matrix.org> Very hacky, but necessary for the moment
starblue has quit [Ping timeout: 265 seconds]
starblue has joined #rust-embedded
<re_irc> <@bradleyharden:matrix.org> What's the crate used for safely transmuting things to arrays or slices of bytes?
<re_irc> <@bradleyharden:matrix.org> I've seen people discuss a particular one before, I think
<re_irc> <@sajattack:matrix.org> yeah, let me find it
<re_irc> <@sajattack:matrix.org> https://crates.io/crates/bytemuck
<re_irc> <@dirbaio:matrix.org> I love the name hehe
<re_irc> <@dngrs:matrix.org> are the cut+paste emojis by heisenbridge just random entertainment or is there deeper meaning behind them?
nexos_ has joined #rust-embedded
<re_irc> <@dngrs:matrix.org> (bytemuck is awesome)
nexos has quit [Ping timeout: 245 seconds]
emerent has quit [Ping timeout: 252 seconds]
emerent_ has joined #rust-embedded
emerent_ is now known as emerent