<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> 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> 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> 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>
<@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.)
<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