#milkymist IRC log for Tuesday, 2012-04-24

GitHub38[board-m1] xiangfu pushed 1 new commit to master: https://github.com/milkymist/board-m1/commit/8fb11bbcba0cc0de1ed109ccf24c80960c38397301:11
GitHub38[board-m1/master] remove m1-cache from project libs - Xiangfu01:11
cladamwwpwrak, i'm going to seperate FPGA.sch into FPGA_P1.sch and FPGA_P2.sch; Since J21 and J22 are directly pointed to U22[B..C], I'll gather them into one sch, the rest are go for the other sheet. is okay to you ?07:35
wpwrakyes, splitting is good :)07:46
cladamwwpwrak, okay. will know new 3494 have powerful cut or paste function or not soon. If no, then needs manually move from sch file. :-)07:50
wpwrakyes, there's cut and paste :)08:04
wpwrakyou can of course choose a more manual approach and give your mouse finger some endurance training ;-)08:05
cladamwwpwrak, ha ~ i mean cut components from this sheet then paste into other sheet. the answer is no. It's okay, i just moved already. :-)08:38
cladamwbut just got 6 warnings. i can upload _P1 and _P2 now. :)08:41
GitHub166[board-m1] adamwang pushed 1 new commit to master: https://github.com/milkymist/board-m1/commit/94898b57eb2fcc0261d71e8d556e86377f1c56f009:20
GitHub166[board-m1/master] split FPGA.sch(A2 size) into two A3 size: FPGA_P1.sch, FPGA_P2.sch - Adam Wang09:20
cladamwwpwrak, i mindlessly removed two files locally after typed 'git clean -xdf', i.e. before i committed. Poor adam. :( To do this split, i manually moved twice from FPGA.sch into new FPGA_P2.sch, and saved new FPGA_P1.sch, And edited both sheet individually. :)09:26
GitHub142[board-m1] adamwang pushed 1 new commit to master: https://github.com/milkymist/board-m1/commit/b0e64e78daca4c1b0251fd5829fbd02629991b1e09:44
GitHub142[board-m1/master] sheet numbers were changed by split, other sheets need to be commited all. - Adam Wang09:44
GitHub195[board-m1] adamwang pushed 1 new commit to master: https://github.com/milkymist/board-m1/commit/5c3e30e756c2cb9c962a60c1efa66a7d7bf3f49911:23
GitHub195[board-m1/master] this commit is to free warnings as: - Adam Wang11:23
cladamwwpwrak, just split and DRC without err, i described in commit to record what i met. It's interesting but may explain many surprising things in current KiCad's weakness. I didn't see into those texts changed in FPGA_P1.sch. But I guessed they are coordinate axis-oriented problems. All this is caused by that work from A2 to A3. I'm happy to know this condition.11:29
cladamwwpwrak, i.e. scaling up/down will cause trouble if there's manually copy & paste work existed there. so a normal editing 'rework' within eeschema may be needed. :-) But it's okay, there's not too much effort to fix warnings. :-) later I'll also ask xiangfu to confirm this commit to see if he gets the same 0 err. :-)11:34
wpwraklet's see ... :)12:50
wpwrakERC is happy here12:51
cladamwwpwrak, nice :-)12:51
wpwrakwhat does "DRAM_A [...] bus are too long" ?12:52
wpwrak .. mean ?12:52
wolfspraula while ago we had a (small) qucs simulation for a part of the reset circuit, right?12:53
cladamwwhen  i tried to scale A2 to A3. I manually copied all parts in FPGA.sch into FPGA_P[1..2].sch12:53
wolfspraulmaybe it's a good idea to commit that qucs file into the board-m1 repo?12:54
cladamwwpwrak, then manually deleted un-wanted parts and reduced the long wires on global wires with bus entry, wire. and saved as A3 size. but those coordinate axis are still accordingly to A2 i think. then ERC got warnings. I didn't figure out why even the editing of draws looks nice. But ERC will say 'unconnected'12:57
wpwrakwolfspraul: hmm, you mean wernermisc/m1rc3/rst/ ? not sure if this has much in common with what we have now. lemme check ...12:58
wpwrakcladamw: oh, i see. yes, that's a possibility. kicad is usually good at making sense of coordinates, but i never tried that kind of operation.12:59
wolfspraulah, there it is - yes, that's what I meant12:59
wolfsprauleven if it's only a small part of the circuit and outdated, it should be moved into the board-m1 repo imho12:59
wpwrakcladamw: or it was the mystery problem that creates those 8 ERC issues for me but vanished after i made a non-change12:59
wolfspraulmaybe later we can make more use of qucs, and it just belongs there more than in wernermisc/m1rc3/rst/13:00
wpwrakwolfspraul: i think it's worse than that - a path too horrible to take. but lemme check :)13:00
wpwraknaw, that's totally obsolete. that was about optimizing C238 with the old diode circuit13:03
cladamw(non-change) yeah. from eeschema you see they care visually connected perfectly but their coordinates probably not. I think KiCad currently can't handle too much switch auto scaling up/down in period while working sheets. Especially like we did  now. :)13:03
wpwrakwe got rid of that madness ;-)13:03
wolfspraulah ok13:03
cladamws/care/can be13:04
wpwrakagreed on keeping better track of the design process, though. irc and mailing list logs are better than nothing, but still difficult to process13:05
wpwrakthe ECN process we had in gta02-core wasn't too bad. perhaps a tad overly bureaucratic, though13:05
wpwrakcladamw: i found that you occasionally have to redraw things but i didn't pay much attention to it. i common trap in pcbnew is that you draw something that crosses s point to connect to but the trace doesn't explicitly end there. kicad then doesn't know that they do in fact connect.13:08
wpwrakcladamw: so what you do is make the first part, end the trace, and then the next part as a new trace. eeschema may have similar traps, particularly with buses13:09
cladamwwpwrak, yeah... i also noticed such things. but it's hard to fix my custom now since edited OrCad, AD, etc. they are not like that way I need to worry about. But in KiCad which is not smart enough and mature. :-O13:12
cladamwbtw,now the 3494's Library Editor is good enough to track/detect 'unconnected', but in eeschema which is not perfectly compared to traditional EDA. :-) Well... since now we got 0 ERC, so any commit later would be pay more attentions then make sure and git push. :-)13:15
cladamwmeanwhile I still need to know git work. still quite don't understand them. :)13:17
wpwrakhehe. git will remain a bit mysterious all your life :)13:17
wpwrakwith kicad, like with any other complex tool, a lot depends on the workflow. some of the things that appear to be bugs may even be intentional. after a while, you almost never hit unexpected problems - and you know how to deal with the expected ones.13:19
wpwrakthere are certain nuisances, but they're more in the area of GUI inefficiencies13:19
cladamwwpwrak, i'll soon send email to both lists, please comment it since I don't describe too much details. especially in future work on systemize components and category. :-)13:20
cladamwhmm...life in git with soul. :)13:25
wpwrakyou mean that git has its own mind ? yeah, sometimes it seems like that ;)13:26
wpwrakbut most of the time, you just have to know the right magic spell :)13:26
wpwrakthe good thing is that there are a lot of helpful discussions on the internet. whenever i need to do something unusual, be it deletion of a remote branch, a tricky merge, or such, google will find the answer.13:27
cladamwjust sent.13:30
cladamwoah...yeah...if time is enough to me. so i usually asked in irc for quickly get answer. i know it's not good. :)13:31
wpwrakhehe. irc works well while your questions aren't too exotic :)13:32
cladamwwpwrak, how we go for next steps ?13:33
cladamwbefore generating more modules(footprints) in KiCad or using your fped tool, I need back to AD work and ask house a while to know status a bit.13:34
wpwraki wouldn't go into footprints just yet13:35
wpwrakfirst clean up the schematics13:35
wpwrakparticularly the wrong label directions are extremely confusing13:35
cladamw(clean up) aha... sounds also great plan to make some rules that if you think them more. :-)13:35
wpwrakyeah, we'll also need rules for specifying values. i need to check if the rules you use are already consistent enough or if more is needed13:36
wpwrakwe should also have proper reviews of the whole thing13:36
cladamwwpwrak, oah...yeah...those direction I quickly checked ds and assigned them in KiCad. so may be more wrong assignments there. :-)13:37
cladamw(ECN) just saw backlog about "tad overly bureaucratic" :-)13:39
wpwrakyeah, i see that you already started to improve the labels. that's good.13:39
wpwraklooking at NOR_FLASH.sch, i can already see a bunch of other issues, though :)13:39
wpwrake.g., CE1 doesn't need a "connecting signals" circle13:39
wpwrakthe FLASH_Dxx labels are a tad disorderly. better move D0 through D14 out a bit such that they align with FLASH_D1513:40
cladamwabout the bus entry, yes, there's like local label there, and some are not there. :)13:40
wpwrakTP37 doesn't need a pin number. you can set pin information of a component invisible.13:41
wpwrakthe ground symbol of A0 is drawn over the text of FLASH_A013:41
cladamw(a bunch of) ... :-)13:42
wpwrakvalues ... we should follow the conventions of gta02-core. they worked pretty well.13:42
wpwrakso 4.7K becomes 4k713:42
wpwrakit's very very easy to overlook decimal points :)13:42
cladamw(gta02-core) they retrieved back already ?13:42
wpwrakah. good question13:44
cladamwyeah ... if there's a link from them. it would be nice to set rules to follow.13:44
wpwrakof course, it's more interesting if you have to follow policies that are kept secret from you. like secret laws. you can get arrested for breaking them, but you're not allowed to know what you did wrong. :)13:45
wpwraksvn.openmoko.org is still down13:46
wpwrakthe mailing list archives are up. yeah !13:46
wpwrakthe thread starts here: http://lists.openmoko.org/pipermail/gta02-core/2009-June/000174.html13:51
wpwraklemme find the conclusion ...13:51
cladamw(SI_writing_style) nice13:54
wpwrakhere is the conclusion: http://lists.openmoko.org/pipermail/gta02-core/2009-July/000184.html13:55
wpwrakyou can see the results here: http://people.openmoko.org/werner/gta02-core.html13:58
cladamwhmm ... nice dense discussions.13:58
wpwrakin later practice, i've strayed a bit from this and also included the units for caps and inductors. i still omit the unit from resistors, though.13:59
wpwrak(this is in part because i rarely have caps with a decimal point. or if i do, they're "special" anyway, for RF or such)14:01
wpwrakbut we can stick to either set of rules14:02
cladamwsure, rules better than no-rules. :-)14:03
wpwrakimportant: no capitalization of multipliers. e.g., no 10K. because that would open the milli vs. mega problem.14:03
wpwrakyeah. and boom will also be happier if it can figure out what those parameters mean :)14:03
wpwrakthat'll be the ultimate test anyway. anything human reviewers don't spot, the machine will mercilessly point out14:04
cladamwhow about those filename ? i used capitalization.14:04
cladamwi see s/w filename seems prefer to a lowercase letter ?14:05
cladamwbtw, i gotta off. night here.14:09
wpwrakfile names don't matter that much. yes, lower case is preferred, but it's not a big deal if you use capitalization14:11
cladamwwpwrak, i bookmarked those links you gave above. it's also good i think that you could mention them in reply mail. tks. cu. :-)14:11
wpwrakwhat's worse are special characters in file names14:11
wpwraksweet dreams, free from DRC errors ! :)14:11
cladamwhmm ... okay14:11
Hodappthis makes me want to do something with my EE degree besides write shitty C++ all day.14:23
wpwrakvery good ! :) and that's precisely the idea - making the design process open14:24
--- Wed Apr 25 201200:00

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