<_whitenotifier>
[Glasgow] whitequark assigned issue #104: Indicate 10/12-bit ADC and DAC as functional equivalents to the 8-bit ones - https://git.io/fhjiK
<_whitenotifier>
[Glasgow] whitequark commented on issue #68: Expose on-board I2C for accessories - https://git.io/fhjiS
<_whitenotifier>
[Glasgow] whitequark commented on issue #68: Expose on-board I2C for accessories - https://git.io/fhji7
<whitequark>
gruetzkopf: poke
<whitequark>
would you consider pushing your FX2 FIFO changes?
<_whitenotifier>
[Glasgow] marcan commented on issue #68: Expose on-board I2C for accessories - https://git.io/fhjix
<_whitenotifier>
[Glasgow] whitequark commented on issue #68: Expose on-board I2C for accessories - https://git.io/fhjij
<_whitenotifier>
[Glasgow] marcan commented on issue #68: Expose on-board I2C for accessories - https://git.io/fhjPU
<_whitenotifier>
[Glasgow] whitequark commented on issue #68: Expose on-board I2C for accessories - https://git.io/fhjPk
<marcan>
whitequark: hypothetical idea for how this could physically look like, btw: *female* 2xN pin headers aligned next to the existing port headers (on a .1" grid), with I²C, 5V, GND, and 2 ID bits for what port this is (for address selection purposes)
<marcan>
alternatively different ports could have isolated buses if we stick a wide enough mux on there
<_whitenotifier>
[Glasgow] marcan commented on issue #68: Expose on-board I2C for accessories - https://git.io/fhjPL
<marcan>
(just brainstorming ideas)
<marcan>
female because that way there's a much lower chance of accidental shorts
<marcan>
I guess 3.3V on there makes sense too since I²C is 3.3V
<_whitenotifier>
[Glasgow] whitequark commented on issue #68: Expose on-board I2C for accessories - https://git.io/fhjPm
<whitequark>
marcan: each port should definitely have a dedicated bus
<whitequark>
address selection pins are a kludge
<marcan>
ack
<whitequark>
you could put an EEPROM there, sure, but what if you need DAC? ADC? IO expander?
<marcan>
right
<whitequark>
the problem is
<whitequark>
the current cases for revC will mean any such accessories will not physically fit in
<whitequark>
or I guess that's not necessarily a problem
<whitequark>
hrm
<whitequark>
maybe i'll give it another thought
<whitequark>
still unsure how good of an experience it'll be
<marcan>
actually for revC, I'd be worried the expansion wouldn't physically fit either, case or no case...
<marcan>
but then again if your expansion needs I²C then it needs I²C
<marcan>
I can see few use cases for "optional" I²C accessories
<whitequark>
i can see a very good use case
<whitequark>
automatic pinout determination
<marcan>
oh you mean just for an eeprom?
<whitequark>
yeah
<marcan>
steal some of the GND pins for I²C? :p
* marcan
hides
<whitequark>
i did think about it
<whitequark>
but no :P
<marcan>
actually I have a mild conundrum now regarding the glasgow pinout
<marcan>
I got some nice rainbow 20-pin ribbon cable
<marcan>
it's 2x10 repeated
<whitequark>
yeah
<marcan>
which means if I crimp it into an IDC as-is, the pinout will be stupid
<whitequark>
yep
<whitequark>
i mean, it's like IDE
<whitequark>
it does make some sense
<marcan>
yeah, so stupid :p
<marcan>
I mean yeah sure GND in between every IO
<whitequark>
hey, it's got good signal integrity
<marcan>
yeah yeah
<whitequark>
i think we really need super cheap adapter boards for common use cases like this
<whitequark>
another one is
<marcan>
anyway I'm trying to decide if I just roll with the stupid, or reorder the wires at the IDC, or what
<marcan>
since it's not like I'd ever use a ton of GNDs for discrete use cases
<marcan>
OTOH, I need 11 pins
<whitequark>
convert two revC ports into a single 20 IO port
<marcan>
and I have 10 colors
<whitequark>
er, 16
<whitequark>
i would personally make an adapter board to a less stupid layout
<whitequark>
and a smaller IDC
<whitequark>
i mean, i did that
<marcan>
sure, but in the meantime
<whitequark>
use grey cable :P
<marcan>
lol
<marcan>
I wonder if I should make cables with GND/IO/Vsense only, with female headers, for plugging into board headers (which will have their own power)
<marcan>
and cables with GND/IO/Vio only, with male headers, for plugging into breadboard and such
<marcan>
(to connect to ICs etc)
<marcan>
that adds up to 10 pins :p
<whitequark>
that's what i'm thinking about
<_whitenotifier>
[Glasgow] smunaut opened pull request #114: applet.program.ice40_sram: Rewrite to use the SPIMaster applet as base - https://git.io/fhjP4
<marcan>
P0/P5 orange, P1/6 green, P2/P7 purple, P3 white, P4 brown... okay that one is broken
<marcan>
and then black - gnd
<marcan>
so... almost not terrible
<marcan>
(and the rest of the colors all gnd/whatever)
<marcan>
meh
<_whitenotifier>
[Glasgow] smunaut synchronize pull request #114: applet.program.ice40_sram: Rewrite to use the SPIMaster applet as base - https://git.io/fhjP4
<tnt>
whitequark: heh, I already had a glasgow wired up to a up5k board, so I just had to plug a usb cable :)
<tnt>
There is a bit of a hack where I sent a 0x00 byte just to set SS low ...
<tnt>
whitequark: I need to add all the other arguments manually as well then ? sck-edge / bitrate / ... SPI app will not works without them set to something sensible.
<whitequark>
tnt: hmmm
<whitequark>
no, that's onerous
<whitequark>
tnt: see last commit
<_whitenotifier>
[GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fhjXG
<_whitenotifier>
[GlasgowEmbedded/Glasgow] whitequark 724208f - applet.interface.spi_master: let subclasses add their own pin arguments.
<whitequark>
aside: what's the best way to recognize someone's contributions to Glasgow? tnt's SB_GB_IO analysis has been positively critical to reliable function of the FIFO bridge, so I feel this ought to be noted somehow
<whitequark>
tnt: btw you know what's funny? I've implemented only a half of your solition
<whitequark>
tnt (or anyone else who feels like it): issue #113 is a good housekeeping issue to do
<whitequark>
i'll get to it myself eventually
<whitequark>
but i could use some help
<gruetzkopf>
fifo changes: yeah, need to clean them up, may be able to do it tonight
<whitequark>
sweet!
<_whitenotifier>
[Glasgow] smunaut synchronize pull request #114: applet.program.ice40_sram: Rewrite to use the SPIMaster applet as base - https://git.io/fhjP4
<_whitenotifier>
[Glasgow] whitequark commented on pull request #114: applet.program.ice40_sram: Rewrite to use the SPIMaster applet as base - https://git.io/fhjXS
<_whitenotifier>
[GlasgowEmbedded/Glasgow] whitequark pushed 2 commits to master [+0/-0/±2] https://git.io/fhjX9
<_whitenotifier>
[GlasgowEmbedded/Glasgow] smunaut 3af02d9 - applet.interface.spi_master: Set SS even on zero length transfers
<_whitenotifier>
[GlasgowEmbedded/Glasgow] smunaut 77d98ea - applet.program.ice40_sram: Rewrite to use the SPIMaster applet as base
<_whitenotifier>
[Glasgow] whitequark closed pull request #114: applet.program.ice40_sram: Rewrite to use the SPIMaster applet as base - https://git.io/fhjP4
<gruetzkopf>
might have a sensor applet based on SPIMaster soonish too
<gruetzkopf>
(for that maxim thermocouple converter)
<whitequark>
handy!
<gruetzkopf>
(14bit 0-1023.75°C)
plaes_ has joined #glasgow
<whitequark>
yeah i might grab my own
<whitequark>
i have some Needs on that front
<whitequark>
mostly related to weird PCB abuse
plaes has quit [*.net *.split]
<ZirconiumX>
Dad, after twenty years of not being employed: I'm going on a training workshop for welding
<ZirconiumX>
Dad, two days later: I got kicked off the course for pointing out lack of GDPT compliance.
<ZirconiumX>
...
<whitequark>
gdpt?
<ZirconiumX>
Thanks autocarrot
<ZirconiumX>
GDPR
<whitequark>
ah
<ZirconiumX>
I'm not sure how to feel about this.
<ZirconiumX>
On the one hand my dad is stubborn and prideful (he thinks his 70's Ph.D on fat objects is still relevant)
<ZirconiumX>
And he probably should have kept his head down
<ZirconiumX>
On the other hand, it *is* an important issue.
<tnt>
fat objects ?
<sorear>
like mac universal binaries?
<ZirconiumX>
Yeah
<ZirconiumX>
Which was used for the PowerPC -> Intel transition, and that's about it
<whitequark>
they still use them
<whitequark>
well, not anymore i think, no 32-bit macs
<ZirconiumX>
Well, I think the format still supports it
<whitequark>
you can build them, yeah
<ZirconiumX>
But Mac OS X was the only OS to use them in anger, I think
naus has joined #glasgow
<ZirconiumX>
Also my dad is proud of a program he wrote in Sculptor, using Jackson Structured Programming.
<ZirconiumX>
He even name-mangled the functions manually.
<sorear>
the 68k to ppc transition was substantially more cursed because you had 68k code in the resource fork and ppc code in the data fork
<ZirconiumX>
I mean, filesystem forks alone are pretty cursed
<ylamarre>
If he's been unemployed for 20 years, wouldn't his knowledge be higly relevant in avionics?
<ZirconiumX>
Hah
<sorear>
try as I might, I've never managed to *like* the Unix/Windows opaque array of bytes model
<hl>
how do you feel about IBM i?
<ZirconiumX>
I'm curious about m68k, I haven't got much experience with it.
<sorear>
dunno, haven't had a chance to play with one
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<gruetzkopf>
i don't have my own yet, but playing with IBMs contest system was fun
<gruetzkopf>
s/was/is/, account's still active
xqb16141 has quit [Quit: WeeChat 2.4]
xqb16141 has joined #glasgow
xqb16141 has quit [Client Quit]
naus has quit [Ping timeout: 256 seconds]
AxiomaticEspress has joined #glasgow
<sorear>
contest system?
AxiomaticEspress has quit [Quit: WeeChat 2.4]
AxiomaticEspress has joined #glasgow
AxiomaticEspress has quit [Client Quit]
AxiomaticEspress has joined #glasgow
<gruetzkopf>
"master the mainframe" contest
<gruetzkopf>
touches the absolute basics of mainframe ops
AxiomaticEspress has quit [Quit: WeeChat 2.4]
AxiomaticEspress has joined #glasgow
AxiomaticEspress has quit [Client Quit]
AxiomaticEspress has joined #glasgow
<sorear>
but i is for midrange systems
AxiomaticEspress has quit [Quit: WeeChat 2.4]
AxiomaticEspress has joined #glasgow
AxiomaticEspress has quit [Quit: WeeChat 2.4]
AxiomaticEspress has joined #glasgow
<gruetzkopf>
oh, bad connectivity reordered messages there
<gruetzkopf>
i *will* have two first-generation AS/400 soon
AxiomaticEspress has quit [Quit: WeeChat 2.4]
AxiomaticEspress has joined #glasgow
<tnt>
whitequark: wrt to your twitter diagram : You know you're being access because CS is low.
<whitequark>
tnt: but the data is not stable
<tnt>
And from there you have 60 ns to put valid data on D[7:0]
<whitequark>
see, the chip is not sampling the bus
<whitequark>
it is driving the bus
AxiomaticEspress has quit [Quit: WeeChat 2.4]
AxiomaticEspress has joined #glasgow
<tnt>
This is a 'CPU read diagram', so CPU is reading from an external chip.
<tnt>
When CS goes low, the Address is stable.
<whitequark>
yes, and this is the datasheet for the external chip
<whitequark>
which makes the bus (that it drives) stable precisely t_RDS before the rising edge of RD (that it samples)
<tnt>
Well I'd say t_RDS is a spec of the CPU, not of the chip.
<tnt>
I'd assume t_acc is the time until you get valid data on Data lines.
<whitequark>
except that's not what the diagram says
<tnt>
Definitely not clear but what I think they meant is that you need to make sure that t_rw > t_acc _ t_rds with t_rds taken from whatever CPU you try to interface with.
<tnt>
err t_acc + t_rds.
<whitequark>
that's not what the diagram says.
<whitequark>
which is my point.
<whitequark>
i know what they failed to communicate, yes.
<tnt>
what chip is that btw ?
<whitequark>
OPL4
<tnt>
One could argue that if you know what they mean, they didn't fail :p
<whitequark>
i know what they mean because i know that their documentation is batshit insane and shouldn't be trusted at all
<ZirconiumX>
whitequark: Is your end plan for the Yamaha FM chips to stick them all on a PCB and multiplex between them?
<whitequark>
no, it's to decap them all and convert to verilog
naus has joined #glasgow
<ZirconiumX>
So instead the Glasgow will become those chips?
<ZirconiumX>
I was going to say "emulate", but I'm not sure if that's strictly accurate of a reimplementation
<whitequark>
no, just run them in verilator
mehar has joined #glasgow
naus has quit [Ping timeout: 246 seconds]
naus has joined #glasgow
naus has quit [Client Quit]
<_whitenotifier>
[GlasgowEmbedded/Glasgow] whitequark pushed 2 commits to master [+0/-0/±2] https://git.io/fhjHX