<eddyb>
so LPC on Glasgow wouldn't just be useful, but potentially dead easy
<whitequark>
in laptops you often have LPC on spare pins of minipcie
<whitequark>
it's really the hardware side that is nontrivial
<whitequark>
as LPC stretches the capabilities of glasgow's FPGA
<whitequark>
i know it can be done, but doing it nicely requires serious effort
<electronic_eel>
oh, what is the difficulty with LPC? it's been a long time since i looked at the protocol
<eddyb>
I think I stopped doing iCE40 things around the time I came up with a pipelining abstraction top of nmigen and failed to implement it (in the sense that I would stare at the empty file and write nothing, having designed the whole thing and looked up all the Python features I would need,,)
<whitequark>
electronic_eel: it's fast (33 MHz) so you can't fake it by adding 2FFs everywhere
<whitequark>
you have to have an island of logic clocked by the LPC bus itself
<whitequark>
and with migen, there was no way to async reset it
<whitequark>
which meant that if you connected a FIFO to LPC clock it would get fucked every time you reset it with LPC clock turned off
pinoaffe has quit [Quit: killed]
<electronic_eel>
ok, the first protocol to be implemented with 2 full proper async clock domains
<whitequark>
yes. I even implemented a part of it
<whitequark>
never got it to work bc the only board where I had exposed LPC also is, for various reasons, something I have to turn off while developing
<whitequark>
so it just completely broke glasgow's workflow that *requires* FIFO reset for basic functionality
<whitequark>
also, on Up5k, meeting even 33 MHz timing is challenging
<whitequark>
... probably less so now that i don't have to use arachne, but still
<electronic_eel>
the pins are bidirectional, aren't they? so the auto dir sense shifters on the first glasgow revs wouldn't have helped too
pinoaffe has joined #glasgow
<whitequark>
I was going for R/O
<whitequark>
... actually no I wasn't
<whitequark>
yeah you are right
<electronic_eel>
it probably sends an address and you have to answer
<whitequark>
I think for port 80 type things you can listen only
<whitequark>
but I actually was trying to emulate an LPC flash...
<electronic_eel>
gruetzkopf: do you have transputer cards in your old telco gear?
<gruetzkopf>
yuuup
<d1b2>
<promach> Can glasgow be used as USB2.0 protocol analyzer ?
<whitequark>
nope
<electronic_eel>
promach: for high speed (480MBit) it is not fast enough
<gruetzkopf>
AVM (today of fritzbox fame) sold millions of active ISDN cards with transputers (B1 family)
<whitequark>
not for high speed
<whitequark>
huh, i had no idea transputers were actually, well, used
<electronic_eel>
gruetzkopf: ah, i had a B1 at work one time, but that was a long time ago. switched to eicon cards, because they had better kernel drivers
<gruetzkopf>
they discontiuned that product line in 2015(!) - last rev used a STM ST20 cpu (pretty clear transputer derivative)
<electronic_eel>
didn't take a look at the exact design of the B1
<whitequark>
for some reason i had this idea that transputers were an academic novelty, which is clearly not the cae
<whitequark>
*case
<electronic_eel>
the B1/c2/c4 series was sold for a long time and used as fax cards for tobit david
<gruetzkopf>
many B1 were OEM'ed by Datev who are in the tax calculation software business (and nearly every german company eventually has to deal with them
<gruetzkopf>
i have two B1 PCMCIA in a laptop
<d1b2>
<promach> Why no ?
<electronic_eel>
wasn't that more the case for the fritz cards? they were used like a dongle for the datev software
<gruetzkopf>
all B1 rev2 i have are DATEV branded
<gruetzkopf>
(ISA, SMT instead of THT)
<electronic_eel>
ah, so maybe they offered both variants for this dongle thing
<gruetzkopf>
using a B1 with period appropriate software for fax offloading is fun
<gruetzkopf>
the early B1 cards were even intended to work with uncooperative software that only talks AT over serial port - they have a DE9F with a DCE-wired RS232 on them
<electronic_eel>
neat, so they could double as an internal isdn modem
<d1b2>
<Attie> @promach signal speed is a big one... and you'd probably need a PHY even if the glasgow could keep up
<electronic_eel>
eddyb: asus mostly uses nuvoton superios for some years now
<whitequark>
yes you would definitely need an external PHY
<whitequark>
more importantly, glasgow has almost no memory on it
<whitequark>
and trying to squeeze HS USB into, well, HS USB...
<d1b2>
<OmniTechnoMancer> Future Glasgow with ECP5 would be better suited to USB HS?
<whitequark>
yup
<d1b2>
<promach> ok
<d1b2>
<Attie> yeah, i was just taking a second to refresh myself... memory / bandwidth were going to be the next reasons I gave
<gruetzkopf>
(that serialport is _extremely_ useful once you start uploading your own code - the B1 behaves like a normal inmos B008 dev board with that 16C650 and the ISDN chip attached)
<eddyb>
is that a typo on DGH1#? I feel like it should be port 0x81h, like DGL1#
<electronic_eel>
could be. these nuvoton datasheets are really crap. you need hours to wrap your head around how it works before you get even the most basic transfer done
<electronic_eel>
at least that is what it took me the first time i tried it
<eddyb>
this looks like something I could confirm with just a multimeter in continuity mode and some patience
<eddyb>
(which pins map to the POST code display, I mean)
<electronic_eel>
and the intel chipsets that go a long way to hide the lpc from the user by wrapping it in 3 layers of abstraction also don't really help
<whitequark>
which ones do you mean here?
<electronic_eel>
eddyb: i think checking which pins connect to your 7seg is better done with the multimeter than by trying to read out the superio registers
<eddyb>
what registers? the screenshot is of the pin mapping
<electronic_eel>
ah, you are right, these are pin nos and not registers
<eddyb>
> The NCT6796D provides UART interface to transfer PORT80 information to other peripheral devices. Default baud rate is 115200Hz for universal UART protocol and it could be change by LD14 CRE2 and LD14 CRE3.
<eddyb>
lol, is this one of those on-by-default things? that would be nice and easy :P
<eddyb>
it... is on by default. hwat
<whitequark>
i mean
<whitequark>
a POST interface that you have to turn on is not very good
<eddyb>
whitequark: okay I can see that. one fun thing I haven't mentioned here yet is this board is one of those that starts w/o a CPU in the socket (like, power goes to fan headers), and the POST code shows 00
<eddyb>
so presumably that's the same state it's in before the CPU takes over
<eddyb>
aww, there's strapping pins as well. so it might still be disabled that way (especially if they need the pin for something else)
<eddyb>
welp I'm tired, just realized I had open an X79 datasheet instead of the Z97 one,
<gruetzkopf>
304%..
<d1b2>
<esden> 460+ glasgows
<sorear>
at what point does this become a major mfg problem
<d1b2>
<uep> that's a lot of soldering
<d1b2>
<esden> sorear: humm... we will do it in batches, so in the worst case the timeline will have to be stretched to reflect later batches.
<d1b2>
<esden> At the moment we have first 200 batch (earlybird) planned and prepared for a second 500-1000 batch.
<d1b2>
<esden> The units after that will have to be scheduled for later.
<sorear>
hmm, I would be a little surprised if this goes over 1000
<d1b2>
<esden> (in the first year I sold more iCEBreakers... and the campaign definitely did not start as quickly as this one)
<d1b2>
<esden> (so we have to be ready just in case)
<d1b2>
<Attie> we're already (after 7h) at ~456 backers, and the average for glasgows-per-backer is going to be >= 1... so I wouldn't think 1000 is unreasonable, from a getting prepared point of view
<d1b2>
<Attie> everything calmed down since the initial storm, so the next 500 might take a while longer!
<d1b2>
<icb> The campaign still has 41 days on it. That's a lot of time to pick up more orders. Not everyone who was planning on buying one immediately has even seen that the campaign has gone live yet, between timezones and this being a holiday week for many people.
<d1b2>
<Attie> yeah, exactly
<d1b2>
<esden> The curve is usually a spike at the beginning, a slow drip throughout the campaign time with some small spikes when there is news, and then another large spike at the very end.
<d1b2>
<esden> I already heard from people that want "work authorization" to place a pre order, and have to wait till January with that.
<sorear>
what does the graph of "utility" versus "number of IOs" look like
<whitequark>
you mostly need many IOs when working with old parallel interfaces
<whitequark>
for some of those we have a workaround
<sorear>
I'm wondering for how many things 16->32 is actually useful
<d1b2>
<uep> i suspect it's "very rarely, but when you need it, you need it"
<d1b2>
<uep> and yeah, parallel bus would be the reason
<sorear>
has anyone used the SYNC function in anger yet
<d1b2>
<uep> or some horrendously complex multi-state input debugging
<d1b2>
<TiltMeSenpai> what does SYNC even do
<whitequark>
it doesn't really do anything yet
<d1b2>
<TiltMeSenpai> gateware-dependent?
<d1b2>
<uep> guessing based on logic analysers: a trigger signal to start / mark capture at a time of interest?
<whitequark>
yeah that was the idea
<d1b2>
<TiltMeSenpai> ah, ok
<sorear>
part of the idea IIRC was that it would be used to connect glasgows together
<d1b2>
<xabean> now that I'm actually expecting to get my hands on a glasgow
<d1b2>
<xabean> (and reading PDF schematics)
<d1b2>
<xabean> whitequark is the LVDS connector essentially solely for future-intended add-on cards? It looks like it is entirely separate from the headers for the fly wires
<d1b2>
<OmniTechnoMancer> AFAIK it is just extra FPGA IOs?
<d1b2>
<OmniTechnoMancer> Which happen to also be pairs usable for differential signalling
<d1b2>
<Attie> I don't think there is any support for it yet, and I'm fairly certain no applets use it yet either... so yes - it's for future/unknown addons
<d1b2>
<esden> It was essentially: "we have a bunch of spare io, it would be a waste not to bring them out to a connector"
<d1b2>
<Attie> (and it is indeed separate from port A / B)
<d1b2>
<xabean> yeah, from what I can see in github issues, "this needs a bunch of passives which have to be on an add-on card"
<d1b2>
<Attie> are you thinking of anything in particular for them?
<d1b2>
<icb> It looks like it's basically "Here's bank 3 directly off the FPGA, with a bunch of guard grounds, VCCIO, 3.3v, and zero input protection circuitry. Do what you want with it, but don't expect it to be there in the same form after revC"
<d1b2>
<xabean> @Attie none, just curiosity.
<d1b2>
<Attie> ok!
<d1b2>
<esden> Just to make it clear. You can think of revC more of a model number. So revC will keep existing in this form, even when revD and revE come on the scene in the future.
<d1b2>
<esden> Just so there is bit less confusion.
<d1b2>
<xabean> I have no idea how/what I will use a glasgow for, I barely use my busblaster (and when I did it was only for jtag)
<d1b2>
<xabean> low level HW hacking/snooping is something immensely interesting to me, and I really like how glasgow is literally a utility knife for debugging/exploring
<d1b2>
<esden> So revC, revD and revE will be produced in parallel and address different levels of requirements and price points. (I hope it helps to understand it a bit better. 😄 )
<d1b2>
<TiltMeSenpai> is revD the planned ecp5 variant?
<d1b2>
<xabean> but much <3 for all the work everyone has put into this! thank you!
<d1b2>
<esden> @TiltMeSenpai revE is, revD will be a higher bank count ice40 version.
<d1b2>
<TiltMeSenpai> ah, I see
<d1b2>
<TiltMeSenpai> how does revE plans compare to the bitmagic pro
<d1b2>
<TiltMeSenpai> or will they be the same
<d1b2>
<esden> @xabean yeah, the number is the actual revision number here 😄
<d1b2>
<xabean> @esden it's like revC is a hardware variant, rather than a revision, heh
<sorear>
500
<d1b2>
<esden> @TiltMeSenpai bitmagic will be focused on logic analyzer needs and data acquisition, if then only very limited data generation. Specifically focused on sigrok needs.
<d1b2>
<esden> sorear: we need a horn sound when we break those round numbers 😄
<d1b2>
<Attie> iirc revE is likely to have Gigabit Ethernet, ECP5, possibly USB3, etc... generally "bigger and better", but I'm not sure it's written down anywhere
<d1b2>
<TiltMeSenpai> fun. I'm just trying to track all the money you all are eventually going to take from me 😛
<d1b2>
<Attie> :)
<d1b2>
<TiltMeSenpai> though I might skip revE for designing some gateware on the ecpix I just got
<d1b2>
<TiltMeSenpai> or revD, sorry
electronic_eel has quit [Ping timeout: 240 seconds]
electronic_eel has joined #glasgow
<d1b2>
<icb> Might be interesting to make an adapter board to get something close to the planned ports C/D from the LVDS connector, with some necessary limitations like there not being enough pins to get the same granularity in pin direction and what comes with not having access to the system I2C bus
<d1b2>
<TiltMeSenpai> maybe pull VIO from A/B and feed it into a voltage follower or something?
<d1b2>
<icb> Yeah, I’m sure a lot of what it could be used for would be at the same voltage as the other ports
<d1b2>
<icb> And if you’re using it for a wider parallel bus, you might not care if you can only switch direction of 8 lines together
<d1b2>
<icb> I usually come up with bad ideas for misusing hardware
<d1b2>
<OmniTechnoMancer> If the parallel bus is not super fast is a shift register a viable work around?
<d1b2>
<icb> Yes, I think the xPROM board does that
<d1b2>
<Attie> yeah - that's used for addressing eeproms
<d1b2>
<Attie> the higher address bits are via a shift register, and the lower are direct, to keep the speed up
<d1b2>
<TiltMeSenpai> ice40 has ddr output right
<d1b2>
<TiltMeSenpai> you could output the clock to sync or something and use a bunch of 2:1 muxes
<d1b2>
<TiltMeSenpai> or something, idk
<d1b2>
<OmniTechnoMancer> Use a DDR shift register :P
PyroPeter_ has joined #glasgow
PyroPeter_ is now known as PyroPeter
PyroPeter has quit [Ping timeout: 264 seconds]
egg|laptop|egg has quit [Remote host closed the connection]
<d1b2>
<Darius> there are a million solutions, obviously the most complex one is best 😉
GNUmoon2 has quit [Remote host closed the connection]
GNUmoon2 has joined #glasgow
<d1b2>
<edbordin> résumé-driven development
Stormwind_mobile has quit [Ping timeout: 246 seconds]
GNUmoon2 has quit [Ping timeout: 240 seconds]
GNUmoon2 has joined #glasgow
nCrazed has joined #glasgow
Stormwind_mobile has joined #glasgow
Stormwind_mobile has quit [Remote host closed the connection]
<sorear>
I just looked again at the case renderings, and I'm confused by the connector pinout
<d1b2>
<uep> I hope it's just a render issue, but worth confirming with @timonsku that's fixed before production
<d1b2>
<esden> lol... good catch I did not mirror the pinout legend it seems?
<gruetzkopf>
you mirrored one axis, not both
<d1b2>
<esden> yeah, but V and S are also wrong in their own way...
m42uko has joined #glasgow
egg|laptop|egg has joined #glasgow
egg|laptop|egg has quit [Ping timeout: 265 seconds]
<d1b2>
<timonsku> ah yea silkscreen is done by esden, I didn't verify that :smile: good catch!
<electronic_eel>
timonsku: may i ask some questions about the case, especially conductivity?
<electronic_eel>
timonsku: as far as i understood, the case will be anodized aluminium. so the surface is not conducting
<electronic_eel>
the screws go in from the top, into threaded holes? so no nut (that could be conducting) on the bottom
rafaelmartins has joined #glasgow
<electronic_eel>
is there some non-anodized section inside of the case that contacts to the gnd of glasgow?
<electronic_eel>
i had a metal case that was coated with some non conducting laquer for a beaglebone black in the past. it made the device highly susceptible to esd: it always rebooted or crashed when i touched it
<electronic_eel>
the solution was to remove the laquer around the screws and inside, so there was a well conducting path between the metal of the case and the gnd pads on the pcb
<d1b2>
<Attie> a good path to ground would be a very good idea...
<d1b2>
<Attie> might take a second machine pass (after anodising) to clean up the surface around the screws... and possibly a slightly raised pillar there too for good contact
<electronic_eel>
it may be different with anodized al, but i think this issue should be taken into account and checked before production
<d1b2>
<Attie> +1
<d1b2>
<thomasflummer> I wonder if it's possible to get washers that can poke through the anodizing?
<electronic_eel>
thomasflummer: yes, that might be a solution if they touch the inside "screw pillars" of the case and the pcb and then are pressed togehter from both sides
<d1b2>
<Attie> possibly, but they still need to be considered "now"... if probably prefer not, to avoid mis-assembly and frustration... but costs might be the deciding one
<d1b2>
<Attie> *I'd
<agg>
you might be able to mask the bottom of the screw pillar on the case while anodising, instead of post machining
<d1b2>
<thomasflummer> yes, the pillars need to be a little shorter, else there will be a gap all around 😉
<agg>
though raw aluminium is not that much more conductive given the oxide layer
<sorear>
how conductive does it need to be? esd currents are tiny
<agg>
depends on how much you care I guess, I've seen conductive chromate coatings on aluminium parts designed for esd control but it's almost surely overkill for this
<sorear>
(sees the sync cable image on the crowdsupply page) are we expecting sync always connects exactly two devices? I assumed it was a multidrop/wired-OR thing
<electronic_eel>
sorear: i'd say it is planned to be multidrop. but in case of multiple glasgows, you have to wire that up yourself
<electronic_eel>
maybe a small pcb that parallels multiple of these connectors
<electronic_eel>
since there aren't any applets that make use of sync yet, i'd say even adding the sync cable to the pack is enough
<electronic_eel>
hmm, don't exactly remember how the discord bridge works and if : is ok to notify or if you need to @, so just to be sure:
<electronic_eel>
@timonsku if you didn't already get notified by my message above, here again
<d1b2>
<Attie> electronic_eel: that's highlighted, so should be good, whatever you did
<electronic_eel>
thanks for verifying. i know it worked once, then broke, was fixed again, so just wanted to make sure that timonsku sees it
<d1b2>
<Attie> np
<d1b2>
<timonsku> there will be a test run so any such issues should probably come up there but yea leaving any part bare doesn't do much, aluminium instantly oxidizes which is a similar insulator as the anodization
<jpa->
sorear: ESD currents are not tiny - in human body model, the initial current is 3 A; and in "charged device model" (human holding a charged device and connecting it to another) it can be up 50 A
<d1b2>
<timonsku> though not sure how ESD could affect the Glasgow that way? Are you sure that was ESD issues you had and not something about different GND potentials due to slight conductivity?
<jpa->
my experience with ESD in metal cases has been that if the PCB ground layer is the closest thing that the case contacts, it is ok; but if the screw holes do not have ground connection, the ESD spark can jump from the metal case to whatever pin or trace happens to be close
<jpa->
and sparks love sharp things like screw tips and pin header pins
<electronic_eel>
i think the problem with a metal case that is not at gnd level is like this: your body is charged and when you touch the non-conducting case, the non conducting layer becomes a capacitor that is charged very fast. the other capacitor, case || non-conductive-coating || pcb-traces is then charged instantly as well. this will send the pulse into the pcb
<electronic_eel>
so you don't even need flying sparks, it is "just" emi
nicoo has quit [Quit: WeeChat 1.7.1]
<d1b2>
<Attie> re oxidisation: crincle washers might be the better option then... humm
<d1b2>
<Attie> not sure how the hardness of the case vs. ENIG plating / copper / pcb will hold up in that scenario
nicoo has joined #glasgow
<d1b2>
<Attie> I've just looked up crinkle washers... what I actually meant was these anti-vibration types:
<electronic_eel>
Attie: yes, these should work. if screwed in tight enough, they will scratch through the anodization of the aluminium and make contact
<electronic_eel>
they will of course also scratch into the pcb, but that shouldn't matter.
<electronic_eel>
the round open ground area around the screw holes in the pcb is not filled in the vcc layer, so no problem if it will penetrate the upper layer
<electronic_eel>
given that the washer isn't larger than the opened area though
<electronic_eel>
if we do another revision, we could add a bit larger cutout in the vcc layer there though
<d1b2>
<xabean> 400% funded. Damn.
egg|laptop|egg has joined #glasgow
<d1b2>
<timonsku> these washer can damage the PCB quite a bit though, I don't think that is a good idea
<d1b2>
<timonsku> @electronic_eel do you have a link to that beagle bone case that gave you issues?
<d1b2>
<Attie> re damage: yeah, that was my concern...
<d1b2>
<Attie> especially when repeated together/apart cycles happen, i imagine it'd end up chewing the PCB quite badly
<d1b2>
<Attie> there may be less aggressive alternatives i suppose - following the same idea
egg|laptop|egg has quit [Remote host closed the connection]
<gruetzkopf>
throwing in a washer might help with the pcb
<gruetzkopf>
but now we're getting into too many parts land
<electronic_eel>
@timonsku i don't think these cases are available anymore. the company that made them changed their focus and i haven't seen the cases offered somewhere else
<d1b2>
<timonsku> or do you have photos?
<electronic_eel>
@timonsku what do you want to know about these cases?
<d1b2>
<timonsku> would be interesting to see how its made up and what material it uses
<electronic_eel>
i can make a photo and post it. material was common steel, probably zinc coated
<electronic_eel>
as you can see it was painted with a black laquer. i had to remove it around the screw holes to make contact between the top cover and the base
<electronic_eel>
the base is screwed to the pcb. the pcb has similar ground pads like glasgow
Stormwind_mobile has joined #glasgow
<d1b2>
<Attie> I'm going to be streaming more stuff with Glasgow later today... LED control, and basic Servo control (likely just PWM freq/duty)
egg|laptop|egg has quit [Remote host closed the connection]
<d1b2>
<timonsku> so the issue was only present when the top cover was on?
bvernoux has joined #glasgow
<d1b2>
<timonsku> I wonder if you had arcing into that battery sense pin, that could possibly trigger a brown out if that got an esd discharge, its really close to that gnd screw
GNUmoon2 has quit [Remote host closed the connection]
GNUmoon2 has joined #glasgow
<electronic_eel>
@timonsku the issue was only when the top cover was on. just a single touch (without any extra measures like polyester sweaters) was enough to either hang it or reboot it
<electronic_eel>
once i removed the lacquer around the screw holes of the top cover, the issue was completely gone
<electronic_eel>
i can now measure a milliohm resistance between the area around the screws on the outside and the gnd inside
<electronic_eel>
so the screws and threads conduct well
<electronic_eel>
this is something that might be different with your design for glasgow, if the threads are anodized as well, they won't conduct
<electronic_eel>
i don't think the battery contacts were involved at all. i also don't think there was any kind of arcing. i couldn't feel any discharge, it was just a normal touch without that feeling of arcing
<d1b2>
<timonsku> yea thats what I'm currently thinking about, I think I'd rather have more expensive for a hard anodize to make sure the part stays insulated enough than try to fully gnd it with would be much more complicated
<electronic_eel>
hard anodizing to the outside is good, but there should be some point on the inside of both parts that are connected to the gnd pads. otherwise a capacitor may form and can have similar effects as i saw with my beaglebone case
<d1b2>
<timonsku> anodized aluminium seems to dissipate ESD pretty well from I found in some study, it gets only icky if you need proper earthing of a case but that would be more in the realm of having high voltage in play
<d1b2>
<timonsku> I have doubts that capacitive effects could play a role here, do you have anything that describes that effect in cases? I never heard that
<electronic_eel>
ok, i don't have any experience with anodized al and esd. it could be that the thin anodization layer has different properties than the lacquer of my beaglebone case
<d1b2>
<timonsku> the case would be a incredibly poor capcitor
<electronic_eel>
an esd discarge is extremely fast, so even a small capacitance is enough to transfer the energy
<electronic_eel>
unfortunately i don't have any textbook articles at hand that describe this effect
<d1b2>
<timonsku> but then arcing must have happened in your case
<d1b2>
<timonsku> e.g. some part of the BB had better contact through the air to the case than the GND pads under the screw, otherwise I can't see how it would have a path other than the GND
<electronic_eel>
no arcing, just charging of small capacitors. remember that capacitors are conducting for high frequencies
<electronic_eel>
unfortunately i have to go now so we can't continue this discussion in depth now
<electronic_eel>
will be back in a few hours
<d1b2>
<timonsku> but if there is no connection anywhere you are not forming any circuit from which a charge could flow yea no worries! see you later 🙂
egg|laptop|egg has joined #glasgow
egg|laptop|egg has quit [Remote host closed the connection]
egg|laptop|egg has joined #glasgow
egg|laptop|egg has quit [Remote host closed the connection]
egg|laptop|egg has joined #glasgow
egg|laptop|egg has quit [Remote host closed the connection]
GNUmoon2 has quit [Ping timeout: 240 seconds]
kmc has joined #glasgow
egg|laptop|egg has joined #glasgow
egg|laptop|egg has quit [Remote host closed the connection]