<re_irc>
<zintao> Want to make 1000s money online easily just by promote online game? Join now partner program 50% affiliate pay out money in monthly.
<re_irc>
Хотите легко заработать 1000 денег в Интернете, просто продвигая онлайн-игру? Присоединяйтесь сейчас к партнерской программе 50% партнерских выплат ежемесячно.
<re_irc>
<raviprajeed1998> Want to make 1000s money online easily just by promote online game? Join now partner program 50% affiliate pay out money in monthly.
<re_irc>
Хотите легко заработать 1000 денег в Интернете, просто продвигая онлайн-игру? Присоединяйтесь сейчас к партнерской программе 50% партнерских выплат ежемесячно.
dc740 has quit [Remote host closed the connection]
dc740 has joined #rust-embedded
starblue has quit [Ping timeout: 268 seconds]
starblue has joined #rust-embedded
<re_irc>
<Urhengulas> What board with good "embedded-nal" support can you recommend?
<re_irc>
Looking at the reverse dependencies of "embedded-nal" it seems that everything that supports "smoltcp" would be a good option. Otherwise maybe the "nRF9160-DK" with diondokters "nrf-modem-nal"?
<re_irc>
Any input is appreciated! 😺
<re_irc>
<ryan-summers> The STM32H7-Nucleo is a good bet
<re_irc>
<ryan-summers> But yeah, I maintain an e-n implementation for smoltcp, so anything with an ethernet PHY would be fine
<re_irc>
<Urhengulas> Thank you ryan-summers. Which implementation would we use with the stm32h7? The smoltcp one?
<re_irc>
<ryan-summers> Yeah, the STM32H7 only has an ethernet PHY, which only lets you send/receive ethernet frames. You'll need smoltcp + smoltcp-nal to get ethernet support
<re_irc>
<ryan-summers> An alternative is to use the w5500 as an external peripheral
<re_irc>
<ryan-summers> It's a hardware ethernet stack controlled over SPI with an embedded-nal implementation pre-written for it as well
<re_irc>
<ryan-summers> Yeah, the STM32H7 only has an ethernet PHY, which only lets you send/receive ethernet frames. You'll need smoltcp + smoltcp-nal to get full UDP/TCP support
<re_irc>
<ryan-summers> If you use the STM32H7, you can also follow the setup process that https://github.com/quartiq/stabilizer uses if you need a reference implementation
<re_irc>
<Urhengulas> 👍️
brazuca has joined #rust-embedded
brazuca has quit [Quit: Client closed]
<re_irc>
<mabez> I don't suppose anyone has a working configuration for Rust + GNU LD linker + LTO?
<re_irc>
<mabez> Enabling LTO in this setup usually means panic ends up being optimized out which then throws a undefined reference error
<re_irc>
<mabez> I'm curious if anyone has figured this out
<re_irc>
<mabez> Probably not a very common setup though
loki_val has quit [Remote host closed the connection]
<re_irc>
<dirbaio> I don't think GNU LD can do LTO on LLVM-compiled projects?
crabbedhaloablut has joined #rust-embedded
<re_irc>
<mabez> Yeah, I figured that might be the case. Seems like it almost works though, I'd expect it to not work at all if it wasn't actually supported
crabbedhaloablut has quit [Remote host closed the connection]
<re_irc>
<dirbaio> LTO means feeding LLVM bitcode to the linker, so it requires the LLVM LD
crabbedhaloablut has joined #rust-embedded
<re_irc>
<dirbaio> or is it supposed to be supported by the "linker plugin" thing?
<re_irc>
<mabez> dirbaio: I thought that only happened with lto = thin?
<re_irc>
<mabez> No, you're right. I misread initially.
<re_irc>
<dirbaio> adamgreig: i've transfered the repo but no longer have permissions to it. can you assign it to the HAL team?
<re_irc>
<dirbaio> btw do you think we could add support for it in cortex-m 0.7.x?
<re_irc>
<dirbaio> just adding the cargo feature to supply the impl, keeping the (unsound on multicore) interrupt::free so it's backwards compatible
<re_irc>
<dirbaio> and do the breaking changes in 0.8
<re_irc>
<dirbaio> this way "critical-section" becomes usable now, instead of having to wait for 0.8
brazuca has joined #rust-embedded
dc740 has joined #rust-embedded
gsalazar has quit [Read error: Connection reset by peer]
gsalazar has joined #rust-embedded
dc740 has quit [Ping timeout: 244 seconds]
gsalazar has quit [Quit: Leaving]
gsalazar has joined #rust-embedded
causal has quit [Quit: WeeChat 3.6]
dc740 has joined #rust-embedded
brazuca has quit [Quit: Client closed]
<re_irc>
<dkhayes117> If I'm using nrf9160's "serial.read(&mut buf)", how do I "complete" the buffer on enter? Serial read is blocking until buffer is full, but of course I won't be filling the buffer so it would be stuck blocking.
<re_irc>
<James Munns> Not certain with the 9160 specifically, but on the nrf family the answer is "it's tricky"
<re_irc>
<James Munns> I don't know of a hal-compatible way of doing it.
<re_irc>
<dirbaio> yeah there's no way to do it, other than reading byte-by-byte
<re_irc>
<James Munns> you'd either need to use a timeout (with an interrupt or PPI), or process each character at a time.
<re_irc>
<dirbaio> * it with nrf-hal,
<re_irc>
<dirbaio> if you want something higher-level that does it, embassy-nrf has "BufferedUarte"
<re_irc>
<dirbaio> which supports "short reads": ".read(&mut buf)" returns as soon as it's got some data, returning how many bytes were actually read
dc740 has quit [Ping timeout: 252 seconds]
<re_irc>
<dirbaio> like std::io
<re_irc>
<dkhayes117> So for byte by byte, would I make another buffer like [u8;1] and use that in the serial read and then push into my acutal buffer until it sees the enter? I started to do that, but it seemed hacky.
<re_irc>
<dirbaio> yep
<re_irc>
<dirbaio> and yep, it's hacky. if you do it too slow you'll lose data (the hardware only has buffer for 4 bytes)
<re_irc>
<James Munns> Other alternative would be to have an interrupt fire on each character received, and push that into a buffer
<re_irc>
<dkhayes117> I'm making an AT serial client for debugging the modem
<re_irc>
<James Munns> (or, if you go the whole nine yards, I have some example code that only fires the interrupt when there HAS been a byte received AND the line has gone quiet for some amount of time)
<re_irc>
<James Munns> Is embassy still using that trick too dirbaio?
<re_irc>
<dirbaio> yep
<re_irc>
<James Munns> (your code is likely cleaner than mine)
<re_irc>
<James Munns> yeah
<re_irc>
<dirbaio> that's exactly what BufferedUarte does
<re_irc>
<James Munns> yeah, that uses PPI to start (or reset) a timer each time a byte is received
<re_irc>
<James Munns> if the timer expires, it sends a "stop" event to the serial port to flush any present bytes and start over
<re_irc>
<James Munns> sort of a hacky "line quiet, terminate DMA early" event, which some other MCUs have built in
<re_irc>
<dkhayes117> Interesting, I'll play with the BufferedUarte some this evening. Thanks!
<re_irc>
<James Munns> (really you don't want most of that logic, just the PPI setup stuff)
dc740 has joined #rust-embedded
rardiol has joined #rust-embedded
neceve has joined #rust-embedded
brazuca has joined #rust-embedded
<re_irc>
<gauteh> Is there anything generic like this existing for serial::Write traits? That I could wrap a serial-interface in to get buffering
<re_irc>
<James Munns> not super generally, no. This would usually be in std::io, but those aren't in core (yet?), so there are just a lot of project-specific versions of them
<re_irc>
<James Munns> (I should preface: AFAIK. It might have changed recently)
rardiol has quit [Ping timeout: 268 seconds]
<re_irc>
<dirbaio> bridge is acting up again? I don't see gauteh's message
<re_irc>
<dirbaio> +on the matrixside
<re_irc>
<dirbaio> * matrix side
<re_irc>
<gauteh> I tried the reply in thread feature: Is there anything generic like this existing for serial::Write traits? That I could wrap a serial-interface in to get buffering
<re_irc>
<dirbaio> ah I do see it in the thread 😓
<re_irc>
<dirbaio> the fact that james replied outside the thread confused me :D
<re_irc>
<gauteh> I was a bit confused whether that reply was to me; thanks James Munns
<re_irc>
<dirbaio> ah, or you mean something that can "add buffering" to any uart implementing the "classic" serial::Write? no, I don't think that's possible
<re_irc>
<gauteh> Yeah, basically
<re_irc>
<dirbaio> because it needs to somehow use interrupts
<re_irc>
<dirbaio> and ideally DMA
<re_irc>
<dirbaio> to read/write from the buffers "in the background"
<re_irc>
<gauteh> I was thinking a bit more naive; write them the next time write or flush is called
<re_irc>
<dirbaio> ah for writing maybe
<re_irc>
<dirbaio> but for reading?
<re_irc>
<gauteh> hm, yeah no that doesn't work
<re_irc>
<gauteh> but writing is my immediate problem :p
<re_irc>
<dirbaio> you can do it by writing to a heapless Vec or String, then write it to the uart
dc740 has quit [Ping timeout: 268 seconds]
rardiol has joined #rust-embedded
rardiol has quit [Ping timeout: 252 seconds]
brazuca has quit [Quit: Client closed]
neceve has quit [Ping timeout: 268 seconds]
gsalazar has quit [Ping timeout: 252 seconds]
brazuca has joined #rust-embedded
fooker has quit [Ping timeout: 268 seconds]
fooker has joined #rust-embedded
dc740 has joined #rust-embedded
crabbedhaloablut has quit [Write error: Connection reset by peer]
crabbedhaloablut has joined #rust-embedded
brazuca has quit [Quit: Client closed]
brazuca has joined #rust-embedded
<re_irc>
<adamgreig> dirbaio: I'm sure there's a good reason, but why check for interrupts being active before disabling on entering the c-m critical section?
<re_irc>
<GrantM11235> It needs to know whether or not to re-enable them afterwards
<re_irc>
<GrantM11235> (speculation, I haven't actually looked at it)
<re_irc>
<adamgreig> yea, I understand that part, but can't you unconditionally disable them anyway?
<re_irc>
<adamgreig> right now it's "let active = enabled?(); if active { disable() }; return active" and then later "if was_active { enable() }"
<re_irc>
<adamgreig> but it seems like you could make the call to disable unconditional
<re_irc>
<adamgreig> has anyone used qemu-system-arm recently and got a "Timer with period zero, disabling" error?
<re_irc>
<adamgreig> it doesn't appear in qemu 2.12 used in the embedonomicon CI, but does in the 6.2.0 on my ubuntu install, the git source suggests the error itself was added 15 years ago but presumably something has changed to cause it to trigger...
brazuca has quit [Quit: Client closed]
<re_irc>
<dirbaio> adamgreig: the prev PR did that, can't think of any reason either. Doing it unconditionally is faster I guess
<re_irc>
<adamgreig> might as well save a cycle or two huh
<re_irc>
<adamgreig> the current cortex-m interrupt::free doesn't check either
<re_irc>
<dirbaio> fixed :P
<re_irc>
<dkhayes117> Question, nrf UARTE "read()" returns "Result<(), Error>", my buffer holds a single byte. How do I get the u8 value from "()"?
<re_irc>
<dirbaio> read "buffer[0]"
<re_irc>
<dkhayes117> I tried that, but it doesn't work
<re_irc>
<dkhayes117> cannot index into ()
<re_irc>
<dirbaio> let mut buf = [0u8; 1];
<re_irc>
uarte.read(&mut buf).unwrap();
<re_irc>
info!("got byte {:02x}", buf[0]);
<re_irc>
<dkhayes117> yep, that is what I have essentially
<re_irc>
<dirbaio> you're probably doing something else. in this code "buf" is the array, not a "()", so indexing is fine
<re_irc>
<dkhayes117> Oh no, maybe I'm wrong
<re_irc>
<dkhayes117> I see, what I did was
<re_irc>
let byte = serial.read(&mut buf).unwrap();