ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to and logged at, code of conduct at
aspe has joined #rust-embedded
aspe has quit [Client Quit]
aspe has joined #rust-embedded
aspe has quit [Read error: Connection reset by peer]
aspe has joined #rust-embedded
aspe has quit [Client Quit]
emerent has quit [Ping timeout: 260 seconds]
emerent has joined #rust-embedded
aspe has joined #rust-embedded
aspe has quit [Quit: aspe]
<re_irc> <yruama_lairba> hi, does someone already played with stm32 spi in i2s mode ? i get trouble to synchronise reliably a slave
<re_irc> <yruama_lairba> for a obscure reason, data seems not to be written at the right moment
bjc has joined #rust-embedded
<re_irc> <yruama_lairba> according to my test, with 32bits datalength, i have sometime 16 LSB bit of right channel transmitted instead of 16 MSB bit of left channel.
<re_irc> <yruama_lairba> i may found what was wrong, i was expected data register to be "deleted" when disabling i2s because datasheet say the corresponding flag is reset. i thought it reset to initial value, but in fact it's deleted
<re_irc> <yruama_lairba> in my logic, i can somtimes disable the device just after data register is filled.
fabic has joined #rust-embedded
<re_irc> <firefrommoonlight> yruama_lairba: Yes
<re_irc> <firefrommoonlight> *Sry nvm misread
<re_irc> <firefrommoonlight> If it's like SAI, you should enable the Master Clock output, and use that as the slave's timing source
<re_irc> <firefrommoonlight> With appropriate scalers on both STM32 and slave
fabic has quit [Ping timeout: 252 seconds]
aspe has joined #rust-embedded
<re_irc> <trangar> Ah I needed "*(.rodata*)", not "*(.rodata)" 👍️
<re_irc> <korken89> Has anyone here tried making a multidrop ethernet bus? I want to be able to have multiple small ethernet based board connected in series - but switch ICs are unobtanium
<re_irc> <korken89> So I'm thinking each board will just pass the ethernet though it (with 2 connectors) and have a passive tap to the PHY on the board using something like an old hub circuit:
<re_irc> <korken89> Does anyone know if this would work or if there is a better way to do this?
<re_irc> <korken89> So I'm thinking each board will just pass the ethernet though it (with 2 connectors) and have a passive "tap" to the PHY on the board using something like an old hub circuit:
<re_irc> <korken89> Or is one required to get ethernet switch chips?
<re_irc> <dcz> why does the core crate not include many f32 functions like f32::abs?
<re_irc> <dcz> are intrinsics meant to be used?
<re_irc> <James Munns> Yes, but libm is not linked in by default dcz
<re_irc> <James Munns> You’ll need to include the libm crate or an alternative like micromath
<re_irc> <dcz> thanks. I can't find any ifdefs for armhf, so I assume it's just incomplete
<re_irc> <dcz> fma would have been nice to have because it's already in the hardware
<re_irc> <ejpcmac> cr1901: Hi cr1901, I’m currently writing an implementation of a simple TLV protocol in Rust, maybe that can fit your purpose:
<re_irc> <ejpcmac> It’s still in active development state though.
<cr1901> ejpcmac: Your protocol looks fine as long as I can use it for RPC from host=>embedded, and the embedded device can _also_ send commands
<cr1901> (i.e. host can send to embedded, embedded ACKs. But also embedded can send to host, host ACKs.)
<re_irc> <ejpcmac> cr1901: It’s bi-directional, but there is currently a design flow where you can have issues if one device sends a command when the other is waiting for a response, because there is only 1 RX buffer that is used for both.
<re_irc> <ejpcmac> Like, in: host sends a command to embedded, but embedded was also sending a command, so host treats the command from embedded as a reply to its command and is then confused.
<re_irc> <ejpcmac> I plan to fix this in a next version of the protocol. Not sure exactly how at the moment, because I want to keep the footprint low.
<cr1901> There might not be a protocol-level solution yet, but in my case "the host abandons trying to send its command and replies to the embedded device" is acceptable
<re_irc> <ejpcmac> If the commands are fully asynchronous, you’ll need to have a “reapeat if response is unexpected” mechanism.
<re_irc> <ejpcmac> I think to solve this issue, I’ll need to properly separate commands from reply at protocol level, and then at implementation level they could use either two buffers, or queued messages.
<cr1901> I wanted to be able to get temperature measurements at regular intervals; my device can send up to 128 16-bit measurements at a time.
<cr1901> My intent was "if a second request for 128 measurements was queued while collecting the first 128 measurements was still ongoing, you would be guaranteed 256 evenly-spaced measurements"
<cr1901> i.e. "the microcontroller would make sure that splitting up the measurements didn't affect the period between measurement 128 and 129
<cr1901> (since there would be overhead from having to pack up the measurements and send them off)
<cr1901> with COBS, I could create a protocol that doesn't need Ack'ing to send both measurement requests
<cr1901> Hmmm, wait nevermind
<cr1901> I think I can get what I want to work while still having everything be host-driven
<cr1901> ejpcmac: Ignore the above minddump. I think I can make things work
<re_irc> <ejpcmac> OK, because your device is only measuring if asked by the host? It’s not a stream of measurement all the time?
<re_irc> <ejpcmac> So you still need a command from the host to start measurements?
<cr1901> Yes
<re_irc> <ejpcmac> Yes, what you need is a command / ack / notification scheme.
<re_irc> <ejpcmac> With the notification containing the data.
<re_irc> <ejpcmac> But if your data is valuable, and you want to be sure not to miss anything, you need command / ack / data / ack.
<re_irc> <ejpcmac> On the device you can retry to send the data if there is any error during the transmission (including an unexpected reply)
<re_irc> <ejpcmac> For this kind of application
<re_irc> <ejpcmac> the risk of having a command arriving at the same time of the data upload is not that great, so the retry path shouldn’t be hit that often.
<cr1901> >including an unexpected reply <-- do you mean "including an unexpected command*"?
<cr1901> since that would be the uncommon retry path
<re_irc> <ejpcmac> Yes
<re_irc> <ejpcmac> I said reply, because in the point of view of the device, which is sending a “data command”, the command from the host is a reply if it arrives at the bad time.
<cr1901> fair enough :)
<cr1901> My alternate solution was "wait for measurements < 128", "start stream", "wait for stream" command. All host-driven
<cr1901> And "end stream" command
<cr1901> s/wait for stream/wait for measurements == 128/
<re_irc> <ejpcmac> Yeah, but in this case how would you schedule the next 128 measurements without a drift?
<re_irc> <ejpcmac> Oh, you do a start stream, then a second start stream, then wait for measurements?
<re_irc> <ejpcmac> So that when the device replies to the wait for measurement command, the second stream has already started.
<re_irc> <ejpcmac> And just after, you do a new start stream, then wait for measurements.
<re_irc> <ejpcmac> But then, between the wait for measurement command and its later reply, you cannot send any command to your device, including stop stream.
<cr1901> The second start stream was my original intent, but I'm not sure if it's necessary. I can make sure the 129th measurement is picked up on time in between sending serial characters
<cr1901> >between the wait for measurement command and its later reply, you cannot send any command to your device, including stop stream.
<cr1901> Correct
<cr1901> if you need a not-multiple-of-128, discard part of the last buffer :P
<re_irc> <ejpcmac> If you go for using, please note that its first version is still under development. I’ll do a breaking change this week-end, adding timeouts to all built-in commands (you can already provide one for custom commands). I may introduce other breaking changes before v0.1.0, but it’s quite unlikely at this point.
* cr1901 nods... I'll take a look when I return to this project, thanks
<re_irc> <ejpcmac> I’d say that apart from the timeouts, the first version is mostly finished in term of API. I’ll be mainly working on the tooling in the weeks to come. (companion CLI, etc.)
<cr1901> I have to bail on this project for now b/c it'll take too much time to get things the way I want (see msgs yesterday). But cool protocol :)
<re_irc> <ejpcmac> Any feedback is appreciated, either for tiny fixes for this version, or bigger changes for v0.2.0 of the protocol + lib.
<re_irc> <ejpcmac> cr1901: Yeah, taking a break sometimes help figuring better solutions.
<re_irc> <yruama_lairba> who already used a rasbperry pico ? i just realize it's insane for the price
<re_irc> <jannic> yruama_lairba: A lot of people. Many can be found at
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 248 seconds]
fabic has joined #rust-embedded
dreamcat4 has quit [Quit: Connection closed for inactivity]
fabic has quit [Ping timeout: 260 seconds]
starblue has quit [Ping timeout: 240 seconds]
aspe has quit [Quit: aspe]
starblue has joined #rust-embedded
dreamcat4 has joined #rust-embedded
dc740 has quit [Remote host closed the connection]
dreamcat4 has quit [Quit: Connection closed for inactivity]
starblue has quit [Ping timeout: 248 seconds]
bjc has quit [Quit: ERC 5.4 (IRC client for GNU Emacs 28.1)]
starblue has joined #rust-embedded
bjc has joined #rust-embedded
emerent has quit [Ping timeout: 260 seconds]
emerent_ has joined #rust-embedded
emerent_ is now known as emerent