<TD-Linux>
zkms, fun fact guess why MPEG-TS packets are 180 bytes
<TD-Linux>
it was designed to be exactly 8 ATM cells
<hl>
oh god ATM
<hl>
I assume everyone knows 53 byte ATM cells were a 'compromise' between Netheads and Bellheads, both of whom refused to yield on their preferred sizes (32 bytes and 64 bytes)who refused to
<hl>
amusingly, both of them had preferred use cases in mind for which 32,64 bytes were preferred, whereas 53 bytes is inferior for both
<hl>
brilliant design
<hl>
spite is practically built into the ATM standard
<sorear>
8*48 = 224 != 180 ??
<hl>
"Wireless and mobile ATM never established a significant foothold." THIS WAS A THING??????
<hl>
Wireless ATM, what?
<TD-Linux>
sorear, sorry 4
<TD-Linux>
also it's actually 188
<TD-Linux>
with 4 bytes of overhead = 192
<sorear>
oh, the MPEG goes inside the ATM?
<TD-Linux>
yes
Stormwind_mobile has joined #glasgow
noobos has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Stormwind_mobile has quit [Ping timeout: 260 seconds]
m4ssi has joined #glasgow
noobos has joined #glasgow
Stormwind_mobile has joined #glasgow
Stormwind_mobile has quit [Ping timeout: 268 seconds]
ktemkin has quit []
ktemkin has joined #glasgow
Stormwind_mobile has joined #glasgow
<Stormwind_mobile>
A kind of different question: is anyone of you people doing stuff like we are talking about professionally? What exactly do you do? How did you get there? Asking for me ^^°
Stormwind_mobile has quit [Ping timeout: 265 seconds]
<noopwafel>
finally found time to patch up bridges on Glasgow attempt
<noopwafel>
provided 5V, get LEDs lighting up with the right colors at least
<noopwafel>
and some of the easy selftest stuff passes, time to solder up the other side of the board I guess
Stormwind_mobile has joined #glasgow
<tnt>
noopwafel: other side ?
ExeciN has quit [Quit: so long king Bowser]
<noopwafel>
tnt: backside, going to try w/hotair
ExeciN has joined #glasgow
<noopwafel>
surprisingly painless
<noopwafel>
but now self-test fails, alas
m4ssi has quit [Quit: Leaving]
<noopwafel>
so A7 seems to be unreliable, will take a scope. nice to have the self tests though!
<emily>
iirc selftest was broken on revC or something?
<emily>
maybe that's outdated knowledge actually
<noopwafel>
yes I just found #151.. but I think this is a real fault
<noopwafel>
thanks tho
<noopwafel>
maybe should be asking in here before trying to debug things..
<noopwafel>
on that note, uart applet gives me asyncio error ("Task was destroyed but it is pending!")
<noopwafel>
oh haha
<noopwafel>
because I don't give it a param and there's no default in the case :)
noobos has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<electronic_eel>
noopwafel: selftest is still broken in revC. The basic design of it is for revAB, where the level shifters had integrated bus-hold. the level shifters of revC don't have that
<electronic_eel>
so expect some false positives
<electronic_eel>
false positive as in the test says fail but in reality it is ok
<electronic_eel>
I plan to work on selftest for revC, but want to get the test jig board with the internal i2c working first
<noopwafel>
electronic_eel: ah ok. thank you too for the info :)
<noopwafel>
electronic_eel: is it worth building a test jig board? is the pcb stable?
<electronic_eel>
noopwafel: I built and tested the test jig board design, it does what it was designed to do. But currently you can't use it for anything practical yet as the access to the internal i2c bus of the glasgow is missing
<electronic_eel>
that is how the test jig board will be accessed in actual tests and how it will be integrated into the selftest code
<electronic_eel>
so as this stuff is still missing, you won't get anything out of building one yet. In the future the test jig board will allow you to speed up testing (no more manual connecting/disconnecting wires for the loop test)
<electronic_eel>
also it should improve test reliability, as it includes current sensing and should be able to detect some short circuit conditions more reliably
m4ssi has joined #glasgow
<noopwafel>
electronic_eel: i2c bus access -> revD?
Stormwind_mobile has quit [Ping timeout: 240 seconds]
m4ssi has quit [Remote host closed the connection]
Stormwind_mobile has joined #glasgow
m4ssi has joined #glasgow
<electronic_eel>
no, revC. there are testpoints on the back which allow to access the internal i2c. when you put a fresh glasgow into the test jig, these testpoints will be connected to the test-jig board
<electronic_eel>
(testpoints on the back of glasgow revC)
<electronic_eel>
the regular glasgow app will connect to the glasgow, initialize the fx2 and then control the test jig board over the internal i2c to measure currents and switch the loopback
<zeiris`>
are there any (english-language) textbooks covering test jig design tricks?
<electronic_eel>
I don't know of a textbook that covers the topic of test jigs and pcb testing well, sorry
<noopwafel>
electronic_eel: ah, hm, that definitely sounds like it's worth making
<noopwafel>
definitely something wrong with A7 on this board :(
<electronic_eel>
noopwafel: the textbook zeiris wants or the test jig board?
<noopwafel>
the test jig board
<noopwafel>
not qualified to write textbooks on test jigs :-)
<noopwafel>
ugh
<noopwafel>
to evaluate writing textbooks on test jigs :P
<noopwafel>
also not qualified to write them, mind
<electronic_eel>
would like to read one too, but haven't found any so far
<electronic_eel>
how many glasgows do you want to manufacture and test?
<noopwafel>
not enough to make a jig worth building (maybe 10), but am at a hackerspace and it might help encourage people to try building one themselves, idk :) let's see how painful it is to debug a few manually
<electronic_eel>
I think even for 10 it won't save you time. It is more designed to help esden manufacture a hundred or more. and to really save time it should be used with a jig instead of manually plugging in wires and somehow fiddling with the i2c-testpads
<whitequark>
electronic_eel: re i2c bus: I asked on twitter and it looks like READ; REPSTART; WRITE is not something that any remotely common device needs
<electronic_eel>
yeah, read the replies on twitter
<whitequark>
in fact I think it would be sufficient to have a very simple protocol that amounts to <addr> <write size> <read size> <write payload>, which produces a S [<addr>|0 <write payload> R] <addr>|1 <read payload> P transaction
<whitequark>
since after thinking some more about it, in practice in single-initiator systems, repeated start is only used to set the pointer or register address or somesuch
<electronic_eel>
no read without write first?
<whitequark>
if you set write size to 0 then the first part is omitted
<whitequark>
(it doesn't have to be-- S <addr>|0 R is defined as a no-op, but it seems pointless to have it)
<electronic_eel>
is there a way to get individual acks or nacks?
<whitequark>
yes, the response will start with the amount of acked written bytes
<whitequark>
and then 0 or 1 for whether the <addr>|1 was acked
<electronic_eel>
when you want to read n bytes, but the device nacks at less than n bytes, you just get the bytes that were successfully read?
<whitequark>
no; USB doesn't let you do that. it's padded with zeroes at the end
<electronic_eel>
hmm, how do you then know that you didn't read zeroes?
<whitequark>
er, wait
<whitequark>
*I2C* doesn't let the device nack a read
<whitequark>
because during reads, ack/nack is provided by the initiator
<whitequark>
(it means "I want one more byte after this")
<whitequark>
I2C only lets the device nack its read address
<electronic_eel>
ah, I thought a device could somehow abort a read
<electronic_eel>
but I forget these details some time after I used a spec
<electronic_eel>
ok, so no support for repeated start, no hacks required
<electronic_eel>
for the purpose of the test jig this is plenty enough
m4ssi has quit [Remote host closed the connection]
<electronic_eel>
when we decide we want to do i2c address scanning for addon boards, we can implement this as special function on the fx2
<electronic_eel>
but the address pin thing for the addons seems a bit more promision
<electronic_eel>
promising
<whitequark>
electronic_eel: address scanning could be done as a special case of this protocol by using 0 for both read and write sizes
<whitequark>
it's a bit awkward because once you start a read, you have to read at least one byte, so it'd have to be special cased to not omit the first half in that case but do omit the second
<whitequark>
(i.e. just do the address write and report the result of that)
<electronic_eel>
it would be scanning for the read address and the write address both, correct?
<whitequark>
you can't easily scan for the read address because once the device acks <addr>|1, it takes control of the bus
<whitequark>
e.g. if what you're about to read is 0x00, then it'll hold SDA low for 8 SCL pulses, and there is nothing you can do about it short of resetting the device
<whitequark>
if we do know we're scanning for EEPROMs, this doesn't matter, but in that case, we also should scan with a write;repstart;read
<whitequark>
(to reset the read pointer to 0)
<electronic_eel>
so a scan for read an write would be to write zero bytes and try to read one byte
<whitequark>
no
<whitequark>
well
<whitequark>
in general, yes
<whitequark>
i think it doesn't make any sense to scan for reads because there are unlikely to be any devices (i can't imagine any reason why) that respond to one but not the other
<whitequark>
and in fact the i2c applet doesn't let you do that. it always just scans for writes
<whitequark>
oh, hm
<whitequark>
ok it does
<whitequark>
but i think that's pointless so maybe it shouldn't
<electronic_eel>
it can do both, that was something I added IIRC
<electronic_eel>
I think there were some devices that only answer one of both
<electronic_eel>
some very old stuff that only has one register that can be read or something
<whitequark>
hm, ok
<electronic_eel>
the complete command goes into one usb control transfer, the answer is read as one control transfer, right?
<whitequark>
yes
<electronic_eel>
aren't there limits on the size of control transfers?
<electronic_eel>
something depending on usb speed or similar?
<electronic_eel>
my mind is a bit foggy when it comes to usb...
<whitequark>
there are (I think with the FX2 it is 4K in practice), but 256 bytes is always fine
<whitequark>
if we use a two byte length then this becomes a problem, which is why I suggest using one byte length; you always have to handle this on the host side, so let's force the host code to take care of this earlier
<whitequark>
(it's not practical to split a single I2C transaction between two USB transfers because this can and will lead to lockups)
Stormwind_mobile has quit [Remote host closed the connection]
<electronic_eel>
two byte length?
<whitequark>
in the USB protocol
<whitequark>
address, write length, read length
<electronic_eel>
sorry, I still don't understand what you mean by two byte lengt
<whitequark>
well, in the USB control request, you have the amount of bytes you want to write to the device
<electronic_eel>
yes
<whitequark>
that amount could be represented with uint8_t or uint16_t
<whitequark>
the latter would be a two byte length field
<electronic_eel>
ah, just the size of the field, one byte would limit to 256
<electronic_eel>
do you know of any devices where you really would want to read or write more than that in one go?
<electronic_eel>
like a flash where you trigger a page write or something?
<whitequark>
i think I2C EEPROMs with more than 256 byte pages are rare but they're conceivable
<whitequark>
it would just lower performance though
<electronic_eel>
is there a max time for a usb control req to be answered? does it conflict with the time it takes to execute the i2c transfer?
<whitequark>
AFAIK you can set any timeout via libusb; certainly you can set a timeout higher than it is reasonable to hog the internal bus for (it should probably not stay busy for more than 50 ms or so)
<whitequark>
also, I just realized an important part
<whitequark>
you can't write AND read in a single control request
<electronic_eel>
ah!
<electronic_eel>
so it is either read or write, wasn't sure about that
<whitequark>
or rather, you can write the SETUP packet (wValue, wIndex, wLength) and then read the payload
<whitequark>
but it's not an arbitrarily long write
<whitequark>
... can we talk about how this is only a problem because we're bridging a terrible bus (I2C) to another terrible bus (USB)
<electronic_eel>
so how will this affect the protocol?
<electronic_eel>
you send a command with some data (write req)
<electronic_eel>
the result is stored on the fx2 in some kind of buffer
<electronic_eel>
then the host waits for some time and sends a read req
<electronic_eel>
the fx2 answers either with the data or some "I'm not finished yet"
<whitequark>
the read request can stall until the transaction is done
<whitequark>
(well, not "stall", that means a different thing in USB)
<whitequark>
(it would "nak", which would cause the host to wait until it's done)
<electronic_eel>
but wouldn't that completely block all other usb transactions?
<whitequark>
yes, but you cannot perform other USB transactions meanwhile, because like half of them involve I2C anyway
<whitequark>
unless you want to add some sort of I2C mutex there, which I don't
<electronic_eel>
no no no mutex
<whitequark>
:)
<electronic_eel>
I mean like sending/reading stuff to the fx2
<whitequark>
oh
<whitequark>
this only blocks *control* transactions
<whitequark>
you can exchange data with the FPGA just fine
<electronic_eel>
ok, so the usb nack is specific to control transfers or the control endpoint, not any other usb thing
<whitequark>
USB control flow is per-endpoint
<whitequark>
which i think you'll see is the only way it would make sense
<electronic_eel>
ok, then I don't see a problem when you stall a few ms
<whitequark>
there isn't
<whitequark>
what I mean is that clock stretching is a thing
<hl>
no device has ever been weird to use control transfers over endpoint!=0, right?
<whitequark>
so an I2C device can hang the bus indefinitely
<electronic_eel>
yeah, we need a timeout for that
<whitequark>
hl: device? no idea. host? no host I know of can do control transfer over EP!=0
<hl>
hooray, I thought of an unholy idea involving USB that hasn't actually been done
<whitequark>
electronic_eel: and that's where the hardware reset pin for the I2C mux comes in
<electronic_eel>
and some mechanism to tell the host about what has happened
<whitequark>
(EP0 STALL)
<electronic_eel>
lets say the clock stretch timeout happens after some data has been received
<electronic_eel>
do we want to tell the host how many bytes where successfully read?
<whitequark>
nop
<whitequark>
i think we should ideally not allow clock stretching on the internal bus at all
<whitequark>
the timeout and mux is there to handle faults gracefully
<whitequark>
the internal i2c bus is too important to let peripherals to hog it for as long as they want, especially given that we don't have a way to reset peripherals connected to the auxiliary power connector
<electronic_eel>
don't microcontrollers often provide clock stretching in their i2c hw to allow for interrupt latency?
<whitequark>
well, yes
<electronic_eel>
I don't want to preclude using microcontrollers on the internal bus if they have sane response times
<electronic_eel>
like on an addon it might make sense to use one
<electronic_eel>
so I think forbidding clock stretching at all is a bit limiting
<electronic_eel>
but we should set sane limits and reset a device if it doesn't comply and hogs the bus
<whitequark>
if your MCU is fast enough it can just respond within the ACK pulse
<electronic_eel>
what i2c speed is used on the internal bus? 100kHz or 400?
<whitequark>
it has 2.5 microseconds to do so
<whitequark>
yeah, 400
<whitequark>
we could use 100 if we wanted
<whitequark>
it's switchable
<electronic_eel>
do you prefer going to 100 over allowing clock stretching?
<whitequark>
good question. I guess what we care about in the end is WCET
<whitequark>
*if* the peripheral behaves, then clock stretching is not, in and of itself, harmful
<electronic_eel>
yes
<whitequark>
if the peripheral *mis*behaves then our ban (which is really a polite request) on clock stretching doesn't change anything
<whitequark>
so I guess we should just allow it
<electronic_eel>
yea
<electronic_eel>
esden: your glasgow branch with the dfm improved footprints and such is labeled revC2. do these non-functional changes warrant a new rev number?
<electronic_eel>
or should this be more something like revC1a?
<whitequark>
any gerber change warrants a new rev number
<whitequark>
in general i don't believe in "patch versions" and the like. the version number in software is major.minor; major++ means you intend to break compatibility, minor++ indicates you do not. of course, you will often break it anyway.
<electronic_eel>
ok
<whitequark>
for hardware it's a bit different, letter++ means a new design, number++ means an improvement on existing design
<whitequark>
the risks going from revC1 to revC1a (footprint changes) are similar to going from revC1 to revC2 (component changes)
<whitequark>
you still have to recheck your entire production sequence and you still have to functionally test the result
<whitequark>
in fact it is more likely that footprint changes will cause issues than component changes IMO
<whitequark>
consider the trouble esden had with the ESD diodes
<emily>
whitequark: semver patch releases are useful because if you use an API introduced in 3.x.0 then you should not allow 3.<x
<emily>
i guess you'd just say "depend on the relevant minor release at the time" though
<whitequark>
yes
<esden>
I think it makes it easier to not have to ponder too hard about which part of the revision to bump too. I do like the simplicity. The only problem is that people then ask "OMG does this mean the rev of the board I have sitting here is junk?"
<esden>
but that is easy to answer usually :D
<emily>
but i think the distinction between "fixes" and "actual new APIs added" is meaningful
<emily>
maybe not meaningful enough to put in the version number but /shrug
<whitequark>
esden: well, we still support revAB
<esden>
I know, just saying that I saw people ask that question. I do agree with your versioning.
<electronic_eel>
IIRC there was the report from eurocircuits about some footprint ambiguities, the usb connector footprint and the numbering of the sync connector. do we also want to change them if we do a revC2?
<whitequark>
emily: yes re "depend on etc". i don't have the time or the incentive to maintain multiple minor version branches
<emily>
sure (i think there's value even without branches, but less)
<whitequark>
emily: regarding fixes, i think the line between "new API" and "bugfix" is inherently blurry. it is quite often that e.g. a racy API can only be fixed by replacing it with a new one
<emily>
(and also you'd never want to maintain a branch for a minor version anyway?)
<emily>
(since by definition it's not breaking!)
<emily>
whitequark: so new features are a minor release but bugfixes are a major release, because all bugs are depended on!
<esden>
I am stuck with the updating of the board at the moment anyways... because I am having a difficult time deciding if i invest another two weeks upstreaming SOT23 and MSOP footprint corrections. Or just fudge it in our local library and be done with it. SOT23 is really tricky as it requires new generator scripts for kicad... >_<
<whitequark>
emily: that is indeed a more extreme version of my view, and i think it has some merit
<whitequark>
emily: mine is a compromise, as is yours, as is the one you suggest as an absurdity/extreme
<emily>
whitequark: ok but now consider that adding new APIs is actually a breaking change because people do from x import * :')
<emily>
at least python doesn't default to that
<emily>
it's a huge problem in haskell
<whitequark>
you can just not add them to __all__, but also, yes
<esden>
also I spent two days digging through JEDEC and IPC to figure out how the vendors came up with their SOT23-x footprint recommendations. So far none of it makes sense. :D
<whitequark>
adding new things to nmigen prelude is technically a breaking changes
<whitequark>
unfortunately, adding new anything to anything in python is
<electronic_eel>
esden: I don't know if SOT23 scripts are really worth it because SOT23-5 and SOT23-6 are different width from 3-pin SOT23
<whitequark>
maybe the code depends on a NoMethodError
<whitequark>
it could easily, because of an unqualified except: clause...
<emily>
cursed
<whitequark>
this kind of stuff is why i *particularly* argue against having patch versions in python projects
<whitequark>
it makes at least some sense in rust
<whitequark>
but i also admit this preference is to a large extent philosophical
<whitequark>
(then again, so is semver in general)
<whitequark>
(if it wasn't we wouldn't need lockfiles)
<esden>
electronic_eel: that is the issue here... but to be honest having a generator will make it easier to update the footprints when the kicad library format or standards change. As the script generates more than just copper lands but also legends and other things. Having static footprints keeps being an issue. That is why still have half of the footprints with roundrect pads.
<esden>
You can't just change a variable somewhere and regenerate all the footprints with roundrect pads.
<whitequark>
electronic_eel: christ, really?
<electronic_eel>
esden: also someone could want the trick you did with the level shifter footprint for sot23-6, just for a more crude process
<whitequark>
that's incredibly frustrating to know
<esden>
all that footprint situation in general is incredibly frustrating... and the way it is being reviewed results in a massive backlog too...
<electronic_eel>
maybe if the script process in kicad were really streamlined, like your joe average user using it - but afaik it isn't
<esden>
not just the fact that there is not enough people doing the review work
<whitequark>
yeah, the process has significant flaws
<esden>
ohh lol... don't get me started on the status of the generator scripts
<esden>
and how I have to "virtually" ziptie my hands behind my back so I don't spend the rest of the year cleaning this stuff up.
<esden>
I want to scream: "I have other things to do, why are you people not doing it right" ... *sigh*
<electronic_eel>
if they want to solve the review situation, good scripts are the best way forward - but do they get enough backing from the major contributors the way they are now?
<esden>
it is a chicken and egg problem... and people come with motivation to the process and don't want to step on anyone's toes and change things.
<esden>
those that originally wrote them did it for themselves, it worked for the one or two libraries they made, the rest grew organically by contributions. Original person has not cleaned up or touched the stuff in months/years.
<esden>
they just merge patches
<esden>
it is at the end "lack of developer time"
<whitequark>
unpaid and not always entirely consensual maintainers, as usual
<esden>
so I can't really complain... it is more... "Why don't I have time to fix this and make the situation better."
<electronic_eel>
but if we provide all the dev time required to kicad, glasgow isn't going forward
<esden>
exactly... that is my dilemma
<whitequark>
i think helping out various upstreams is in scope of the project
<whitequark>
of course, it's always a compromise
<electronic_eel>
esden: fully understand that, often feel like this when seeing a project struggling with this
<esden>
but at the end, the upstreaming process was a really good and steep learning curve
<whitequark>
but for example glasgow was my #1 motivation for multiple nmigen features and nmigen in general
<esden>
and I might have explained it through my twitch stream to one or two people
<whitequark>
(and ironically that's why it still uses omigen syntax...)
<esden>
so the teaching part and upstreaming part and learning part were definitely reached
<whitequark>
as long as *something* in the ecosystem moves forward, i personally am happy
<esden>
I am too. :)
<esden>
but today and the rest of the week I need to do accounting which only through several indirections related to any of this. :P
<electronic_eel>
I don't envy you
<esden>
Thank you... :)
<electronic_eel>
bite your way through, when you are done some more rewarding stuff like kicad or glasgow is waiting
<esden>
hehe... yeah I am telling myself exactly that... it is the "payment" to do other more fun stuff :)