<d1b2>
<rwhitby> looking for advice - I have a USB-PD addon which has an I2C bus and an interrupt line from the FUSB302. I've got the I2C working fine, and have a routine (handle_irq) which I can call from repl or run and it reads the status registers and does stuff accordingly.
<d1b2>
<rwhitby> Is there a way to create some gateware to monitor the interrupt line, and to have a python function called when the interrupt line becomes active (i.e. falling edge)?
<d1b2>
<rwhitby> Just a pointer to an applet which does something similar will be very useful, otherwise if this is the first time this has been done then some guidance on the architecturally best way to do this which is compatible with the future glasgow roadmap.
<d1b2>
<rwhitby> Ideally, when in repl, you'd register an interrupt handler function, and this function would be called in the background whenever an interrupt fires, potentially performing autonomous actions in python while you're still at the repl prompt (including using logger.info).
<d1b2>
<Attie> currently, I suspect polling a register is your best bet... but the response time / overhead might be a bit not-great
<d1b2>
<Attie> (what are you looking for in terms of response time?)
<d1b2>
<rwhitby> My thoughts on polling is to create a hardware register containing the interrupt line in gateware, and use USB_REQ_REGISTER to poll it, rather than just polling the status register over I2C.
<d1b2>
<rwhitby> So that's doable, and I can probably work out how to code that.
<d1b2>
<rwhitby> But I'm looking for something thats interrupt driven rather than polling if possible.
<d1b2>
<Attie> you dont need to handle USB REQ * yourself - its abstraced nicely
<d1b2>
<rwhitby> (I realise that USB transactions are in the middle, so response time is limited by that)
<d1b2>
<rwhitby> (yes, I'd use the abstracted register read, not USB_REQ direct)
<d1b2>
<Attie> and yep - I was referring to an nMigen register, not a register in the FUSB part
<d1b2>
<rwhitby> gotcha, we're on the same page for polling
<d1b2>
<rwhitby> even for polling, how do I get that happening in the background while I'm sitting at the repl prompt?
<d1b2>
<Attie> start an async task - applets like UART use them
<d1b2>
<Attie> but I'm not sure how well it'll work in REPL
<d1b2>
<rwhitby> I guess I'd do that in run instead of interact for repl
<d1b2>
<rwhitby> (note that I can read python well, but have not written very much of it at all, so this will be a good learning curve)
<d1b2>
<rwhitby> ok, so the polling interval will be set by the argument to asyncio.sleep() in the async task while True loop.
egg|anbo|egg has joined #glasgow
<d1b2>
<rwhitby> with respect to interrupt latency, it'll need to be around 10ms or less to be effective for handling PD contract negotiations in python. otherwise that will need to be done in gateware.
<d1b2>
<rwhitby> @Attie did you see the latest USB-PD board layout after doing some work with @electric_eel last Friday?
<rwhitby>
With JP1 open, I can still measure VBUS on 3&5 with a multimeter. The same place I would inject it.
<electronic_eel>
when you have the jumper JP1 open, you can't use J6 to measure VBUS.
<rwhitby>
why not? VBUS comes from the left hand side of the picture
<electronic_eel>
you can use J8 for it. but you might want to use J8 to inject
<rwhitby>
oh, sorry, I've been mistaking J6 and J8.
<electronic_eel>
was just going to ask
<electronic_eel>
i have the schematics open, i think that is more easy to follow for this kind of discussion
<rwhitby>
I've got you now
<rwhitby>
So I missed a use case:
<rwhitby>
5) J6 and J7 can be used to measure any voltage (connect it to the jumper). As a special case, you can bridge JP1 and JP2 to measure VBUS and 1.2V rails.
<d1b2>
<rwhitby> so, for example, you could bridge D+ and J6 to measure D+ voltage.
<d1b2>
<rwhitby> I don't want to tie J6 to only VBUS measurement, but make it generically available to measure from any other test point or header point on the board.
<electronic_eel>
hmm, is usecase 5) that interesting? remeber the capacitance, it will ruin D+ for fast data transfer
<d1b2>
<rwhitby> Imagine someone without a multi-meter. They want to know whether the VDM debug switch they just did resulted in a 3.3V interface or a 1.2V interface. they can measure it on J6 before selecting jumpers on Port B.
<electronic_eel>
ok
<d1b2>
<rwhitby> but maybe they can do that on J7 instead
<d1b2>
<rwhitby> The FUSB302 has vbus tracking and measurement features.
<electronic_eel>
yes, J7 is always free for that, measuring the 1.2v is more like a gimmick
<d1b2>
<rwhitby> J8 has two points to see VBUS. What's the use case where both are covered by jumpers?
<d1b2>
<rwhitby> If you're DFP, then you're driving VBUS and don't need to measure it.
<d1b2>
<rwhitby> If you're UFP, then you can measure on pin 3&5.
<electronic_eel>
oh, as DFP you might want to measure if the voltage is still within tolerance even with all the load on it
<d1b2>
<rwhitby> For funky charger detection or something like that, you may want to measure D+ and D- at the same time, using J6 and J7 to do so.
<electronic_eel>
ah, yes, that is a reasonable usecase
<electronic_eel>
ok, leave it as it is
<d1b2>
<rwhitby> thanks for challenging it and teasing out the use cases
<electronic_eel>
next point: esd protection
<electronic_eel>
i suggest to add a tvs diode array to d+-, sbu, cc
<electronic_eel>
you could use the same 6x array that is used on glasgow now: SP3012-06UTG
<d1b2>
<rwhitby> ok, is that a JLCPCB-able thing, or will I need to solder that afterwards?
<electronic_eel>
it is available at lcsc and i think also at jlcpcb
<electronic_eel>
yes, also jlcsmt
<electronic_eel>
and for protecting vbus i suggest a SMF20A
<electronic_eel>
(also available at jlcsmt)
<d1b2>
<rwhitby> ok, I did some measurements last night, and the addon board does not yet extend out to the glasgow limits on the south side, so I can extend north and south sides to fit in TVS on the connectors.
<d1b2>
<rwhitby> Should I add to both connectors, or is one instance enough?
<electronic_eel>
do you need to extend the board? it looks like you could fit it next to the connector, where the array of traces leaves the connector
<d1b2>
<rwhitby> oh, if I can fit it existing I will
<electronic_eel>
better would be on both connectors, as you want to discharge esd as fast as possible and don't want it travelling over your board
<d1b2>
<rwhitby> ok
<d1b2>
<rwhitby> maybe it is time to bite the bullet and copy the glasgow layout around the connectors.
<electronic_eel>
glasgow uses a different ic for protecting the usb. these arrays are used for protecting the glasgow ports
<d1b2>
<rwhitby> ok
<electronic_eel>
so when you copy the port layout, you still have to do the esd arrays yourself
<electronic_eel>
while we are talking usb port layout: i think the vbus traces are a bit small
<electronic_eel>
i would try to increase them a bit, also use two vias instead of one
<electronic_eel>
think you want to power something with 1 amp
<electronic_eel>
not from glasgow obviously, but for example when snooping or injecting from a psu
<d1b2>
<rwhitby> yep, agreed
<d1b2>
<rwhitby> I was not thinking of psu injection, but can include that in the use cases
<electronic_eel>
even if you would not include that, snooping two devices could still require it
<d1b2>
<rwhitby> true
<electronic_eel>
just two points left from my review :)
<d1b2>
<rwhitby> Is there any issue with the placement of the vias here? I can place them underneath passives like this?
<electronic_eel>
you can place them under passives, but you shouldn't place them in the pads
<electronic_eel>
otherwise the solder is sucked away into the via
<rwhitby>
but right next to the pad is ok?
<electronic_eel>
there should be a small dam of soldermask between
<rwhitby>
ok, so I need to move those vias closer to the centre of underneath the passives to achieve that. I was putting them near the pad to prevent bridging, but I guess the soldermask does that for me.
<d1b2>
<j4cbo> right next to is fine if the via is tented (covered in solder mask)
<d1b2>
<j4cbo> historically you wanted to avoid “acid traps” (acute angles in the layout where etchant can get stuck) but I’ve heard that’s not really a problem with modern fabs
<electronic_eel>
the soldermask will protect you from bridging. j4cbo is right, tenting will also protect the pad. but only if the full via is tented, if it is hanging half in the mask opening of the pad it won't really help
<rwhitby>
I don't think jlcpcb does tenting, does it?
<electronic_eel>
they do it for small vias without issue
<rwhitby>
ok
<rwhitby>
so I move the vias just far enough away that there's soldermask between.
<d1b2>
<j4cbo> properly “tenting” is covering the hole itself, but just covering the annular ring is a layout thing
<d1b2>
<j4cbo> for small holes the whole thing tends to wind up covered though
<electronic_eel>
kicad unfortunately doesn't differentiate between the two, when you select no tenting it will also remove mask from the annular ring+tolerance
<d1b2>
<rwhitby> How do I check in KiCAD if that is far enough away?
<d1b2>
<rwhitby> I put 1uF on 5V and 3.3V supply lines from Glasgow.
<electronic_eel>
that poor tiny little thing?
<electronic_eel>
i thought more of proper bulk capacitance, like required by the usb spec
<rwhitby>
yes, replace the tiny thing with something suitable
<electronic_eel>
the glasgow vio might break down if some usb device is plugged in and powered on. this could for example reset the FUSB302 and so on
<electronic_eel>
the bulk cap should prevent that
<d1b2>
<rwhitby> ah, ok a huge cap package
<d1b2>
<rwhitby> need to go somewhere else then
<electronic_eel>
the other thing from my list is fault tolerance: when you accidently plug in the addon the wrong way (ports a & b interchanged) and set your 3v3 rail to 5v because of this, the level shifters will be fried
<d1b2>
<rwhitby> It's not gonna fit without extending the board.
<electronic_eel>
maybe you could power the addon with 3.3v first and try to talk to the FUSB302. only when it answers you know everything is ok and then go up to 5v?
<d1b2>
<rwhitby> yep, can do that - that's a great idea.
<electronic_eel>
and no schematics changes needed at all!
<electronic_eel>
these were all the points i wrote down during my review
<d1b2>
<rwhitby> excellent - thanks for the review. I'll upload an updated version over the next day or so.
<electronic_eel>
ok, let me know and i'll take a look
<d1b2>
<rwhitby> thanks!
<d1b2>
<rwhitby> I've also added an Applet Requirements section to the README to capture the power-up sequencing.
egg|anbo|egg has quit [Read error: Connection reset by peer]