* sorear
has a random diagram from wikimedia commons because people get mad at you if you don’t have an avatar
<marcan>
whitequark: what.
<sorear>
“eggs”, “digits accounts”, …
<marcan>
whitequark: you can tell it's not me because of the extra JPEG artifacts in the full-size view >_>
<whitequark>
lol
<marcan>
I sent him a tweet, we'll see :p
<marcan>
if they don't reply... I wonder if you can DMCA profile icons on twitter >_>
ma1 has quit [Read error: Connection reset by peer]
<gruetzkopf>
heh, i kept the egg my twitter account was delivered with (i have since learned of alternate interpretations for that word, but i don't care)
<marcan>
oh he just changed it
<marcan>
cool
<marcan>
apparently he didn't even notice my nickname on it? *facepalm*
<electronic_eel>
marcan: whitequark suggested renaming it to control-gpio-pca953x, is that what you agree with or do you prefer gpio-pca953x?
<electronic_eel>
marcan: see irc log
<whitequark>
fwiw i don't have a super strong opinion on that naming
<whitequark>
i feel that just "gpio" might be too generic to be useful. but maybe our other taxons are also too generic to be useful.
<electronic_eel>
I like control-gpio-pca953x and would go with that
_whitelogger has joined #glasgow
ExeciN has joined #glasgow
ExeciN has quit [Quit: so long king Bowser]
ExeciN has joined #glasgow
<uovo>
egg?
<marcan>
electronic_eel: yeah that's fine too
<marcan>
no strong opinion here
<marcan>
all I meant was that a general "gpio" thing is useful
<marcan>
putting it under "control" works fine, though mentally I tend to think of it the other way around (gpio-control-pca953x) but I'll go with whatever whitequark says on this
<whitequark>
i say let's go for gpio-control-* and if it turns out to be a mistake we just fix it.
<whitequark>
er
<whitequark>
control-gpio-*
* whitequark
is not awake
<gruetzkopf>
sleep optional - grue uptime 34h
<whitequark>
that was yesterday
ExeciN has quit [Quit: so long king Bowser]
ExeciN has joined #glasgow
ExeciN has quit [Client Quit]
ExeciN has joined #glasgow
ExeciN has quit [Client Quit]
ExeciN has joined #glasgow
ExeciN has quit [Client Quit]
ExeciN has joined #glasgow
ali_as has quit [Remote host closed the connection]
ali_as has joined #glasgow
ExeciN has quit [Quit: so long king Bowser]
ExeciN has joined #glasgow
ExeciN has quit [Client Quit]
ExeciN has joined #glasgow
ExeciN has quit [Client Quit]
pie_ has quit [Ping timeout: 265 seconds]
carl0s has joined #glasgow
pie_ has joined #glasgow
pie_ has quit [Ping timeout: 240 seconds]
<_whitenotifier>
[GlasgowEmbedded/Glasgow] whitequark pushed 2 commits to master [+0/-0/±2] https://git.io/JeZc7
<_whitenotifier>
[GlasgowEmbedded/Glasgow] whitequark 2813263 - device.hardware: start USB poller thread only after enumeration.
<_whitenotifier>
[GlasgowEmbedded/Glasgow] electroniceel 2190ecf - applet.internal.benchmark: also show worst case latency
<whitequark>
electronic_eel: cherry-picked your latency patch into master. i like it a lot, thanks
<whitequark>
oh wait, that just adds worst case latency, i forgot that i already merged the latency *mode* before
<whitequark>
ok i still like it a lot :)
pie_ has joined #glasgow
carl0s has quit [Remote host closed the connection]
<electronic_eel>
they separate into port, just not A and B, but 0 and 1
<whitequark>
it uses two bytes per address to fill a 16-bit shift register
<electronic_eel>
see the "P" numbering
<whitequark>
so what kind of ports would a GPIO-over-JTAG applet have?
<electronic_eel>
P00-P07 and P10-P17
<whitequark>
i'm thinking something like get-input-word would be more universal than get-input-port
<electronic_eel>
hmm, doesn't that depend very much on the jtag target you have connected?
<whitequark>
nope
<whitequark>
you can do it over BSCAN
<whitequark>
what i'm thinking is
<whitequark>
there are two useful ways of thinking about GPIOs
<whitequark>
you could either work with an entire word that consists of states of every pin
<whitequark>
like the BSCAN register, or the full PCA9535 shift register
<whitequark>
or, you could rather work with individual pins
<whitequark>
so it makes sense to have `get-input-word` that returns the entire word, and, to have `get-input-pin` that uses the datasheet numbering like P00 and P17
<whitequark>
(there should be a map to registers)
<whitequark>
thoughts?
<electronic_eel>
hmm, words
<electronic_eel>
how would you map the glasgow ports?
<electronic_eel>
would they be one word?
<whitequark>
you mean a GPIO applet whose GPIOs are just individual Glasgow pins?
<electronic_eel>
yes
<whitequark>
the utility of that seems marginal
<whitequark>
but if you were to make such an applet, it would take a --pins-gpio argument that would be something like --pins-gpio 0:15
<whitequark>
just like any other applet (see --pins-jtag for example)
<whitequark>
that makes up a word.
<whitequark>
of course you could use an arbitrary sequence of pins instead. like --pins-gpio 0,8,1,9,2,10,...
<whitequark>
then your word would be permuted wrt actual pins. that is also perfectly fine.
<electronic_eel>
I don't really get the importance of using words instead of 8 bit ports
<electronic_eel>
the io expanders use 8 bit ports, glasgow itself also
<whitequark>
i don't understand why the artificial split into 8 bit chunks is useful or fundamental
<whitequark>
if we're adding an entire group of GPIO applets they should have an uniform interface
<electronic_eel>
yes, the interface should be well designed. that's why we are having this discussion
<whitequark>
btw the reason glasgow uses 8 wire ports is more of a coincidence, that's the largest FXMA device i could find
<whitequark>
and i think i also wanted to stay compatible with bus pirate or something like that
<whitequark>
no, not bus pirate. ARM JTAG?
<whitequark>
yep, ARM JTAG
<electronic_eel>
the io extenders I've seen all use 8 bit ports, glasgow too, it is very common
<electronic_eel>
when the devices we mostly talk to use the 8 bit port scheme, wouldn't it be easier, for the users and code, to stick to that?
<whitequark>
but is it easier?
<whitequark>
what happens when you need to bitbang something that's connected to P07 and P10?
<whitequark>
(presuming you want to do it via the port-/word-wide commands)
<whitequark>
(actually, if I understand your proposal correctly, if you want to do it via bit-wise commands too)
<electronic_eel>
I want to add bit-wise commands, and you'd use the same port numbering there
<electronic_eel>
but your idea of adding a map which maps the datasheet names like "P10" to a bit&port numbering would is also good
<whitequark>
note that the glasgow *interface* does not expose the fact that ports are 8-bit to the applets in any way whatsoever
<whitequark>
you actually cannot request an entire port for your applet
<whitequark>
the way it works is that the user specifies --port A, or --port AB, or --port BA, and the ports are glued together accordingly into one long virtual port
<whitequark>
after that, --pin-x arguments choose the wires from this virtual port that actually are conected to the applet
<whitequark>
this is done so that the structure of the arguments stays the same even if you connect an I2C device to A7+B0 for whatever reason
<whitequark>
(maybe it was more convenient to crimp a cable that way)
<electronic_eel>
yeah, makes sense
<electronic_eel>
my gpio applet currently only supports 8 bit devices, so no different ports.
<_whitenotifier>
[Glasgow] emilazy opened issue #160: selftest uses outdated LED resource name - https://git.io/JeZWS
<_whitenotifier>
[Glasgow] whitequark commented on issue #160: selftest uses outdated LED resource name - https://git.io/JeZWH
<electronic_eel>
whitequark: in your word proposal - would the word width always be 16 bits or depend on the device you are talking to?
<electronic_eel>
there are 24 bit i2c io extenders in the pca9xxx line
<electronic_eel>
so if we go the 16 bit word route, you get the same P07 and P10 problem you noted with P17 and P20
<whitequark>
depend on the device definitely
<whitequark>
by "word" I mean "a series of bits with arbitrary width"
<whitequark>
arbitrary device-specific
<whitequark>
as opposed to "byte" which is width 8
<electronic_eel>
ok, unless someone comes up with a device with 10 io ports and it becomes cumbersome to enter it in anything but binary
<electronic_eel>
but I haven't seen such a io extender yet
<whitequark>
i think by that point you should use `glasgow run-repl` instead
<electronic_eel>
so the word solution would basically mean that all the pins of the devices are in a linear space
<whitequark>
yep
<whitequark>
just like the logical applet-side view of glasgow itself
<_whitenotifier>
[GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/JeZWp
<_whitenotifier>
[GlasgowEmbedded/Glasgow] whitequark b28a6d7 - applet.internal.selftest: adapt after changes in eb600097.
<_whitenotifier>
[Glasgow] whitequark closed issue #160: selftest uses outdated LED resource name - https://git.io/JeZWS
<electronic_eel>
so some example commands for a 16 bit io extenders would be: