Topic for #milkymist is now Radical Tech Coalition :: Milkymist One, Migen, Milkymist SoC & Flickernoise :: Logs: http://en.qi-hardware.com/mmlogs
<wolfspraul>
6 precious samples, at that time seriously precious
<wolfspraul>
and then the grinding-down started, and one by one we lost them due to exposure to unqualified processes, people
<wolfspraul>
no point
<wpwrak>
well, we contributed a few lines back into mainline linux. at least they got a small token of appreciation ;-)
<wpwrak>
;-)))
<wolfspraul>
the first one or two of the 6 were roasted by a wrong temperature profile, I think
<wolfspraul>
and so the story continued
<wolfspraul>
nothing was gained for anybody
<wpwrak>
a tragic fate
<wpwrak>
but yes. "bleeding edge" on the component side isn't our game.
<wolfspraul>
yes
<wpwrak>
too expensive (since it's exclusive). too unreliable (due to bugs awaiting the early adopters). too unpredictable (for long-term support)
<wpwrak>
the bleeding edge is for those who have more (financial) muscle than brains :)
<wolfspraul>
we can prepare our files and processes for upgrades, then adopt chips when they become generally available, but then quickly
<wpwrak>
either because they can't innovate on anything else, or because they've painted themselves in a corner and absolutely need those few extra percent of performance to survive
<wpwrak>
exactly
<wolfspraul>
that seems to be better tailored towards our strengths
<wolfspraul>
I can easily imagine that that may overtake a competitor who focuses on the samples/chips first, and then figures out process and testing/qa
<wolfspraul>
I do want to be first with the most high-end stuff, just how...
<wolfspraul>
not so easy :-)
<wolfspraul>
I think testing is the key, quality testing. that's where time is sunk.
<wolfspraul>
process and testing/verification
<wpwrak>
we can beat them on other fronts. e.g., with an fpga, we could implement protocols or accelerators quickly
<wpwrak>
and we can continuously upgrade the existing product this way, if we want (and if it makes sense)
<wpwrak>
testing is a little weak on our end
<wolfspraul>
I think it's not bad on m1
<wolfspraul>
and in every round we made improvements
<wpwrak>
what i mean is continuous QA
<wolfspraul>
maybe some effort to document the flow better would be nice, though Adam may already have something in the wiki
<wpwrak>
boring as hell, of course ...
<wolfspraul>
you mean temperature cycles, for example?
<wolfspraul>
sure we are beginners in some areas
<wpwrak>
naw, feature/regression testing. also including software
<wolfspraul>
ah yes
<wpwrak>
temperature testing ... hmm. i could leave the air conditioning off. than my M1 would be roasted at ~40 C. that could get interesting ;-)
<wolfspraul>
interesting, I'm just reading that (in higher volume) you can buy fpgas from xilinx and lattice that were tested only to run your design, giving up reprogrammability
<wolfspraul>
discounts for such chips can be 50-80% of standard pricing
<wolfspraul>
(article is about some structured ASIC company, but it's mentioned inside)
<wolfspraul>
I can't wait until Milkymist technology matures to the point that we can move to more basic manufacturing like structured asic or asic, to make some really powerful product :-)
<wpwrak>
hmm. i kinda like the idea of being able to play with the logic. but maybe s/move/branch/
<wolfspraul>
for now, yes of course
<wpwrak>
then you can make an ultra-cheap non-upgradeable M1-classic :)
<wolfspraul>
but later on if our tech is really great (the free part), then the big and expensive fpga chip will be a drag
<wolfspraul>
not now
<wpwrak>
dunno. they can also be a feature.
<wolfspraul>
now, definitely
<wolfspraul>
of course it's a feature
cladamw [cladamw!~adamwang@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #milkymist
<wolfspraul>
cladamw: hi good morning!
<wolfspraul>
sorry I'm too tired again to chat about rc4 priorities thinking right now, let's move it until after my sleep
<cladamw>
wolfspraul, hi good morning
<cladamw>
okay
<wolfspraul>
however, I have been discussing with Werner already, so if Werner has time he can also tell you our joint thinking
<cladamw>
or later I back to see backlog
<wolfspraul>
no rush on any of this, I know you still have a lot of work
<wolfspraul>
well for something this important and specific, I rather have you read it 'live' and ask questions right away if something is not clear
<wpwrak>
yeah, let's wait until wolfgang is awake again
<cladamw>
okay...
<wpwrak>
the good news: there's nothing we haven't talked about yet :)
<wolfspraul>
sure, just priorities, so when there are conflicts it's easier to decide how to proceed
<wolfspraul>
k later then, n8
<cladamw>
n8
<wpwrak>
sweet dreams, untroubled by kicad's class hierarchy :)
xiangfu [xiangfu!~xiangfu@fidelio.qi-hardware.com] has joined #milkymist
cladamw [cladamw!~adamwang@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #milkymist
mumptai [mumptai!~calle@brmn-4d0ac2c1.pool.mediaWays.net] has joined #milkymist
<wolfspraul>
cladamw: alright, back
<wolfspraul>
rc4 priorities, let's get it on
<wolfspraul>
first of all after several discussions here on the channel, it's clear that nobody sees much value in DVI-I dual-link
<wolfspraul>
so let's forget about dual-link. let's focus on single-link and making that work well, and all the other things. but we don't want dual-link.
<wolfspraul>
that one is out
<wolfspraul>
but what is in?
<wolfspraul>
#1 reset-circuit, USB power switch
<wolfspraul>
#2 adv7181c
<wolfspraul>
#3 sourcing with boom, and probably it makes sense to combine schematics in kicad with that
<wolfspraul>
#4 dvi-i single-link
<wolfspraul>
#5 better expansion header system
<cladamw>
#5 ~ adding another same pins of J21 to make a "U"-shaped
<wolfspraul>
yes
<wolfspraul>
and also I still think removing J3 to make space and focus on what's important
<wolfspraul>
the positioning of the old and new (second) expansion headers is very important, as they function 'together' and we want to keep them like that as long as possible
<wolfspraul>
let's just talk *priorities* now
<wolfspraul>
#6 more USB, possibly make space by removing buttons
<wolfspraul>
#7 leds for ports
<wolfspraul>
that's it
<wolfspraul>
things like 'layout in kicad' are not really on the radar right now, just a technical possibility but nothing we feel should actually be done urgently/soon
<wolfspraul>
Werner and I roughly agree on the said priorities (#1-#7), I think for the most part Sebastien is in agreement as well
<cladamw>
for #3 is Werner to use KiCad to draw schematic first then generate *.lst file for boom?
<wolfspraul>
he was not so enthused yesterday about removing buttons to make space for USB connectors, but let's work on the higher priority ones first anyway
<wolfspraul>
we were hoping you would want some KiCad editing as well?
<wolfspraul>
you and Werner have to be smart about the boom+schematics collaboration
<wolfspraul>
I don't know
<wolfspraul>
the devil is in the details, as always
<wolfspraul>
let's first talk about the priorities though
<wolfspraul>
do you understand those 7 items?
<wolfspraul>
do you agree with the priorities?
Martoni [Martoni!~chatzilla@ip-167-165.evhr.net] has joined #milkymist
<cladamw>
understood items: #1, 2, 4, 5
<cladamw>
uncleared items: #3, 6, 7
<wolfspraul>
#5 needs some real thinking
<wolfspraul>
#7 is the new leds, it's already written up in the wiki
<wolfspraul>
but we feel it's relatively low priority, let's work on all the other stuff first
<wolfspraul>
but I think #7 should be clear, no?
<cladamw>
for me, priorities is actually not the problems. Problems on my site is to understand what parts to add in schematic.
<wolfspraul>
what is your current Altium workflow?
elldekaa [elldekaa!~hyviquel@abo-168-129-68.bdx.modulonet.fr] has joined #milkymist
<cladamw>
i all knew above ideas, so when drawing schematic, just put all needed parts in relevant schematic sheet.
<wolfspraul>
are you editing the Altium schematics yourself, then go to layout house which is updating the layout in those same files?
<wolfspraul>
or is the layout house doing both schematic & layout update?
<cladamw>
i edit schematic firstly then let house to import & placement
<wolfspraul>
in which software are you editing the schematic?
<cladamw>
Altium Designer
<cladamw>
No KiCad now
<wolfspraul>
sure
<cladamw>
the *.lst came from KiCad's schematic to achieve #3, but not now.
<wolfspraul>
ok, maybe we break the work into different streams
<cladamw>
but if you wanted rc4 to source from boom system then two seperate ways i have to work
<wolfspraul>
first we do the Altium path as before
<wolfspraul>
let's work on the Altium rc4 schematics
<cladamw>
exactly
<wolfspraul>
and review them as PDF etc. as before
<wolfspraul>
but we don't want to make schematic changes that then become impractical on the layout side
<wolfspraul>
true?
<wolfspraul>
how do we avoid that?
<cladamw>
false
<cladamw>
when we change schematic( adding, removing ) will _later_ directly import to PCB files(which needs libraries links, works, etc). Just don't need to modify PCB design files only.
<wolfspraul>
yes
<wolfspraul>
but we can make schematic changes and then later find out that things don't fit
<cladamw>
so we can just _review_ schematic sides once I done, then we let house to _placement_ to see if the place is good.
<cladamw>
if considering those placements are okay, then start to route.
<wolfspraul>
maybe nothing we can do but use common sense now, and then try in layout
<wolfspraul>
alright
<cladamw>
house is 'passive' group, they would only accepts schematics(parts changes) then get the money they want.
<wolfspraul>
sure
<wolfspraul>
so maybe you start on 1, 2, 4 first?
<wolfspraul>
and 5
<wolfspraul>
as of today, are they already entered and finalized in Altium?
<cladamw>
no, i'd like to know 3, 6, 7 at the same time.
<wolfspraul>
good
<wolfspraul>
:-)
<cladamw>
not yet.
<wolfspraul>
what is not clear about #7 ?
<wolfspraul>
the only thing not clear to me about it is whether we want it at all
<wolfspraul>
but I am not against it either and if Werner is excited about the leds and nobody sees a big problem, let's just do it
<wolfspraul>
Werner is planning some tests on what looks good
<wolfspraul>
cladamw: what is not clear about #7 ?
<cladamw>
so does #7 is meant that to add a led to each relative connector?
<cladamw>
total of 14 new leds proposed: 2*dmx, 2*midi, 3*video-in, power, 2*usb, ir, dvi-i, ethernet, memcard
<wolfspraul>
yes
<wolfspraul>
all green for now, same as the leds we already haev
<wolfspraul>
have
<cladamw>
wpwrak, so I just add 14 leds with 14 limited resistors in series for #7 ? and then _placement_ each led to close to connector when we're placementing. ?
<wolfspraul>
sounds about right to me ;-)
<wolfspraul>
as I said, Werner was planning some experiments to find out what looks good
<wolfspraul>
the leds are driven by Werner, he will give final input on this
<wolfspraul>
and if he doesn't, no leds :-)
<cladamw>
wpwrak, this means that I pulls out fpga's another un-used 14pins to connect.? I think that using all them as "Pull high resistors" is good then directly driving led.
<cladamw>
wolfspraul, no, we can still wait for wpwrak's experiments about luminance of leds. meanwhile I just add 14 leds and related pull up resistors.
<wolfspraul>
yes
<cladamw>
fo #6, do we now make final to use 1*2 usb connector plus one usb connector? or 2 * 2 usb connectors?
<wolfspraul>
no final yet
<wolfspraul>
we have to be very careful to pick a connector that is common, reasonable price, etc.
<cladamw>
To know if we really need to remove buttons depends on I need to draw all parts-in then cowork with house to know how many space we can get or remove.
cocoadaemon [cocoadaemon!~cocoadaem@2a01:e35:8a99:e90:20d:93ff:fe3b:868c] has joined #milkymist
<cladamw>
forget FIC.
<cladamw>
alright, for usb 2*2 connectors, I'd like molex since its four fixed pins is more stronger then FCI. :)
<wolfspraul>
yes but we need to find out whether the molex one maybe is 'only' usb 1.1 ?
<wolfspraul>
and what that means
<wolfspraul>
the field is empty there
<wolfspraul>
and the connector is strangely cheap
<cladamw>
yes, i saw it. don't know EDAC Inc. , but needs to know more.
<wolfspraul>
molex is good, just need to find out that 'empty field' story
<wolfspraul>
it's very cheap though, that is suspicious I think
<wolfspraul>
maybe usb 1.1 ? does that matter to us?
<wolfspraul>
or is this in fact irrelevant for that connector and if our chips could do it (which they don't today), one could also drive USB 2.0 high-speed over the molex connector? I don't know...
<cladamw>
from molex site, compared 48037 and 67298 series, there's no specific 'usb2.0' mentioned. :)
<wolfspraul>
yes
<wolfspraul>
cladamw: unless you can find a big problem with 67298, I think that one looks good
<wolfspraul>
and I think 2 of them
<wolfspraul>
2*2
<wolfspraul>
I definitely don't want two different USB connectors on m1
<cladamw>
yes, 67298, I'll take an eye on that part/drawing again.
<cladamw>
wolfspraul, alright, i think that later when I am done on schematic, then generate pdf file to review.
<cladamw>
wolfspraul, about #5, werner told me that before, so I'll direct add related un-used fpga pins to those two headers.
<wolfspraul>
hmm
<cladamw>
the U-shaped idea is definitely greatful.
elldekaa [elldekaa!~hyviquel@laptopy.irisa.fr] has joined #milkymist
<wolfspraul>
the current J21 needs to stay as it is, I think
<wolfspraul>
so we have backward compatibility with existing boards
<wolfspraul>
and the pins of the new one need to be chosen carefully, there are different types of pins (banks, voltages, etc)
<wolfspraul>
has that been clarified already?
<wolfspraul>
and then mechanically, we should choose the position of the two in such a way that it can really last for a while (=years)
<wolfspraul>
I also think we should completely remove J3, but before the result was to only DNP J3
<wolfspraul>
I think removing J3 will cause some work, but I think it should go.
<wolfspraul>
I just fail to see the value of J3.
<cladamw>
the original idea of J3 is to reserve the option for audio application, but now it seems no worthy.
<wolfspraul>
we already decided to DNP J3 in rc4
<wolfspraul>
that's the current decision
<wolfspraul>
but I still think we should go one step further and completely remove it
<wolfspraul>
especially if we implement the new 2-part U-shape expansion idea
<wolfspraul>
let's just cleanup that area and remove J3 then
<cladamw>
instead of implementing U-shaped, I think we need to remove completely J3.
<wolfspraul>
that's my opinion
<wolfspraul>
not 'instead'
<wolfspraul>
they are unrelated
<wolfspraul>
J3 'can' be removed
<wolfspraul>
I would do that first, and then add the second expansion header, the U-shape idea
<wolfspraul>
J3 and J21/expansion are unrelated, other than for space and cleanup reasons
<wolfspraul>
I think we should remove J3 and focus on J21 and the new J21+
<wolfspraul>
let's see what Werner says
<wolfspraul>
Sebastien preferred to keep J3 DNP, but not strongly I think. just because removing it creates work.
<wolfspraul>
I like cleanup work ;-0
<wolfspraul>
:-)
<cladamw>
to implement new J21+, a whole 18 wires to be added in J21+, so remove J3 is just indeed to get route space not clean up reasons.
<wolfspraul>
sure
<wolfspraul>
out with it :-)
<wolfspraul>
we already agreed on DNP'ing J3, so the next step of removing it should not be a big deal
<wolfspraul>
the main reason Sebastien favored DNP'ing was the removal workload
<wolfspraul>
cladamw: there may be a few twists in removing J3, don't know. maybe something we can do wrong?
<cladamw>
wolfspraul, twists?
<cladamw>
don't understand about twists.
<cladamw>
do you have rc3 board on hand now?
<wolfspraul>
yes
<wolfspraul>
with 'twists' I mean that Sebastien said removing J3 is work
<cladamw>
there's many DNPs parts at audo codec's right side: C25, C23, R26, C26, R27, C27, they are not needed in rc4, so the new J21+ will be at that place.
<wolfspraul>
so there may be a few pullups/pulldowns or whatever needed if we remove J3
<wolfspraul>
I guess
<wolfspraul>
it's not just "rip it out"
<wolfspraul>
the audio codec still has to work after removing J3 ;-)
<cladamw>
sure, in rc3, they are Useless already. ;-)
<wolfspraul>
i can just say that I support the removal of J3, even if it creates work - it feels like good work to me to free space
<cladamw>
yeah. :)
<cladamw>
even I think that IR receiver can be placed more close to fixed hole corner, so J21+ can be much close to board edge to get more daughter board's size.
<cladamw>
wolfspraul, one thing forgot to ask, the expansion header should be receptacle type not male header, ho do you think?
<wolfspraul>
cladamw: you mean both? or just the new one?
<wolfspraul>
most expansion headers seem to be male types
<wolfspraul>
but it's a good question
<wolfspraul>
we definitely want to keep the existing J21 as-is
<cladamw>
both, U-shaped would be a female/receptacle one for better?
<wolfspraul>
and to reduce the number of parts - can the new header be the same as J21 ?
<wolfspraul>
(the number of different parts)
<wolfspraul>
both definitely not
<wolfspraul>
because that would break compatibility with the current J21
<wolfspraul>
what's the advantage of a female type in your opinion?
<cladamw>
they must be the same to strengthen mechanical structure when a daughter board hooked up with U-shaped.
<wolfspraul>
cladamw: I'm looking at my board, and I don't understand how moving the IR helps
<wolfspraul>
but... if the IR can be moved into the corner more - great
<wolfspraul>
1) most expansion headers I remember are male
<wolfspraul>
i don't know why but that is what I remember
<wolfspraul>
you think female is better? why?
<wolfspraul>
2) the current J21 is male, and we need to keep compatibility. we should, I think.
<wolfspraul>
and I don't think we want to mix one male and one female
<cladamw>
sure, can't be one male and the other one is female, the J21 and J21+ can be liked WM4241-ND type.
<wolfspraul>
no
<wolfspraul>
cannot
<wolfspraul>
I think
<wolfspraul>
because that breaks compatibility with existing boards
<wolfspraul>
we should not do that, unless we have a VERY GOOD REASON
<wolfspraul>
which I don't see
<wpwrak>
whoa. catching up ...
<wolfspraul>
it doesn't matter that we have no existing users of expansion boards, keeping compatibility is a good exercise and necessary to kick this alive at some point
<wolfspraul>
wpwrak: good morning! :-)
<cladamw>
compatibility with existing boards?
<wolfspraul>
lots of chat :-)
<wolfspraul>
cladamw: yes
<cladamw>
no
<wolfspraul>
that means, if someone makes an expansion board in the future, it should be easy to make that in such a way that it can also fit into rc3 or rc2
<wolfspraul>
cladamw: now werner is back, give him a little time to catch up
<cladamw>
a header with conductive pins is worse than a receptacle one with holes to let user do application.
<cladamw>
sure sure.
<wolfspraul>
ok, so you say a closed connector is safer?
<cladamw>
see pictures carefully
<wolfspraul>
because one cannot accidentally short it?
<wolfspraul>
I just try to understand your argument, we are exchanging arguments here
<wolfspraul>
if we switch to female type, we break compatibility
<cladamw>
when user is doing somethings electrical experiments or exercises on U-shaped bridge.
<cladamw>
if using header like current J21 is worse than using a receptacle one like WM4241-ND.
<wolfspraul>
that's a serious setback for anybody who is ever willing to actually make an expansion board
<wolfspraul>
and if we say "nobody has one anyway", then maybe it will also stay like that and we are better off removing the whole thing :-) (just kidding, I try to make a point about the value of backward compatibility)
<cladamw>
http://www.smartprojects.it/ like this, the receptacle female socket is better than using male headers. :-)
<cladamw>
i don't think rc4 needs to let m1 to be backward compatibility at all.
<wpwrak>
(#5) we can then also fully specify the expansion system, e.g., pin assignment (without having to look at the M1 schematics), space between headers, guaranteed clear space for the pcb, distance to the sidewall and position there (also in case a connector/conduit is desired), electrical characteristics (minimum assured current and such, ...
<cladamw>
wpwrak, good points.
<wolfspraul>
breaking backward compatibility is a very risky move
<wolfspraul>
we have zero users of the expansion boards right now
<wolfspraul>
and very few m1 users
<wolfspraul>
but that is our breeding ground!
<wolfspraul>
if we break compatibility, it's like trampling over the small sees we have in place now
<wolfspraul>
do you think all that greatness allows us to kick rc2/rc3 owners in the butt?
<wpwrak>
(#7, leds) we still need to specify a number of things, such as color and placement. also, we need to see if the whole concept actually looks right. among all the items we have, this is the least clearly defined one.
<cladamw>
for far now, there's no one using J21, unless wener/christien paul / else? also the J21 can be moved to get more space.
<wolfspraul>
wait wait
<wolfspraul>
werner is right
<wolfspraul>
we need to specify something, and then people know those things won't change
<wolfspraul>
I wish we can keep those specs rc2/rc3 compatible
<wolfspraul>
but maybe not?
elldekaa [elldekaa!~hyviquel@adm02.insa-rennes.fr] has joined #milkymist
<cladamw>
with receptacle socket, user can easily insert through hole led directly into it to write codes for quick test/debugs, if using header which is not. :)
<wolfspraul>
yes I can see your point, let's see what Werner thinks
<wolfspraul>
I am just worried about compatibility
<wolfspraul>
is it possible to have some sort of female-female plug one can stick onto the current J21 to convert it to female?
<lekernel>
there are exactly zero expansion boards atm, so screw compatibility
<wolfspraul>
that's a sure way to guarantee that there will never be any
<wolfspraul>
then we can also remove it entirely :-)
<lekernel>
there are no expansion boards atm because the M1 popularity is abysmal, not because we broke compatibility or anything like that
<wolfspraul>
how is that related? we discuss rc4 now
<lekernel>
so if you have a good reason to break expansion board compability, just do it. it's always going to be better than the current situation.
<wolfspraul>
nah. I protect the community we have now. if you want to start from zero because you think that's what will achieve 'popularity', you can try...
<wolfspraul>
if someone makes an expansion board one day, they will want it to be usable by the community we have now, no matter how small
<wolfspraul>
that's how it can grow in fact
<wolfspraul>
cladamw: are you aware of female-female connectors one could plug into J21 to make it a receptable?
<wolfspraul>
might become a little high then :-)
<wolfspraul>
I will wait for Werner's wisdoms
<wpwrak>
(J3 removal) i could see a point in keeping an access open (= DNP header) for audio signals. e.g., AUX and HP. don't need to keep all of J3, though
<wolfspraul>
you mean just a few of the pads?
<wolfspraul>
which ones?
<wolfspraul>
lekernel: btw, good news. we just sold 4 m1 to the US! :-)
<cladamw>
wolfspraul, sure, there's female receptacles on daughter board can be inserted to J21 male one.
<wpwrak>
(DNP header) or DNP headers. doesn't have to be combined. and i'd pick whatever space is the most convenient. e.g., close to the codec
<wolfspraul>
don't understand
<wolfspraul>
yes, close to the codec. but do we need all the space for a 2*9 header?
<wolfspraul>
or much smaller/less pads?
<cladamw>
wolfspraul, but try to imagine one fact thing: an insertion work, if user put a dughter board with male pins to hook J21(receptacle) easy or a daughter board with female to hook J21(male) easy and not insert pins wrong. ;-)
<cladamw>
maybe Werner can give more info & idea. ;-)
<wpwrak>
(J21 m/f) interesting idea. male headers should be quite a bit cheaper than female headers. that's a consideration for making boards. i.e., if the expensive part is on the M1, then the cost of making boards drops. also, it's easier to get a fitting male header (they come in cut-off strips) than a fitting female header (you need to buy one of about the right size)
<cladamw>
wpwrak, good point but trying to think one fact thing: if Arduino putted theirs with male type at the begining, the wider broadcast application maybe not so fast. ;-)
<cladamw>
well, you got right points, cost problems. ;-)
<wpwrak>
lekernel: you really need to learn to be more self-centered and more arrogant ;-) "popularity is abysmal". bah. we like it. YOU like it. you should be perfectly happy with that. all the people who matter like it. all objectives achieved ;-) the rest are just stupid. it's their loss :)
<wpwrak>
(current J21 users) adam and me, i guess. but just for experimental / ad hoc wiring, no real boards.
<wpwrak>
(j3 remnants) AUX* and HP* perhaps. plus ground. so that would be 2 pieces 1x3 or one piece 1x5 1x6, or 2x3
cocoadaemon [cocoadaemon!~cocoadaem@2a01:e35:8a99:e90:211:24ff:fe20:c95] has joined #milkymist
<wpwrak>
cladamw: (J21 m/f) my cost argument goes in favour of equipping m1 with a female header :)
<cladamw>
wpwrak, ;-)
<cladamw>
wpwrak, so you prefer to downsize the pin numbers of J3 rather than DNP and remove?
<cladamw>
wpwrak, of course can be DNP J3 even rc4? is that your point?
<wpwrak>
(J3) downsize and DNP, maybe split, maybe move
<wpwrak>
so in case we want some board with audio or such, we could add connect to audio in or out with a 1x3 cable (after soldering a suitable header)
<cladamw>
wpwrak, got your points: so for examples: 2*3pins(downsize) ==> one CD L/R audio input, maybe the other is AUX L/R audio inputs if user still want.
<cladamw>
wolfspraul, did you get werner's J3 downsize idea?
<wpwrak>
i'd make it audio in (e.g., CD or AUX) and out (HP). that is, provided these things still work that way. i remember that there was some quirk, but i'm not exactly sure what it was. (HP missing ?)
<wpwrak>
afk for a few minutes
<wolfspraul>
back
<cladamw>
there's no HP out from wm9707
<wolfspraul>
lekernel: yesterday you mentioned a capacitive sensor button. do you have one in mind? url?
<cladamw>
wpwrak, so i think no need HP.
<wolfspraul>
I indeed would be very interested in something that can work through the acrylic, if it's robust/stable/cheap. one of my goals for rc4 is cost reduction...
<cladamw>
wpwrak, total three audio inputs(e.g., CD, AUX, Video) in rc3.
<wolfspraul>
downsize *and* dnp j3 -> great
<wolfspraul>
yes, please only cut down to relevant pins
<wolfspraul>
switch expansion headers to female -> I can accept that if Sebastien and Werner both have no problem with that or want it
<wolfspraul>
I will suck it up on the compatibility :-)
<wolfspraul>
and yes - wpwrak - I love m1, that's why i work on it every day. we stand here saying m1 and milkymist are technologies worth investing into, and more people will join for sure.
<wolfspraul>
cladamw: so go ahead, female
<wolfspraul>
maybe Werner can write up the specs of the expansion system? seems only Werner can do that, or nobody
<wolfspraul>
but from then on we *do* have to keep compatibility with that system
<cladamw>
wolfspraul, sure, I'll sum up or update this results here to known issue wiki pages.
<wolfspraul>
please cut down J3 as much as possible
<wolfspraul>
good idea
<wolfspraul>
and DNP
<cladamw>
yeah..let's DNP in rc4. ;-)
<wolfspraul>
*and* cut down to only the relevant pins
<cladamw>
yeah
<wolfspraul>
that's a great idea, I like it
<wolfspraul>
better than removing the whole J3
<cladamw>
yes
<whitequark>
what's DNP?
<cladamw>
whitequark, do not place the part. or do not mount but keep footprint in pcb
<whitequark>
(as per the capacitor buttons. I do not really know the issues which may arise in mass production, but these aren't hard to do with just an appropriately clocked atmega, some timing measurements, and a copper rectangle)
<wolfspraul>
scary, I definitely don't want to get into making such buttons myself now
<wolfspraul>
I want to buy them for 1 USD
<wolfspraul>
or if that's not possible - keep our current mechanical switches
rejon [rejon!~rejon@li382-141.members.linode.com] has joined #milkymist
<wpwrak>
i suspect that you won't be able to find a "cap button" part. there may be some integrated ones (with electronics), but $$$ ...
<wpwrak>
the mechanical button works quite well. all we need to solve is making the cap. clearly, a laser cutter is not the ideal tool for that.
<wolfspraul>
ok then not
<wolfspraul>
I try to cost-down rc4, not cost-up
<wpwrak>
but a cnc mill will do it with a a yawn :)
<wolfspraul>
so what have we decided on J3/J21 now
<wolfspraul>
J3: reduce to just the necessary pins (seems 3 or so?), *and* DNP, *and* move closer to codec
<wolfspraul>
are the pins final?
<wpwrak>
(j3) move wherever it's most convenient for us.
<wolfspraul>
yes, sure
<wolfspraul>
can we finalize the pins?
<wpwrak>
(pins) dunno which make sense. there are three groups: AUX, CD, "video". not sure how they differ internally
<wolfspraul>
yeah well
azonenberg [azonenberg!~azonenber@cpe-67-246-33-188.nycap.res.rr.com] has joined #milkymist
<wolfspraul>
why so many inputs? can there be outputs as well?
<wolfspraul>
I mean audio
<cladamw>
yes, the wm9707 equiped with those inputs plus two MICs, PCBEEP, PHONE, LINE-INs, LINE-OUT, MONO out, SPDIF out.
<cladamw>
the original J3 in before is to keep them. :-)
<wolfspraul>
none of which will ever be used, imho
<cladamw>
now no need. ;-)
<cladamw>
yeah..but who knows. Since also we don't have U-shaped great idea to broadcast to extra-application. :)
<wolfspraul>
wpwrak: so we have 2 ways - find out which pins make sense, or remove J3 entirely
<wpwrak>
i would keep some access
<wolfspraul>
now we just need to decide which, then we can do it
<cladamw>
i can imagine like Werner can do daughter board to access J3 & J21s to make great/or incredible cascade audio-in/out platform if he have time. ;-)
<cladamw>
wolfspraul, :-) sure decide now is hard though. ;-)
<wolfspraul>
if werner cannot decide, then I can decide
<cladamw>
hehe...:)
<wolfspraul>
indeed we are under no rush to decide now, actually
<wolfspraul>
but if the reality is that nobody cares enough about J3 to actually look into which pins it should have, then we are all better off removing it
<wolfspraul>
I mean this in a positive way. there are many more interesting, Milkymist-related things on the board we can and should focus on.
<wolfspraul>
cladamw: I think you have enough input on schematic changes already, things that are clear & decided today, correct?
<wolfspraul>
and on J3 and J21, we will get some clarity soon, I feel we are close
<cladamw>
wolfspraul, l'll start to work on sch side.
<wpwrak>
i was hoping that someone who already examined those chips would have an opinion. the codec seems to have a history, e.g., the evolution of that HP output. so i wonder what makes sense in the context of the full story.
<wolfspraul>
that's the thing. I don't think anybody cares :-)
<wolfspraul>
so we are going in circles just keeping that thing in because of all the 'greatness', but nobody is even motivated to look into the greatnes
<wolfspraul>
that's my feeling
<wolfspraul>
I certainly am not motivated.
<wolfspraul>
(to look into J3)
<wolfspraul>
I am only motivated to rip it out, unless the real owners step forward.
<wolfspraul>
however, we are close now. It's now DNP & cut down & move to convenient place.
<wolfspraul>
*almost*
<wolfspraul>
now we only need to find out 'cut down to what?', and then we are done
<wpwrak>
my minimum context pick would be to connect "AUX". that sounds nice and safe :)
<wolfspraul>
that's just 1 pin? or 2?
<wpwrak>
one problem i have is also that i don't quite understand that floating ground of the CD group. is it meant to decouple grounds, which may be a good idea. or is there more to it ?
<wpwrak>
all choices are 3 pins. left, right, ground.
<cladamw>
wpwrak, why you mentioned HP? Since rc2 equiped with LM4550B then we changed to wm9707 in rc3 to get better low noise but no HP more.
<cladamw>
(j3) AUX_R/AUX_L/AUDIO_GND, done. ;-)
<cladamw>
so 1*3 2.54mm footprint. :)
<cladamw>
Are we done in J3: 2.54mm footprint with 1x3 pins ?
<wpwrak>
yeah, 100 mil sounds good
<cladamw>
yeah...more popular.
wolfspraul [wolfspraul!~wolfsprau@p5B0ABD37.dip.t-dialin.net] has joined #milkymist
<wpwrak>
(HP) but the codec does seen to have an output. not sure what "line level" means
<wpwrak>
(HP output) so if that output does something useful, we should also make it available. can be on a separate connector
<cladamw>
you meant LNLVLOUT(L & R).
<wpwrak>
yup
<wolfspraul>
5 pins now?
<wolfspraul>
aux (3 in) + lnlvout (2, or 3?)
<wpwrak>
(5 pins) depends. if they're on the same connector, then 5 pins will do. if they're separate (AUX and LNLVL are on opposite sides of the chip), each gets its own ground pin.
<wolfspraul>
sure we can do two 1*3 pads
<wolfspraul>
DNP
<cladamw>
wpwrak, if keep LNLVLs, the rest parts of C23 to C27 and R26/R27 still keep?
<cladamw>
wpwrak, or you want to directly route wires only to 1*3 pins?
<cladamw>
(two 1*3pins) there're seperate.
xiangfu [xiangfu!~xiangfu@fidelio.qi-hardware.com] has joined #milkymist
<wpwrak>
annoying. the 9707 seems to be the only wolfson chip with "line level" outputs. and they're not usefully documented.
<wpwrak>
hmm. why would precision resistors be needed ?
<cladamw>
your question on this was also my question before, so I surfed a bit then recorded there. but copied from somewhere? I think that I forgot. ;-)
<wpwrak>
;-)
<wpwrak>
let's try to catch joerg this evening. he may understand what they mean
<cladamw>
wpwrak, at that time I didn't dig into. Since at that moments , just tried to collect all layout criteria from web.
<cladamw>
yeah...he maybe know the reasons. ;-)
cjdavis [cjdavis!~cjdavis@cpe-71-67-99-208.cinci.res.rr.com] has joined #milkymist
xiangfu [xiangfu!~xiangfu@fidelio.qi-hardware.com] has joined #milkymist
wpwrak [wpwrak!~werner@94-163-231-201.fibertel.com.ar] has joined #milkymist
azonenberg [azonenberg!~azonenber@cpe-67-246-33-188.nycap.res.rr.com] has joined #milkymist