00:01 <d1b2> <rwhitby> so I have an I2CInitiatorSubtarget in my build(), and now I need to add a register for the alert signal which is polled by the async task.

00:02 <d1b2> <rwhitby> I can call iface.add_subtarget() twice? Once for I2CInitiator (unchanged) and once to add some new gateware for this alert register connected to the pin on A2?

00:06 <d1b2> <rwhitby> My gateware additional subtarget just needs to connect the input pin A2 to a register bit.

00:08 <d1b2> <rwhitby> How can I see what logic the nmigen has generated in a glasgow build?

00:39 <d1b2> <rwhitby> @Attie getting something unexpected here - the i2c transactions in the handle_irq() call in the _monitor_alert() aync task seem to block while the repl() is sitting at the prompt waiting for input.

00:42 <d1b2> <rwhitby> I guess it's because both the async task and the repl task are both waiting on the same FIFO.

01:24 <d1b2> <rwhitby> here's my conundrum. I have an async task which needs to use the I2CInitiatorSubtarget to read the alert status. Then I also have repl or interact which also needs to use the same I2CInitiatorSubtarget to do stuff. This aint gonna work cause these two coroutines will both put stuff on the FIFO and the two streams will get interleaved and confused by the unexpected responses.

02:24 <whitequark[m]> rwhitby: yes, you can add two subtargets. to see the logic you can run `glasgow build -t v <applet>` for example. yes, you have a problem due to FIFO interleaving; use some form of exclusive access, like a mutex

02:26 <d1b2> <rwhitby> thx for the tip

05:54 <d1b2> <rwhitby> Decided to see what could be done without polling the interrupt, and it seems I can achieve a 14ms response from receiving source caps to sending request. So 10ms to spare (of course this is completely dependent on USB request latency).

05:54 <d1b2> <rwhitby> https://cdn.discordapp.com/attachments/613461005392936961/815461802183753748/Screen_Shot_2021-02-28_at_4.22.40_pm.png

08:48 <d1b2> <davoid> good idea with cobs, we switched all our various framing protocols over uart/spi to use cobs for efficiency and zero-copy. are you thinking some crc at the end to handle rare glitches -> recovery? or just rely on the usb-phy there?

08:57 <whitequark[m]> rely on usb phy

08:57 <whitequark[m]> we don't currently have any extra crc, don't see why multiplexing must introduce it

08:58 <whitequark[m]> cobs is self-synchronizing anyway

23:29 <d1b2> <rwhitby> @electronic_eel, @TomKeddie any other changes you think are needed to the USB-PD board before I finalise the layout?

23:33 <electronic_eel> sorry, I was busy with other stuff over the weekend so I didn't have time to take a look

23:34 <electronic_eel> I can take a look in the evening, I'm already in bed