<wpwrak> i'm developing a new set of allergies, e.g., to certain pin namings. e.g., pins named "PIN" ...
<DocScrutinizer05> hehe
<DocScrutinizer05> don't expose yourself to any alergens when you got a flu!
<DocScrutinizer05> your leucos are in combat mode already
<DocScrutinizer05> rather the T cells I guess
<wpwrak> alas, that one has to wait until i get to exorcise the PHS8 unit orgy. right now it's non-editable, with its 80 (!!!) units
* DocScrutinizer05 looks into the module file to find out how to sed-nuke units
<wpwrak> manual editing seems to be the best way
<wpwrak> you want to classify (into a reasonable number of units) at the same time
<wpwrak> and most are GND anyway. one unit per pin
<DocScrutinizer05> meh, I can't even find the modem module
<wpwrak> luckily, the number of pins isn't all that large
<wpwrak> PHS8
<DocScrutinizer05> where?
<wpwrak> neo900.lib
<wpwrak> line 4928 etc.
<DocScrutinizer05> meh I looked into ne900-legacy.lib and searched in /components/modules/*
<DocScrutinizer05> ta
<DocScrutinizer05> hmm, no idea where the units hide in there
<DocScrutinizer05> it's just too simplistic to really get it from this one thing
<DocScrutinizer05> probably it's just sed 's/([^ ]* [^ ]* [^ ]*) [^ ]* ([^ ]* [^ ]* [^ ]* )/\1 MOD1 \2/"
<DocScrutinizer05> or U instead MOD, or whatever
<wpwrak> yeah, by the time you have the right sed rules, you're done manually, too :)
<DocScrutinizer05> possibly, the first time
<wpwrak> after that, the beast is fixed and remains fixed ;-)
<wpwrak> actually, i made a new component for wlan, so that i don't have to edit around in neo900.lib. that would be a bit too scary
<DocScrutinizer05> then maybe making a new module file from modem was the logical first step ;-)
<wpwrak> that's my plan, yes
<DocScrutinizer05> seems easy enough, open for edit and save in new library
<wpwrak> if that worked, it would indeed be easy ;-)
<DocScrutinizer05> also delete in old library while at it
<DocScrutinizer05> why wouldn't it work?
<wpwrak> but remember that kicad gets a little confused already after 26 units, and merrily discards everything after 64
<DocScrutinizer05> well
<wpwrak> thus, the process is a little more .. rustic
<DocScrutinizer05> goes down to "Unit CB"
<wpwrak> behaviour is very inconsistent. i wouldn't trust kicad when handling that
<wpwrak> i saw too many bugs already (mentioned them on #kicad). this is really really treacherous ground
<wpwrak> i'm just happy that i never tried to fix anything in the modem so far (i.e., before knowing about this problem). else, all hell would have broken loose
ob-sed has joined #neo900
<wpwrak> wlan is now the TI reference design. fm still needs work on the right-hand signals.
<wpwrak> (sheet) or page
<wpwrak> well, cut out the DRAW ... EndDRAW section of PHS8 in neo900.lib and run a diff. then you can be sure it didn't lose or change anything
<DocScrutinizer05> when you know how it works, why don't you do it that way?
<DocScrutinizer05> if it's really just a verbatim cut out of the original then it's easy enough to do it, no?
<wpwrak> and how do we proceed now ? will you do the sanitizing of PHS8 ? or do i do it, and the above was just a local experiment ?
<wpwrak> yes, that's how i did it
<DocScrutinizer05> the latter
<wpwrak> ok
<DocScrutinizer05> so you were not very verbose on what you do, I thought you might create a new component from scratch
<wpwrak> hell no :)
<wpwrak> just tweaking it with vi
SylvieLorxu has quit [Quit: ZNC - http://znc.in]
<wpwrak> with a lot of saving :)
ob-sed has quit [Ping timeout: 240 seconds]
<DocScrutinizer05> anyway that local experiment shown that lib editor goes all the way down to unit "CB"
<DocScrutinizer05> ~3*26 + 2
<infobot> 80
<wpwrak> yup, it's in the DEF line: DEF PHS8 M 0 40 Y Y 80 L N
<wpwrak> can you guess who else has more than 26 units ? :)
<DocScrutinizer05> who else?
<wpwrak> OMAP
<DocScrutinizer05> ooh which component
<DocScrutinizer05> so we have the OMAP footprint?
<wpwrak> so that one's a battle for another day. first i need to collect the bits and pieces, to see what's actually there, and how it's structured
<wpwrak> yes
<wpwrak> it's ... PBGA784-N515-0.4
obsed has joined #neo900
ob-sed has joined #neo900
chomwitt has quit [Ping timeout: 248 seconds]
<DocScrutinizer05> wpwrak: I'm not surprised kicad acts up, not at all -> http://wstaw.org/m/2016/10/02/plasma-desktopsW2309.png
<wpwrak> yup :) and you already hit a lot of bugs even below 64
<wpwrak> so the only safe number of units is <= 26
<wpwrak> anyway, PHS8 is now safe. down to 13 units. and the modem sheet basically looks identical
<wpwrak> well, PHS8-CLEAN is. PHS8 still is the same nightmare it always was :)
<wpwrak> ah, and i found some more problem parts: the FH23 connectors. they also consists of individual pins
<wpwrak> they're in the BB section. i guess i'll just kill them and use my generic connectors. it's not as if there was anything special about them
<wpwrak> after that, we have the TLV320AIC34ZAS with 24 units. close but no trouble.
<wpwrak> and of course, good old OMAP, with 40
<DocScrutinizer05> this 64 limit looks _very_ randomly chosen
<wpwrak> clearly in need of a good haircut
<DocScrutinizer05> please pstpone OMAP
<wpwrak> could be sizeof(uint64_t) * 8
<wpwrak> (OMAP) yup, definitely not for today :)
<DocScrutinizer05> not even needed for proto_v2
<DocScrutinizer05> and we don't know what exactly we'll need for OMAP when we use it, e.g. we might want footprint already with in-pad vias, or whatever
<wpwrak> but i want to use it sometime soon. the idea is that i connect signals to the omap, to make sure everything has its place. that will also tell me about any pin type conflicts (which the connector to BB wouldn't)
<DocScrutinizer05> ohmy
<wpwrak> (footprint) that's unrelated. i'm not changing the pin "numbers". it's the pin numbers that define what goes where on the footprint
<DocScrutinizer05> that's a job for pinmux!
<wpwrak> in other words, all this cleanup has no effect on the footprints
<wpwrak> luckily, kicad doesn't allow you to split a footprint into "units" ;-)
<DocScrutinizer05> the idea was to keep OMAP out of design for proto_v2, not only regarding PCB and layout but also schematics
<wpwrak> (pinmux) pinmux doesn't know the pin types in our schematics
<wpwrak> yes, i just want to use it temporarily. we can then just remove the sub-sheet, and it's gone
<DocScrutinizer05> definiteve nope @ using OMAP for proto_v2 schematics
<wpwrak> (gone) until we put it back. so, it goes into hiding, not permadeath
<wpwrak> as i said, temporarily, to help detect problems early
<DocScrutinizer05> nope, too much overhead
<wpwrak> not really. fixing problems we failed to detect will have much more overhead
<DocScrutinizer05> no
<wpwrak> just trust me on this :)
<DocScrutinizer05> no
<DocScrutinizer05> we have not the time nor the funds for doing it this way
<wpwrak> der boese geist, der stets verneint
<DocScrutinizer05> review of pin types in OMAP alone takes days if not weeks
<DocScrutinizer05> and in the end it's totally meaningless for proto_v2 since we do not have any omap in proto_v2
<wpwrak> and just a few weeks ago, you wanted the OMAP in there yourself, and even operational, not just for checking. amazing, how quickly how something can change from "let's just do it" to "oh, even a tenth of it would be prohibitively expensive to do" :)
<DocScrutinizer05> don't twist my words!
<wpwrak> i would assume that nik got the pin types mostly right
<wpwrak> especially on the omap
<DocScrutinizer05> not going to happen
<DocScrutinizer05> this sort of "ERC" is 100% pointless for proto_v2
<wpwrak> i've seen quite a number of his choices so far, and most are reasonable. there are areas of sloppiness, but they tend to announce themselves by other issues as well
<wpwrak> so you say we do v2 without ERC ?
<DocScrutinizer05> I say there won't be any OMAP getting used in proto_v2
<DocScrutinizer05> period
<wpwrak> sigh, there will of course be no omap for v2. merely as a transitional design aid, it will appear in the schematics. i mean, it already does at a number of places
<DocScrutinizer05> adding the omap gives us zilch validation or check for the BB interface, plus it will defimnitely add a bazillion new bogus ERC errors and warnings
<DocScrutinizer05> honestly, I totally fail to see the point of that maneuvre
<wpwrak> it gives us indirect validation: the next step is then a transfer from omap to equivalent (i.e., also omap) pins on the BB interface
<DocScrutinizer05> heck, then how do you check that the pins on BB interface are equivalent to those on OMAP, and what is the end benefit of that whole exercise??
<wpwrak> and then deal with what remains (after disappearing the transient omap)
<DocScrutinizer05> no
<wpwrak> we have to check BB-OMAP equivalence anyway
<DocScrutinizer05> exactly, so forget about that omap
<wpwrak> we don't have a magical solution for BB. this will be a fair bit of work.
<DocScrutinizer05> it only adds a week of useless overhead, if not more
<wpwrak> more like a day, or half that
<DocScrutinizer05> whatever it is, it's useless overhead
<wpwrak> well, it's your project ...
<DocScrutinizer05> you need to manually validate against the BB interface anyway
<wpwrak> in any case, i'm done with editing for a bit. probably won't have time tomorrow. so in case you want to work on the two analog circuits (CABC and GSM comparator) you proposed, please feel free. though there are probably better ways to spend a sunday ;-)
<DocScrutinizer05> and that manual evaluation and validation need to be waaay more in depth and high level than what a DRC can do. In the end the workflow with OMAP would be: here's a IRQ that needs to be fast and has wake capability, what do we have on BB interfaces? aaah here is pin ZZ34 GPIO, with pinmux alternative functrions not conflicting, so we can use that. [<now cruft starts>} So do we have a similar GPIO on our virtual OMAP? hmm, yes, let's take
<DocScrutinizer05> this YX45. I connect it now. Oh, gives ERC error. Wait I found in virtual OMAP that pin is incorrectly clasified as POWER. I fix it. HOORAY http://wstaw.org/m/2016/10/02/plasma-desktopOx2309.png is happy now, connecting Output to BIDIR
<DocScrutinizer05> but we already knew we're connecting output to bidir, we searched for exactly such thing on the available pins of BB interface
<DocScrutinizer05> for signals like e.g. video bus it's even more bizarre, since we know we only can connect it to the video pins, and the pin type of those is pretty rigidly defined, we will learn exactly zilch from connecting them to a virtual OMAP before we connect them to the real BB video interface
<DocScrutinizer05> same for I2C, SPI, PCM, you name it
<DocScrutinizer05> s/DRC/ERC/g
qws-user-1229 has joined #neo900
qws-user-1228 has quit [Ping timeout: 272 seconds]
<DocScrutinizer05> it makes way more sense to for example redefine pin types of the BB-xM interface connector according to the purpose we want to use that pin for. So OUTPUT even for a GPIO we want to use in output pinmux config
<DocScrutinizer05> it's a manual task either way to make sure that OMAP pin on BB-xM's OMAP is compatible with that usage we specified for it. No local virtual transient OMAP chip will help on that
afwang has quit [Ping timeout: 244 seconds]
afwang has joined #neo900
afwang has quit [Ping timeout: 252 seconds]
afwang has joined #neo900
ravelo has quit [Ping timeout: 264 seconds]
ravelo has joined #neo900
ravelo has joined #neo900
ravelo has quit [Changing host]
Pali has joined #neo900
jonsger has joined #neo900
louisdk has joined #neo900
pigeons has quit [Ping timeout: 243 seconds]
pigeons has joined #neo900
pigeons is now known as Guest54199
afwang has quit [Ping timeout: 244 seconds]
SylvieLorxu has joined #neo900
ashneo76 has quit [Quit: ZNC - http://znc.in]
SylvieLorxu has quit [Ping timeout: 248 seconds]
SylvieLorxu has joined #neo900
SylvieLorxu has quit [Quit: ZNC - http://znc.in]
SylvieLorxu has joined #neo900
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined #neo900
ravelo has quit [Read error: Connection reset by peer]
ravelo has joined #neo900
ravelo has joined #neo900
ravelo has quit [Changing host]
chomwitt has joined #neo900
Guest54199 is now known as pigeons
merlin_1991 has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
merlin1991 has joined #neo900
xman has joined #neo900
ravelo has quit [Disconnected by services]
liteIRC_ has joined #neo900
liteIRC_ is now known as liteIRC__
liteIRC__ is now known as ravelo
afwang has joined #neo900
ravelo has quit [Ping timeout: 248 seconds]
galiven has joined #neo900
galiven__ has quit [Ping timeout: 264 seconds]
ravelo has joined #neo900
ravelo has quit [Changing host]
ravelo has joined #neo900
jonsger has quit [Quit: jonsger]
Zero_Chaos has joined #neo900
Pali has quit [Remote host closed the connection]
afwang has quit [Ping timeout: 265 seconds]
louisdk has quit [Ping timeout: 272 seconds]
lobito1 has joined #neo900
wiewo has quit [Quit: I'm out]
wiewo has joined #neo900
paulk-collins has quit [Ping timeout: 252 seconds]
Oksana has quit [Ping timeout: 264 seconds]
Oksana has joined #neo900
xman has quit [Quit: Leaving.]
pagurus has joined #neo900
SylvieLorxu has quit [Quit: ZNC - http://znc.in]
jonsger has joined #neo900