hellsenberg has quit [Quit: CPU triple-faulted.]
hellsenberg has joined #glasgow
pie_ has quit [Ping timeout: 240 seconds]
ExeciN has joined #glasgow
ali_as has joined #glasgow
pie_ has joined #glasgow
pie_ has quit [Ping timeout: 265 seconds]
Exec1N has joined #glasgow
Exec1N has quit [Quit: so long king Bowser]
Exec1N has joined #glasgow
Exec1N has quit [Quit: so long king Bowser]
Exec1N has joined #glasgow
Exec1N has quit [Quit: so long king Bowser]
Exec1N has joined #glasgow
carl0s has joined #glasgow
Exec1N has quit [Ping timeout: 246 seconds]
Exec1N has joined #glasgow
pie_ has joined #glasgow
electronic_eel_ has joined #glasgow
electronic_eel has quit [Ping timeout: 276 seconds]
electronic_eel_ has quit [Ping timeout: 240 seconds]
electronic_eel has joined #glasgow
ExeciN has quit [Ping timeout: 268 seconds]
carl0s has quit [Remote host closed the connection]
Exec1N has quit [Ping timeout: 240 seconds]
<
_whitenotifier>
[Glasgow-Archive] electroniceel opened pull request #1: Add G00042: PCA9534 Remote 8-Bit I2C and SMBus Low-Power I/O Expander… -
https://git.io/JeG5g
<
whitequark>
electronic_eel: why not have it as control-gpio-pca953x?
<
whitequark>
that reads better, too
<
whitequark>
because you might want to do other gpio things, like emulate a pca953x
<
whitequark>
or spy on pca953x transactions
<
whitequark>
which would be something like monitor-gpio-pca953x and so on
<
electronic_eel>
oh, are subgroups ok? I thought about that, but didn't see any anywhere else
<
electronic_eel>
but control-gpio-pca953x is fine with me
<
whitequark>
no problem with subgroup
<
whitequark>
sensor-mouse-ps2 is a thing
<
whitequark>
for gpio we might even do something like
<
whitequark>
have a control-gpio abstract applet
<
whitequark>
or a mixin or w/e, i might look at it
<
whitequark>
so that the interface is defined by it
<
whitequark>
and then only plug various modules into it
<
whitequark>
that actually do the talking
<
whitequark>
but for now your implementation is fine as it is, i think
<
electronic_eel>
yes, thought about that, but wanted to start somewhere...
<
whitequark>
nit: the naming is more like GPIOPCA953x
<
whitequark>
which is actually kind of awkward to type
<
whitequark>
so maybe we should change it to use underscores between globally or something
<
whitequark>
but its what we use now
<
electronic_eel>
yeah
<
electronic_eel>
ControlGPIOPCA953x?
<
whitequark>
nit: _read_reg(addr) rather than _read_raw(reg)
<
electronic_eel>
bah, can't type that without my editor providing autocorrection
<
whitequark>
nit: description should have capitalized sentences, see other applets for examples
<
whitequark>
commands should be more clear in their naming
<
whitequark>
i think something like...
<
electronic_eel>
do you prefer read/write or get/set?
<
whitequark>
get-state, set-state, get-dir, set-dir
<
whitequark>
mh, state isn't too good either, since it could refer to OE state as well
<
electronic_eel>
hmm, set-state?
<
electronic_eel>
set-output is better i thing
<
electronic_eel>
think
<
whitequark>
get-input, set-output, set-mode ?
<
whitequark>
`run control-gpio-pca953x get-input 1`
<
whitequark>
`run control-gpio-pca953x set-output 1 0`
<
whitequark>
`run control-gpio-pca953x set-state 1 input`
<
whitequark>
something like this
<
electronic_eel>
oh, you want bitwise read?
<
whitequark>
isn't that more convenient from cmdline?
<
electronic_eel>
I have just implemented port-wise
<
electronic_eel>
but the arg parser parses bitwise input too
<
whitequark>
we can have both
<
whitequark>
get-input-port and get-input-bit
<
electronic_eel>
yeah, both would be better
<
_whitenotifier>
[Glasgow-Archive] whitequark closed pull request #1: Add G00042: PCA9534 Remote 8-Bit I2C and SMBus Low-Power I/O Expander… -
https://git.io/JeG5g
<
_whitenotifier>
[GlasgowEmbedded/Glasgow-Archive] whitequark pushed 1 commit to master [+1/-0/±0]
https://git.io/JeG5y
<
_whitenotifier>
[GlasgowEmbedded/Glasgow-Archive] electroniceel b27bb55 - Add G00042: PCA9534 Remote 8-Bit I2C and SMBus Low-Power I/O Expander With Interrupt Output and Configuration Registers
<
whitequark>
btw you have one extra commit with benchmark latency, did i miss that one before?
<
electronic_eel>
no, I was just too lazy to open a separate pull for that
<
electronic_eel>
hope you don't mind
<
whitequark>
no problem
<
whitequark>
i don't care how fine grained pull requests are
<
whitequark>
even if you open one per typo its not much work to hit Rebase and merge
<
electronic_eel>
but I have to create a separate remote branch for each, so it is some more commands
<
electronic_eel>
so I prefer to group them a bit
<
whitequark>
oh i see
<
whitequark>
the reason i asked is that e.g. your pca9534 PR really ought to be squashed into one commit
<
whitequark>
but i ca't do that from the github UI
<
whitequark>
and it's a bit annoying to do for PRs from command line
<
electronic_eel>
I can do that if you prefer
<
whitequark>
yeah, that also works
<
electronic_eel>
btw, the io expander on the test jig works as planned
<
electronic_eel>
I think I'll write an applet for the current sensor next
<
whitequark>
also excellent
<
electronic_eel>
and then tackle the internal i2c access commands
<
electronic_eel>
I think I'll go to bed now and do the renaming and arg parsing improvements tomorrow
<
whitequark>
i'm so confused
ExeciN has joined #glasgow
ExeciN has quit [Quit: so long king Bowser]
ExeciN has joined #glasgow
ExeciN has quit [Client Quit]
ExeciN has joined #glasgow