<awygle>
whitequark: can you configure Glasgow so that every other pin is "ground" (driven low)?
<whitequark>
yes but I wouldn't have enough pins to drive this display then in that port
<awygle>
mk
<awygle>
Do you have any scope shots from before the breadboard?
<whitequark>
not at hand
<whitequark>
but I also didn't measure it all that well
<whitequark>
I don't have proper scope ground
<whitequark>
and I'm not even sure how I would go at it with a parallel bus
<awygle>
Mk. I have to cook and eat, then I'll dive into the front end on my end
<whitequark>
maybe I could grab an IDC cable and bite into it with a scope?
<whitequark>
I really don't know...
<whitequark>
btw I also found a very mysterious gateware bug, so that's probably also related
<awygle>
splitting and stripping the cable works OK yeah. I am gonna start by probing the bottoms of the pins
<awygle>
What's the nominal frequency of the bus?
<whitequark>
it's very... quaint
<whitequark>
it doesn't specify a frequency.
<whitequark>
it's an asynchronous edge-triggered bus that only specifies setup/hold timings
<whitequark>
one of the datasheets I have lists E pulse width as 140 ns and E cycle duration as 1200 ns
<awygle>
.... Geh.
<awygle>
Lol
<whitequark>
so it's "less than 1 MHz"
<whitequark>
I can only run it at "less than 1 kHz" so far
<awygle>
But noise immunity is garbage sounds like
<whitequark>
exactly
<whitequark>
the thing though is this is squarely within glasgow's domain
<whitequark>
it'd suck if I can't even interface hd44780...
<awygle>
mhm
<whitequark>
something that any old mcu can do
<whitequark>
even a literal 8051
<whitequark>
which this is developed for.
lrvick has joined ##openfpga
<tinyfpga>
Hello
<lrvick>
Ohai
<awygle>
hi tinyfpga
<lrvick>
At tinyfpga booth. Was told this is a thing
<awygle>
woo, pr
<tinyfpga>
:)
* rqou
brings in the bad PR with shitposting :P
<rqou>
but seriously, hi lrvick
<awygle>
yeah, welcome lrvick
<awygle>
what brings you to our ~lair~ channel?
<whitequark>
oh
<whitequark>
oh for fuck's sake
<whitequark>
aaaargh
<awygle>
whitequark: I'd have to check the schematic to be sure but if it's possible it might be a decent idea to pop one shifter off of a port to do differential debug (is it the shifter or not)
<rqou>
inb4 "i told you magic level shifters are sketchy"
<whitequark>
rqou: it's not clear to me so far exactly what the failure is
<whitequark>
it could equally be "i can't read or design shit"
<rqou>
lol that's just me every day :P
<whitequark>
e.g. i have never even considered signal integrity when doing that part of schematic
<whitequark>
it is absolutely unsurprising that signal integrity is shit
<whitequark>
awygle: found the bug
* awygle
is somewhat surprised
<awygle>
oh?
<whitequark>
i thought i'd be "efficient" and declare only the bits of command latch that i use
<whitequark>
but then i added more commands
<whitequark>
because of the way the bus works in nibble mode it EXTREMELY SORT OF worked
<whitequark>
this really drives in the fact that i need to add simulation to applets ASAP
<whitequark>
debugging this with a scope is a) dumb b) nightmare
<whitequark>
awygle: surprised that it's shit?
<awygle>
whitequark: surprised that it's as shit as it seems to be
<whitequark>
with 35 mA current sources inside fxma?
<whitequark>
oh, i think a large part of it is my fuckup above
<whitequark>
let me redo every test again lol
<awygle>
lol K. I'm gonna do dinner, I'll be back in ~2h
<rqou>
wtf dinner so early?
<qu1j0t3>
dumb electronics question: If I'm using a transceiver IC with switchable direction, connected _directly_ to arduino GPIO, do I need to be concerned about possible overcurrent when I switch direction on the transceiver from input to output almost immediately before changing Arduino pin direction to input? Should I set all Arduino inputs to high-Z before changing transceiver direction as a safety measure? I
<qu1j0t3>
haven't done this sort of thing before.
<qu1j0t3>
(by which i mean, use a directly connected transceiver.)
<rqou>
yes, there can be issues
<qu1j0t3>
is the high-Z dance a good fix?
<rqou>
usually the higher-level protocols define some kind of "turn-around" cycle for this situation
<rqou>
yeah, i would set the arduino pin to high-Z/input first
<rqou>
and then toggle the transceiver directly
<rqou>
*direction
<qu1j0t3>
well, luckily the direciton change always occurs outside the bus handshake
<qu1j0t3>
(it's gpib)
<rqou>
oh goddammit
<rqou>
good luck
<qu1j0t3>
:)
<whitequark>
awygle: amazing
<whitequark>
so this chip has a fully asynchronous bus
<whitequark>
by this I mean that if you start a transaction reading the status register, it will literally just drive the register onto the bus
<whitequark>
that is, once the busy flag goes down, it goes down. period.
<whitequark>
doesn't matter that you thought, and the datasheet claimed, that data has any phase relationship to enable whatsoever
cr1901_modern has joined ##openfpga
MrSynAckster has quit []
pie__ has quit [Quit: Leaving]
pie_ has joined ##openfpga
GenTooMan has quit [Quit: Leaving]
<awygle>
whitequark: i'm getting a command timeout when trying to run fx2tool
<awygle>
i suspect i'm supposed to be installing the bootloader? but i can't figure out how to do that
Bike has quit [Quit: Lost terminal]
<awygle>
whoop fixed it i think
Ultrasauce has quit [Ping timeout: 264 seconds]
Ultrasauce has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
<awygle>
whitequark: so my current status is that I got Glasgow running the io toggle test and took some scope measurements. I'm seeing about 250mV over/under shoot at the connector and 1V at the end of an 8cm ish wire (unloaded). tomorrow I'm going to try some terminations and see what results I get. edge rate is 2.5ns which is pretty fast.
<awygle>
also, it seems fx2tool didn't like 1.1 mode (my vm was set up wrong). just fyi
rohitksingh has joined ##openfpga
rohitksingh has quit [Ping timeout: 264 seconds]
rohitksingh has joined ##openfpga
rohitksingh has quit [Ping timeout: 240 seconds]
bitd has joined ##openfpga
<eduardo__>
awygle: open source tool are very often terrible in the beginning, but they are a starting poing and get better ove time, even if they have to be rewritten in the process several times. What travels though time is the expertise of the evolving community developing it with a much higher innovation speed than any closed source company could do.
m_t has joined ##openfpga
user10032 has joined ##openfpga
Bike has joined ##openfpga
m_t has quit [Quit: Leaving]
eduardo_ has joined ##openfpga
eduardo__ has quit [Ping timeout: 260 seconds]
bitd has quit [Ping timeout: 240 seconds]
bitd has joined ##openfpga
pie_ has quit [Ping timeout: 240 seconds]
cr1901_modern has quit [Ping timeout: 248 seconds]
cr1901_modern has joined ##openfpga
<whitequark>
awygle: fx2tool -B command
<whitequark>
awygle: eduardo_: 1.1 will never be supported, FX2 is 2.0 only
<whitequark>
although it *does* do full speed
<awygle>
whitequark: ah I see
X-Scale has quit [Ping timeout: 260 seconds]
pie_ has joined ##openfpga
<whitequark>
I'm not actually sure when is 2.0 full speed even possible
<whitequark>
maybe if you have a rate matching hub?
<whitequark>
and it only does 1.?
<whitequark>
awygle: I conclusively confirmed this problem as a signal integrity issue.
<whitequark>
I ran the E pin of the display using a wire completely separare from the other ribbon cable and it works 100% reliably now
<whitequark>
I also staggered the breadboard pins with a spacing of 1 row
<whitequark>
not sure if that did anything, really
X-Scale has joined ##openfpga
<whitequark>
awygle: yep
<whitequark>
with this fix to E wire it works with the most aggressive timings from the datasheet
<gruetzkopf>
usb version is faily independent of speed
<whitequark>
gruetzkopf: yeah but are there really any 2.0 controllers that don't do high speed?
<gruetzkopf>
yes!
<gruetzkopf>
i've only ever seen one, but definitly (digging for part number)
<gruetzkopf>
TI OMAP 35xx family SoC at least
<whitequark>
LOL
<whitequark>
I had no idea
<balrog>
whitequark: what would it take to support 1.1 FS as opposed to 2.0?
<gruetzkopf>
putting 11 into the descriptor version field. which you shouldn't ever need to do
<gruetzkopf>
not even win95 won't work with usb 2.0 low/full speed devices
<whitequark>
yeah, I think this is actually possible with FX2
<whitequark>
since it gives you an HSGRANT interrupt
rohitksingh has joined ##openfpga
_whitelogger has joined ##openfpga
zkms has joined ##openfpga
SpaceCoaster has quit [Ping timeout: 260 seconds]
SpaceCoaster has joined ##openfpga
<reportingsjr>
whitequark: what does the rise time of your signals look like?
<whitequark>
reportingsjr: 3.5ns
<reportingsjr>
:O
<reportingsjr>
that is fast for this type of setup
<awygle>
yeah it's speedy
<reportingsjr>
Are those chip IOs nice enough to be able to slow down the edges in the firmware?
<awygle>
nnnnope. level shifter doesn't have firmware.
<reportingsjr>
ahhh
<daveshah>
Even the ice40 doesn't have slew rate control anyway
anuejn has joined ##openfpga
m_t has quit [*.net *.split]
hl has quit [*.net *.split]
bitd has quit [*.net *.split]
kmehall has quit [*.net *.split]
kuldeep has quit [*.net *.split]
sielicki has quit [*.net *.split]
xdeller has quit [*.net *.split]
FabM has quit [*.net *.split]
eightdot has quit [*.net *.split]
hackkitten has quit [*.net *.split]
<reportingsjr>
I suppose this is why you were both talking about adding termination resisttors.
eightdot has joined ##openfpga
kmehall has joined ##openfpga
kuldeep has joined ##openfpga
xdeller has joined ##openfpga
hackkitten has joined ##openfpga
bitd has joined ##openfpga
FabM has joined ##openfpga
<awygle>
yup
sielicki has joined ##openfpga
hl has joined ##openfpga
m_t has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
rohitksingh has joined ##openfpga
<pie_>
hey
<pie_>
hey guys
<pie_>
why have riscv when you can have webassembly :_
<pie_>
* ;)
<qu1j0t3>
y u trol
<pie_>
^trolling
<pie_>
otoh, only slightly trolling: azonenberg make wasm antikernel
<pie_>
"haha only serious:
<sorear>
wasm missed a great opportunity to be an actually reasonable machine language
<awygle>
riscv-w
<pie_>
sorear, :c
noobineer has joined ##openfpga
rohitksingh has quit [Ping timeout: 245 seconds]
user10032 has quit [Quit: Leaving]
<reportingsjr>
riscw
<zkms>
riscuwu
<reportingsjr>
riscy
<rqou>
aarch64 :P
* rqou
is shot
<jn__>
risc-ytho
<pie_>
zkms doin it right
<pie_>
jn__, lmao
<jn__>
i wonder when the new RISC-V workshop videos are going to be published
<jn__>
and how the quality is going to be…
<rqou>
offtopic: clickspring is such an amazing machinist
<gruetzkopf>
import more c3voc
<rqou>
oh wtf HTME is doing this weird "TV" thing :P
<rqou>
somebody really needs to find the HTME guy some ChemEs and MechEs to collaborate with :P
<rqou>
i mean, there was also that low-end siemens thing that scanlime was trying to hack
<gruetzkopf>
they're also doing wild stuff to ethernet frames (and pbysical layer) with their ethercat protocol, but that's fairly well-documented and actually useful
<rqou>
yeah
<rqou>
synchronous ethernet + 1588 together can be really cool too
<rqou>
"it works in BRCM's lab" :P
<gruetzkopf>
CERN has a synchronous ethernet protocol
<gruetzkopf>
ethercat needs no special support in the timing master, the slaves are a bit interesting (swapping bits in the frame while passing it onwards)
<zkms>
interesting
<zkms>
i havent heard of ethercat
<rqou>
i have, it's pretty neat
<zkms>
i've read about the ethernet stuff they want to use instead of CPRI; it's hella neat
<gruetzkopf>
i do have quite a bit in operation
<gruetzkopf>
the EtherCATp stuff is a bit scary (pushing two 24V supplies over the same two pairs as ethernet TX/RX)
<whitequark>
isn't that just PoE?
<whitequark>
actually PoE goes up to 48V
<q3k>
there's many PoE standards and pseudostandards
<q3k>
with different voltages and ways of transporting power (from additional wires on 100Base to phantom voltage on 1GbE)
<q3k>
and until recently many cheapo vendors would roll their own PoE standard instead of something from 802.3 (*ahem* mikrotik *ahem*)
<pie_>
<gruetzkopf> import more c3voc
<gruetzkopf>
poe is phantom power using magnetics center taps
<gruetzkopf>
ethercatp provices two t-bias feeds
m_t has quit [Quit: Leaving]
lexano has quit [Ping timeout: 248 seconds]
<rqou>
thinking of crashing the post-maker-faire #bringahack afterparty
<rqou>
supposedly a "wonderful tradition that @jeriellsworth started"
noobineer has quit [Ping timeout: 256 seconds]
<rqou>
anyone know if it'd be worth it?
<pie_>
you're asking us?
<rqou>
some people here are in the bay too
<rqou>
pie_ you need to get the hell out of HU :P
<qu1j0t3>
LOL
<qu1j0t3>
and maybe not into the fire, though
qu1j0t3 has quit [Quit: WeeChat 0.4.3]
qu1j0t3 has joined ##openfpga
bitd has quit [Quit: Leaving]
<gruetzkopf>
pie_ moving out of hungary would lead to CCCAC losing it's hungarian outpost :(
<pie_>
hahaha
<pie_>
hm.
<pie_>
i was going to say the budapest group recently became a chaostreff, but that isnt really cccac's hungarian outpost is it? ;P
<pie_>
hehe
<pie_>
much good a hungarian outpost gets you, especially that its not in budapest xD
<gruetzkopf>
the berlin outpost, Chaos Computer Club Aachen, Aussenstelle Berlin at least has a great acronym
<gruetzkopf>
CCCACAB :P
<rqou>
wait what
<rqou>
why is everything under CCC Aachen?
<whitequark>
outpost?
<rqou>
can i make a CCCAC sf bay outpost? :P :P
<gruetzkopf>
pie_ visited us, the other outposts are members who moved away :D