figushki has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
redstarcomrade has quit [Read error: Connection reset by peer]
<asjackson>
im writing (or at least trying :D) a gpib controller applet and im a bit confused about buffers and pullup resistors. if i have an io buffer and im using the oe line, does that disable the pull up resistors when oe is low?
whitequark[cis] has joined #glasgow
<whitequark[cis]>
the pulls are separate
<whitequark[cis]>
and they're fixed for the duration of an applet's runtime
<whitequark[cis]>
(right now anyway, this is a software limitation)
<asjackson>
ah i see
<asjackson>
i wonder if actually even possible to do gpib at the moment then
<urja>
what do you need to disable the pulls for? I mean, if you enable the output driver, it will happily override the pull so ... ?
<urja>
(I'd need to check GPIB spec myself...)
<asjackson>
my understanding is that which ever device is talking enables pull up resistors on the input lines (but it's very likely ive misunderstood something)
<urja>
It could operate the I2C bus to the pull drivers, but then you'd have the "fun" of being multi-master I2C with the FX2... or it could ask the FX2 to change the pulls... or it could ask the host program to ask the FX2 to change the pulls (which is electrically to me the most ridiculous thing but ina software way the most likely to happen, to me :P)
<whitequark[cis]>
wow, you got way further with it than i ever did
<asjackson>
i have messed about with gpib quite a bit in the past. helped a friend with an arduino implementation, and later wrote a 2.11BSD driver for a PDP-11 GPIB controller card :D
<asjackson>
happy this is working though
<asjackson>
i don't think the code is too gross either
<asjackson>
(although i dont know what im doing with the glasgow so... :D)
<whitequark[cis]>
i got defeated by the GPIB spec
<whitequark[cis]>
i have some GPIB devices though so i would definitely be willing to review and test a prospective applet
redstarcomrade has quit [Read error: Connection reset by peer]
<asjackson>
it's a shame it's listen only, would love to be able to use it bidirectional, but currently i guess that will need an external hat
<whitequark[cis]>
how so?
<whitequark[cis]>
i am pretty sure nothing in the spec requires any additional logic
<asjackson>
the pull up resistors are fixed
<whitequark[cis]>
and?
<asjackson>
which ever device is talking needs to handle the pull up of certain lines i think
<asjackson>
as you said it would need software changes
<asjackson>
idk how to do that :D
<whitequark[cis]>
hm
<whitequark[cis]>
if you didn't mind a bit of delay you could just call a python method that changes pull resistors whenever you switch state
<whitequark[cis]>
like, right now
<asjackson>
oh really
<asjackson>
i'd like to try that, although not tonight, odd work tomorrow though 😎
<whitequark[cis]>
await device.set_pulls(args.port_spec, args.pin_blah.number) i think
<asjackson>
OH
<whitequark[cis]>
* await device.set_pulls(args.port_spec, high={args.pin_blah.number}) i think
<asjackson>
is it that easy, ok yeah i can do that
<asjackson>
i pretty much implemented what I THINK is bidirectional, and then deleted a bunch of stuff to get it listen only
<asjackson>
so maybe it'll be quite quick
<whitequark[cis]>
this isn't a fantastic interface because you would like, override pulls any other applet does. but we don't have multi-applet support yet anyway
<asjackson>
i have had lots of fun figuring out amaranth this weekend (and a bit last weekend with the logic analyzer triggering stuff)
<whitequark[cis]>
GPIBInterface should be called GPIBSubtarget, and the UART applet does a dirty thing where it directly returns the stuff demultiplexer.claim_interface returns
<asjackson>
ah right
<whitequark[cis]>
which isn't intended to be applet-end-user-exposed
<whitequark[cis]>
and weirds people out sometimes
<whitequark[cis]>
i should fix that actually
<whitequark[cis]>
but yeah it just calls await device.set_pulls when you do claim_interface(pull_high=)
<asjackson>
i see!
<whitequark[cis]>
modulo some stuff you can see in the implementation
<asjackson>
i think i could get that working tomorrow
<whitequark[cis]>
like handling CLI-level pin inversion
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #glasgow
redstarcomrade has quit [Read error: Connection reset by peer]
<asjackson>
if i can get gpib working properly tomorrow is it worth doing the bus and interface as gateware? there are lots of other "things" that sit on top of gpib, including some weird floppy drives :)