2010-12-27 01:47 <qi-bot> [commit] Xiangfu Liu: gmenu2x files: add emacs icon http://qi-hw.com/p/openwrt-packages/c0002c5
2010-12-27 05:05 <kristianpaul> wolfspraul: do you know what the Jz4750L Ingenic board is, and what i have an FPGA ?
2010-12-27 05:06 <kristianpaul> i just discover it reading some lines from u-boot changelog
2010-12-27 05:11 <wolfspraul> kristianpaul: don't understand your question
2010-12-27 05:12 <wolfspraul> I think the 4750L is the low-cost (=cob) version of the 4750
2010-12-27 05:13 <kristianpaul> wolfspraul: i found this line in the U-boot source code
2010-12-27 05:13 <kristianpaul> 2009.05.14
2010-12-27 05:13 <kristianpaul> * Add Jz4750L platform: F4750L board(which is a FPGA board).
2010-12-27 05:14 <kristianpaul> and the FPGA word call my atention, no more :-)
2010-12-27 05:16 <wolfspraul> hmm
2010-12-27 05:16 <wolfspraul> I can only guess.
2010-12-27 05:16 <wolfspraul> so the 4750 is a 'normal' chip, very much like 4720/40 just with some improvements
2010-12-27 05:16 <wolfspraul> 'l' is the low-cost version
2010-12-27 05:17 <wolfspraul> now, inside the Ingenic office I regularly see _a lot_ of different boards
2010-12-27 05:17 <wolfspraul> they are building all kinds of small-volume prototype boards for development, for customers, with customer, by customers, etc.
2010-12-27 05:17 <wolfspraul> and I have seen fpgas in combination with Ingenic chips on some of those boards
2010-12-27 05:17 <wolfspraul> very much like SIE
2010-12-27 05:18 <kristianpaul> I see
2010-12-27 05:18 <wolfspraul> probably because Ingenic, and/or their customers, are prototyping or developing something
2010-12-27 05:18 <wolfspraul> the support for all these different boards in the u-boot, or Linux kernel, or other kernel sources is messy
2010-12-27 05:18 <wolfspraul> because a lot of these boards are only made in a few units, and are superseded by something else quickly, and/or the customer or Ingenic aborts the development, etc.
2010-12-27 05:19 <wolfspraul> so maybe that line is connected to such a board
2010-12-27 05:19 <wolfspraul> also notice that it says "F4750L"
2010-12-27 05:19 <wolfspraul> F = fpga?
2010-12-27 05:19 <kristianpaul> dont know
2010-12-27 05:19 <wolfspraul> but even then, you will most likely not find information about this board anywhere
2010-12-27 05:20 <wolfspraul> they make 10, for whatever reason, learn something from it or not, and move on
2010-12-27 05:20 <kristianpaul> yes i realized that before asking you :-)
2010-12-27 05:20 <kristianpaul> They move fast :-)
2010-12-27 05:20 <wolfspraul> oh sure
2010-12-27 05:20 <wolfspraul> lots of projects always going on
2010-12-27 05:20 <wolfspraul> everything fast. quickly started, quickly abandoned.
2010-12-27 05:22 <zrafa> wolfspraul: all: some guy was talking me several times because he uses jlime and he was very interested on the wikireader thing and other features... Few days ago he was explaining me that he, and his students (uni) are trying to write a nice GUI, very easy to use (imagine like just one search bar like goolge, or few buttons), to convert the nanonote as a device similar to this : http://www.literacybridge.org/talking-book/ .. But, because nn is a lot more
2010-12-27 05:23 <zrafa> wolfspraul: He already has around 30 nns!.. which is a really nice
2010-12-27 05:23 <zrafa> if he is really interested on to do that thing.
2010-12-27 05:23 <zrafa> I think that his idea is really nice as final target for a device like nn,
2010-12-27 05:24 <zrafa> so I am trying to tell him to join community (like this channel :) ) in order to do the whole idea working
2010-12-27 05:24 <kristianpaul> wow 30 sounds like a pilot coming?..
2010-12-27 05:24 <kristianpaul> s/pilot/small deployment
2010-12-27 05:26 <wolfspraul> zrafa: wow he has 30 nanonotes?
2010-12-27 05:27 <wolfspraul> sure it sounds good
2010-12-27 05:27 <wolfspraul> I think we will see lots of great apps next year...
2010-12-27 05:27 <kristianpaul> :D
2010-12-27 05:28 <wolfspraul> I am currently hacking up a little script that will let me download ogg music files from wikimedia commons :-)
2010-12-27 05:28 <kristianpaul> wow
2010-12-27 05:28 <zrafa> wolfspraul: yes, he told me that he and his students has around 30 nns. And maybe they would need more
2010-12-27 05:29 <zrafa> wolfspraul: downloader script : nice :) if you do I would add the GUI :)
2010-12-27 05:29 <wolfspraul> well they only have classical music there, but it's a start. I also saw the 'spoken wikipedia' project, which made me realize to look for audio books...
2010-12-27 05:30 <kristianpaul> wolfspraul:  audio books > a lot of then in the public domain at librivox.org
2010-12-27 05:32 <zrafa> wolfspraul: does your script would list on stdout the list of music files available?
2010-12-27 05:32 <kristianpaul> had you tught in Gutenberg proyect, i think their format is better to port on nanonote than wiki-* also wikireader startert to incorporate? (maybe people get tired of reading just wikis..)
2010-12-27 05:32 <kristianpaul> s/tught/tought
2010-12-27 05:34 <kristianpaul> "The software on the Talking Book is the heart of the device. Because it is a computer, we can work with our partners to customize the software to precisely fill their needs. "
2010-12-27 05:34 <kristianpaul> well i dint expected something better..
2010-12-27 05:36 <kristianpaul> zrafa: i guess they are using your wikipedia-gnudict plugin?
2010-12-27 05:43 <zrafa> kristianpaul: about talking book: just a note: he is not wanting to use that software if I understood him corretly. It is just a link to show the idea
2010-12-27 05:43 <kristianpaul> arggg i need a good ccc low bandwitch streaming link..
2010-12-27 05:44 <kristianpaul> zrafa: (link) sure it points the idea
2010-12-27 05:44 <zrafa> kristianpaul: I have no idea exactly which thing they use, but from what he told me he wants to understand how we did the wikireader, no to use it. And he is not going to do a wikireader either, they want to do a new thing easy to use
2010-12-27 05:45 <kristianpaul> sure
2010-12-27 05:45 <zrafa> so they would not use the current stuff. They want to understand how to play music, video; how to show graphics, pictures, how to do some engine of knowledge, things like that
2010-12-27 05:56 <Jay7> wikireader + festival :)
2010-12-27 05:59 <wolfspraul> zrafa: yes sure, browse categories and list files. 10 lines php :-)
2010-12-27 05:59 <wolfspraul> it's not finished yet, need to find a few hours so that it can download as well. I just want an easy way to download music to my nano.
2010-12-27 06:00 <wolfspraul> also for it to work on the NanoNote, the current script uses the HTTP_Request class which I doubt it installed right now.
2010-12-27 06:00 <wolfspraul> of course there are other ways like invoking wget, but I like to stay in php
2010-12-27 07:57 <kristianpaul> wpwrak: i finally discover the cpu is reading tos fast the ram-like-fpga-setup, so i'm implementing a delay in software.. to avoid repeated data
2010-12-27 07:59 <kristianpaul> s/tos/too
2010-12-27 08:04 <kristianpaul> hmm i dint work as i spected..
2010-12-27 08:05 <kristianpaul> I need an IRQ (glup!)
2010-12-27 09:36 <kristianpaul> I found a "IRQ" signal, but it is also LCD_D15 pin.. :/
2010-12-27 10:13 <wpwrak> kristianpaul: no free IRQs on SIE ? :-(
2010-12-27 10:23 <wpwrak> wolfspraul: (kicad patches) hmm, eeschema-bom-only-mode.patch has a change to eeschema/CMakeLists.txt where the context contains cmp_library_keywords.cpp. my bzr revision 2358 doesn't have this.
2010-12-27 10:30 <wolfspraul> wpwrak: he one we 'standardized' upon was 2448?
2010-12-27 10:30 <wolfspraul> that was the one you told me you are using...
2010-12-27 10:31 <wpwrak> hmm, maybe i got lost myself :) lemme check ...
2010-12-27 10:31 <wolfspraul> upticking kicad is another thing, I will not make the first step there, no need right now (for me)
2010-12-27 10:32 <wolfspraul> but if you uptick it, feel free to just comment out my -scripted patches, and I am standby to uptick them as well, right away
2010-12-27 10:32 <wpwrak> right, 2448. funny. all my notes say 2358. never trust documentation ;-)
2010-12-27 10:32 <wolfspraul> well but why do you get the context problem?
2010-12-27 10:33 <wolfspraul> you are actually using 2358? but all this time you thought it was 2448?
2010-12-27 10:33 <kristianpaul> wpwrak: i just sent a mail to qi (cc: carlos camargo) exmplaining my situation
2010-12-27 10:33 <wpwrak> no, i'm using 2448 but the places where i have written down the number (e.g., docs/GETTING-STARTED in gta02-core) say it's 2358
2010-12-27 10:34 <wolfspraul> but why do you get the context problem then?
2010-12-27 10:34 <kristianpaul> wpwrak: (IRQ) well not free, but i still asking my self why the pin in sharef with LCD, or is just a label..
2010-12-27 10:34 <wolfspraul> my 2 patches apply cleanly against 2448, in the quilt series as uploaded
2010-12-27 10:35 <wpwrak> (2448) and i lost that kicad source tree with the disk loss a few weeks ago. so i restarted from documentation ... and thus ended up with 2358 :)
2010-12-27 10:35 <kristianpaul> wpwrak: (well not free) > not sure if free
2010-12-27 10:35 <wolfspraul> as for KiCad upticking, that's a task I can definitely offer to work on, if you want to get rid of it and suspect that some improvements might be worth the work.
2010-12-27 10:35 <wolfspraul> I am slowly getting more and more familiar with KiCad, so I can already 'test' a newer version to a certain degree.
2010-12-27 10:35 <wolfspraul> it's up to you...
2010-12-27 10:35 <wolfspraul> of course I may uptick it to xxxx, and then you find some major problem with xxxx that I just wasn't aware of
2010-12-27 10:35 <wpwrak> need to check what the latest version offers. there are a few bugs in 2448 that i wouldn't mind seeing gone.
2010-12-27 10:36 <wolfspraul> like I said, I offer to work on this, if that helps you
2010-12-27 10:37 <wolfspraul> either you explain to me what the 2448 bugs are, so I can test whether they are gone, or you try yourself. you need to decide what costs you less time...
2010-12-27 10:37 <wolfspraul> if we move kicad-patches to eda-tools, I can commit right there and it should be quite efficient for me
2010-12-27 10:37 <wpwrak> thanks ! it's mainly a question of running the new stuff on a design you know well and see if anything appears unusual
2010-12-27 10:37 <wolfspraul> sure
2010-12-27 10:37 <wolfspraul> that's why I think I am only 20% ready for the job now, slowly increasing
2010-12-27 10:37 <wolfspraul> maybe by the time we manufacture Xue I'm at 75%? :-)
2010-12-27 10:38 <wpwrak> (2442 bugs) they're things that happen occasionally. like kicad running into an internal error if you resize areas. or "create a corner" only being available sometimes.
2010-12-27 10:38 <wolfspraul> 2448
2010-12-27 10:38 <wpwrak> err yes, 2448
2010-12-27 10:39 <wpwrak> 2448 patched cleanly. building ...
2010-12-27 10:43 <kristianpaul> MauroRojas: hola
2010-12-27 10:43 <MauroRojas> Hola!
2010-12-27 10:43 <wpwrak> MauroRojas: welcome back among the living ! ;-)
2010-12-27 10:43 <MauroRojas> thanks :-)
2010-12-27 10:45 <wpwrak> nice ... pcbnew --help  ... now it looks like a real program :)
2010-12-27 10:47 <wpwrak> wolfspraul: having -print-layers and --print-layers is a bit confusing. if the short option is the same at the long option, there probably shouldn't be a short option at all
2010-12-27 10:47 <wolfspraul> yes, eeschema doesn't have that yet, but when I go back to eeschema I'll clean it all up there, and merge your --plot patch as well.
2010-12-27 10:47 <wolfspraul> yes but the wx layer has its system
2010-12-27 10:47 <wolfspraul> I'm trying to follow KiCad as much as possible, and will do even more so then I start to cleanup
2010-12-27 10:48 <wpwrak> wolfspraul: also, the help for ps-pads-drill is confusing. --ps-pads-drill-ops is clear, but what does -ps-pads-drill do ? (supposedly the same as --ps-pads-drill-opts)
2010-12-27 10:48 <wolfspraul> http://docs.wxwidgets.org/trunk/classwx_cmd_line_parser.html
2010-12-27 10:49 <wolfspraul> yes sure, same
2010-12-27 10:49 <wolfspraul> -ps-pads-drill is a random 'short name' for the long name
2010-12-27 10:49 <wolfspraul> the wx... class has this concept of 'short' and 'long'
2010-12-27 10:49 <wolfspraul> I can try to see what happens if I leave the short string empty
2010-12-27 10:49 <wolfspraul> maybe it will only display the long one then, that would be better, I agree
2010-12-27 10:50 <wolfspraul> these are pecularities of the wxCmdLineParser class I haven't gotten around to yet
2010-12-27 10:50 <wolfspraul> wx is support to work well on Mac and Windows too
2010-12-27 10:50 <wolfspraul> so they also have this concept that the separator can be != '-'
2010-12-27 10:50 <wolfspraul> like / on Windows
2010-12-27 10:50 <wpwrak> hmm yes, i see. i think the idea for a "short name" is for it to be just a letter
2010-12-27 10:51 <wolfspraul> I have two options in all this. I can try to follow the KiCad classes, design, etc.
2010-12-27 10:51 <wolfspraul> and that will produce some 'quirks' when you look at it from a pure Linux/Unix perspective
2010-12-27 10:51 <wolfspraul> or I can just do it all Linux-style, but then bringing it to Mac or Windows would be a lot of work
2010-12-27 10:51 <wolfspraul> (and most likely never happen)
2010-12-27 10:52 <wolfspraul> yes that's the idea, 'just a letter'
2010-12-27 10:52 <wolfspraul> something short
2010-12-27 10:52 <wolfspraul> I can try to see whether the class accepts an empty/missing short name, haven't tried that yet
2010-12-27 10:52 <wpwrak> that would also work on unix
2010-12-27 10:53 <wpwrak> i think if you can just change the "short" names - that are actually quite long - to single letters, that would be sufficient
2010-12-27 10:53 <wolfspraul> don't you think that's even more confusing?
2010-12-27 10:53 <wolfspraul> sure we can do that...
2010-12-27 10:53 <wpwrak> the usefulness of a ton of cryptic one-letter abbreviations is somewhat questionable, but at least they wouldn't get in the way
2010-12-27 10:53 <wolfspraul> maybe let's see how the parameters evolve first
2010-12-27 10:53 <wolfspraul> I suggest to completely ignore the short names right now
2010-12-27 10:53 <wolfspraul> let's focus on making the long ones better
2010-12-27 10:54 <wolfspraul> I will check whether the class allows disabling of the short ones.
2010-12-27 10:54 <wpwrak> yep, if there's a choice for not having short names at all, i think that would be better. we're not exactly optimizing keystrokes here anyway ;-)
2010-12-27 10:59 <wpwrak> wolfspraul: since we discussed consistency ... a netlist generation option in eeschema would also be nice
2010-12-27 11:00 <wpwrak> wolfspraul: it would also let one run the full build process from files in the repository to the fabrication data
2010-12-27 11:03 <wolfspraul> yes definitely, will add netlist to eeschema
2010-12-27 11:03 <wolfspraul> together with erc
2010-12-27 11:04 <wolfspraul> and merging the current --plot and --bom patches into something cleaner
2010-12-27 11:04 <wolfspraul> wpwrak: did you run some of the pcbnew cmdline stuff successfully?
2010-12-27 11:04 <wolfspraul> without crash - did it produce usable files?
2010-12-27 11:29 <wpwrak> wolfspraul: drill file so far. worked flawlessly
2010-12-27 11:30 <wolfspraul> nice!
2010-12-27 11:30 <wolfspraul> that makes for a happy flight to Berlin now, thanks for letting me know :-)
2010-12-27 11:30 <wolfspraul> so you gave your green-light already for moving the patches to eda-tools, and doing more work on the eeschema side (including merging your --plot patch)
2010-12-27 11:31 <wolfspraul> I will try to do this soon, to get over the whole KiCad thing, maybe the next week or so
2010-12-27 11:31 <wpwrak> (happy flight) ;-))
2010-12-27 11:31 <wolfspraul> first need to get 27c3 behind me, not sure how much spare time I have there
2010-12-27 11:31 <wolfspraul> so maybe I'll finish the kicad cmdline stuff when I'm back from there
2010-12-27 11:31 <wpwrak> (27c3) you'll probably sleep negative hours :)
2010-12-27 11:32 <wolfspraul> what I need from you is feedback on whether the current cmdline options work, and whether you need more, or whether you have some ideas for re-layout of the parameters
2010-12-27 11:32 <wolfspraul> those kind of things
2010-12-27 11:32 <wpwrak> (patches and eda-tools) in fact, i have them sit there already. they're just a git add, commit, and push away :)
2010-12-27 11:32 <wolfspraul> but we can do that slowly as we realize more clearly what we need...
2010-12-27 11:32 <wolfspraul> he, nice
2010-12-27 11:34 <wpwrak> (option names) maybe change --print-layers to --list-layers, considering that we;re in the midst of plotting and printing here
2010-12-27 11:35 <wolfspraul> sure
2010-12-27 11:35 <wpwrak> also, the help text for -l should say what that list is for :)
2010-12-27 11:35 <wolfspraul> I think the options will evolve over time
2010-12-27 11:35 <wolfspraul> don't know :-)
2010-12-27 11:35 <wolfspraul> it lists the 'enabled' layers
2010-12-27 11:35 <wolfspraul> I think it's the same as those that are checked by default in the dialogs
2010-12-27 11:36 <wpwrak> let's try somthing harder now ... the postscripts
2010-12-27 11:36 <wolfspraul> unless you overwrite those defauls somehow (KiCad seems to save options and option overrides in several places)
2010-12-27 11:36 <wolfspraul> I try to make the cmdline options as deterministic as possible
2010-12-27 11:36 <wolfspraul> they should not be influenced by anything but the .sch and .brd files
2010-12-27 11:36 <wpwrak> the whole options systems is borderline incomprehensible :-(
2010-12-27 11:36 <wpwrak> (the one of kicad i mean)
2010-12-27 11:36 <wolfspraul> but it is quite possible that they still are influenced by stuff saved locally in KiCad somewhere
2010-12-27 11:36 <wolfspraul> if so, that's a bug
2010-12-27 11:37 <wolfspraul> I tried to write the codepath in such a way to bypass those 'local' options and option overrides
2010-12-27 11:37 <wolfspraul> but we need to see over time, I expect some surprises...
2010-12-27 11:37 <wolfspraul> so this --list-layers lists the 'enabled' layers, whatever that is exactly
2010-12-27 11:37 <wolfspraul> I hope it's a deterministic on/off switch in the .brd file.
2010-12-27 11:38 <wolfspraul> also you may need those strings if you want to specify layers for the svg or plot options
2010-12-27 11:38 <wpwrak> maybe it's the ones you select in  pcbnew: Design Rules > Layers Setup ?
2010-12-27 11:38 <wolfspraul> yes
2010-12-27 11:38 <wolfspraul> and those are the same strings used in the comma separated lists
2010-12-27 11:39 <wolfspraul> in --layers=a,b,c
2010-12-27 11:43 <wpwrak> aha. the area fill problem hits
2010-12-27 11:45 <wpwrak> interestingly, --drc doesn't affect it. --drc also seems unusually fast.
2010-12-27 11:46 <wpwrak> the report look good, though. strange.
2010-12-27 11:46 <wpwrak> maybe you run just the report generator without recalculating the checks ?
2010-12-27 11:48 <wpwrak> run time: 5 s for manual DRC (time during which the dialog is "running", so without pcbnew startup an such). 0.6 s for --drc and --plot
2010-12-27 11:50 <wolfspraul> which --plot are you running ?
2010-12-27 11:50 <wolfspraul> which .brd file?
2010-12-27 11:50 <wpwrak> runing pcbnew, filling the zones, and saving it with the zones filled solves the problem of them not getting plotted. it's a nasty trap, though. (could be something that's fixed in a more recent version, though. it's something that can bite you also without --plot)
2010-12-27 11:50 <wpwrak> --plot=ps_a4
2010-12-27 11:50 <wpwrak> atusb.brd
2010-12-27 11:50 <wpwrak> pcbnew  --plot=ps_a4 -l Front -mirror --ps-pads-drill-opt=real atusb.brd
2010-12-27 11:51 <wolfspraul> and you like to mix short and long options, probably to torture me :-)
2010-12-27 11:51 <wolfspraul> the short ones are really horrible...
2010-12-27 11:52 <wolfspraul> so this plot when run on the cmdline produces a different result from running in the plot dialog?
2010-12-27 11:53 <wolfspraul> when you say "running pcbnew, filling the zones, and saving it with the zones filled solves..." what do you mean exactly in KiCad?
2010-12-27 11:53 <wolfspraul> what are the steps...
2010-12-27 12:04 <wpwrak> hates brown-outs
2010-12-27 12:04 <kristianpaul> UPS?
2010-12-27 12:07 <wpwrak> i had one - just made the brown-outs worse
2010-12-27 12:13 <wpwrak> and another one :-(
2010-12-27 13:37 <wolfspraul> wpwrak: I found a bug wrt default line thickness, uploaded a new pcbnew-scripted.patch
2010-12-27 13:37 <wolfspraul> I was able to reproduce that with the atusb.brd and options you gave me
2010-12-27 13:37 <wolfspraul> so that's good, that's definitely an improvement
2010-12-27 13:37 <wolfspraul> I also renamed --print-layers to --list-layers
2010-12-27 13:38 <wolfspraul> update is here http://downloads.qi-hardware.com/people/wolfgang/kicad_patches/pcbnew-scripted.patch
2010-12-27 14:03 <lekernel_27C3> http://www.youtube.com/watch?v=6AesY6V-qto (that was shot in early april)
2010-12-27 14:19 <kristianpaul> argg you french is hard to catch ;-)
2010-12-27 17:48 <kristianpaul> oh well seems LCD have free pins after all, just was a bit tricy as they keep labeled as LCD and the new functions too.
2010-12-27 18:22 <kristianpaul> andres-calderon: the only thing i see sram example is missing is a busrt mode for data transfer from FPGA to Xbusrt ;-)
2010-12-27 18:27 <kristianpaul> Is some kind of frustating at first then funny see a fpga as ram :-)
2010-12-27 18:28 <andres-calderon> kristianpaul: its just a starting point. There must be room for a lot of optimizations (timing, burst?, dma?..  I do not know ).
2010-12-27 18:28 <kristianpaul> dma??
2010-12-27 18:29 <kristianpaul> really...
2010-12-27 18:31 <kristianpaul> timing still tricky but even if it get optimized (cpu cylces, etc..) i think is mainally oriented to be efficient both with buffer like setup or with not hihg demanding IO transfer setup :-)
2010-12-27 18:32 <kristianpaul> andres-calderon: i was checking dma for jz4725 also wpwrak , but seems there is no documentation or feature avaliable for EMC
2010-12-27 18:32 <kristianpaul> so far i just realized DMA capabillties with the nanonote and the mmc controller
2010-12-27 18:33 <andres-calderon> Some really nice SoC support external DMA.
2010-12-27 18:33 <kristianpaul> any hint from your side is very wellcome, o just met SIE when ti was renamed to that name... surelly you had lots of tetchnical discuss with carlos camargo about this topic i guess
2010-12-27 18:34 <kristianpaul> andres-calderon: is that really nice SoC the Xbusrt JZ4725? :-)
2010-12-27 18:34 <kristianpaul> as i said any help with dma in SIE is apreciate :-)
2010-12-27 18:35 <andres-calderon> kristianpaul: nice price
2010-12-27 18:35 <kristianpaul> hmm'
2010-12-27 18:35 <kristianpaul> ?
2010-12-27 18:36 <kristianpaul> ah i you meant Xbust chips are cheap, i totally agree :-)
2010-12-27 18:37 <wpwrak> (dma) the xburst don't seem to have it :-( the only one where i found a mention in the documentation is the 4720, and there, it's an empty chapter.
2010-12-27 18:37 <kristianpaul> btw are you p:anning get a M1? i already order one will be nice have more people in Colombia working around this nice and free SoC  :-D
2010-12-27 18:38 <wpwrak> (dma) there are also no pins marked for DMA request/ack and such. nor are there register values that suggest they could be used for selecting external dma.
2010-12-27 18:38 <kristianpaul> (argg tomorrow interesting talks at 27c3  are too early..)
2010-12-27 18:41 <andres-calderon> wpwrak: Hi Werner, What do You think about  this chip? http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=296-19652-1-ND
2010-12-27 18:43 <andres-calderon> wpwrak: too expensive?
2010-12-27 18:43 <kristianpaul> wpwrak: (dma and 4720) hopefully that should be asociated with mmc..
2010-12-27 18:44 <kristianpaul> looks easy to use chip :-)
2010-12-27 18:47 <andres-calderon> kristianpaul: very easy, i like it
2010-12-27 18:49 <wpwrak> andres-calderon: i think low design risk trumps low cost for now :)
2010-12-27 18:50 <andres-calderon> wpwrak: i agree
2010-12-27 18:52 <kristianpaul> wolfspraul: hi, how looked the M1 case?? (blue one)
2010-12-27 18:53 <webpower> hi all
2010-12-27 18:53 <kristianpaul> hi wolfspraul
2010-12-27 18:53 <kristianpaul> hi webpower
2010-12-27 18:53 <webpower> i want to know the differences between LGA 1156 and LGA 1366
2010-12-27 18:53 <webpower> socket
2010-12-27 18:53 <wpwrak> the chip looks friendly.
2010-12-27 18:53 <wolfspraul> he
2010-12-27 18:54 <wolfspraul> just arrived in Berlin after an adventurous flight and landing, then Sebastien said he was too tired and now I'm at his place going to crash...
2010-12-27 18:54 <wpwrak> wolfspraul: (line width) excellent ! i ran into this, too. you fixed it before i could mention it :)
2010-12-27 18:54 <kristianpaul> ok
2010-12-27 18:54 <wolfspraul> but the great thing I saw during the 10 minutes I was at 27c3 was the m1 happily crunching away in the lounge, entertaining people
2010-12-27 18:54 <wpwrak> wolfspraul: (flight) what happened ?
2010-12-27 18:54 <wolfspraul> very nice
2010-12-27 18:54 <wolfspraul> if it can handle that for 4 days I feel much better about the quality of the whole thing...
2010-12-27 18:55 <wolfspraul> [flight] delays delays delays
2010-12-27 18:55 <wolfspraul> nothing to complain though, lots of snow, runway had to be cleaned, we circled in the air longer than the actual flight, etc.
2010-12-27 18:55 <wpwrak> wolfspraul: hah, you should try domestic air travel in argentina ;-)
2010-12-27 18:55 <kristianpaul> snow snow snow everywhere :-)
2010-12-27 18:55 <wolfspraul> anyway, arrived. m1 doing a great show in the lounge.
2010-12-27 18:55 <wolfspraul> wpwrak: hmm, OK. so the line width was not the only thing.
2010-12-27 18:55 <wpwrak> (m1) great !
2010-12-27 18:56 <wolfspraul> you still have the fill zone problem?
2010-12-27 18:56 <wolfspraul> I cannot reproduce it, or rather you didn't give me reproduction steps I would understand.
2010-12-27 18:58 <wpwrak> wolfspraul: (fill problem) pcbnew: select "Add zones" mode. right-click on a zone. select "Remove Filled Areas in All Zones"
2010-12-27 18:58 <wpwrak> (if that item doesn't appear, try again and again)
2010-12-27 18:58 <wpwrak> now the filled zones should go from solid to outlines with thin lines
2010-12-27 18:59 <wpwrak> then save the board. then exit pcbnew and plot the board. the postscript won't have filled zones.
2010-12-27 19:01 <wolfspraul> hmm. when I click on 'remove filled areas in all zones' - I don't see any visible change. I'm in atusb.brd
2010-12-27 19:01 <wolfspraul> or I can only see the difference in the .ps ?
2010-12-27 19:02 <wpwrak> maybe it's already unfilled
2010-12-27 19:02 <wpwrak> if you're using exactly the version in git, without running a DRC or such, then it will be unfilled
2010-12-27 19:03 <wolfspraul> ah yes. when I say 'fill' then it will all become green and yellow etc.
2010-12-27 19:03 <wpwrak> yup, that's it
2010-12-27 19:03 <wolfspraul> ok, so when this gets plotted, in the cmdline version of the plot it doesn't come out right?
2010-12-27 19:03 <wolfspraul> in the cmdline version, which one does not come out right - filled or unfilled?
2010-12-27 19:04 <wpwrak> the plot won't have the zones. (neither would it if you plotted manually from pcbnew)
2010-12-27 19:05 <wpwrak> the problem for non-interactive plots is that this problem makes them quite unpredictable. in manual use, you at least have a chance to spot the problem. not that this is a very happy situation either - i've thrown away some stuff where i didn't notice it in time.
2010-12-27 19:07 <wolfspraul> what is the problem?
2010-12-27 19:07 <wolfspraul> the plot will never have the filled zones, whether they are filled visually in pcbnew or not?
2010-12-27 19:07 <wolfspraul> but you want them to be filled in the .ps plot, when they are filled visually?
2010-12-27 19:08 <wolfspraul> or you say the current --plot works fine, it will fill or unfill the zones depending on the settings in the file, but you cannot tell from outside which one it was?
2010-12-27 19:08 <wpwrak> yes, you can't tell
2010-12-27 19:09 <wolfspraul> in that case, what do you prefer? do you think we should introduce a way to query the fill status from the command line? Or should we automatically do the fill/unfill operation depending on cmdline setting?
2010-12-27 19:09 <wpwrak> i don't think you'd ever want a plot with the zones not filled
2010-12-27 19:09 <wolfspraul> ok
2010-12-27 19:09 <wolfspraul> in the current version, if it's filled in the saved .brd file, it will also be filled in the .ps plot?
2010-12-27 19:09 <wpwrak> i think always filling or at least the option of commanding a fill would be highly desirable
2010-12-27 19:09 <wpwrak> yes
2010-12-27 19:09 <wolfspraul> (when invoked from the cmdline)
2010-12-27 19:10 <wolfspraul> ah OK
2010-12-27 19:10 <wolfspraul> so the only problem is that you don't know from the outside
2010-12-27 19:10 <wolfspraul> is the fill/unfill operation always 'safe'?
2010-12-27 19:10 <wpwrak> so your stuff works. it's just a pcbnew usability issue that gets worse if you don't have visual feedback
2010-12-27 19:10 <wolfspraul> or would you want to manually check the results?
2010-12-27 19:11 <wolfspraul> or is it possible that you would want to fill some zones, and leave others unfilled?
2010-12-27 19:11 <wpwrak> it should always be safe, assuming your design has passed DRC
2010-12-27 19:11 <wpwrak> of course, if you choose to produce something you haven't checked, well ... ;-)
2010-12-27 19:11 <wolfspraul> the fill/unfill setting is always for the whole board? or can it be partially filled/unfilled?
2010-12-27 19:12 <wpwrak> you can also partially fill/unfill. not sure when you'd want to do that. some of this may just be optimizations for faster interactive use.
2010-12-27 19:12 <wolfspraul> hmm
2010-12-27 19:13 <wpwrak> i can't quite imagine that you'd want a partially filled board
2010-12-27 19:13 <wolfspraul> so maybe we do this: we leave the current cmdline behavior as it (i.e. we leave the saved .brd settings untouched), and in addition we introduce a new parameter --fill-all-zones
2010-12-27 19:13 <wolfspraul> that will override whatever is in the file
2010-12-27 19:13 <wpwrak> also considering that DRC will fill everything anyway
2010-12-27 19:13 <wpwrak> sounds good to me
2010-12-27 19:15 <wolfspraul> drc will fill it?
2010-12-27 19:15 <wolfspraul> but if you run --drc from the cmdline, nothing gets saved
2010-12-27 19:15 <wolfspraul> ok I think it's clear. I will add a --fill-all-zones option
2010-12-27 19:16 <wpwrak> (--drc) yes, don't know why not. it seems that you're not running the entire DRC process
2010-12-27 19:16 <wolfspraul> no
2010-12-27 19:16 <wolfspraul> I don't save on purpose.
2010-12-27 19:17 <wolfspraul> I wouldn't know why printing a drc report should modify the source. that looks very wrong to me.
2010-12-27 19:17 <wpwrak> (--drc) e.g., a pcbnew --plot takes about 0.5 s, --drc and --plot takes about 0.6 s. when i do a DRC interactively, it takes about 5 s. so unless you did some very clever optimization, something is missing :)
2010-12-27 19:17 <wolfspraul> wait, one by one
2010-12-27 19:17 <wolfspraul> I know it's fast, but I do think it checks everything. The GUI is only marginally slower on my notebook.
2010-12-27 19:18 <wolfspraul> complaining about 'too high speed' is not a good bug report :-)
2010-12-27 19:18 <wolfspraul> so unless we know what's wrong with --drc, I assume it's all fine
2010-12-27 19:18 <wpwrak> on my pc, the difference is quite large :)
2010-12-27 19:18 <wolfspraul> if you want me to save back the fill-zone side-effect when running --drc, I can add that
2010-12-27 19:18 <wolfspraul> I would think that's really ugly.
2010-12-27 19:19 <wpwrak> when i put --plot and --drc, which gets done first ? does it depend on the order in the command line ?
2010-12-27 19:19 <wolfspraul> also it would cause issues with my plans to run some of those reports on the server, at least I would definitely not automatically commit some of those changes back.
2010-12-27 19:19 <wpwrak> (save back) you mean to in-core state ? or to the file ?
2010-12-27 19:19 <wolfspraul> ah good point.
2010-12-27 19:20 <wpwrak> i don't think you really have a choice about in-core state :)
2010-12-27 19:20 <wolfspraul> that's not really thought through. it depends on the order I check the cmdline options in the sources.
2010-12-27 19:20 <wolfspraul> maybe we should only support one 'major' command per pcbnew process?
2010-12-27 19:20 <wpwrak> when DRC does its filling, then it will mess with in-core state
2010-12-27 19:20 <wolfspraul> yes
2010-12-27 19:20 <wolfspraul> but we can only accept 1 major command, then exit the process
2010-12-27 19:20 <wpwrak> you could. or just put the one(s?) with side-effects first
2010-12-27 19:21 <wpwrak> or something :)
2010-12-27 19:21 <wolfspraul> no I think I will only support the first major command.
2010-12-27 19:21 <wolfspraul> so if you do --plot --drc, it will only plot
2010-12-27 19:21 <wpwrak> warn if there are more ?
2010-12-27 19:21 <wolfspraul> if you do --drc --plot, it will only run the drc report
2010-12-27 19:22 <wolfspraul> yes I can warn, although the wx cmdline parsing class forces me into certain expected behavior
2010-12-27 19:22 <wolfspraul> once we move away from that, the code gets ugly (but no problem)
2010-12-27 19:23 <wolfspraul> ok, so that's settled too? only 1 major command per process...
2010-12-27 19:23 <wolfspraul> 1) --fill-all-zones
2010-12-27 19:24 <wolfspraul> 2) only process first major command, warn if there are more
2010-12-27 19:24 <wpwrak> sounds fine
2010-12-27 19:25 <wpwrak> a warning would be useful because it may not be obvious for the user what constitutes a "major command". and then you get silent failure.
2010-12-27 19:26 <wpwrak> i also expected that wx may not be overly helpful here. that's why i suggested to just make the order deterministic but accept any set of commands. as long as all commands get processed, there's no error to report or warn about ;-)
2010-12-27 19:28 <wolfspraul> I rather operate more narrowly. one command per process is enough, then it's cleanup time :-)
2010-12-27 19:28 <wolfspraul> yes the wx --help thing is quite limited, they work from a structure and I need to fill my stuff in there.
2010-12-27 19:28 <wolfspraul> warning is good
2010-12-27 19:28 <wolfspraul> I don't think it's a good idea to run multiple totally different files in one shot anyway.
2010-12-27 19:29 <wolfspraul> and it introduces potentially very hard to track down error cases. not worth it! Need to focus...
2010-12-27 19:30 <wpwrak> heh, whatever works :) for my Makefiles, one file at a time is nice enough
2010-12-27 19:33 <wpwrak> ah nice. today, we had a "subjective" temperature > 40 C
2010-12-27 19:39 <wolfspraul> zrafa: you lost some files on the openmoko projects server?
2010-12-27 19:56 <zrafa> wolfspraul: yes, the web page of the fatfinger shell. ANd the web page had a copy of the sources as well IIRC
2010-12-27 19:56 <zrafa> kristianpaul: http://www.xatakamovil.com/motorola/game-gripper-sencilla-forma-de-convertir-un-teclado-qwerty-en-un-pad-para-videojuegos
2010-12-27 19:56 <zrafa> kristianpaul: that would solve our game pad idea :)
2010-12-27 19:58 <zrafa> bah.. wolfgang is not here
2010-12-27 19:58 <andres-calderon> zrafa, kristianpaul: ttp://www.youtube.com/watch?v=GVfydHEsXX8
2010-12-27 19:59 <zrafa> andres-calderon: I would like something a lot easier :) http://www.engadget.com/2010/04/23/game-gripper-review/
2010-12-27 19:59 <zrafa> andres-calderon: check the idea.. it is just a game pad which press keys on qwerty :D
2010-12-27 20:01 <andres-calderon> nice, easy to implement through the microSD slot
2010-12-27 20:02 <wpwrak> add an avr and connect an old analog joystick ? :)
2010-12-27 20:03 <andres-calderon> I like the openpandora keyboard:  http://www.openpandora.org/
2010-12-27 20:04 <zrafa> andres-calderon: I think that the gamepad link I pasted just press keys on qwerty
2010-12-27 20:04 <zrafa> andres-calderon: it is not connected to any IO
2010-12-27 20:09 <andres-calderon> andres-calderon: wow... so trivial :)
2010-12-27 20:17 <zrafa> kristianpaul: kyak: did you see the doxbox for dingoo?.. it seems me that those guys are running dosbox (I tested their binary on nn and it works) like if the screen would have 640x480. It would be interesting to check how them are running an application which uses 640x480 on a 320x240. Of course, surely they are doing some scaling.. but it would be nice to know how, so we can run any 640x480 application on our screens. A new world would appear on our fro
2010-12-27 20:18 <zrafa> I have no much free time, that is why I just point the idea :)
2010-12-27 21:05 <qi-bot> [commit] Werner Almesberger: Patches to enhance KiCad, mainly for non-interactive use http://qi-hw.com/p/eda-tools/d2da52b
2010-12-27 22:30 <qi-bot> [commit] Werner Almesberger: atusb.brd: saving with the zones filled, to avoid surprises http://qi-hw.com/p/ben-wpan/5dde617
2010-12-27 22:30 <qi-bot> [commit] Werner Almesberger: atusb/Makefile: targets "front" and "back" to print layers for toner transfer http://qi-hw.com/p/ben-wpan/fe60705
2010-12-27 22:30 <qi-bot> [commit] Werner Almesberger: atusb/cam2/: streamlined CAM data processing, added generation of prerequisites http://qi-hw.com/p/ben-wpan/a0b064b
2010-12-27 22:30 <qi-bot> [commit] Werner Almesberger: atusb: added "clean" targets to main and CAM makefile http://qi-hw.com/p/ben-wpan/3385afc