00:02 <awygle> i feel that the entire data model of kicad's component libraries is flawed, which makes it difficult to drum up motivation to help with their scripts and things

00:02 <awygle> but i strongly agree with esden's description of the problem as chicken-and-egg

09:54 <emily> "the data model is flawed, so I can't bring myself to help with the implementation" is such a mood ;w;

11:52 <Stormwind_mobile> whitequark: a propos i2c scanning and repstart: I tinkered with a Melexis I2C IR temperature sensor in December, I think it was MLX60314 or similar. Getting repstarts right, or at all, proved to be crucial with this device. Not sure if it matters for scanning, though.

11:52 <whitequark> hmm

11:59 <whitequark> Stormwind_mobile: that's just SMBus

11:59 <whitequark> my proposal is a superset of SMBus so it's fine

21:08 <electronic_eel> whitequark: about the internal i2c access and timeout due to a device holding scl low (again, hope you don't mind)

21:09 <whitequark> sure

21:09 <electronic_eel> the fx2 will detect this condition without interaction from the host, issue the reset and so on

21:09 <electronic_eel> correct?

21:09 <whitequark> partially

21:09 <whitequark> detect: yes

21:09 <whitequark> reset: we don't have one

21:09 <electronic_eel> ok, not yet

21:10 <whitequark> the thing is we mostly can't have one

21:10 <whitequark> I2C devices with reset are very rare

21:10 <electronic_eel> maybe reset the i2c hardware of the fx2 if a bug in that causes it

21:10 <whitequark> huh? what bug?

21:10 <whitequark> (also it doesn't have a reset either)

21:10 <electronic_eel> don't know, maybe some hardware design issue we don't know about yet?

21:11 <whitequark> that seems extremely unlikely compared to just noise or glitches on external i2c lines

21:11 <whitequark> not that it's impossible, but the latter category is very common.

21:12 <whitequark> or just a misused microcontroller peripheral, or a buggy software i2c implementation

21:12 <electronic_eel> ok, let's say glitches and noise. wasn't there some condition where both master and slave pulled the scl low at the same time?

21:12 <whitequark> that's just clock stretching, no?

21:13 <whitequark> that's how it works. the fx2 pulls scl low, and the device keeps it low until it's ready

21:14 <electronic_eel> yeah, but the master doesn't pull low anymore during stretching

21:15 <electronic_eel> I thought you posted some condition in the spec where it could happen that both keep pulling low at the same time and you can't easily resolve it

21:16 <electronic_eel> but maybe I misremember and it was a bug in an implementation somewhere

21:18 <electronic_eel> they even have a paragraph in the i2c spec where they recommend using a reset line to resolve these cases

21:18 <electronic_eel> (or switch off vcc of the devices if they don't have reset)

21:21 <whitequark> ohh

21:21 <whitequark> that condition in the spec is in multimaster I think

21:21 <whitequark> well, there are a few

21:22 <electronic_eel> ah, ok, with multimaster this seems more likely

21:22 <whitequark> let's see, the only two cases where a chip drives SCL is when it is (a) master, or (b) something that does clock stretching

21:23 <whitequark> in the multimaster case, the problem is when two masters transmit an exactly identical write for example

21:23 <whitequark> both will think theirs succeeded

21:23 <whitequark> so if it's not idempotent it's a problem

21:23 <whitequark> but I think that doesn't require a reset

21:23 <whitequark> what you need a reset for is when the device hogs the *SDA* line

21:23 <whitequark> i.e. you have a desync between the fx2 and the device in our case

21:24 <whitequark> there are only two possible ways out of that: either you reset the device, or you blindly clock SCL and hope for the best

21:24 <whitequark> at some point the device will release SDA and then you can transmit the stop condition

21:24 <electronic_eel> yes, clocking out is common.

21:25 <whitequark> unfortunately, you might end up e.g. corrupting an EEPROM

21:25 <electronic_eel> of course

21:25 <whitequark> (which is why I2C should have just required a time based reset...)

21:25 <whitequark> (I think SMBus does)

21:25 <gruetzkopf> oh, now you're requiring a _timer_

21:26 <electronic_eel> I guess they didn't want to require internal clocks when they first developed it

21:26 <gruetzkopf> no videotext decoder has a - oh wait there's the vsync .. :D

21:28 <electronic_eel> so, how should the fx2 handle these problems?

21:29 <electronic_eel> if a device keeps sda low we could detect it on the host and send the clock out stuff from the host in the next request

21:29 <electronic_eel> if a device keeps scl low we can for now just detect it on the fx2 but can't do anything about it

21:30 <electronic_eel> in the future we will be able to isolate the bus that has this problem

21:30 <whitequark> IMO a practical way to solve this is to disable that branch of mux and ask the user to power cycle the device

21:31 <electronic_eel> yes. but disabling the mux branch means the mux handling should be completely done on the fx2

21:31 <whitequark> the clock out (or whatever other way we use to unscrew the bus) should be done autonomously on the FX2

21:31 <whitequark> yes, sure.

21:31 <whitequark> how else?

21:32 <electronic_eel> do you want to plan for that now in the access protocol or should it be extended later?

21:32 <whitequark> we can stuff the port number in wIndex, the same way it's currently done for ADCs/DACs

21:32 <whitequark> so it comes naturally

21:33 <electronic_eel> ok

21:34 <electronic_eel> if the bus-unscrew is done by the fx2, shouldn't the host be informed about it so that it can try to repeat the transfer or similar?

21:35 <electronic_eel> also if one mux-branch was disabled due to errors we should inform the host

21:35 <whitequark> yes. it'll be another error flag, we already have some (e.g. for voltage failure)

21:35 <electronic_eel> so I'm not sure if your proposal to just let the control transfer read timeout is the best way to do it

21:36 <whitequark> no, not *just* timeout

21:36 <whitequark> and for that matter, not even timeout at all

21:36 <whitequark> if the time limit is enforced on FX2 then it should stall EP0, which immediately kills the transfer

21:36 <whitequark> with -EPIPE on Linux

21:37 <whitequark> then the host can send a status request to see exactly what happened

21:37 <whitequark> that's the way a similar condition is already handled

21:38 <electronic_eel> how does the usb stall work exactly? the host tries to read from the device, but the device nacks

21:40 <electronic_eel> or is stall a special kind of packet?

21:40 <whitequark> latter

21:41 <electronic_eel> ok, so there is no timeout, very good. and then a bunch of i2c error flags. that should be enough to handle everything

21:41 <whitequark> yep

23:10 <esden> Repost from Discord:

23:10 <esden> I am looking for people that have blogs and YT channels, and want to do projects they can talk about using the glasgow. I have a few prototype units for that purpose.

23:10 <esden> I am not interested in "mailtime" -> "drawer" at the moment.

23:10 <esden> Also if you have specific, interesting applets you want to develop for glasgow and need the hardware for it I do want to hear about the project, and I might be able to help out. :slight_smile:

23:11 <esden> (cut and pasted bit too much ... damn emoji stuff :P )