| kristianpaul | musl libc dont use autotools, afaik not a OS besides linux i'm aware could use it.. | 00:13 |
|---|---|---|
| cladamw | wpwrak, good morning ! Does MIDI KiCad connector numbering still confuse with you ? 3-5-2-4-1 numbering is okay to you ? | 01:05 |
| cladamw | wpwrak, does this http://en.wikipedia.org/wiki/DIN_connector#Analog_audio still have confusion to compare m1 ? | 01:07 |
| wpwrak | heya ! | 01:19 |
| wpwrak | no, now i understand the MIDI connector numbering. the data sheet confused me. | 01:20 |
| 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 :) | 01:23 |
| cladamw | wpwrak, so now is okay to you , right ? :-) | 01:32 |
| wpwrak | yes :) | 01:33 |
| cladamw | (C163+C244) thanks for got you. i typed wrong. | 01:33 |
| cladamw | to asymmetrical - in rc1, there's only three blocks of bypassing capacitors in schematics: C[157..C161], C[162..166] and C156. | 01:34 |
| cladamw | there's no special reasons for asymmetrical, i just recalled that why we got this results now : | 01:35 |
| wpwrak | so the 10 nF vs. 100 nF mixup is probably something that happened when they did the layout | 01:36 |
| 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. | 01:36 |
| wpwrak | and we'll probably never understand where the 1 uF comes from ;-)) | 01:36 |
| wpwrak | ah, good. then that's where this comes from | 01:37 |
| cladamw | the became this whole ASYMMETRICAL things and no one discovered until you. | 01:37 |
| wpwrak | there's a reason why i try to have very detailed and clean schematics :) | 01:37 |
| wpwrak | with the table that says what goes where, the layout will be properly defined | 01:38 |
| 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 | 01:38 |
| wpwrak | now, we should do the same for the FPGA ... | 01:38 |
| 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. | 01:39 |
| 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. :-) | 01:40 |
| wpwrak | NOR may also want explanations. there's 1 x 1 uF plus 3 x 100 nF. | 01:41 |
| cladamw | but where's that 1 uF to place ? | 01:42 |
| 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 ;-) | 01:42 |
| wpwrak | which 1 uF ? | 01:43 |
| cladamw | C156 ( 1 uF ) | 01:43 |
| wpwrak | ah yes, that's a very good question, isn't it ? ;-) | 01:44 |
| cladamw | you don't want to try to make this time symmetric ? | 01:44 |
| cladamw | since you just discovered it, i think it's good. | 01:45 |
| wpwrak | perhaps C245 should become 1 uF then. so that both pins 18 have the same bypassing. | 01:45 |
| 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") | 01:46 |
| wpwrak | on the other hand, what we have now is quite messy. so cleaning it up would be an improvement. | 01:46 |
| cladamw | sounds good but i am reading your points on "1 x 1 uF plus 3 x 100 nF" | 01:46 |
| cladamw | ("never change a working design") >>> :-) | 01:47 |
| 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 | 01:48 |
| 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. | 01:48 |
| wpwrak | well, only 70 caps. still pretty chaotic ;) | 01:49 |
| 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. | 01:50 |
| wpwrak | ("never change a working design") and the extended version: "never change a working design, no matter how wrong it is" :) | 01:51 |
| cladamw | so now, no need to change C245 to be 1uF as no matter how wrong it is ? | 01:53 |
| 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 | 01:53 |
| wpwrak | i'd leave the decision to wolfgang. i think i can predict sebastien's opinion already :) | 01:53 |
| cladamw | sure, so enhance this gap is like you pointed: table and mark respective pins which we didn't do it. | 01:55 |
| wpwrak | yes, what will close the gap. and it may lead to more interesting discoveries :) | 01:55 |
| wpwrak | sorry for digging out all those work-intensive issues :) | 01:57 |
| GitHub77 | [board-m1] adamwang pushed 1 new commit to master: https://github.com/milkymist/board-m1/commit/57069aa0ecb0ff39dc870cadfd00d2976c6dbaa0 | 01:58 |
| GitHub77 | [board-m1/master] Dram.sch: fixed wrong type texts on C163+C244 instead of C162+C244 - Adam Wang | 01:58 |
| 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. | 02:01 |
| wpwrak | good that you don't mind :) and yes, great to have that in the wiki | 02:03 |
| GitHub4 | [board-m1] adamwang pushed 1 new commit to master: https://github.com/milkymist/board-m1/commit/cc12d1ffc75261b93455e005045f20a25ece9b80 | 02:50 |
| GitHub4 | [board-m1/master] DVI-ISingle.sch: fixed cross-style junction between R[144..146] and GND. - Adam Wang | 02:50 |
| GitHub199 | [flickernoise] xiangfu pushed 1 new commit to master: http://git.io/VWjdZw | 05:11 |
| GitHub199 | [flickernoise/master] pdfreader.c: update head files path - Xiangfu | 05:11 |
| Action: lekernel is out to buy a reverse engineerable wacom tablet | 08:27 | |
| Fallenou | you want to replace usb mouse and keyboard with a touch-something ? :) | 08:29 |
| Fallenou | to get rid of usb ? | 08:29 |
| Fallenou | wait, wacom is usb afaik | 08:30 |
| roh | Fallenou: it its. and it needs a special pen. no finger-foo | 08:52 |
| Fallenou | I had a laptop with a wacom screen | 08:52 |
| roh | in short: its a capacitive sensor, and the pen is a resonator which you can detune (button(s)) | 08:53 |
| Fallenou | it was usable with both the pen and the finger | 08:53 |
| Fallenou | capacitive sensor works with finger as well | 08:53 |
| roh | then it wasnt purely a wacom tablet but also had another component, either resistive touch or similar stuff | 08:53 |
| Fallenou | I guess it depends on the signal processing | 08:53 |
| roh | Fallenou: finger sensing is working completely differen when looking at the effects afaik. also you have much less precision. | 08:54 |
| Fallenou | I am using a capacitive 7" touchscreen at the office, powered by an atmel chip (mxt224E) with my fingers | 08:54 |
| Fallenou | it can track up to 10 fingers and it works pretty nicely | 08:54 |
| roh | sure. but it doesnt have the precision of a wacom by far. | 08:54 |
| Fallenou | you must be right I don't know if mine is very precise | 08:55 |
| Fallenou | it's precise enough for clicking on GUI :) | 08:55 |
| roh | wacoms do tenth of a mm precise with pens. also they detect the angle of the pen you hold. | 08:55 |
| Fallenou | on something like an Android OS | 08:55 |
| roh | and pressure some can do too. | 08:55 |
| Fallenou | I guess it's bad for someone who wants to draw (artist and co) | 08:55 |
| roh | means: has nothing to do with boring touchscreens, either single or multitouch. | 08:55 |
| Fallenou | atmel capacitive detects the angle too | 08:56 |
| roh | Fallenou: they can do a lot. but all disable all nice feats as soon as you want fingers to work | 08:56 |
| roh | finger-useable screens are simply bad design. | 08:57 |
| Fallenou | but still, it's precise enough and good enough to click on a UI :) | 08:58 |
| Fallenou | like flickernoise for instance | 08:58 |
| 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. | 08:58 |
| roh | Fallenou: forget it. | 08:58 |
| roh | Fallenou: touchscreens are NOT timing precise. | 08:59 |
| Fallenou | I mean not the performance mode | 08:59 |
| roh | and driving another screen is out of the question with the mm1 hardware. it barely manages to drive one. | 08:59 |
| roh | Fallenou: osd on vga out needs to stop anyhow. its a major fail i get asked about every time someone looks at it. | 09:00 |
| 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. | 09:00 |
| Fallenou | you mean vga out should only output the performance mode and not the setting GUI ? | 09:01 |
| roh | yes. no ui ever on vga. or somehow locked that it may not happen by accident. | 09:01 |
| Fallenou | you're right, I think it's like this because it was the easiest way to start | 09:01 |
| roh | currently its simply not a professional tool., but a Consumer electronic toy. | 09:01 |
| roh | its on the software to change that it behaves like a professional tool. | 09:02 |
| roh | the hardware should be up to do both | 09:02 |
| Fallenou | I agree | 09:02 |
| roh | bbiab..need to fetch some breakfast | 09:03 |
| Fallenou | good fetch(and decode/execute/write back) | 09:03 |
| lekernel | roh: I think I had already explained a bit what my plans were. yes, it will have a second screen. | 09:08 |
| roh | lekernel: i see. nice. do we also get faster ram then? | 09:09 |
| lekernel | yes, we already have in fact | 09:09 |
| lekernel | all those problems are more because of lack of time than any fundamental technical limitation... | 09:10 |
| lekernel | get those people on board instead of just criticizing | 09:10 |
| roh | have them all covered. sounds good | 09:11 |
| roh | well... memory bandwith is a real limit. just asking to see if you | 09:11 |
| roh | meh. i lost a sentence | 09:11 |
| 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 | 10:09 |
| Fallenou | :) | 10:14 |
| Fallenou | how will you deal with patent issues ? | 10:14 |
| lekernel | just ignore | 10:16 |
| 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 | 10:16 |
| Fallenou | ok | 10:17 |
| lekernel | so... cheap FR2 PCB material, multiplexing with old school 4051/4053's, ASIC, and two yet unidentified chips | 10:55 |
| lekernel | 2100 B42 JRC, in 8-pin SMT | 10:55 |
| lekernel | op amps maybe? | 10:56 |
| lekernel | http://semicon.njr.co.jp/njr/hp/fileDownloadMedia.do?_mediaId=9833 looks like a good suspect... checking | 10:59 |
| cladamw | wpwrak, hi how do you think that when we can use your boom applied into m1r4 ? | 12:49 |
| 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) | 12:53 |
| wpwrak | one thing that's important for boom are the footprints. i think they're not defined yet. | 12:54 |
| cladamw | hmm ? from footprints ? | 12:55 |
| cladamw | ah .... i recalled | 12:55 |
| 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. | 12:56 |
| cladamw | wpwrak, btw, these days I played around fped which is really powerfull | 12:56 |
| 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 | 12:57 |
| wpwrak | (fped) glad you like it :-) | 12:57 |
| 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 | 12:58 |
| 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. | 12:58 |
| 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 :) | 12:59 |
| cladamw | alright, f.g. I've seen the stdpass.fpd and dip.fpd, they are built very well and systematizely | 13:00 |
| wpwrak | (fped for mechanical) yes, good examples are here: http://projects.qi-hardware.com/index.php/p/wernermisc/source/tree/master/labsw/mech/ | 13:01 |
| wpwrak | and here: http://projects.qi-hardware.com/index.php/p/wernermisc/source/tree/master/m1/case/ | 13:01 |
| 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) | 13:02 |
| cladamw | yes, i viewed them today, which is super nice for me. so my questions are: | 13:04 |
| wpwrak | of course, you need a CNC mill to fully enjoy these mechanical designs :) | 13:04 |
| 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 ? | 13:07 |
| cladamw | 2. a geometric ratio of vector (raw data) combines said as n=1, s; | 13:09 |
| cladamw | a vector is likely you were trying to unfold pins arrays for examples ? i hope i can get whole back knowledge soon. | 13:11 |
| 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" | 13:11 |
| 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 | 13:13 |
| cladamw | i think i can build another footprint like http://www.fairchildsemi.com/ds/6N/6N138.pdf in these two days. when i played around your this fped which is much funny. | 13:14 |
| cladamw | yeah, really really fun tool.:-) | 13:15 |
| 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 :) | 13:16 |
| cladamw | the dip.fpd you established good parameters then combined that vector then magic drawn. | 13:16 |
| wpwrak | the "magic" is the important part, yes ;-) | 13:16 |
| cladamw | yeah...i run into much more corruption, and quited | 13:16 |
| cladamw | btw, are you always 'follow' datasheet's suggestions for body size ? or expand it a little ? | 13:17 |
| 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 | 13:20 |
| cladamw | so one *.fpd at best to include all series packages for pins are [2..20] , etc. ? | 13:21 |
| 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 :) | 13:21 |
| wpwrak | yes, that's the easiest approach. you can also vary more parameters, like i've done in qfn.fpd | 13:22 |
| wpwrak | there;s a bit of background information for qfn.fpd in http://projects.qi-hardware.com/index.php/p/kicad-libs/source/tree/master/modules/INFO | 13:23 |
| cladamw | so we don't need to set rules for naming those parameters, do you? | 13:25 |
| 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 :) | 13:27 |
| 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 ? | 13:27 |
| wpwrak | i often try to follow the parameter names vendors use | 13:27 |
| wpwrak | they only appear in fped | 13:27 |
| cladamw | yeah | 13:27 |
| cladamw | okay. | 13:27 |
| 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 | 13:28 |
| 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. | 13:29 |
| 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. | 13:30 |
| cladamw | yeah i see. so now i just knew that why this fped came out. :-) | 13:33 |
| cladamw | wpwrak, which version in your fped now ? rev 43928db ? | 13:35 |
| wpwrak | rev 5130707+ | 13:36 |
| wpwrak | oh, yours is newer than mine ;-) | 13:37 |
| wpwrak | ah no. they're the same. i just didn't rebuild after committing. | 13:37 |
| cladamw | the same, good. tks. | 13:39 |
| wpwrak | btw, revision numbers are not ordered - they're just the beginning of the git hash. for example, 5130707 would be older than 43928db | 13:39 |
| lekernel | Fallenou: the patent has expired by the way. http://www.freepatentsonline.com/4878553.pdf | 14:33 |
| 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... | 14:34 |
| lekernel | (2-layer == double-sided) | 14:35 |
| 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 | 14:36 |
| wpwrak | so .. no local visual feedback ? | 14:44 |
| lekernel | ? | 14:48 |
| lekernel | the screen I'm talking about here is a LCM for the local GUI | 14:49 |
| wpwrak | but you'd then have the whole screen assembly (with lots of metal) between surface and the PCB | 14:59 |
| lekernel | yeah, we need to find a way to ditch the metal | 15:02 |
| wpwrak | ;-) | 15:04 |
| lekernel | http://www.youtube.com/watch?v=xZgUZwtd_Rg | 15:05 |
| lekernel | it can definitely be done | 15:05 |
| lekernel | by the way - is Kicad scriptable? (to generate repetitive PCB patterns) | 15:05 |
| kristianpaul | geda is.. | 15:06 |
| wpwrak | (kicad) not yet. but if you can express this as a footprint, you can generate it with fped. fped is very good at doing repetitive things. | 15:12 |
| lekernel | hmm we'd need vias | 15:13 |
| lekernel | with stuff connected on both ends of course | 15:13 |
| wpwrak | (bongofish) so he put a wacom tablet behind an lcd - and it just worked ? (the narrative on that site is quite mandering) | 15:13 |
| lekernel | more or less... maybe removing the metal | 15:13 |
| lekernel | it doesn't work through my laptop LCD | 15:14 |
| wpwrak | maybe two footprints then, one for the top, the other for the bottom | 15:14 |
| lekernel | or do that part in geda? the sensor PCB is just the generated structure + multiplexers | 15:15 |
| lekernel | or without any PCB layout program even :) | 15:15 |
| lekernel | i'm sure there must be some appropriate python vector graphics lib... | 15:16 |
| wpwrak | you could just generate gerber directly | 15:17 |
| wpwrak | of course, that way DRC won't work | 15:17 |
| GitHub126 | [milkymist-ng] sbourdeauducq pushed 2 new commits to master: http://git.io/g5_xGA | 17:47 |
| GitHub126 | [milkymist-ng/master] Connect Ethernet IRQ - Sebastien Bourdeauducq | 17:47 |
| GitHub126 | [milkymist-ng/master] Add timer - Sebastien Bourdeauducq | 17:47 |
| GitHub101 | [milkymist-ng] sbourdeauducq pushed 1 new commit to master: http://git.io/agI-TQ | 17:53 |
| GitHub101 | [milkymist-ng/master] Common interrupt numbers - Sebastien Bourdeauducq | 17:53 |
| GitHub128 | [migen] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/migen/commit/9449bbea0a98a4037d9b84d2878e44a7cc728964 | 17:57 |
| GitHub128 | [migen/master] Add LICENSE file - Sebastien Bourdeauducq | 17:57 |
| GitHub57 | [milkymist-ng] sbourdeauducq pushed 1 new commit to master: http://git.io/unKFMg | 18:02 |
| GitHub57 | [milkymist-ng/master] libbase: unmask UART interrupt correctly - Sebastien Bourdeauducq | 18:02 |
| GitHub117 | [milkymist] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/milkymist/commit/889a57c9accdeb1ff3ffbba58e78086dab099a1d | 20:23 |
| GitHub117 | [milkymist/master] bios/boot: fix off by one error in SFL magic string - Sebastien Bourdeauducq | 20:23 |
| GitHub131 | [migen] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/migen/commit/493b181af1e3a3dd889b1923e9295d058cce4e45 | 20:56 |
| GitHub131 | [migen/master] bank/description: pad unaligned multi-word registers at the top - Sebastien Bourdeauducq | 20:56 |
| GitHub134 | [milkymist-ng] sbourdeauducq pushed 5 new commits to master: http://git.io/w_Gw_w | 20:58 |
| GitHub134 | [milkymist-ng/master] tools/mkmmimg: remove LZMA option - Sebastien Bourdeauducq | 20:58 |
| GitHub134 | [milkymist-ng/master] bios/ddrinit: use new padding scheme for address register - Sebastien Bourdeauducq | 20:58 |
| GitHub134 | [milkymist-ng/master] bios: timer support - Sebastien Bourdeauducq | 20:58 |
| Fallenou | things seem to accelerate over here :) | 21:02 |
| Action: Fallenou likes those numerous commits | 21:03 | |
| Fallenou | dtlb exception handling needs testing | 21:03 |
| Fallenou | let's write tests | 21:04 |
| --- Tue May 22 2012 | 00:00 | |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!