<wpwrak>
btw, perhaps it would be useful if we had some commit notifications on IRC (like we have on #qi-hardware), at least for the ee repo. that way, everyone would know when stuff is changing, and what
<wpwrak>
grmbl. found two major bugs in schtoc.pl already. it's interesting that you can dump all sorts of text into a PDF and it's simply ignored. now that should make for a nice "covert channel"
<wpwrak>
hmm, and i wish git would warn when committing while in "detached head" mode. kinda silly to be working on a fake branch for hours ...
announ has quit [Quit: announ]
arcean has joined #neo900
chomwitt has quit [Ping timeout: 244 seconds]
<wpwrak>
DocScrutinizer05: make sch -> Generate netlist; Run Pcbnew; Read netlist; wait until it's done; then switch to Cairo ... and experience entirely new dimensions of slowness ;-)
<wpwrak>
opengl is pleasantly responsive, though
wpwrak has quit [Read error: Connection reset by peer]
<DocScrutinizer05>
Technical-Briefing.pdf) *really* can block baseband access to data on the phone, when BB uses shared RAM (>> If an attacker can gain access to the BP to the extent of being able to execute code on the BP of a secure phone, then he can circumvent or bypass a number of security functions, including access to the phone’s application processor (AP) memory, which may contain valuable secrets like clear text or encryption keys.<<) since it
<DocScrutinizer05>
simply kicks in too late. Only true physical separation between tainted modem and APE can create a truly secure phone
<DocScrutinizer05>
wpwrak: however ^^^ has a great description of heuristics in BB monitoring
<DocScrutinizer05>
don't miss that their BPFW only has the Android RIL API to "monitor" the BB
<DocScrutinizer05>
while Neo900 has sophisticated HW subsystems to monitor the modem, which are not in reach of the BP and thus are impossible to get faked or compromised by an established BB exploit
<wpwrak>
hellekin: wouldn't that be an opportunity for a bit of propaganda ? :)
<DocScrutinizer05>
also don't miss that nowadays it doesn't need an exploit in BB firmware, since pretty much *all* baseband chips have Over-The-Air firmware update
<wpwrak>
technological progress, making exploits easier, cheaper, more scaleable :)
<DocScrutinizer05>
usually user has no way to tell such OTA update is happening, nor a saying in whether it shall happen or not
<DocScrutinizer05>
cryptophone BPFW may or may not detect such update. It's however highly arguable what it could do about it, even if detected
<DocScrutinizer05>
only Neo900 has embedded Mjolnir :-)
<wpwrak>
we need code names. nokia has "GAIA". let U401 be "Mjolnir"
<DocScrutinizer05>
why not :-)
<DocScrutinizer05>
was exactly what I thought of :-D
<wpwrak>
hmm, now we need the names of three seers for U402 to U404 ...
<wpwrak>
btw, i managed to get the number of ERC complaints below 800. mainly by adding POWERED symbols and sorting out various smaller issues
announ has joined #neo900
<wpwrak>
the main source of complains now are probably unconnected things. but before attacking those, i think we should fix the sub-circuits that have diverged (SIM, HB, IR, ...) and/or never quite made it from the white papers to the schematics.
<wpwrak>
but for now i'm looking into a quick way to bring back schematics diffs. because once we start making serious changes, it'll be hard to keep track of things if all we have are textual change logs.
<wpwrak>
(also, some changes may happen unintentionally, and we'll definitely want to catch these)
<DocScrutinizer05>
dunno if anything better than netlist diffs is feasible and actually practical
<wpwrak>
in the old days, we had graphical diffs: script went through the repo, rendered schematics to bitmap, then pixel-compared and marked the regions that had changed.
<wpwrak>
alas, that needed wolfgang's command-line patches. that never made it into mainline.
<wpwrak>
and that C++ is a jungle, at least to my eyes. i've given up trying to contribute code to this some years ago. it's just too alien.
<DocScrutinizer05>
graphical diffs are possibly useful for a generic though not thorough evaluation of what changed, serving as mere hint where to look at. However note that e.g. the VBUS-MODEM-CPU glitch doesn't even _show_ in a graphical diff
<DocScrutinizer05>
for functional diffs you want netlists. It's similar to difference between a sourceode diff done byte by byte, vs a diff done on the resulting assembler listing
<wpwrak>
in kicad, you couldn't have such "invisible" net aliases. so it would show in a graphical diff.
<wpwrak>
there are things that don't show normally, but we can of course make them visible, too, with a bit of creative tweaking :)
<DocScrutinizer05>
the solution I followed for Eagle been based on the script representation creating a complete schematics from scratch, so this pretty much is identical to assembler diff plus comments
<wpwrak>
dunno if you've seen the schematics history we had some years ago (~2010-2012) in qi-hw. it worked quite well.
<ds2>
btw - OrCAD is potentially an affordable option too
<ds2>
and that can directly read in the BBX files
<DocScrutinizer05>
anyway I'm still musing if a mere diff that has no feature to also create "patches" is really that useful. It doesn't provide any real added value regarding merges
<DocScrutinizer05>
I don't know those qi-diffs. Please elaborate on "worked quite well" - what did you really accomplish with that stuff?
<wpwrak>
DocScrutinizer05: the idea is to let one quickly see where changes have happened, and get a decent idea of what these changes were. sometimes you may still have to dig deeper, but that's rare.
<DocScrutinizer05>
how was it used?
<wpwrak>
it produced graphical diffs between revisions of sheets, with changes indicated by drawing deleted things in red, added things in green, and a yellow background around areas with changes
<DocScrutinizer05>
why would you want to see *where* changes happened, instead of reviewing the result?
<wpwrak>
all this along the revision history from git
<wpwrak>
yes, you can also see what has changed and/or the result
<DocScrutinizer05>
that's how it was implemented/accomplished, not how it was used
<wpwrak>
it also had links to the respective sheers
<wpwrak>
sheeTs
<DocScrutinizer05>
well, maybe it's sometimes useful, but honestly I don't think it's highly mandatory
<DocScrutinizer05>
I wouldn't know when I last time been interested in the *differences* between schematics more than in the review of the most recent version. This would only help for reviewing pretty minimal changes, while assuming the previous version was OK
<wpwrak>
that assumes that you do a full and very detailed review after every commit. then you'd be certain that everything is perfect. but in reality, you have lots of commits you just take in good faith. and if you, much later, detect that something is amiss, you'll want to find out what happened
<wpwrak>
sure, it can be an isolated slip. but then, there may be more
<wpwrak>
and of course, if more than one person is involved, the question of "what happened there ?" pops up even more often
<DocScrutinizer05>
I simply don't see the suggested workflow
<wpwrak>
well, basically just how you use textual diffs with code. only that text isn't a "natural" format in this case
<wpwrak>
at least not for humans
<DocScrutinizer05>
I hardly ever use textual diffs in sw development either
<DocScrutinizer05>
they are only used for peer review, if anything
<wpwrak>
you do things in strange ways ;-)
<DocScrutinizer05>
as I already said, those diffs might be useful in certain rare situations, but they are not a mandatory or particularly useful feature for the normal development workflow as I see it
<DocScrutinizer05>
this might be different when you do checkin every 5 minutes, after editing 2 wires
<DocScrutinizer05>
but even then, who would browse through all the diffs instead rather looking at the result. I think it is prone to shift focus away from what's relevant towrds a mere 'technical' review of changes without considering the semantics
<DocScrutinizer05>
IOW for me it's completely sufficient to know the sheet that seen edits, and this gets excellently supported by kicad's project file structrue already
<wpwrak>
yes, but sometimes kicad makes changes that don't affect the visible part
<DocScrutinizer05>
the rest is window flipping rather than creating a pixel diff. My eyes are better at diffing than imagemagic ;-)
<wpwrak>
or that - so far - are completely mysterious
<wpwrak>
so you know that the sheet has changed, but you don't know how, or whether this is actually something that matters
<DocScrutinizer05>
then a graphical diff will fail completey - exactly my point
<wpwrak>
no, it will tell you if the change affects something that is relevant
<DocScrutinizer05>
???
<DocScrutinizer05>
I'm not metally on par today, sorry
<wpwrak>
of course, you can do a manual side-by-side comparison of the whole sheet
<wpwrak>
;-)
<DocScrutinizer05>
I'm out
<DocScrutinizer05>
yes, that is what I actually do when I'm interested in diffs, since then I also can zoom in and check properties etc
<DocScrutinizer05>
no pixel diff needed, not helpful
<DocScrutinizer05>
flip windows with same content (except the diffs), so called flickerbox
<wpwrak>
in kicad, hidden properties are rare. so you normally don't need to explore at that level. you can just look for visual differences.
<DocScrutinizer05>
*sigh*
<wpwrak>
yes, but you still have to do that for every sheet. every time you're looking for differences.
<DocScrutinizer05>
NO! I only need to do this for the sheet that changed
<wpwrak>
the "flickerbox" is nice (i actually had that, too, as a means for digging deeper when analyzing a change), but has its limits.
<DocScrutinizer05>
I'm NOT going to check all diffs of every commit you do
<EndZ>
simply use .tar.gz
<EndZ>
:D
<DocScrutinizer05>
this is a rarely ever needed feature in real life schematics development
<DocScrutinizer05>
you tell me "look at the microphones on sheet XY", I do and think "oh nice, looks much better now" - *maybe* I even have a peek at former version to recall how ugly it been. Am I interested in the changes in every single signal wire and symbol? no, not at all. Rather I give the new mic circuit a brief review to spot any possble oopses you introduced. I won't refer to the old schematics for that
<DocScrutinizer05>
if in doubt, I compare the **netlists* and get an instant proof that both schematics are functionally / semantically identical
<DocScrutinizer05>
so rather than generating diffs from gifs from pdfs, we rather should generate diffs from netlists
<DocScrutinizer05>
those would indeed accomplish a way higher value for verifying and change tracking
<DocScrutinizer05>
((...prone to shifting focus...)) I actually did exactly what I described above, and I checked that the two mics have the L/R select correctly different on both mics. I didn't check if this has been changed from old ugly to new nice schematics, so I had caught any error in this detail no matter if you introduced it or it been already there in old version.
<wpwrak>
but you don't know if something else has changed, too. accidents happen. so maybe a misguided click changed something not related to the microphone. you won't catch this because you only review the microphone.
<wpwrak>
so we're really talking about different contexts here
<DocScrutinizer05>
thus netlists
<wpwrak>
you're talking about changes where you already know exactly where to look
<DocScrutinizer05>
one sheet is a sufficiently small part of schematics to review completely
<wpwrak>
netlists are tricky :)
<DocScrutinizer05>
and netlists will go a long way for that
<wpwrak>
though i take your point that you'll want a filter that removes at least the worse "irrelevant" changes from netlists, then compares
<DocScrutinizer05>
honestly, nobody will review all your schematics checkins to make sure you didn't accidentally do a misplaced click. You need more confidence in your own work. :-)
<wpwrak>
you'll still encounter considerable "noise", because there internal identifiers that change often, and they also appear in the netlists. but in some cases, the netlists can indeed be useful.
<wpwrak>
(confidence) i confide in my humanity and my ability to err ;-)
<DocScrutinizer05>
when there's an issue with identifyiers changing at random, then we rather tackle and fix that
<wpwrak>
well, it's not that easy ... (see the discussions on #kicad)
<DocScrutinizer05>
sorry, I'm not really fit for serious discussions today
<wpwrak>
part of the solution seems to be a rewrite of internal data representation in eeschema
<DocScrutinizer05>
and afk
<wpwrak>
so that'll take a while. the good news is that getting rid of such things is on the radar.
<DocScrutinizer05>
I more thought along the line of a sematically educated diff tool that detects and handles such inadverted changes in a name
<DocScrutinizer05>
maybe show a diff line for first occurance of the new name in same semantic position as the old one, for all further occurences of the new name the diff tool knows it's a diff that already got handled (basically sed -i s/oldname/newname/g temp-olf-netlist
<DocScrutinizer05>
this will deal with such issue while not breaking when kicad gets fixed eventually
<wpwrak>
what happens is that power symbols get machine-generated component references. and whenever something changes in the set of power symbols, new references are generated. so this creates a lot of noise. and i wouldn't be surprised if the same reference was used for the same thing in different versions of the schematics.
<DocScrutinizer05>
*sigh*
<wpwrak>
add things changing places, and it gets messy
<DocScrutinizer05>
why do we need names on gnd symbols anyway
<wpwrak>
goood question :)
<DocScrutinizer05>
so simply don't diff them
<wpwrak>
i'm just telling you how it is. i think everyone agrees that these effects aren't nice.
<wpwrak>
i guess we might have a few of these. occasions when nik himself got lost amidst his gazillions of units, and ended up accidently creating a new part :)
<wpwrak>
i call it poetic justice ;)
chomwitt has joined #neo900
<DocScrutinizer05>
I (naively) decode that as our schematics having two WWAN components called 801 and 802 (sounds strangely familiar, originally we had a **801 modem, right?)
* DocScrutinizer05
searches half a minute on page0 for the WWAN/modem page ... :-/ ... >:-(
<DocScrutinizer05>
finally found it
<wpwrak>
(searching) sometimes it helps to grep *.sch :) not only does this tell you on which sheet to search, but it also tells you where else that critter may show up
<wpwrak>
sometimes, there are surprises :)
<DocScrutinizer05>
grep?
<wpwrak>
grep foo *.sch
<wpwrak>
or you can use "gg" to search just the files known to git
<DocScrutinizer05>
I just checked modem component on sheet6. Component annotation M601 (the other option aside of 801 iirc). 'Edit in component editor' makes me wonder where from any "Pin 1" might be
<DocScrutinizer05>
why would I look into the raw .sch files?
<DocScrutinizer05>
E, Ctrl+C,ESC,Ctrl+F,Ctrl-V, [Alt+F]...
<DocScrutinizer05>
is there anything like a generic kbd macro manager under XFCE?
<DocScrutinizer05>
but actually, we urgently want some versatile and convenient scripting support in eeschema, I wouldn't know how to determine the sheet ruler coords of a component, even when I spotted it by above mentioned key macro
<DocScrutinizer05>
wait...
<DocScrutinizer05>
hmm no, it seems `conventiently´ impossible to even find out about the XY coords of a label
<DocScrutinizer05>
this sucks big time, yeah
<DocScrutinizer05>
I want: a context menu entry "run macro" that runs arbitrary external executables, handing over all object properties as parameters and accepting the binary's STDOUT in the form of e.g. SETPROPERTY X=123; SETPROPERTY Y=234; REDRAW; KEY "Ctrl+C:Enter"
<DocScrutinizer05>
STERR goes to a popup notifier
<DocScrutinizer05>
the coords from .sch (grep -A1 "ANT-GNSS-DC" *.sch http://paste.opensuse.org/3663813) seems not really easily relatable to the eeschema editor coords
<DocScrutinizer05>
could we get a generic "comment escape char" into all eeschema strings? sth like ¡ or whatever, so we could use "ANT-GNSS-DC¡sheet6,A4" ?
<DocScrutinizer05>
and "ANT-GNSS-DC¡sheet8,C7", and the two would still match each other
<DocScrutinizer05>
could be mad useful for other purposes too
<DocScrutinizer05>
prolly needs only one patch of the helper-lib strcmp() function
_whitelogger has joined #neo900
Defiant has quit [Ping timeout: 240 seconds]
Defiant has joined #neo900
<atk>
heh
<atk>
Don't ever underestimate the potential complexity of implementing a simple feature.
<DocScrutinizer05>
I'm pretty much aware there might be funny unexpected side effects
jonsger1 has joined #neo900
jonsger1 has quit [Quit: jonsger1]
jonsger has quit [Quit: ZNC 1.7.x-git-615-5dd2093 - http://znc.in]
<DocScrutinizer05>
wpwrak: re offsheets, aiui you're pretty familar with the *.sch (format). Possibly a simple AWK script should be able to fix the little flaw with offsheet symbols not showing a (list of) destination coords
<DocScrutinizer05>
a dead simple grep -A1 "${offsheet_name}" *.sch already yields a lost of sheet/coord tupels where the symbol shows up
jonsger has joined #neo900
<DocScrutinizer05>
what's missing yet is a conversion from *.sch coords to 'real' coords and then maybe even to sheetframe ruler coords (A1 to G8)
<DocScrutinizer05>
then I'd suggest adding this list as a simple text next to the offsheet symbol, maybe even _grouping_ it with the offsheet symbol into one object
<ds2>
doesn't real coords happen only at printing?
<DocScrutinizer05>
I'd also be interested in a way to automatically create a netlist each time you save a schematics
<DocScrutinizer05>
btw Eagle has an automatism for offsheet referencing, but it's pretty braindead too in that the offsheet symbol arrow points right when the destination is at a higher_than_self sheet, and left when desination sheet number lower. No idea what it does with multiple offsheets in one network
<DocScrutinizer05>
for sure way more convenient to use 'find' (Ctrl+F) to jump to a page, than to search for the right dang rectangle with 3PT fontsize writing of sheet title on main sheet
<DocScrutinizer05>
F5 repeats last find
<DocScrutinizer05>
with correct settings in "find" dialog you could swiftly switch between 2 resp cycle through 3 or more pages with same "indexing label" - the above used "#01" .. "#38" are only one possibility. We concurrently could use other labels e.g. for the pages dealing with WWAN incl antennas, for NFC, you name it
<DocScrutinizer05>
Ctrl+F "find" search for an offsheet symbol name and cycle swiftly through all pages this offsheet symbol is used at, by simply pressing F5
<DocScrutinizer05>
downside: the newly displayed page is centered to the index-label you search for
<DocScrutinizer05>
again sucks: you can't search for any of the strings in A3 frame infobox
<DocScrutinizer05>
they only show up visibly on index page
<DocScrutinizer05>
s/visibly/find-able/
<wpwrak>
oh, if the small fonts bother you, just make them bigger
<wpwrak>
you can also put some free text into or near the boxes
<DocScrutinizer05>
sure, still sucks
<DocScrutinizer05>
I direct jump from page N to page M is way more useful, and particularly when that jump can get done by mere kbd input, without mouse acrobatics
<DocScrutinizer05>
s/I/A/
<wpwrak>
btw, one important decision still awaits: shall we continue with having everything in one design or should we split it into multiple designs ? e.g., UPPER, LOWER, BOB, BB-xM-bridge, or similar
<DocScrutinizer05>
multiple designs?
<wpwrak>
separate by PCB
<DocScrutinizer05>
we had that in eagle, sucks like hell
<wpwrak>
advantage: we don't need to split net names (e.g., GND of UPPER, GND of LOWER, VBUS of UPPER/LOWER, etc.)
<DocScrutinizer05>
finally even Nik thought it was more useful to merge them
<wpwrak>
disadvantage: a bit harder to move things around
<DocScrutinizer05>
no, nothing works with split designs
<wpwrak>
what would make that fail ?
<DocScrutinizer05>
you spead one circuit over to segregate projects
<DocScrutinizer05>
honestly, we had that and we were happy when finally we were able to merge
<wpwrak>
you'd still share libraries
<DocScrutinizer05>
no
<DocScrutinizer05>
irrelevant
<wpwrak>
just trying to understand what makes you feel so negative about it. that's unexpected.
<wpwrak>
hmm, so you want off-sheet symbols that cross boards ?
<DocScrutinizer05>
sure, I don't care if the signal crosses boards
<wpwrak>
i see. yes, that's an option
<wpwrak>
the current design tries to keep things apart, though. so that's a major renaming
<DocScrutinizer05>
no, that's evil heritage
<wpwrak>
still a major renaming to get rid of that heritage :)
<DocScrutinizer05>
it tries to avoid the workload that inevitably came with merger
<wpwrak>
now i'm confused. do you want to share nets or not ?
lkcl has joined #neo900
<DocScrutinizer05>
nobody tries to keep things apart, things were apart
<DocScrutinizer05>
originally we had separate projects for UPPER and LOWER. When merging, Nik had to cope with net name collisions
<wpwrak>
and you want to merge them (i.e., to benefit from having it all in a single design) ? or let them stay apart (i.e., not benefit) ?
<DocScrutinizer05>
yes
<wpwrak>
yes, no or no, yes ? :)
<DocScrutinizer05>
yes
<wpwrak>
merge and keep apart ? :)
<DocScrutinizer05>
no
<wpwrak>
so nik merged, but chose to separate the net names, thus not benefiting from the merge. hmm ;)
<DocScrutinizer05>
I already said a few days ago that GND1, GND2 GND3 is a nonsensical fallout of the merger and should get sanitized since we have only one GND (maybe an additional analog GND but that's a different story)
<wpwrak>
okay, so you DO want to merge
<DocScrutinizer05>
*sigh* please read what I said. He didn't want to do the work that comes with merger
<wpwrak>
thus, no 1V8-UPPER and 1V8 (implicitly LOWER), or such things
<DocScrutinizer05>
no way
<DocScrutinizer05>
there's no reason for such stuff
jonsger has quit [Ping timeout: 264 seconds]
<wpwrak>
we need to go over all the signals anyway. i don't trust them much. way too many suspicious-looking things
<DocScrutinizer05>
it's as pointless as 1V8-LEFT and 1V8-SOUTH
<wpwrak>
so renaming them in the process shouldn't be a big deal
<wpwrak>
good :)
<DocScrutinizer05>
I guess Nik just added a UPPER suffix whenever there was a merger name collision
<wpwrak>
i wonder about "collision" in this context
<wpwrak>
ah, one issues is the number of layers in the boards
<DocScrutinizer05>
and honestly I'm more concerned about the cases wher the same signal didn't cause a collision since it been subtly differently named in the two split projects
<wpwrak>
if they'll be different, we'd have to "manually" ban some layers on some boards. easy to check for violations, though
<DocScrutinizer05>
that was the original reason for split
<DocScrutinizer05>
yes
<DocScrutinizer05>
that's the obvious solution: pretend LOWER was 8-layer and simply don't use 4 of them
<wpwrak>
and we should make sure things like track width, clearances, via sizes, etc., are compatible
<DocScrutinizer05>
then prior to production change the board specs
<wpwrak>
else things would get really messy
<DocScrutinizer05>
yes
<DocScrutinizer05>
I however guess track width, clearance etc are complely unrelated to number of layers
<wpwrak>
one big drawback is, however, that design variants will conflict (e.g., bb-xm bridge vs. UPPER with OMAP). not sure how to deal with that.
<DocScrutinizer05>
well, in eagle we would use exactly that: variants#
<wpwrak>
(unrelated) yes, but 8-layer may pick a generally more advanced process than 4/6 (?) layer
<DocScrutinizer05>
those didn't exist yet when project started
<DocScrutinizer05>
no, aiui the precision is per layer and totally unrelated to layer count
<wpwrak>
i don't know of a way to have variants of a design in kicad. no #ifdef.
<DocScrutinizer05>
IOW each multilayer PCB consists of 2layer PCB plus prepreg
<DocScrutinizer05>
well, we don't have variants in eagle either (at least not used that feature)
<DocScrutinizer05>
with git it seems safe enough to rely on means outside of kicad to handle variants
<DocScrutinizer05>
after all we won't build another proto_v2 when we already make changes meant for proto_v3
<DocScrutinizer05>
so there are no concurrent branches of design anyway
<wpwrak>
mmh. you could have parallel branches. but that's a bit messy, since you have to constantly move things from one to the other. plus, you need to be VERY careful to never get anything not related to the other branch in a commit that's supposed to be shared. given that kicad likes to sometimes "save everything", that's a difficult requirement.
<DocScrutinizer05>
I hope we can sustain this
<DocScrutinizer05>
doesn't apply since: see above, There never are parallel branches
<wpwrak>
so you want to skip v2 ?
<wpwrak>
(and bb-xm)
<DocScrutinizer05>
I really don't know why I'm not able to make my point today
<wpwrak>
;-)
<DocScrutinizer05>
I don't even get how you come to ask this
<wpwrak>
well, you proposed that a few days ago
<DocScrutinizer05>
did I say anything that sounded like I would plan to
<wpwrak>
yes
<DocScrutinizer05>
no
<wpwrak>
you proposed to integrate omap & co. already in our coming prototype
<DocScrutinizer05>
no
<DocScrutinizer05>
I never used the term 2integrate"
<wpwrak>
yesm you probaby used a different word
<wpwrak>
but you proposed that the prototype would already include omap & co.
<DocScrutinizer05>
I pondered to build the BB-xM on our UPPER instead of buying them and attaching them via cable. That's not integration, neither tiurns it a proto_v2 into proto_v3
<DocScrutinizer05>
proto_v3 would not use an infinitely large UPPER
<DocScrutinizer05>
proto_v3 would use 1GB RAM and all the other stuff we need to add for core
<DocScrutinizer05>
proto_v3 has eMMC
<DocScrutinizer05>
I didn't suggest or ponder any of that
<wpwrak>
Jul 18 14:29:04 <DocScrutinizer05> maybe we're better off already throwing a DM3730 and a TPS65950 on proto_v2
<wpwrak>
the rest sounds like relatively minor details
<DocScrutinizer05>
see?
<wpwrak>
and if you're already doing the full design, why not try to make it the real size ?
<DocScrutinizer05>
I'm not willing to follow from >>already throwing a DM3730 and a TPS65950 on proto_v2<< to >>so you want to skip v2 ?<<
paulk-collins has quit [Quit: Leaving]
<wpwrak>
okay, "skip v3" then, if that sounds better ;-)
<wpwrak>
"optimize v3 away"
<DocScrutinizer05>
this is a pointless discussion
<DocScrutinizer05>
it lead nowhere
<wpwrak>
so it seems
<DocScrutinizer05>
I'll rename them to the 4 evangelists if you like
<wpwrak>
well, let's see if there'll be hope for convergence tomorrow then
<DocScrutinizer05>
we're about to build proto_v2 and I pondered if a lazy addition of OMAP and some sort of power supply would be easier than the BB-xM stuff
<DocScrutinizer05>
no skipping of anything since we are the ones to deine what happens, so nithing could possibly get skipped. We possibly redefine a few parameters
<DocScrutinizer05>
s/deine/define/
<DocScrutinizer05>
and I don't see how that's relevant for parallel branches
<DocScrutinizer05>
re "why not do it right?" - simply beacuse we couldn't keep the alternative connectors to nevertheless unsolder the onboard OMAP and connect a BB-xM. And because layout in final formfactor takes quite a few weeks
<wpwrak>
the issue with parallel branches is that they are needed if we want to concurrently have multiple variants. e.g., with just bb-xm vs. with omap et al.
<wpwrak>
and it seems likely that parallel branches would be disastrous if the design isn't split. so these things are all connected.
<DocScrutinizer05>
we won't
<DocScrutinizer05>
see above, I said that 3 times now
<wpwrak>
if we have one variant at a time, and discard it (we can still keep a copy, of course) when moving to a different variant, then that works