<_whitenotifier-5>
[glasgow] github-merge-queue[bot] created branch gh-readonly-queue/main/pr-810-1db81071563f89619c2b29a80ae3ccced70d65f4 - https://github.com/GlasgowEmbedded/glasgow
<whitequark[cis]>
apologies to everyone affected by dropping python 3.10 support
<whitequark[cis]>
there is technically a backport of the required functionality, but I don't trust it and testing it is adding to the logistical nightmare shipping Python projects already is
<whitequark[cis]>
pdm python install cpython@3.11 should have you covered if you're using pdm on linux (if you're on windows you probably don't care in first place)
<whitequark[cis]>
so, i have a bit of a conundrum with pull resistors
<whitequark[cis]>
glasgow has configurable pull resistors. it achieves this by connecting a PCA6408A GPIO expander to Vio and configuring the outputs to be floating, high, or low; the GPIO expander has an array of 10k resistors connected between it and the IOs
<whitequark[cis]>
this means that, at the very least, glasgow has one bit (technically, four bytes) of state, stored in the GPIO expanders, and controlling the resistors themselves. this state is lost if for any reason Vio goes below 1.1 V (1.4 V max)
<whitequark[cis]>
* this means that, at the very least, glasgow has four bytes (two bytes per GPIO expander) of state, stored in the GPIO expanders, and controlling the resistors themselves. this state is lost if for any reason Vio goes below 1.1 V (1.4 V max)
<whitequark[cis]>
when you're running an applet, you generally want to configure pull resistors: to set them high, low, or explicitly float if you don't need them, since there is no guarantee that the GPIO expanders were reset since starting the applet
<whitequark[cis]>
(the GPIO expanders are currently reset by the firmware whenever you reload the FPGA bitstream, but this is due to a bug in revC3 and it's something we will fix in newer revisions)
<whitequark[cis]>
you can't necessarily configure the GPIO expanders (either to turn them floating, or to set them to the right values) when you're configuring the FPGA because Vio might not be enabled (and, again, with revC3 it is guaranteed to be disabled)
<whitequark[cis]>
this means that if you specify whether you want the pin to be pulled high or low at the time when you construct the bitstream, it has to be stored elsewhere in the software until it can be applied (i.e. when Vio rises)
<whitequark[cis]>
that makes twice the amount of state, and of course this state can get out of sync
<whitequark[cis]>
moreover, when you're configuring an applet, you usually don't want to configure a whole port's worth of pulls; rather you want to configure pulls on the pins you care about
<whitequark[cis]>
nothing stops you (aside from the lack of UI support) from having a UART0 applet on pins A0, A2 and UART1 applet on A1, A3
<whitequark[cis]>
so the state can't live in the applet; it has to be shared between them somehow
<whitequark[cis]>
there's also an additional concern, which is that right now you can't easily change pull resistor state from the FPGA
<asjackson>
does that mean the two desires (configurable from the fpga + multiple applets) are slightly incompatible
<whitequark[cis]>
not necessarily
<whitequark[cis]>
what the desire for multiple applets means is that somewhere, there must be a source of truth for the pull resistor state
<whitequark[cis]>
it could be in the FPGA fabric, or it could be in the FX2, or it could be in the software