<wpwrak>
no, now i understand the MIDI connector numbering. the data sheet confused me.
<wpwrak>
you'd think, when implementing a connector design that's so standard that the whole series is named after the standards series (DIN means German Industrial Norm/standard), they would have had the decency of preserving the numbering :)
Hawk777 has quit [Quit: Coyote finally caught me]
Hawk777 has joined #milkymist
<cladamw>
wpwrak, so now is okay to you , right ? :-)
<wpwrak>
yes :)
<cladamw>
(C163+C244) thanks for got you. i typed wrong.
<cladamw>
to asymmetrical - in rc1, there's only three blocks of bypassing capacitors in schematics: C[157..C161], C[162..166] and C156.
<cladamw>
there's no special reasons for asymmetrical, i just recalled that why we got this results now :
<wpwrak>
so the 10 nF vs. 100 nF mixup is probably something that happened when they did the layout
<cladamw>
in rc1, there's no bypass capacitor in U14.18. but seems there's a C156(1u F) existed in schematic, so now I discovered house out C156 to U14.18 only.
<wpwrak>
and we'll probably never understand where the 1 uF comes from ;-))
<wpwrak>
ah, good. then that's where this comes from
<cladamw>
the became this whole ASYMMETRICAL things and no one discovered until you.
<wpwrak>
there's a reason why i try to have very detailed and clean schematics :)
<wpwrak>
with the table that says what goes where, the layout will be properly defined
<cladamw>
so in later rc2, we all seems to directly add another two blocks in schematics: C[240..245] and C[248..252] to fullfill
<wpwrak>
now, we should do the same for the FPGA ...
<cladamw>
yeah ... so this really defintely confused you at all, and also there's no table on schematics to show how they are being placed to respective pins.
<cladamw>
so now, let's fix them to be symmetrical, i.e. to make capacitances are the same, is it okay to you ? and we see m1r4's results. :-)
<wpwrak>
NOR may also want explanations. there's 1 x 1 uF plus 3 x 100 nF.
<cladamw>
but where's that 1 uF to place ?
<wpwrak>
(make it symmetric) dunno. it seems to work at the moment, so i think we have no urgent need to clean this up. of course, if something breaks after making it symmetric, that would be VERY interesting ;-)
<wpwrak>
which 1 uF ?
<cladamw>
C156 ( 1 uF )
<wpwrak>
ah yes, that's a very good question, isn't it ? ;-)
<cladamw>
you don't want to try to make this time symmetric ?
<cladamw>
since you just discovered it, i think it's good.
<wpwrak>
perhaps C245 should become 1 uF then. so that both pins 18 have the same bypassing.
<wpwrak>
i'm neither strongly for nor against making it symmetric. i think it may not matter that much, since bypassing often has very large tolerances. and some people may be afraid of this causing trouble. ("never change a working design")
<wpwrak>
on the other hand, what we have now is quite messy. so cleaning it up would be an improvement.
<cladamw>
sounds good but i am reading your points on "1 x 1 uF plus 3 x 100 nF"
<cladamw>
("never change a working design") >>> :-)
<wpwrak>
(1 x 1uF ...) what i'm saying is that, if we have a group of bypass caps with different values, then there should be an explanation where they go
<wpwrak>
the nastiest bit in that regard is of course the FPGA. there you have something like 100 caps, with all sorts of values, and no indication where they should go.
<wpwrak>
well, only 70 caps. still pretty chaotic ;)
<wpwrak>
for the FPGA, i wouldn't make a table. that's too much work. but just put the pin number next to the cap.
<wpwrak>
("never change a working design") and the extended version: "never change a working design, no matter how wrong it is" :)
<cladamw>
so now, no need to change C245 to be 1uF as no matter how wrong it is ?
<wpwrak>
for me, the most interesting result from discovering and examining the U14/U15 asymmetry is not that there may be a problem with the DRAM, but that this shows that we have a gap in the information flow to layout
<wpwrak>
i'd leave the decision to wolfgang. i think i can predict sebastien's opinion already :)
<cladamw>
sure, so enhance this gap is like you pointed: table and mark respective pins which we didn't do it.
<wpwrak>
yes, what will close the gap. and it may lead to more interesting discoveries :)
<wpwrak>
sorry for digging out all those work-intensive issues :)
<GitHub77>
[board-m1/master] Dram.sch: fixed wrong type texts on C163+C244 instead of C162+C244 - Adam Wang
<cladamw>
wpwrak, don't say that words: I liked those diggings. to know such important bugs and I'll add this into wiki for schematic editing rules. It's very worthy to.
<wpwrak>
good that you don't mind :) and yes, great to have that in the wiki
<GitHub4>
[board-m1/master] DVI-ISingle.sch: fixed cross-style junction between R[144..146] and GND. - Adam Wang
pablojavier has joined #milkymist
rejon has quit [Ping timeout: 265 seconds]
rejon has joined #milkymist
pablojavier has quit [Quit: Leaving.]
rejon has quit [Ping timeout: 248 seconds]
rejon has joined #milkymist
ximian has quit [Ping timeout: 245 seconds]
sh[4]rm4 has joined #milkymist
sh4rm4 has quit [Ping timeout: 276 seconds]
ximian has joined #milkymist
cladamw has quit [Quit: Ex-Chat]
voidcoder has quit [Remote host closed the connection]
xiangfu has joined #milkymist
wolfspraul has quit [Ping timeout: 245 seconds]
rejon has quit [Ping timeout: 250 seconds]
Gurty` has joined #milkymist
wolfspraul has joined #milkymist
<GitHub199>
[flickernoise] xiangfu pushed 1 new commit to master: http://git.io/VWjdZw
<GitHub199>
[flickernoise/master] pdfreader.c: update head files path - Xiangfu
Gurty has quit [Ping timeout: 265 seconds]
pablojavier has joined #milkymist
pablojavier has left #milkymist [#milkymist]
cladamw has joined #milkymist
rejon has joined #milkymist
cladamw has quit [Ping timeout: 244 seconds]
rejon_ has joined #milkymist
rejon has quit [Ping timeout: 252 seconds]
mumptai has joined #milkymist
Jia has quit [Quit: Konversation terminated!]
cladamw has joined #milkymist
wolfspraul has quit [Ping timeout: 240 seconds]
Jia has joined #milkymist
wolfspraul has joined #milkymist
mumptai has quit [Ping timeout: 265 seconds]
xiangfu has quit [Ping timeout: 246 seconds]
xiangfu has joined #milkymist
xian9fu has joined #milkymist
xiangfu has quit [Ping timeout: 246 seconds]
xian9fu is now known as xiangfu
elldekaa has joined #milkymist
wolfspraul has quit [Ping timeout: 244 seconds]
rejon_ has quit [Ping timeout: 240 seconds]
rejon_ has joined #milkymist
lekernel_ is now known as lekernel
rejon_ has quit [Ping timeout: 245 seconds]
wolfspraul has joined #milkymist
* lekernel
is out to buy a reverse engineerable wacom tablet
<Fallenou>
you want to replace usb mouse and keyboard with a touch-something ? :)
<Fallenou>
to get rid of usb ?
<Fallenou>
wait, wacom is usb afaik
wolfspraul has quit [Ping timeout: 260 seconds]
wolfspraul has joined #milkymist
<roh>
Fallenou: it its. and it needs a special pen. no finger-foo
<Fallenou>
I had a laptop with a wacom screen
<roh>
in short: its a capacitive sensor, and the pen is a resonator which you can detune (button(s))
<Fallenou>
it was usable with both the pen and the finger
<Fallenou>
capacitive sensor works with finger as well
<roh>
then it wasnt purely a wacom tablet but also had another component, either resistive touch or similar stuff
<Fallenou>
I guess it depends on the signal processing
<roh>
Fallenou: finger sensing is working completely differen when looking at the effects afaik. also you have much less precision.
<Fallenou>
I am using a capacitive 7" touchscreen at the office, powered by an atmel chip (mxt224E) with my fingers
<Fallenou>
it can track up to 10 fingers and it works pretty nicely
<roh>
sure. but it doesnt have the precision of a wacom by far.
<Fallenou>
you must be right I don't know if mine is very precise
<Fallenou>
it's precise enough for clicking on GUI :)
<roh>
wacoms do tenth of a mm precise with pens. also they detect the angle of the pen you hold.
<Fallenou>
on something like an Android OS
<roh>
and pressure some can do too.
<Fallenou>
I guess it's bad for someone who wants to draw (artist and co)
<roh>
means: has nothing to do with boring touchscreens, either single or multitouch.
<Fallenou>
atmel capacitive detects the angle too
<roh>
Fallenou: they can do a lot. but all disable all nice feats as soon as you want fingers to work
<roh>
finger-useable screens are simply bad design.
<Fallenou>
but still, it's precise enough and good enough to click on a UI :)
<Fallenou>
like flickernoise for instance
<roh>
atleast i still have to see a single usecase where fingers get me any advantage to proper pointer devices as re have em already.
<roh>
Fallenou: forget it.
<roh>
Fallenou: touchscreens are NOT timing precise.
<Fallenou>
I mean not the performance mode
<roh>
and driving another screen is out of the question with the mm1 hardware. it barely manages to drive one.
<roh>
Fallenou: osd on vga out needs to stop anyhow. its a major fail i get asked about every time someone looks at it.
<roh>
vga out is PRESENTATION screen. putting a menu there is simply unprofessional and you need to be able to change stuff around while its running. so from my pov there is only a network interface left to use.
<Fallenou>
you mean vga out should only output the performance mode and not the setting GUI ?
<roh>
yes. no ui ever on vga. or somehow locked that it may not happen by accident.
<Fallenou>
you're right, I think it's like this because it was the easiest way to start
<roh>
currently its simply not a professional tool., but a Consumer electronic toy.
<roh>
its on the software to change that it behaves like a professional tool.
<roh>
the hardware should be up to do both
<Fallenou>
I agree
<roh>
bbiab..need to fetch some breakfast
<Fallenou>
good fetch(and decode/execute/write back)
<lekernel>
roh: I think I had already explained a bit what my plans were. yes, it will have a second screen.
<roh>
lekernel: i see. nice. do we also get faster ram then?
<lekernel>
yes, we already have in fact
<lekernel>
all those problems are more because of lack of time than any fundamental technical limitation...
<lekernel>
get those people on board instead of just criticizing
<roh>
have them all covered. sounds good
<roh>
well... memory bandwith is a real limit. just asking to see if you
<roh>
meh. i lost a sentence
rejon_ has joined #milkymist
rejon_ has quit [Ping timeout: 256 seconds]
kyak has joined #milkymist
kyak has joined #milkymist
rejon_ has joined #milkymist
voidcoder has joined #milkymist
Jia has quit [Quit: Konversation terminated!]
rejon_ has quit [Ping timeout: 265 seconds]
<lekernel>
Fallenou: who said I was going to keep the original electronics? what I want is assimilate their sensor technology to build an improved reactable interface
<Fallenou>
:)
<Fallenou>
how will you deal with patent issues ?
<lekernel>
just ignore
<lekernel>
or rather - one by one. if they go after us, this means we've come out of the closet, which is the #1 problem at the moment
<Fallenou>
ok
xiangfu has quit [Remote host closed the connection]
kyak has quit []
kyak has joined #milkymist
kyak has joined #milkymist
kyak has quit [Changing host]
cladamw has quit [Quit: Ex-Chat]
<lekernel>
so... cheap FR2 PCB material, multiplexing with old school 4051/4053's, ASIC, and two yet unidentified chips
<cladamw>
wpwrak, hi how do you think that when we can use your boom applied into m1r4 ?
<wpwrak>
cladamw: you would generate a BOM and then pass it through boom. boom is currently non-interactive, so all the information has to be in the schematics (plus a few support files)
<wpwrak>
one thing that's important for boom are the footprints. i think they're not defined yet.
<cladamw>
hmm ? from footprints ?
<cladamw>
ah .... i recalled
<wpwrak>
there are three places where you can set footprints: 1) in the component library (there, the setting acts as a suggestion - the "Footprint Filter"). 2) in the schematics, where it provides the default value for the specific component. 3) in cvpcb, where you make the final decision.
<cladamw>
wpwrak, btw, these days I played around fped which is really powerfull
<wpwrak>
if there's a default in the schematics and nothing contrary has been set, cvpcb will take that value. in any case, what has been set explicitly in cvpcb "wins". that is stored in the .cmp file
<wpwrak>
(fped) glad you like it :-)
<wpwrak>
(footprints) they're particularly important for resistors, capacitors, and such, since there's no other information that allows boom to select the right package
<cladamw>
(fped) i know now you ususally used it to generate mechanical frame which is what i wanted. I just don't know and not realized.
<wpwrak>
for capacitors, footprints also indirectly determine the voltage. so they're even more important there. (of course, in an ideal world, we would actually specify the voltage in the schematics :)
<cladamw>
alright, f.g. I've seen the stdpass.fpd and dip.fpd, they are built very well and systematizely
<wpwrak>
the firs is the front panel of labsw, the second are replacement panels (for two sides) for m1 (e.g., with the horizontal hole for the jtag usb cable)
elldekaa has quit [Ping timeout: 252 seconds]
<cladamw>
yes, i viewed them today, which is super nice for me. so my questions are:
<wpwrak>
of course, you need a CNC mill to fully enjoy these mechanical designs :)
<cladamw>
1. since fped's conceipts are objects and instances, how you determine that how vectors to be as "backbone" and depict the shape you want ?
<cladamw>
2. a geometric ratio of vector (raw data) combines said as n=1, s;
<cladamw>
a vector is likely you were trying to unfold pins arrays for examples ? i hope i can get whole back knowledge soon.
<wpwrak>
1) you have to choose a structure for the geometric design. there are usually many choices for how you do it. e.g., you could do everything with vectors that start at the origin and calculate all the coordinates, you could attach vectors to other vectors, and you could also do things in frames. there's no firm rule - you basically have to do what feels "natural"
<wpwrak>
2) in a vector, you can say n*100mil and then there will be an instance for each value of n. so with loop n = 1,5 you get an instanced with that length set to 100 mil, one with 200 mil, ..., 500 mil
<wpwrak>
one important thing with fped: there's still a bug somewhere that can cause some corruption (some vectors suddenly attach to the wrong place). i haven't figured out yet what's happening - it's doesn't occur very often and i've never been able to reproduce it. so please save often :)
<cladamw>
the dip.fpd you established good parameters then combined that vector then magic drawn.
<wpwrak>
the "magic" is the important part, yes ;-)
<cladamw>
yeah...i run into much more corruption, and quited
<cladamw>
btw, are you always 'follow' datasheet's suggestions for body size ? or expand it a little ?
<wpwrak>
depends a bit. i normally try to follow the data sheet. but if there is conflicting information or if i see that the part has difficulties, then i make changes
<cladamw>
so one *.fpd at best to include all series packages for pins are [2..20] , etc. ?
<wpwrak>
e.g., for stdpass.fpd, i combined information from several vendors. since they all have a different idea what the "correct" footprints should be like :)
<wpwrak>
yes, that's the easiest approach. you can also vary more parameters, like i've done in qfn.fpd
<cladamw>
so we don't need to set rules for naming those parameters, do you?
<wpwrak>
(multiple parameters) in qfn.fpd, when you click on zone_ratio_35 or paste_ratio_20 (on the left side, both in the root frame), you see the values for the current footprint. so you don't have to calculate them by hand :)
isa_ has joined #milkymist
<cladamw>
like "P, Ax, Ay, Bx, By, ... ", etc... Elements used for construction, such as vectors, only appear in fped. so no need to always to follow yours ?
<wpwrak>
i often try to follow the parameter names vendors use
<wpwrak>
they only appear in fped
<cladamw>
yeah
<cladamw>
okay.
<wpwrak>
of course, when you compare with the data sheet(s) that provide the original geometry, it helps if the names are the same or at least similar
isa_ has quit [Client Quit]
<wpwrak>
that's not always possible, though. e.g., if you use parameters from different vendors and they use different naming schemes. e.g., for qfn. there' my naming is mainly based on what NXP do.
<wpwrak>
regarding style, i try to avoid complicated formulas in vectors. so i do the calculation in a variable assignment and then just use that variable. this way, the formula is visible on the left side and not hidden in the vector.
<cladamw>
yeah i see. so now i just knew that why this fped came out. :-)
<cladamw>
wpwrak, which version in your fped now ? rev 43928db ?
<wpwrak>
rev 5130707+
<wpwrak>
oh, yours is newer than mine ;-)
<wpwrak>
ah no. they're the same. i just didn't rebuild after committing.
<cladamw>
the same, good. tks.
<wpwrak>
btw, revision numbers are not ordered - they're just the beginning of the git hash. for example, 5130707 would be older than 43928db
<lekernel>
wolfspraul: to answer your concern about the large PCB behind the screen, they do it with a 2-layer FR2 board. can't imagine this would be very expensive...
<lekernel>
(2-layer == double-sided)
<lekernel>
then we can easily put the multiplexers on the same board and connect it with 10-20 pins to the multilayer FR4 board with the FPGA etc. on it
kyak has quit [Ping timeout: 245 seconds]
<wpwrak>
so .. no local visual feedback ?
mumptai has joined #milkymist
<lekernel>
?
<lekernel>
the screen I'm talking about here is a LCM for the local GUI
<wpwrak>
but you'd then have the whole screen assembly (with lots of metal) between surface and the PCB
<lekernel>
yeah, we need to find a way to ditch the metal