<whitequark>
electronic_eel: thinking about it again, i am strongly in favor of using INA233 and connecting its ALERT pin directly to the LDO. this goes well in line with other safety features of Glasgow.
<whitequark>
in fact i now think this design should definitely be used for revD.
<whitequark>
(and revC2 in the future)
craigo has quit [Ping timeout: 265 seconds]
<whitequark>
electronic_eel: re INA233, did you mean we should reuse eg. R48 as existing high side shunt, or reuse the value of R48 to add an additional low side shunt?
<_whitenotifier>
[GlasgowEmbedded/glasgow] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/JeC7E
fridtjof[m] has quit [Read error: Connection reset by peer]
jschievink has quit [Read error: Connection reset by peer]
cyrillu[m] has quit [Remote host closed the connection]
nrossi has quit [Read error: Connection reset by peer]
JJJollyjim has quit [Read error: Connection reset by peer]
disasm[m] has quit [Remote host closed the connection]
chocol4te has quit [Remote host closed the connection]
ExeciN has joined #glasgow
<mwk>
so uh, I have an FPGA board with shit I/O capabilities and I want to transfer a lot of data to/from a host machine
fridtjof[m] has joined #glasgow
<mwk>
I'm thinking of using its GPIO pins to connect to glasgow and use it as a host interface
<mwk>
is there some ready-made applet for such use-case or do I get to write my own?
<mwk>
my requirements are: lotsa bandwith (as much as can be spared), but no realtime constraints (it's... let's call it a "compute" job); I want to transfer small request-reply packets (max 64 bytes I think) in both directions (with pipelining), roughly symmetric bandwidth requirements both ways
<emily>
aww ye hyperspeed UART time
<mwk>
sort of, yes
<mwk>
oh, and: the target board cannot do LVDS, I just have 16 single-ended 3.3V I/Os
<mwk>
correction, 32 single-ended I/Os
<mwk>
and the FPGA can do LVDS, it's just that the board manufacturer didn't care about pairing anything
<mwk>
it's a board so well-designed, they figured that including a 19200baud-only USB-to-UART is a good idea
nrossi has joined #glasgow
cyrillu[m] has joined #glasgow
jschievink has joined #glasgow
chocol4te has joined #glasgow
JJJollyjim has joined #glasgow
disasm[m] has joined #glasgow
carl0s has joined #glasgow
umarcor has joined #glasgow
ExeciN has quit [Ping timeout: 246 seconds]
<electronic_eel>
whitequark: do you want to use the PCAL6534 on revD? If you let me, I'll certainly get some new circuit ideas to put all those 34 bits to use :)
<electronic_eel>
whitequark: I thought of using R48 as high side shunt. Low side is calling for lots of trouble because you'd need to have per-port-GNDs and can't connect a DUT with one common GND to more than one port
<electronic_eel>
now we wouldn't really need 34 extra GPIOs on revD, but a more reasonably sized io expander would still make sense: we could move all the leds onto it and free up some proper GPIO pins
<electronic_eel>
on of these GPIOs could be used for a analog mux that connects all the ALERT pins of the INA233s together. That would allow the user to select between per-port shutoff and full hardware shutoff for all ports together
fibnot is now known as fibxor
<electronic_eel>
we could also consider using two of the now freed fx2 pins to create a second, low speed, bit banged i2c bus
<electronic_eel>
that can then be used through the PCA9545 i2c switch to talk to the addon boards
<electronic_eel>
as it is separate and software-only, it would have no chance to somehow interfere with the internal i2c of glasgow, which wouldn't be exposed at all
m4ssi has quit [Remote host closed the connection]
ExeciN has joined #glasgow
craigo has joined #glasgow
Exec1N has joined #glasgow
ExeciN has quit [Ping timeout: 268 seconds]
fibxor is now known as fibmod
carl0s has quit [Remote host closed the connection]
<esden>
Ok, Glasgow CrowdSupply pre-launch page is now updated! Thank you all for all the corrections and improvements. :D (especially electronic_eel ;) ) https://www.crowdsupply.com/1bitsquared/glasgow