00:33 <re_irc> <yruama_lairba> hi, does someone already played with stm32 spi in i2s mode ? i get trouble to synchronise reliably a slave

00:39 <re_irc> <yruama_lairba> for a obscure reason, data seems not to be written at the right moment

01:21 <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.

02:04 <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

02:07 <re_irc> <yruama_lairba> in my logic, i can somtimes disable the device just after data register is filled.

03:43 <re_irc> <firefrommoonlight> yruama_lairba: Yes

03:43 <re_irc> <firefrommoonlight> *Sry nvm misread

03:44 <re_irc> <firefrommoonlight> If it's like SAI, you should enable the Master Clock output, and use that as the slave's timing source

03:44 <re_irc> <firefrommoonlight> With appropriate scalers on both STM32 and slave

08:05 <re_irc> <trangar> Ah I needed "*(.rodata*)", not "*(.rodata)" 👍️

08:28 <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

08:29 <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: https://www.eeweb.com/wp-content/uploads/articles-articles-the-setting-of-a-passive-ethernet-hub-1326382960.gif

08:29 <re_irc> <korken89> Does anyone know if this would work or if there is a better way to do this?

08:32 <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: https://www.eeweb.com/wp-content/uploads/articles-articles-the-setting-of-a-passive-ethernet-hub-1326382960.gif

08:41 <re_irc> <korken89> Or is one required to get ethernet switch chips?

09:00 <re_irc> <dcz> why does the core crate not include many f32 functions like f32::abs?

09:00 <re_irc> <dcz> are intrinsics meant to be used?

10:08 <re_irc> <James Munns> Yes, but libm is not linked in by default dcz

10:09 <re_irc> <James Munns> You’ll need to include the libm crate or an alternative like micromath

10:14 <re_irc> <dcz> thanks. I can't find any ifdefs for armhf, so I assume it's just incomplete

10:15 <re_irc> <dcz> fma would have been nice to have because it's already in the hardware

10:23 <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: https://github.com/ercp/ercp_basic.rs/tree/develop

10:24 <re_irc> <ejpcmac> It’s still in active development state though.

10:45 <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

10:46 <cr1901> (i.e. host can send to embedded, embedded ACKs. But also embedded can send to host, host ACKs.)

10:49 <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.

10:52 <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.

10:53 <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.

10:54 <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

10:55 <re_irc> <ejpcmac> If the commands are fully asynchronous, you’ll need to have a “reapeat if response is unexpected” mechanism.

10:57 <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.

10:59 <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.

11:00 <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"

11:00 <cr1901> i.e. "the microcontroller would make sure that splitting up the measurements didn't affect the period between measurement 128 and 129

11:00 <cr1901> (since there would be overhead from having to pack up the measurements and send them off)

11:01 <cr1901> with COBS, I could create a protocol that doesn't need Ack'ing to send both measurement requests

11:02 <cr1901> Hmmm, wait nevermind

11:02 <cr1901> I think I can get what I want to work while still having everything be host-driven

11:03 <cr1901> ejpcmac: Ignore the above minddump. I think I can make things work

11:03 <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?

11:03 <re_irc> <ejpcmac> So you still need a command from the host to start measurements?

11:03 <cr1901> Yes

11:04 <re_irc> <ejpcmac> Yes, what you need is a command / ack / notification scheme.

11:04 <re_irc> <ejpcmac> With the notification containing the data.

11:05 <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.

11:05 <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)

11:06 <re_irc> <ejpcmac> For this kind of application

11:06 <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.

11:07 <cr1901> >including an unexpected reply <-- do you mean "including an unexpected command*"?

11:08 <cr1901> since that would be the uncommon retry path

11:08 <re_irc> <ejpcmac> Yes

11:09 <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.

11:09 <cr1901> fair enough :)

11:10 <cr1901> My alternate solution was "wait for measurements < 128", "start stream", "wait for stream" command. All host-driven

11:10 <cr1901> And "end stream" command

11:10 <cr1901> s/wait for stream/wait for measurements == 128/

11:11 <re_irc> <ejpcmac> Yeah, but in this case how would you schedule the next 128 measurements without a drift?

11:11 <re_irc> <ejpcmac> Oh, you do a start stream, then a second start stream, then wait for measurements?

11:12 <re_irc> <ejpcmac> So that when the device replies to the wait for measurement command, the second stream has already started.

11:12 <re_irc> <ejpcmac> And just after, you do a new start stream, then wait for measurements.

11:13 <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.

11:14 <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

11:14 <cr1901> >between the wait for measurement command and its later reply, you cannot send any command to your device, including stop stream.

11:14 <cr1901> Correct

11:14 <cr1901> if you need a not-multiple-of-128, discard part of the last buffer :P

11:17 <re_irc> <ejpcmac> If you go for using ercp_basic.rs, 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.

11:18 <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.)

11:19 <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 :)

11:19 <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.

11:21 <re_irc> <ejpcmac> cr1901: Yeah, taking a break sometimes help figuring better solutions.

12:15 <re_irc> <yruama_lairba> who already used a rasbperry pico ? i just realize it's insane for the price

13:42 <re_irc> <jannic> yruama_lairba: A lot of people. Many can be found at #rp-rs:matrix.org