01:15 <justacec[m]> I have been looking for a bit of information on how long the CS line should be de-asserted between R/W operations on an SPI line. Not finding a lot on that or any information in the timing diagrams on the device. Is there a minimum standard that implementations should use? I am using the MPU9250 library at https://github.com/copterust/mpu9250. The chip was not behaving until I put delays in the code right after the CS line was

01:15 <justacec[m]> de-asserted.

01:15 <justacec[m]> For instance, it is at least 1 clock cycle?

01:17 <adamgreig[m]> the clock isn't running when cs is deasserted, so it won't generally be in terms of bus clock cycles

01:18 <justacec[m]> The timing diagram I was looking at is at https://invensense.tdk.com/download-pdf/mpu-6500-datasheet/ on page 16

01:18 <adamgreig[m]> yea, the timing diagram annoyingly doesn't say, but you could expect it needs at least the same setup and hold time that it does when asserted, i.e. around 500ns total

01:19 <adamgreig[m]> are you able to measure (with a logic analyser or oscilloscope) how long you have between deassert and assert without a delay in your code?

01:19 <adamgreig[m]> it's possible the delay is just masking some other problem you were having, but if the cs is being re-asserted really quickly perhaps that's the issue

01:20 <adamgreig[m]> that said, the second table suggests that the hold time could be as low as 1ns when the spi clock is faster, so....

01:22 <adamgreig[m]> seems you're maybe not the only one: https://github.com/copterust/mpu9250/issues/9

01:25 <justacec[m]> :)

01:25 <justacec[m]> I did not see that issue in there. Thanks for that pointer.

01:26 <justacec[m]> Not sure that reducing the optimization is the right approach. Good for debugging.

01:36 <justacec[m]> One thing I find interesting about the MPU6500 (and friends) is that when an interrupt occurs, you have to interrogate the interrupt status register to see which interrupt fired. Reading the interrupt status register also clears the interrupt. I would have expected to writing to the interrupt status register would have cleared the interrupt.

01:59 <Darius> saves you an IO request if reading clears it though

02:01 <Darius> (and I2C is slow)

08:17 <thejpster[m]> ok, let's go. This morning's task is to re-work the embedded-sdmmc test infrastructure and see if we can't weed out some more bugs.

08:46 <Farooq> <Darius> "(and I2C is slow)" <- Guess what, a local shop in my country sells a SCCB camera module for 1 USD

08:46 <Farooq> The camera is 15fps

08:47 <M9names[m]> what's SCCB?

08:48 <diondokter[m]> I guess it's Serial Camera Control Bus

08:48 <diondokter[m]> https://www.waveshare.com/w/upload/1/14/OmniVision_Technologies_Seril_Camera_Control_Bus%28SCCB%29_Specification.pdf

08:51 <diondokter[m]> VGA is analog though... So not sure how that'd work

08:51 <Farooq> yeah. it says compatible with I2C. And it says max framerate 30fps VGA. I wonder if this SCCB is capable of that transfer

08:52 <Farooq> no it means VGA resolution from my understanding. 640x480 px

08:52 <diondokter[m]> Ah ok

08:54 <Farooq> It turns out I missed the Tuesday meeting?

08:54 <Farooq> I didn't expect it to be that soon when I saw the hackmd link. didn't read carefully though

09:31 <Darius> Farooq: the camera is controlled via I2C (pretty common AIUI) but the video is anotehr matter

09:54 <Farooq> so you mean the video signals are not transfered using i2c? it makes much more sense now.

10:33 <Lumpio-> Transferring video via I2C would be pretty unusual

12:07 <dalepsmith[m]> Video takes a lot more bandwidth that I2C

12:14 <diondokter[m]> According to my calculations you could do a 12x9 pixels at 16 bit color depth at 24 fps over a 400 khz I2C bus :P

12:23 <Darius> diondokter[m]: smokin'

17:14 <cr1901> 48x36 at 1 bit color depth at 24 fps seems more reasonable

17:23 <JamesMunns[m]> You could probably get a VGA-ish, lossy/compressed format like h.264/h.265 over 1mbps I2C

17:34 <JamesMunns[m]> (as in theoretical bitrate, not like... you SHOULD do that or could buy that off the shelf anywhere)

18:18 <cr1901> That sounds like a horrible idea... let's do it :D

19:57 <GijsBurghoorn[m]> Regarding joining the weekly meeting, is there just a call here I can join on 8pm CET every Tuesday?

19:57 <diondokter[m]> The meeting is just using chat, right here in this room

19:57 <GijsBurghoorn[m]> Perfect. Thank you very much.

22:17 <adamgreig[m]> <JamesMunns[m]> "You could probably get a VGA-ish..." <- lots of (highly compressed) 1080p video is about 1Mbps! it's amazing how little bandwidth modern video codecs use

22:17 <adamgreig[m]> h265 would be even better

22:18 <diondokter[m]> Ok, so that has been solved. Now how do we compress and decompress the video on a 100mhz cortex m4 :D

22:20 <likewise[m]> We cheat by using RPMsg with STM32MP1, I guess.

22:20 <firefrommoonligh> Yea I think that's a good use for those

22:22 <likewise[m]> With Cortex-M4 we are talking SPF instead of FPS.

22:24 <likewise[m]> Cortex-M4 is too new, we need an ARM9 core...

22:24 <likewise[m]> https://www.unifore.net/ip-video-surveillance/ip-camera-soc-hi3518e-vs-hi3518c.html

22:52 <gussius[m]> (reposted) Hi All, I get a linker error when I define an #[exception] in a submodule of my project. I am using the cortex-m-rt crate. The specific error is a duplicate symbol error. I presume that the default linker script (where ever that is) sets up the exception if there is none defined in the root module (i.e. PROVIDE(...). Any thoughts?

22:53 <dirbaio[m]> can you paste the full error?

22:53 <gussius[m]> Yep, I'll just whip it up again...

22:59 <gussius[m]> 🤔 It is linking now. It wasn't yesterday. Sorry about that I will just try to make use of the exception, and I'll see if it works...

23:33 <gussius[m]> Looks like I was focusing on the linking error and not really thinking through what I was trying to achieve. Looks like a false alarm. 🙄 I think I need to put some more thought into this.

23:33 <gussius[m]> Thanks.