#milkymist IRC log for Wednesday, 2012-04-11

cladamwgood morning :)00:40
cladamwwpwrak, nice mockup !00:40
cladamwwolfspraul, do you like that idea ?00:41
wolfspraulwell I still don't get it, frankly00:41
wolfspraulwhich type of header is on the m1 pcb ?00:42
cladamw(J24) currently it's a 2*5 male header with one key. so from mockup shows that need a very small pcb with one female (2*5 receptacle header) and one USB-A receptacle mounted.00:45
wolfspraulwhy do we need that?00:46
cladamwJ24 is on M1r4 for original internal usb ports E/F00:46
wolfspraulI don't even understand what is being discussed and why :-)00:46
wolfspraulthe 2 internal USB headers are *internal*, we said we want the keyed 2*5 male header00:46
cladamwdo you mean why we needed internal usb ports header ?00:47
cladamwyes, we discussed for a 2*5 male header with one pin keyed. so ?00:48
wolfsprauland that's it, no?00:49
wolfspraulwe are trying to think ahead where to position that header?00:49
wolfspraulyeah so?00:49
wolfspraulI don't know00:49
wolfspraulwhat is being discussed now?00:49
cladamwreferenced to J24 which is placed curretly right of DMX TX con. : http://downloads.qi-hardware.com/hardware/milkymist_one/pcb/r4/041012/MILKYMISTONE.pdf00:51
cladamwthere's with limited space to even plug into 2*5 header if we still have a plan with an extendable usb cable. so 1) hard to plug in 2) don't know how exactly mechanical requirements(space, e.g. a real cable spec.) to plug00:55
cladamwso i spoke up to Werner that where we should place J24.00:55
cladamwthen seems yes that we haven't worked out /or found a real usb cable, so J24's problem raised up.00:57
wolfspraulI just don't think there is a problem in the first place00:57
wolfspraulit seems we are looking for some extra work to do00:57
wolfspraulan easy solution is to remove the 2 internal usb00:57
wolfspraulall other options are totally hypothetical00:58
wolfspraulwe don't like the position because we don't know what will be plugged into it !?00:58
wolfsprauljust think about that for a moment00:58
wolfspraulif we don't know what will be plugged into it, then... :-)00:58
wolfspraulwe can leave the header in that corner there, or if we don't like this just remove altogether and worry about it later00:59
wolfspraullemme look at werner's pics again00:59
wpwrakwolfspraul: why are you suddenly against that header ?01:01
wpwrakone use case we discussed was for an RF dongle. like the one used by the rii keyboard01:01
wolfspraulI'm not against it, I try to unwind the arguments01:02
wolfspraulit seems we jump from problem A to solution B to problem C to solution D01:02
wolfsprauland so on01:02
wpwrakwhen discussing how to connect things to this header, you brought up the easy to source cables01:02
wolfspraulthen we have this whole stack, but it's all hypothetical01:02
wolfspraulsure I am always looking around a little01:02
wolfspraulis this still the latest proposal? http://downloads.qi-hardware.com/people/werner/m1/tmp/iusb-doodle.png01:03
wolfspraulso you move the header behind the upper usb?01:03
wpwraktherefore, we didn't move forward on the remaining parameters of the interenal USB solution (mainly mechanical)01:03
wolfspraulthat looks good if it fits01:03
wolfspraulI just want to avoid that we go down in a spiral of reasoning away from real value01:03
wolfspraula very good example is "we don't like the position because we don't know what will be in there"01:03
wolfspraulso the problem is not the position01:04
wolfspraulthe problem is that we don't know what goes in there :-)01:04
wpwraknow, if we combine the use case with the state of the header, there's a mismatch: if we want to make use of it, and the rii dongle seems ideal, then we need to reach a conclusion about how to make the connection between header and dongle01:04
wolfspraulthat url from you, is that the latest proposal?01:04
wpwrak(latest proposal) yes01:04
wolfsprauland what is the problem with that idea?01:04
wpwrakit needs agreement :)01:05
wolfspraulmakes perfect sense to me, if it fits01:05
wolfspraulwell sure, what are the downsides compared to the one with header on the side?01:05
wpwrakvery good. we're making progress ;-)01:05
wolfspraulif none: take it :-)01:05
wolfspraulany known downsides?01:05
wpwrakit may make the layout folks sweat a little more01:05
wpwrakbut only a little :)01:05
wolfspraulbut not much, yes01:05
wolfspraulthere is space in the dmx area i believe01:05
wpwrakyou won't notice amidst the buckets of sweat DVI should cause them ;-)01:06
wolfspraulcladamw: when you compare solution A and solution B, what is *worse* in solution B?01:06
wolfspraulA is the one in your PDF01:06
wolfspraulB is the one in werner's drawing01:06
wolfspraulA = near the edge01:06
wolfspraulB = between external USB and dmx chips01:07
wpwrakpart two of the question: shall we plan to make such an adapter board to be available simultaneously with M1r4, e.g., included in the package, maybe even pre-installed ?01:07
wolfsprauladapter board?01:07
wolfspraulwe ship with a 2*5 male header, that's by far enough I think01:08
wpwraksince we don't have a cable :)01:08
wolfspraulit won't affect sales on tiny bit as far as I can tell, either way01:08
wpwrakbut you can't connect the rii dongle to the header01:08
wolfspraulthose are all just random 'for developer' features01:08
wpwrakit's more a "no parts sticking out" feature01:08
cladamwworse of A is the difficult scenario would be same as jtag/serial cable to plug, it's mechanical issue. for layout , actually A would be easy.01:08
wolfspraulno definitely not. the dongle is tiny and can easily be on the outside01:09
wolfspraulthe work to move it inside is so much, it just makes no sense *now*01:09
wpwrakit's just an adapter board away :)01:09
wpwrakbut okay, let's wait for the first complaints then ;-)01:10
cladamwworse of B is layout, seems (port e/f will cross together with else ports). Too close, I didn't against on this, since I leave this task to let house work out.01:10
wolfspraulcladamw: yes but I think the routing of option B is also not too difficult01:10
wolfspraulI mean just from the distance01:10
wolfspraulmaybe the dmx chips can be moved to the left a little01:10
wolfsprauland the fallback is to move the header to the edge (option A)01:11
wpwrakcladamw: we can also consider using an SMT variant of the header instead of through-hole. that would reduce the impact on routing01:11
wolfspraulbecause the whole reason of moving it still seems a little hypothetical01:11
wolfspraulbut then you could also argue for removing it, of course01:11
wolfsprauldifficult to design features with no known use case :-)01:11
wpwraksee above :)01:12
wpwraki'll definitely keep my RF dongle on the inside :)01:12
wpwrakthere's already way too much stuff poking out of M101:12
wolfspraulcladamw: so let's try werner's placement first01:13
wolfspraulsee what happens01:13
cladamwwolfspraul, WORNG, B's routes(ports e/f) will cross heavily to ports c/d. But i agreed that to change to a smd type connector, just need to find it.01:14
wolfspraulsorry that I was a little slow in understanding the issue01:15
wolfspraulso are we in consensus now?01:15
cladamwwolfspraul, wait a moment, let me chat with werner more. :-)01:16
cladamwwpwrak, since routes from fpga from here design files, i can see (e/f, J24) >> (c/d, J20) >> (a/b, J16), they(routes) will routed clockwisely.01:18
cladamwthis means even e/f set(two ports) goes bottom, c/d can go internal layer, a/b can go top layer when they reach closely to its connector.01:20
wpwrakwe can reorder the pins as long as the ones of M1rc3 end up on an external connector01:20
wpwrak(pins) FPGA pins01:21
cladamwi'm think to try precisely pick what type of connector to prevent such potential messy routes(cross).01:22
wpwrakif e/f goes to the bottom, that would suggest that we keep the through-hole connector ?01:22
wpwrakotherwise, they should be on top. at least near the connector01:22
cladamwlike combination: type of J24[smd, through] vs J20[smd, through], J16[smd, through]01:23
cladamwman! my brain is messy up, need a calm brain now. :)01:24
cladamwwpwrak, wait me for a while. i study a little.01:26
wpwrakseems difficult to find a keyed version of the SMT header01:34
wpwrakthrough-hole would of course also be better for mechanical reasons01:36
wpwrakah, and i think it would be okay to have J24 some distance away from the other USB connector. it doesn't have to be as close as i've shown in the doodle or the mockup. so there would be some room for routes01:37
cladamwwpwrak, http://downloads.qi-hardware.com/people/adam/m1/tmp/m1r4/m1r4_usbports_netin_case.png02:00
cladamwafter calm my brain, now, let's keep the current type through of usb connector, and through hole J24. haha.. :-)02:01
wpwraksounds good to me :)02:02
cladamwjust illustrate big rough route rule for house, then else let house to overcome.02:02
wpwrakyeah. shouldn't be too nasty. the parts on the bottom of the PCB can certainly be moved away, so there's room02:03
cladamwbtw, so all usb routes from fpga to usb transceiver will all goes internal layers to get strong ground shielding noise mask. :-)02:04
wpwrakheh :)02:06
cladamwalright, thanks all chats for solving this place problem and also came out a right-angle potential daughter board for RF dongle. ;-) Don't you ?02:06
cladamwwpwrak, okay. so i keep working. ping me once you have another discovery.02:08
wpwrakthe RF dongle should be very easy. i'm just undecided whether to make it SMT for reduced length or though-hole :)02:09
cladamwwpwrak, btw, could you draw your atusb dimension roughly so that I can let house to illustrate its suitable visible rectangle block once you decided. Even this is an option use case for m1r4.02:12
cladamwi meant liked you did for expansion's dimension.02:13
wpwrakis this good enough ? http://downloads.qi-hardware.com/people/werner/m1/tmp/atusb-ref.png02:22
cladamwnice, but no length of usb plug ?02:27
cladamwthe text of 37.6 mm and 17.3 mm you edited by KiCad or else tool ?02:29
wpwrakthat's kicad, yes02:30
cladamwi need to learn.02:31
wpwraki think it's all manually drawn :)02:33
wpwraki don't seem to have any drawing with the connector size :-(02:34
wpwrakthe overall length of my mockup, from antenna to the pins of the USB receptacle (!) is 61 mm02:36
wpwrakadd maybe 7 mm for the header. so that's ~68 mm total length of adapter board plus atusb02:37
cladamwno rush on exactly right length, later you can figure out how to draw.02:37
cladamwnice a rough ~68 mm is ref. :-)02:37
wpwrakbt let's not make too much out of this - atusb is just a random example02:38
wpwraki picked it because it's relatively large, larger than the usual USB dongles02:38
cladamwsince I just need centerize that J24's position, don't want to get surprise later once m1r4 assembled then your atben collides DMX-TX con. or else. :-)02:39
wpwrakkeep maybe 2 mm of clearance left and right02:41
wpwrakUSB dongles can be a bit wider than the header, but not much02:41
wpwraknow, if i could just find the rii rf dongle, i could tell you how wide that one is exactly ...02:42
wpwrakhmm. i'd say, as close to U15 as possible02:51
wpwrakpreferably without any components between J24 and U1502:52
wpwrakthen even the nastiest USB sticks i have should fit02:52
wpwrakin   http://downloads.qi-hardware.com/people/adam/m1/tmp/m1r4/m1r4_usbports_netin_case.png  that area looks clear, which is good02:54
wpwrakso just shift J24 a bit more to the south and it's perfect02:54
wpwrak"nice" dongles won't need all that much space. but some nasty big ones might. of course, the one i used for that measurement is some 15 years old, i think ;-)02:55
wpwrakcan't find my rii dongle :-( which of course just proves my point that such things are way too easy to lose ...02:56
cladamwyeah...i just noitced that J24 needs to close to south. And routes(A/B) may be changed on bottom, E/F goes through Top.02:56
cladamwwpwrak, no worries now, I have rii dongle and atben here. :-)02:56
cladamwyes, i said wrong, atusb.03:05
wpwrakeven better :)03:12
wolfspraulwpwrak: how is your flu btw? feeling better?03:16
wpwrakwolfspraul: today wasn't so bad. but it's not defeated yet.03:17
wolfspraulok, rest well03:17
wolfspraulit seems the kicad schematics is moving nicely03:17
wolfsprauleven though mostly adam charging ahead, but that's great03:17
wolfspraulthen bom, then maybe we try to copy over the layout right away too? just as an experiment? I have this urge to try kicad layout more :-)03:18
wolfspraulbut one by one... :-)03:18
wolfspraulmaybe we can at least import the gerbers, and start to grasp the layout problem a little03:19
wolfspraulthat way we can expose bugs or other realizations in kicad that may come hurt us later03:20
wpwraklayout need the footprints first. and yes, you can import gerbers .. but that's not much use because you still don't have the connectivity03:20
wolfspraulyes I understand03:20
wolfspraulbut we can start diving into that, as opposed to keeping this big black box03:21
wolfspraulbtw I was smiling the other day reading a book about IC manufacturing03:21
wolfspraulat the end they talked about packaging03:21
wolfsprauland at the very end (last 2 pages) they talked about "2nd level packaging"03:21
wolfspraulwith which they meant the entire pcb! :-)03:21
wolfspraulI like it when a problem suddenly shrinks conceptually03:21
wolfspraulthat whole board is just the 2nd-level packaging anyway03:22
wolfspraulthe case is the 3rd level packaging03:22
wolfspraulthe box the 4th level03:22
wolfsprauland the store it's sold in (not yet) the 5th level?03:22
wolfspraulthe cloud must be the 6th level then03:22
wolfspraulI was trying to understand something conceptually about the fpga04:58
wolfspraulso the basis of the fpga are lookup tables04:58
wolfspraulwhy can't the synthesis tool extend this concept say to the nor chip we have?04:59
wolfspraulwhy can't part of the truth tables be outsourced to nor, yet still be part of the digital machine that runs primarily in the fpga?04:59
wolfspraulsame for sdram04:59
wolfspraulis this primarily a limitation of the synthesis tools, or is there some reason nobody would want that anyway?05:00
scrtsinterconnect speed and latency05:43
wolfspraulbut conceptually one could design a machine that goes beyond the fpga chip and includes the nor or sdram?05:50
wolfspraulso the reason to not do that is speed, or lack of advantage for a design at hand?05:50
qi-botThe firmware build was successful, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-20120411-0642/06:28
GitHub114[scripts] xiangfu pushed 1 new commit to master: http://git.io/BgmOhA08:23
GitHub114[scripts/master] add compile-milkyminer-firmware.sh - Xiangfu Liu08:23
lekernelwolfspraul: this is called a CPU08:26
lekerneland it's slow08:27
qi-botThe firmware (using branch) build was successful, checkout the VERSIONS for detail, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-20120411-0828/08:55
GitHub6[board-m1] xiangfu pushed 1 new commit to master: https://github.com/milkymist/board-m1/commit/2a3f64abdd491bbe149f67c72f9340df364b1da809:30
GitHub6[board-m1/master] add Milkymist components - Xiangfu09:30
GitHub171[board-m1] xiangfu pushed 1 new commit to master: https://github.com/milkymist/board-m1/commit/7f80878d79f2eccfaf49f616c8760905e150dcee09:33
GitHub171[board-m1/master] add NORFlash components - Xiangfu09:33
GitHub177[board-m1] xiangfu force-pushed master from 7f80878 to 2f81c3e: https://github.com/milkymist/board-m1/commits/master09:34
GitHub177[board-m1/master] add NORFlash component - Xiangfu09:34
xiangfuwhen I add the NORFlash component. all .sch files changed.09:34
cladamwxiangfu, hehe ... :-)09:45
xiangfuI guess it should be ok. :)09:46
cladamwxiangfu, bravo ! Your first schematic editing. :-)09:48
GitHub156[board-m1] xiangfu pushed 1 new commit to master: https://github.com/milkymist/board-m1/commit/0581cff297b7945aae69abf9dec4ab9499eb7ae609:58
GitHub156[board-m1/master] NORFLAH: add FLASH bus - Xiangfu09:58
GitHub113[board-m1] xiangfu pushed 1 new commit to master: https://github.com/milkymist/board-m1/commit/c0513f06b1e0a8411a6d03c82f5954baa3a85b6110:09
GitHub113[board-m1/master] NORFLAH: add FLASH D bus - Xiangfu10:09
GitHub133[board-m1] xiangfu pushed 1 new commit to master: https://github.com/milkymist/board-m1/commit/36a8d6c1577448f0d359420ba85b1cfbbc4a0d0510:13
GitHub133[board-m1/master] NORFLASH: fix the label name, adjust the flash bus - Xiangfu10:13
GitHub28[board-m1] xiangfu pushed 1 new commit to master: https://github.com/milkymist/board-m1/commit/4d339a5ddf5221797d4ee9967a49e77fe0aea77010:27
GitHub28[board-m1/master] NORFLASH: add gobal labels - Xiangfu10:27
wolfspraullekernel: hmm, thanks! [cpu]10:38
wpwrakxiangfu: you can use "save current sheet only" to avoid updating all the other sheets10:44
wpwrakxiangfu: kicad has the annoying habit of keeping timestamps inside its files, and to update them all the time. so if you don't actively avoid this, you get lots of changes that aren't really changes.10:44
GitHub36[board-m1] xiangfu pushed 3 new commits to master: https://github.com/milkymist/board-m1/compare/4d339a5...5dd3e7f10:52
GitHub36[board-m1/master] NORFLASH: add local labels, there is no A8 under JS28F256J3F105 - Xiangfu10:52
GitHub36[board-m1/master] NORFLASH: update with correct JS28F256J3F105 - Xiangfu10:52
GitHub36[board-m1/master] NORFLASH: finish FLASH_D local labels - Xiangfu10:52
xiangfuwpwrak, yes. I just found that. but Ctrl + S is common. sometime just press that.10:54
xiangfuwpwrak, should be a shortcut for "save current sheet only" :)10:54
wpwrakyou can submit a patch. see if they like it :)10:55
wolfspraulbetter fix the file format10:57
GitHub167[board-m1] xiangfu pushed 1 new commit to master: https://github.com/milkymist/board-m1/commit/75880101063d59a402e1bc67e9d0b366b35d71ac10:58
GitHub167[board-m1/master] NORFLASH: more wires - Xiangfu10:58
wpwrakmay be hard to convince people to stop doing that timestamp nonsense. but yes, we can try ...11:01
wpwrakit may be one of those "we had to do this on the PDP-11 because the operators often forgot to set the time after resetting the system" things ...11:02
xiangfuwpwrak, very easy to get dizzy when I watch so much parallel  wires in KiCAD :-D11:03
wpwrakit takes some getting used to :)11:12
wolfspraulthat is hard to explain? urgh12:32
wolfspraulit breaks *any* concept and meaning of revision control systems12:32
wolfspraulas if they all had never heard of such an invention?12:32
wolfspraulit creates completely unnecessary merge conflicts in collaborative distributed teams12:33
wolfspraul'open source' anyone?12:33
wolfspraulwell, scarily you are probably right, so I won't try to explain it either :-)12:33
xiangfuwolfspraul, confuse. you mean the " kicad has the annoying habit of keeping timestamps inside its files" ?12:38
wolfspraulyes, just ranting :-)12:38
wolfspraulactually we should not get dragged into too many kicad bugs, just use the tool...12:38
wolfspraulI was just ranting because timestamps inside a file are such an obviously bad idea :-)12:41
wolfspraul(this kind of timestamp in this kind of file)12:41
wolfspraulbut just workaround, manually revert changes where only the timestamp has changed12:41
wolfspraulotherwise the revision history gets cluttered12:42
xiangfuI can do a 'rebase' now fox fix that.12:43
xiangfuthat needs git push -f.12:43
xiangfubetter start from now. use "save current sheet only"12:44
xiangfurebase is a little bit time consume. :(12:44
wolfspraulsure, what's in the history now doesn't matter, now you know this detail with the timestamps and going forward can find an easy solution12:46
Fallenoupush -f is evil12:46
Fallenoureally don't do this12:46
Fallenouunless you really don't care that someone who has already cloned your repository has to rm -rf and reclone again12:47
xiangfuFallenou, and dangerous12:47
xiangfuwhat is the different on 3.3V and 3V3. is that same?12:49
xiangfu +3.3V and 3V3.12:49
wolfspraulit means the same thing but that's one of the many details we are trying to standardize/document better12:50
wolfspraulthere probably should be a README or STYLE-GUIDELINE document or so in the schematics12:50
wolfspraulthen we can merge stuff like this into it, and remove from the wiki http://en.qi-hardware.com/wiki/Copyleft_Hardware_Style_Guide#Values_and_Units_in_Schematics12:50
xiangfusounds good12:54
GitHub41[board-m1] xiangfu pushed 1 new commit to master: https://github.com/milkymist/board-m1/commit/e5a760334eb1ca738f204f3b1b3868d68881403913:08
GitHub41[board-m1/master] NORFLASH: add GND and TP - Xiangfu13:08
GitHub96[board-m1] xiangfu pushed 1 new commit to master: https://github.com/milkymist/board-m1/commit/4e1622e533eb0f0290185040950f0fce69dc2d8f13:49
GitHub96[board-m1/master] NORFlash: finish NORFlash - Xiangfu13:49
GitHub197[board-m1] wpwrak pushed 1 new commit to master: https://github.com/milkymist/board-m1/commit/73949be6c94d86e8463cd4da25e4957fb0d9504614:06
GitHub197[board-m1/master] r4/m1.pro: added ../../kicad-libs/... to LibDir - Werner Almesberger14:06
lekernelhaha this one is even better http://2.bp.blogspot.com/-6vxlYXUf6ew/T3E5kRFJnfI/AAAAAAAAIig/O5R4pbdIjbM/s1600/image-768579.gif17:51
sh4rm4note the link at the bottom "web us at - milkmymist.in"18:34
lekernelwpwrak: we have the room for 28-30 december19:51
wpwrakwhee ! congratulations !19:57
wolfspraulSebastien will love this - the USB standards will be extended to support all sorts of power profiles up to 100W, at 5V, 12V or 20V - all negotiable between devices :-)22:56
wolfspraulone neat thing about a 'standard' is that the user knows "this will just work". "ah, it has USB, so I can use it over here..."22:57
wolfspraulbut with such a huge range of power profiles, lots of combinations won't work anymore if this standard really becomes widely used22:57
wpwrakit'll be a royal mess, with the corresponding pain levels22:58
wolfspraulgood thing that the general trend of low power is intact, so hopefully those power profiles won't become widely used22:58
wpwrakparticularly because the higher wattages also increase the voltage :)22:58
wolfspraulsure, total mess22:59
wolfsprauland like I said, you will have a situation where you first think you can plug device A into B, but then you realize "no, doesn't work"22:59
wolfsprauland there are so many combinations that it is essentially impossible to predict whether it will work or not unless you plug in and try22:59
wolfspraula host that can implement *all* power profiles is more like a smart power supply and switch than anything else23:00
wolfspraulso many device makers, say like m1, will give a damn about those X power profiles :-)23:00
wpwrakyeah, it'll get nasty once there are holes in the set. i.e., if it's not just profiles 0-5, but 0, 1, 4, 5+ :)23:02
--- Thu Apr 12 201200:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!