<wpwrak> adamw_: heya ! question: for 4x4 mm qfn, is it okay if the center pad is just one square, with one square of solder paste, or should the solder paste be split into smaller portions ?
<adamw_> wpwrak, this is good question!
<wpwrak> i knew you'd like it ;-))
<adamw_> either smaller portion or bigger than solder pad, it really depends on datasheet said firstly
<adamw_> but datasheet always say recommended layout footprint ONLY.
<wpwrak> naw, data sheet says nothing ;-)
<adamw_> they are not care more about 'solder paste' or 'solder pad'
<wpwrak> NXP do :) but they're the only ones, it seems
<adamw_> but like in avt2 , the cpu die
<adamw_> some chip manufactuer will very carefully on telling you the size of center 'solder pad', and define if connected to GND plate.
<adamw_> so I could only tell you a normal spec. from pcb maker
<wpwrak> i'm talking about the AT86RF231 and the C8051F326. for the f326, the land pattern is given. central pad on the package is 3.15 x 3.15 mm, in the land pattern 3.25 x 3.25 mm (typ/median values)
<adamw_> you could just split into at 5 mil nominal between pad and paste layer.
<wpwrak> for the rf231, i only have the package definition: 3.30 x 3.30 mm
<adamw_> then you won't worry your design one day pcb maker won't produce it.
<wpwrak> so .. 125 um on each side ?
<adamw_> just remember the clearance to be at least 5 mils : land pattern > 5 mil > central pad > 5 mil > solder paste.
<wpwrak> ah, okay. thanks !
<adamw_> so clearance please leave 0.127mm = 0.0254 * 5 mm
<adamw_> hope this help you.
<wpwrak> i suppose, nobody worries about such things for other components. 0402 and such ? i.e., there, solder paste = pad size ?
<adamw_> no ...it really depends on what kinds of product. some times always solder pad != pad size...more common!!!
<adamw_> but if for your design, you could just use Milkymist foortprint for 0402, they are more common.
<adamw_> that was I asked from pcb maker and smt vendors.
<wpwrak> oh, really ? hmm. ought to be a global setting then.
<adamw_> i have had very care about the pad and solder paste on bga pcb design on bluetooth earphone before
<adamw_> no, a said globe setting, we should always follow IPC specification,
<wpwrak> ah .. what does ipc say about 0402 ? :)
<adamw_> wait...check for you.
<adamw_> before you get digging into more precise suggestion on 0402 layout, please check http://en.qi-hardware.com/wiki/Milkymist_One_RC2_Layout_History
<adamw_> scrolling down to see last 0402 picture I made stencil size.
<adamw_> you should read this first.
<adamw_> then you will know why people are caring about 0402 mounting.
<wpwrak> ah, at the very end :)
<adamw_> then you could determine what the histories for good design on 0603/ 0402, 0805, or others.
<adamw_> we've never produced over 3k products...you will hard to know the impact of bad 0402 footprint design.
<adamw_> but I have met 1kk before for producing product....so they are important for MP.
<adamw_> so I could only say to say with a 5 mil clearance, your board can be produced in all over the world.
<adamw_> not just follow IPC ..:)
<wpwrak> for 0402, my pads are 0.6 x 0.45 mm. (0402-M from kicad-libs/modules/stdpass.fpd)
<wpwrak> would you also there make a 5 mil reduction ?
<wpwrak> the solder paste would then be about 0.35 x 0.2 mm. seems very small.
<adamw_> 0.6 x 0.45 mm is a central pad? or solder past size?
<wpwrak> that's the solder pad for 0402
<adamw_> yes , 0.35 x 0.2 is too small
<adamw_> please use http://en.qi-hardware.com/wiki/File:0603_0402_stencil_aperture_dimension.png  for 0402 solder pad design.
<adamw_> the recommended pad design I took from VIA for mother board industry.
<wpwrak> that's much larger than my pads ;)
<adamw_> larger than your 0.6 x 0.45 mm
<wpwrak> my pad sizes come from the land pattern recommendations by various chip makers
<adamw_> haha...
<wpwrak> hmm, i should have the analysis somewhere ...
<adamw_> so what would you prefer? to let your board all over the world can use or few only?
<adamw_> yes...analysis is good
<adamw_> check out this IPC for solder paste.
<adamw_> you will get official answer.
<wpwrak> "My 0402" is a fairly tight version that's difficult to solder manually. since then, i've introduced a version that's 0.1 mm longer and is easily soldered manually, 0402-M
<adamw_> aha....improvement from experienced life...quite good.
<wpwrak> ;-)
<adamw_> here layout house have three catagories for 0402 footprint design..
<adamw_> i should ask them for sharing here....their experienced design was really confirmed by their much high quantities in customer end.
<adamw_> some times to read more data like IPC is not bad.
<wpwrak> well, from manual soldering with an iron. reflow is a bit easier. i should build myself a proper reflow oven once. the toaster i use for this purpose has a hard time melting the solder but is really good at, well, toasting the FR4 (and oxidizing the traces in the process). not exactly how i want things ...
<adamw_> but too many to learn.
<adamw_> hmm..I have to run outside now.
<wpwrak> zrafa: gaah ! wireshark doesn't run. when loading its decoders ("dissectors"), it fails around "cisco" with Unhandled exception (group=1, code=6)
<zrafa> wpwrak: did you try with a bit of swap on SD?
<czr> Jay7, cool. stock OE or something else?
<Jay7> stock OE
<Jay7> but as I've said, I've not build any images for nn yet :)
<Jay7> I'm building for zauruses mostly
<Jay7> but DISTRO="jlime" and MACHINE="ben-nanonote" should be sufficient :)
<wpwrak> zrafa: (swap) nope, but there was also nothing in dmesg
<wpwrak> hmm, also jlime disables overcommit_memory. bad habits everywhere ....
<wpwrak> indeed, that helps. now at ipv6 ...
<wpwrak> ... ppp ...
<wpwrak> getting veeeerryyyy slooooowwww ... i think the ben really needs more memory :)
<wpwrak> and, eventually, the OOM killer got it. ah well, it's not that i really needed it ...
<xMff> ppp on the nanonote is too heavy?
<wpwrak> xMff: no, ppp probably isn't, but wireshark is :)
<xMff> ah... heh
<wpwrak> added pcap support to one of my wpan tools and wanted to show it off, but ... sneef
<xMff> maybe something like ettercap would be better suited?
<wpwrak> ah, nice. doesn't support IEEE 802.15.4, though.
<wpwrak> wow, not even tcpdump has it (at least not on my ubuntu host). how peculiar.
<qi-bot> [commit] Xiangfu Liu: bc, add -l, use the predefined math routines by default http://qi-hw.com/p/openwrt-packages/216706c
<wpwrak> jlime's tcpdump is better. heh :) gets very confused by my junk frames, though
<wpwrak> hmm, if a hypothetical ben successor had DDR SDRAM support (the Jz4720), then it could have 128 MB (32 Mb x 32) at about the same price as the current 32 MB
<wpwrak> s/Jz4720/Jz4720 doesn't/
<wpwrak> the memory would also be much faster (4 x the burst rate. of course, setup eats some of this.)
<kyak> mm, 128 Mb, luxury
<lekernel> kyak: get yourself a M1 ;)
<kyak> lekernel: i'll have to google that first :)
<kyak> what's that?
<kyak> ah, ok
<kyak> yeah, i could get it, but it seems like a very specific thingy!
<wpwrak> kyak: 128 MB seems to be around the "knee" in the price/capacity curve. anything smaller doesn't lower the price much, anything bigger grows proportionally in price or worse
<wpwrak> lekernel: so M1 is the official acronym, not MM1 ?
<kyak> wpwrak: are you talking about embedded systems? because desktop "knee" is perhaps around 2Gb
<wpwrak> kyak: in fact, it's the least specific thingy you could imagine ;-))
<lekernel> dunno, I use both interchangeably. M1 is faster to type and easier to pronounce
<wpwrak> kyak: embedded, yes. well, i didn't plot the graph. it just feels like that when i compare a few price points.
<kyak> wpwrak: specific thingy.. i'm not sure, because i can actually buy a desktop PC for that much money MM1 costs
<kyak> it's around 850 Euro, if i'm not mistaken
<lekernel> you are mistaken
<kyak> oh!
<wpwrak> kyak: btw, be careful with GB vs. Gb. the capacity of memory chips is usually specified in mega- or giga-bits, Mb or Gb. so you get 1 Gb (32 M x 32), which means that it has 1 gigabits with the bus interface organized as 32 M words of 32 bits each.
<kyak> its 380.0¬
<kyak> i'm sorry :)
<kyak> still, i bought 1.5 years ago Shuttle K45SE and it costs less than that
<kyak> and it's muuuuch faster
<kyak> that's why, MM1 is very specific
<lekernel> it's much faster?
<lekernel> uhm
<wpwrak> lekernel: ... compiling linux kernels ;-)
<lekernel> the fpga on MM1, when properly programmed, beats any CPU core, even the high end ones
<kyak> it is, 2Gb DDR, E6500  @ 2.93GHz Pentium etc
<wpwrak> lekernel: any core at any task ?
<kyak> lekernel: yes, fpga, so very specific :)
<wpwrak> kyak: mind your capitalization ! :)
<lekernel> oh, well for texture mapping for example, it's certainly faster than that CPU core
<kyak> wpwrak: so tired of hittin ctrl+a with my left hand all day, lazy to hit Shift :)
<lekernel> even the current design
<kyak> i would like to have some many-purpose device
<lekernel> I wonder how you can argue that FPGAs are "very specific" :)
<kyak> and i think that MM1 is very limited-purpose.. like you said, it "can be programmed"
<kyak> but can it be programmed to do all tasks faster than regular PC?
<wejp> are you seriously comparing a FPGA with a general purpose cpu? if you really want to do that, you have to implement a similar cpu on the fpga and compare that to the cpu
<wpwrak> lekernel: btw, in terms of marketing, i have some doubts about the attribute "interactive". as i understand things, that's basically the key feature as far as a VJ is concerned. but i wonder if "interactive" is strong enough. after all, if it was just some macbook application where you have can manipulate the colors a little while the loop is running, that would be "interactive", too.
<lekernel> going the "implement a similar CPU" way for this purpose is stupid and will definitely yield poor performance results
<wejp> of course it will, but comparin g an fpga with a general purpose cpu is at least as stupid as that
<lekernel> using partial reconfiguration and novel hardware synthesis approaches is very likely to be a lot more interesting and will work if you do it right
<lekernel> but it's a hard thing to do, and there are intermediate approaches like manually implementing dedicated acceleration cores, like milkymist does
<wpwrak> wejp: you may want to consider that many fathers think their kid is the best and most beautiful :-)
<kyak> wejp: in fact, you can compare them from the users' point of view. "What can i do with that, and how fast?"
<wejp> wpwrak: yeah, right ;)
<lekernel> it's an interesting research subject, really
<wejp> i'm not saying FPGAs aren't worth using them, but they are totally different form a cpu, so comparing them isn't all that useful
<wpwrak> lekernel: (partial reconfiguration) oh yes. that's what i'm looking for
<lekernel> oh, on the contrary it _is_ useful :)
<wejp> oh yeah?
<lekernel> but you need a way more complex metric than GHz
<lekernel> yeah, a silicon compiler that runs Python or Ruby extremely fast using PR on FPGA would be a wonderful thing
<wpwrak> i'd settle for C :)
<wejp> there is no such metric. you can compare sepecific tasks and how an implementation on a fpga compares to one on a specific cpu, but that's not comparing fpga and cpu but rather comparing different implementations of a specific problem
<roh> wejp: its the question if one wants a synthetic or an real world comparison
<roh> synthetic ones are just generating not much saying marketing numbers.
<wejp> i consider synthetic comparisons to be rather useless
<lekernel> wpwrak: C would be a horrible language for this purpose
<qi-bot> [commit] Xiangfu Liu: update the qi-hardware sources mirror address http://qi-hw.com/p/openwrt-xburst/bf27ef7
<qi-bot> [commit] Xiangfu Liu: bash-files: update the package url http://qi-hw.com/p/openwrt-xburst/e3999a9
<qi-bot> [commit] Xiangfu Liu: add 127.0.0.1 BenNanoNote to hosts file http://qi-hw.com/p/openwrt-xburst/14981ac
<qi-bot> [commit] David Kühling: fix DNS timeout problem when applications resolve the FQDN http://qi-hw.com/p/openwrt-xburst/5299335
<qi-bot> [commit] David Kühling: undo hosts file fix.  Xiangfu was quicker and did it better :) http://qi-hw.com/p/openwrt-xburst/a7c8d1f
<qi-bot> [commit] David Kühling: Adapt config.full_system to new emacs package name.  Add emacs japanese http://qi-hw.com/p/openwrt-xburst/5337fe8
<qi-bot> [commit] Xiangfu Liu: update package to known-good revisions, thanks David Kuehling http://qi-hw.com/p/openwrt-xburst/c6eda58
<qi-bot> [commit] Xiangfu Liu: config.all_packages: remove mp3, mp4, rootfs, u-boot http://qi-hw.com/p/openwrt-xburst/698f0ec
<qi-bot> [commit] David Kühling: Add gfortran compiler support to the toolchain http://qi-hw.com/p/openwrt-xburst/57daa05
<qi-bot> [commit] Xiangfu Liu: configu.full_system: remove IB and Toolchain http://qi-hw.com/p/openwrt-xburst/1ea482b
<qi-bot> [commit] Xiangfu Liu: using 'strip' instead of 'sstrip' http://qi-hw.com/p/openwrt-xburst/672539f
<qi-bot> [commit] Xiangfu Liu: config.full_system, add math stuff and some new pakcages http://qi-hw.com/p/openwrt-xburst/0a3ed89
<qi-bot> [commit] kyak: put qi openwrt-packages git on top in feed.conf http://qi-hw.com/p/openwrt-xburst/c137e6a
<qi-bot> [commit] David Kühling: use ccache also for C++ compilation http://qi-hw.com/p/openwrt-xburst/1ce0cb7
<qi-bot> [commit] Xiangfu Liu: enable the toolchain option for Octave and libgfortran http://qi-hw.com/p/openwrt-xburst/536fd95
<qi-bot> [commit] Xiangfu Liu: config.full_system-add-more-php5-modules.patch http://qi-hw.com/p/openwrt-xburst/6e2a0c1
<qi-bot> [commit] Xiangfu Liu: config.full_system: add package sqlite2-cli http://qi-hw.com/p/openwrt-xburst/7872756
<qi-bot> [commit] Xiangfu Liu: feeds.conf add @revision to feeds.conf http://qi-hw.com/p/openwrt-xburst/da282ed
<qi-bot> [commit] Xiangfu Liu: INSTALL_FGORTRAN needs those two options http://qi-hw.com/p/openwrt-xburst/52c8c73
<qi-bot> [commit] Xiangfu Liu: config.full_system: add recently new packages http://qi-hw.com/p/openwrt-xburst/07b9ae1
<wpwrak> lekernel: how's that ?
<lekernel> with all its pointers, side effects and ad hoc code everywhere e.g. for memory allocation, string handling, error reporting, etc.
<wolfspraul> oops, some merge I think :-)
<wpwrak> lekernel: or is this just your way of saying that you don't like C ? :)
<lekernel> and it's not even productive to write such code, compared to high level languages
<lekernel> C is fine when you need fast code on a RISC CPU
<lekernel> period
<wpwrak> seems that xiangfu's boss has returned ;-)
<xiangfu> rebase 'master' on upstream 'backfire', last upstream backfire commit date: [Mon Jan 17 02:15:27 2011]
<wpwrak> lekernel: i'd convert C to a more regular form, i.e., SSA, and then extract patterns from that. the fact that you have C on top doesn't really matter at that point, but you get "lean" operations without gazillions of dependencies and side-effects
<wpwrak> lekernel: i wouldn't be surprised if there was also research on alternative but similarly regular formats than SSA. after all, SSA is pretty old already and the work on obtaining efficient algorithms for the basic transforms seems to be more or less done. (haven't been following developments in the field for the last years, though)
<lekernel> SSA has nothing to do with problems posed by unrestricted usage of pointers and ad hoc code for every basic operation
<lekernel> C has the traditional CPU architecture built into its fundamental design
<lekernel> and you want to move away from this traditional architecture
<kyak> xiangfu: please help me resolve this "Pull is not possible because you have unmerged files." after git pull -\
<xiangfu> kyak: do you have un-commit modify ?
<kyak> xiangfu: there is one, and several untracked files
<xiangfu> kyak: I think it's will goto an temp branch. what is the output of "git branch"
<kyak> on master
<kyak> i think i understood you.. git branch temp; git checkout master?
<xiangfu> kyak: no.
<xiangfu> kyak:  when do rebase the git will goto a temp branch first. so I guess if the git pull, will also goto a temp branch first.
<xiangfu> kyak: can you wait me some minutes. I found there some file should not commit, let me delete them first.
<kyak> not sure.. it could do it in one step
<kyak> sure
<kyak> i think i have problems mostly because i'm working on master branch.. maybe it's better to branch always, as explained in git tutorials
<kyak> then i can always update master, and then move my updates there
<xiangfu> when you do git pull , you can run "git stash" backup you un-commit first.
<kyak> git: you'll never know when it kicks you :)
<xiangfu> then after pull, run "git stash pop"
<kyak> yeah, i do it sometimes, when i have conflicts
<kyak> but in this case, dozens of "added" files appeared for soem reason
<xiangfu> kyak: too bad, there are some temp files commit. I need sometime cleanup it.
<wolfspraul> kyak: for m1, I think we should not get stuck in fpga vs. asic thinking
<wolfspraul> I hope we are able to establish milkymist for the long run, and build greats products with it
<wolfspraul> then we have to dramatically lower the barrier of entry to use fpgas in free software - we leave the path to asic open whenever that makes sense anyway
<wolfspraul> what I like about m1 is that it is a product, so we can skip all the theory talk and focus right away on making something that works, same as with the Ben
<wolfspraul> it is not the fpga's fault that software tools to utilize its power have been developing so slowly, in free software it's even worse
<wolfspraul> the tools are so bad, I think I can compare it to a normal let's say Intel CPU, and then all apps are run in Python. No C compiler all, let's say the C compiler for some reason only works for the kernel and the Python interpreter.
<wolfspraul> then people run all their apps in Python, weather forecase, databases, everything.
<wolfspraul> that would certainly grind down even the latest and greatest stuff, and it's what I think is being done to FPGAs currently
<wolfspraul> I agree we need to get the price of m1 down, but first we need to make it a full product/package, then start to bring the price down. It will take some time...
<qi-bot> [commit] Xiangfu Liu: update the qi-hardware sources mirror address http://qi-hw.com/p/openwrt-xburst/efd9373
<qi-bot> [commit] Xiangfu Liu: bash-files: update the package url http://qi-hw.com/p/openwrt-xburst/b4d7537
<qi-bot> [commit] Xiangfu Liu: add 127.0.0.1 BenNanoNote to hosts file http://qi-hw.com/p/openwrt-xburst/aaaef18
<qi-bot> [commit] David Kühling: fix DNS timeout problem when applications resolve the FQDN http://qi-hw.com/p/openwrt-xburst/2a870e5
<qi-bot> [commit] David Kühling: undo hosts file fix.  Xiangfu was quicker and did it better :) http://qi-hw.com/p/openwrt-xburst/38a5421
<qi-bot> [commit] David Kühling: Adapt config.full_system to new emacs package name.  Add emacs japanese http://qi-hw.com/p/openwrt-xburst/d0e0372
<qi-bot> [commit] Xiangfu Liu: update package to known-good revisions, thanks David Kuehling http://qi-hw.com/p/openwrt-xburst/ef77ca6
<qi-bot> [commit] Xiangfu Liu: config.all_packages: remove mp3, mp4, rootfs, u-boot http://qi-hw.com/p/openwrt-xburst/5bbdc66
<qi-bot> [commit] David Kühling: Add gfortran compiler support to the toolchain http://qi-hw.com/p/openwrt-xburst/fae2ee8
<qi-bot> [commit] Xiangfu Liu: configu.full_system: remove IB and Toolchain http://qi-hw.com/p/openwrt-xburst/94ddef2
<qi-bot> [commit] Xiangfu Liu: using 'strip' instead of 'sstrip' http://qi-hw.com/p/openwrt-xburst/708d901
<qi-bot> [commit] Xiangfu Liu: config.full_system, add math stuff and some new pakcages http://qi-hw.com/p/openwrt-xburst/b0ccf2b
<qi-bot> [commit] kyak: put qi openwrt-packages git on top in feed.conf http://qi-hw.com/p/openwrt-xburst/60dec5b
<qi-bot> [commit] David Kühling: use ccache also for C++ compilation http://qi-hw.com/p/openwrt-xburst/a63d39d
<qi-bot> [commit] Xiangfu Liu: enable the toolchain option for Octave and libgfortran http://qi-hw.com/p/openwrt-xburst/8e334fb
<qi-bot> [commit] Xiangfu Liu: config.full_system-add-more-php5-modules.patch http://qi-hw.com/p/openwrt-xburst/752f820
<qi-bot> [commit] Xiangfu Liu: config.full_system: add package sqlite2-cli http://qi-hw.com/p/openwrt-xburst/ebf59b7
<qi-bot> [commit] Xiangfu Liu: feeds.conf add @revision to feeds.conf http://qi-hw.com/p/openwrt-xburst/b458f29
<qi-bot> [commit] Xiangfu Liu: INSTALL_FGORTRAN needs those two options http://qi-hw.com/p/openwrt-xburst/351a2b5
<qi-bot> [commit] Xiangfu Liu: config.full_system: add recently new packages http://qi-hw.com/p/openwrt-xburst/3adb62d
<roh> wolfspraul: i would not wonder if the mm1 also sells well as a develboard
<roh> wolfspraul: i compared some prices and actually all develboards seem to be more expensive (and have less interfaces) when they use the same, similar or bigger fpga. the only ones (fpga develboards) priced below 350us$ are the ones with spartan3 or really small spartan6 or similar sized chips
<kyak> wolfspraul: ok, let's think about MM1 as "FPGA computer". What i can do with it? It is positioned as a VJ station, and i don't really understand how i make use of it...
<wolfspraul> hard to answer for me because I haven't use it much yet myself
<wolfspraul> I like to work late at night, and I like to listen to music while working.
<wolfspraul> so that's a starting point :-)
<wolfspraul> once I have my own m1, I will definitely let it project something - what I don't know yet
<kyak> i think roh is right, it will be used as a dev board mainly
<wolfspraul> it shouldn't be too distractive because I'm still working...
<wolfspraul> I believe in software as the enabler.
<wolfspraul> software has to get easier and easier - once that's the case people will drive it into more use cases
<wolfspraul> as a 'dev board', well let's see I don't know
<wolfspraul> I doubt I can understand the motivation of someone buying a 'dev board' per se. Need to know what comes next.
<wolfspraul> I think a lot of people who buy a dev board buy it out of an almost automatic habit.
<wolfspraul> for example I've heard this several times:
<wolfspraul> company decides to use chip X for a new project, company buys one (or multiple, depending on team members) 'official' devboards for that chip
<wolfspraul> they totally don't care about the actual features of the devboard, it's just a habit, a way of running a project
<wolfspraul> in that case there is no chance to replace that devboard with an m1
<wpwrak> it gives them a baseline. basically completes the documentation :)
<LunaVorax> Hi everyone !
<wolfspraul> yeah
<LunaVorax> I have a technical question
<wolfspraul> wpwrak: and often not used at all in the end.
<LunaVorax> Does an emulator of the CPU used in the Ben Nanonote do exist ?
<wolfspraul> also many projects get canceled, but by that time the devboards were already sold...
<wpwrak> wolfspraul: yeah. it's kinda like insurance :)
<wolfspraul> LunaVorax: I think qemu works to a degree, but I don't know details maybe others do...
<LunaVorax> Ok wolfspraul
<LunaVorax> It's MIPS architecture right ?
<wolfspraul> kyak: it is too early to come up with really convincing use cases.
<wolfspraul> the VJ is one
<wolfspraul> I am _sure_ we will come up with others, but it depends on us, how we get software to run on it, software as the enabler of use cases...
<wolfspraul> then those use cases need to be marketed too
<wolfspraul> kyak: have you seen this? http://visikord.com/
<wolfspraul> it's something that m1 probably could do relatively easily
<wolfspraul> a nice usecase I think
<kyak> not seen
<wolfspraul> bundle m1 with camera and projector, and you have a nice dance augmentation system...
<kyak> sounds cool.. only i 'm not a dancing type :)
<wolfspraul> this is also guess-land, but I guess it would be easy to implement real-time video & audio compression, say into Ogg Theora, and then stream it over Ethernet
<wolfspraul> maybe you can do this with other computers too, but you do need some 'computer' to do it, why not an M1 box...
<wolfspraul> dmx and midi offer interesting and unique use case opportunities too, need to see which are the low hanging fruits there in terms of getting software ready
<wolfspraul> roh had the idea to hack the video-in signals to what? a 3-channel scope?
<wolfspraul> forgot
<xiangfu> kyak: hi seems now, everything is ok. remove duplicate merge commit.
<xiangfu> kyak: do you lose anything?
<zrafa> wolfspraul: do you know if m1 would have the same customs tratamiento than nn?.. I mean, if I would buy one I would like to know if it would be the same from a custom point of view (I know that I should know better than you perhaps, after all, I live here :P .. but maybe you already know some m1 features customs would like to use for disturbing buyers)
<zrafa> wolfspraul: tratamiento=treatment :P
<wpwrak> zrafa: the power supply
<roh> m1 coult be more complicated depending on where
<roh> e.g. the us seems to think: 'powerfull fpga == weapons grade technology' ;)
<zrafa> wpwrak: ah :( .. but we could ask to remove that from package before shipping right?
<wpwrak> zrafa: yup. that's how i solve this sort of issue. did it twice already successfully. (not sure if they would have caught the power supply if it had been there, though.)
<zrafa> roh: (weapons technology).. ah.. that will not happen here I guess (Arg). They will think "what is fpga?"
<zrafa> roh: well if they look in google, maybe find the us customs thinking "it is weapons grade technology" :P
<roh> zrafa: i am in germany and had customs hassle with getting a beagleboard from the us
<wpwrak> i don't think weapons are a problem at the moment. right now. drugs are the thing they have to watch out for. at least until the latest scandal (about a ton of cocaine airlifted from argentina to spain) has calmed down a little :)
<roh> in the end i gave digikey the finger and used different hw
<xiangfu> kyak: if you don't lose anything, we can do 1. git fetch -a  2. git reset --hard origin/master, for force local master sync with server
<roh> if i can avoid it i dont buy anything from the us. its just pain. the rest of the planet is easy compared to that.
<zrafa> roh: ah, I see.
<roh> wpwrak: the tunesian ex-first lady supposedly airlifted about 1.5tons in gold out of the county while fleeing ;)
<zrafa> wpwrak: yeah.. and all for that tiny cocaine package for personal use
<roh> hrhr
<wolfspraul> zrafa: we can ship it without the power adapter
<wolfspraul> then we can ship the power adapter separately, see whether it passes, or you get the power adapter locally
<wolfspraul> you are still in Argentina, right?
<wpwrak> roh: yeah. private cargo flights seem to be popular these days ;-)
<zrafa> wolfspraul: yep, Argentina
<zrafa> wolfspraul: and the power adaptar should be easy to get here I guess
<roh> sometimes i wonder if there should be a wiki documenting such oddnesses
<wolfspraul> wpwrak: I have never seen that logo anywhere (watching for it now), but it's mostly a printing problem :-)
<LunaVorax> Wasn't there a Nanonote2 wishlist or something, I though I saw one some weekd ago
<roh> like 'open logistics and sales'-wiki
<wpwrak> wolfspraul: :-) some of the big names have it. ibm, asus, fujitsu, etc.
<wpwrak> LunaVorax: i wonder if the "nanonote2" (officially "ya") is really still on the roadmap. it's been a long time since i heard about any plans for that.
<roh> wpwrak: i think thats a more difficult question.
<LunaVorax> Too bad if it has disapeared, the nanonote lacks some important features (like video out and usb host)
<roh> there is the want. the could... the experiences and then the opportunies
<roh> the last being a combination of money and avail materials (chips which one can buy not only talk about (etc))
<roh> LunaVorax: video out? whatfor?
<LunaVorax> well vga out to plug on a bigger screen :o
<roh> m-)
<LunaVorax> I was working for a mod to turn the nanonote into the board of an arcade cabinet
<roh> will not happen. waste of money (and mechanically unfeasible)
<LunaVorax> But the lack of video out stopped me
<LunaVorax> Like, real quick
<wpwrak> roh: yeah, basically no growth in development resources, and i suppose neither in finances
<roh> i built a mame-o-mat (arcade machine mechanics with a pc inside) once.. running linux and mame and hundreds of games
<LunaVorax> Yeah roh my idea is a bit more complex
<LunaVorax> Maybe not the right place to talk about it
<roh> real badass-hack. running the mame on fbdev, having some  menu infront and shell hacks around that. using a second keyboard pcb connected to the mechanical buttons
<LunaVorax> But if I had the knowledge for it I would have took the nanonote's schematics and modifieds them just to add/remove the features I wanted
<wpwrak> LunaVorax: now here's your chance to learn :)
<roh> the point is: the nanonote is a low end multimedia computer (low end because its <1ghz cpu, no hw-accel gpu etc)
<LunaVorax> I think it's starting way too high for a beginning wpwrak :P
<roh> but thats ok. anything high end would suck the batteries dry asap
<LunaVorax> roh, not a problem
<wpwrak> LunaVorax: for video out, there are chips that can do basic vga out. e.g., the propeller. you would be extremely limited in what you can display, but if you connected it to the ben, you could, say, have a text screen with relative ease.
<LunaVorax> wpwrak, I was thinking about graphics actually
<LunaVorax> I guess that's a different story then
<wpwrak> LunaVorax: make small steps. build the ben-blinkenlights board. then add an mcu that blinks on its own. then make it talk to the ben. and so on.
<LunaVorax> I should make tinyer steps wpwrak since I understood 50% of your sentence
<LunaVorax> :D
<LunaVorax> But I'm much into learning programming for now
<LunaVorax> And messing around with my arduino stuffs
<LunaVorax> More advanced electronics may (or not) happend later
<wpwrak> LunaVorax: ben-blinkenlights is a rather simple board: http://www.almesberger.net/misc/ben/blinken/blinken-100831.jpg
<LunaVorax> Oh right,
<LunaVorax> Oh !
<wpwrak> LunaVorax: ah, arduino. that's already waaaay more advanced !
<LunaVorax> So that was that strange picture on the wiki
<wpwrak> ;-))
<LunaVorax> arduino is advanced ?
<wpwrak> LunaVorax: you can do a lot with it. of course, it has its limits, but you're not starting from zero
<LunaVorax> Yeah
<LunaVorax> wpwrak, what is the purpose of this ben-blinkenlights anyway ? To command them using the Ben Nanonote ?
<LunaVorax> I think I anwered my own question
<LunaVorax> answered*
<wpwrak> yes. the real purpose was to put the 8:10 card slot to use. proof of concept that we can indeed drive something there.
<wpwrak> this project then spawned a few more advanced designs: a passive cable/board combo to program the c8051f32x family of microcontrollers and then the atben board of ben-wpan
<LunaVorax> Hum ok, pretty unexpected for me
<wpwrak> illustrates the process of small steps: first do something trivial to make sure the basics (signals, software, mechanical) are okay. then build more ambitions things on it. well, ben-wpan is admittedly a fairly huge leap, because this also adds the whole complexity of RF.
<roh> wpwrak: btw: atmel solves the 8051-misery finally
<roh> atmega8U2 32U2 16U2 series is also in the 2.0-2.30US$ region like the c8051f32x
<roh> and it also got real usb, dfu etc
<wpwrak> roh: usb sans crystal ?
<roh> dunno. i think yes. it has an internal 8mhz rc which it also can use to generate the 48mhz via usbpll
<roh> my point is mostly not details, but the part that the reactions i get from embedded hackers when it comes to 8bit cpus and 8051 (from my pov understandable) are different but all in the region of *run
<roh> *
<wpwrak> roh: http://www.atmel.com/dyn/resources/prod_documents/doc7799.pdf section 20.2, page 185 says you still need a crystal
<roh> *eeek* *yikes* .. stuff like that. avr most of them like.. pic most of them also despise now
<wpwrak> roh: well, sdcc isn't the nicest compiler, that's true. but 8051 isn't *that* horrible.
<roh> true. still its a deadend nobody wants to even be near. (the arch)
<roh> cisc. ugly to read. complicated to do simple stuff
<wpwrak> yeah, everybody uses it. the obvious hallmark of a deadend ;-)))
<roh> bad clockcycles vs getting stuff done ratio
<wpwrak> nice single-bit i/o operations
<roh> so what. every serious mcu has that
<roh> even the z80 clones
<wpwrak> peripherals suck a bit, though. but i'm not sure how much of this is the 8051's fault.
<wpwrak> single-bit i/o ? no, not really
<roh> still pain nobody wants to see again. (peripherals from that time)
<roh> most had theses mcs51 learning computer experiences in school.
<wpwrak> well, the 8051 arch doesn't bother me so much. the sdcc compiler bugs are a bit of a nuisance, though. but also that got better.
<roh> single bit iolike sbi cbi? or what do you mean?
<wpwrak> i don't know the assembler. but that sounds about right, yes
<wpwrak> set/clear bit
<roh> wpwrak: i think you can understand why people avoid such cpus after having worked with avr and similar post 1980 archs
<roh> btw: sbi and cbi are actually used by gcc in avr in some situations. means the gcc already does quite some cool optimisations
<wpwrak> i've worked with z80, 6502, 8086, ia32, pic, m8c, avr, arm, had some peeks at sparc, mips, vax, and propeller, and i don't find the 8051 overly repulsive
<wpwrak> maybe some people are just sissies ;-)
<roh> about the crystal.. whats the issue there?
<wpwrak> space, cost, yield
<roh> even for a serial one needs one to have not shitty baudrates
<wpwrak> the usb host gives you an accurate clock. use it :)
<roh> only as long as its plugged. its usb. it doesnt mean permanent connection
<wpwrak> often enough, it does. but yes, if you unplug, the scenario changes.
<roh> if your device gets bus powered only thats correct. still you need some special purpose pll for that inside the chip
<wpwrak> sure. but the problem has been solved. that is, unless you insist on avr. then you still have to wait until atmel figure it out, too ;)
<roh> i dunno how that works in detail.. even every usb hub i know has a crystal. and every serial2usb also
<wpwrak> (ftdi have also caught up at long last. of course, their is the evil kingdom of secrecy, with the predicable result on the quality of free software support.)
<roh> wpwrak: my point mostly is: with 8051 you are riding a dead horse and nobody wants to hop on and help out/send patches develop extensions, reuse code etc. thats what opensource is all about. (community of developers)
<roh> with avr you are sitting in a melting pot of people who are motivated to do stuff. or abuse your hw with different fw to stuff we never thought about
<wpwrak> nonsense. lots of people are developing on 8051. also open stuff. it just seems that the communities don't mix much.
<roh> means more hw sales, more developers, more rapid growth in community and sales
<roh> wpwrak: i know lots of hackers and they all stay clear of platforms like that. sure, if neccessary one hacks and disassembles everything. but if one can avoid it...  its not a likely choise for stuff you are not paid to do
<wpwrak> give me an avr that is as nicely integrated as the c8051f32x series and comparable cost and i'll switch in a heartbeat. that is, usb without crystal, built-in ldo, reasonable amount of flash, the basic peripherals.
<roh> i think the ldo are in there
<roh> 8-32k flash. 512-1k ram and eeprom each
<wpwrak> for me the main weakness of the c8051f32x is that they're not good with battery power (well, without external stuff)
<roh> all the avr peripheral niceties
<roh> and the low-power stuff gets quite well with avr now too.. not as crazy as the msp430 stuff or specialised pics i think
<wpwrak> roh: (avr and ldo) only for 5V i/o. otherwise you need an external supply.
<wpwrak> naw, the avr core is nice, but a lot of the rest of their technology is deeply last millennium
<roh> wpwrak: sure? (ldo) .. it looked like it does its own 3.3 from the usb 5v
<wpwrak> figure 20-6, page 188
<wpwrak> oh, wait
<roh> thats just one option when bypassing the internal 3.3v ldi
<roh> eh ldo
<wpwrak> naw, got that wrong. you're right. they can do it. figure 20-4
<roh> thats like special for the new usb variants
<roh> these U2 variants seem to be the successor of the at90usbxxxx stuff
<wpwrak> yeah, with usb, you kinda need it :)
<wpwrak> now they just need to get rid of the crystal :)
<roh> wpwrak: use a ceramic resonator
<roh> works as well
<roh> cheap also
<wpwrak> (resonators) you can choose between accurate or cheap ;-)
<wpwrak> atmel specify 0.25% tolerance for usb use. a resonator that does that costs about as much as a crystal.
<roh> wpwrak: the spec derives from the usb requirements i guess. even serial needs <3% real world to work
<wpwrak> (spec) probably, yes.
<roh> usb is picky
<wpwrak> yeah, in many ways :)
<wpwrak> zrafa: you should post it here ;-)
<zrafa> haha :)
<zrafa> tip for nn when something is doing problems : http://www.youtube.com/watch?v=Fow7iUaKrq4
<wpwrak> zrafa: "I was coding shit in MIPS while you were playing Space Invaders." (-:C
<zrafa> wpwrak: ;-))
<qi-bot> [commit] Werner Almesberger: lib/Makefile.common: changed "clean:" to "clean::" to allow for additions http://qi-hw.com/p/f32xbase/ab915dd
<wpwrak> let's see how the electricity is doing ... had to shut down the "old" branch again, because the differential circuit breaker tripped
<wpwrak> oops, wrong channel
<qi-bot> [commit] Werner Almesberger: atrf-txrx: cleaned up the usage output http://qi-hw.com/p/ben-wpan/5407180
<qi-bot> [commit] Werner Almesberger: atrf-txrx: added ability to record received frames in pcap format http://qi-hw.com/p/ben-wpan/f9aee54
<qi-bot> [commit] Werner Almesberger: atrf-txrx: added BER test pattern transmit mode http://qi-hw.com/p/ben-wpan/999ce53
<qi-bot> [commit] Werner Almesberger: atrf-txrx: define the pcap file magic number (0xa1b2c3d4) in pcap.h http://qi-hw.com/p/ben-wpan/ea81e70
<qi-bot> [commit] Werner Almesberger: atrf-txrx: renamed BER (bit error rate) test to PER (packet ...) test http://qi-hw.com/p/ben-wpan/96e8fc6
<qi-bot> [commit] Werner Almesberger: misctxrx.c (wait_for_interrupt): let "ignore" control printing more tightly http://qi-hw.com/p/ben-wpan/1fb05c2
<qi-bot> [commit] Werner Almesberger: tools/atrf-txrx/perdump: new utility to analyze a PER dump http://qi-hw.com/p/ben-wpan/6002759
<wpwrak> grmbl. no useful transmission bathroom -> office
<qi-bot> [commit] Werner Almesberger: perdump: print relative receive timestamp http://qi-hw.com/p/ben-wpan/6282c33
<wolfspraul> wpwrak: sorry I was too sleepy last night to reply to LunaVorax and Ya...
<wolfspraul> flew back to China overnight...
<wolfspraul> I think Ya is very much on the table/roadmap, why not?
<wolfspraul> I am as 100% committed to Qi as ever, and I often 'reboot' my mind thinking what I would do if I would start from zero today.
<wolfspraul> but so far the conclusion is always to continue exactly where we are now :-)
<wolfspraul> there is no point in blindly building (buying) more powerful hardware
<wolfspraul> we threw some money at the Ben to get the ball rolling, but now it's about converting the momentum to true copyleft, or free software driven momentum
<wolfspraul> as soon as we have a package that we believe we can build into a Ya NanoNote that would sell really well, we'll do it, why not?
<wolfspraul> and the pieces for that package are coming together one by one
<wolfspraul> I doubt that we will start selling Ya NanoNote in 2011 however.
<wolfspraul> but let's see...
<wolfspraul> I'm not very motivated about the 4760 right now, that's a bit of an on-and-off love.
<wolfspraul> for Ya NanoNote, we must do something that will be enthousiastically welcome by our current Ben customers.
<kristianpaul> (I'm not very motivated about the 4760 right now), wow when i met you that love was no so off :-), well at that time wasnt even M1 board yet
<kristianpaul> copyleft hardware for touch based screens is not bad idea
<wolfspraul> kristianpaul: yes, at some point we need to look at capacitive touch, I agree
<wolfspraul> one by one though :-)
<wolfspraul> for touch, I think we should skip resistive, even if we get it to work well it will be discredited as 'old/outdated' by the larger audience
<wolfspraul> and if we look at capacitive, we should not attempt to make our own controller, for a number of reasons it's too hard
<wolfspraul> so then it basically comes down to sourcing the whole screen including multi-touch capable controller, and talking to it just with UART or so
<wolfspraul> which is actually easy, but unfortunately not very copyleft.
<wolfspraul> just my present thinking on this subject, I (hopefully) keep learning...
<wolfspraul> kristianpaul: [4760] depends on Ingenic really
<wolfspraul> I never understood my work as writing free drivers to help others sell proprietary technology.
<wolfspraul> we made the first step to get the NanoNote to work, and will continue to improve software for the Ben.
<wolfspraul> whether we continue with 4760 or switch to a Milkymist-based solution right away is Ingenic's choice
<wolfspraul> anyway that's what I will do :-)
<wolfspraul> btw, xiangfu is working quite hard to get 100% of Ben NanoNote support into u-boot upstream
<wolfspraul> the Linux kernel is far more important, but u-boot also needs to get out of the way (= all into upstream)
<wolfspraul> kristianpaul: how is your m1 and scope doing? :-)
<wolfspraul> hey I just noticed rjeffries was on this channel! cool!
<kristianpaul> (one by one though) agree
<wolfspraul> rjeffries: is it the Real Ron?
<kristianpaul> (Ingenic) you mean you tried call Ingenic atention basically with all the work around nannote, but they just ignored it?..
<wolfspraul> no not ignore, not at all.
<kristianpaul> At least try to show other ways of work?
<wolfspraul> but the question is - is it a fair give and take? for me it connects to whether we can make copyleft hardware sustainable or not
<wolfspraul> if our work is free work to help others sell proprietary hardware, then it's absolutely unsustainable and will fail
<kristianpaul> (right away is Ingenic's choice) yeah sure is too early, both worlds are needed
<kristianpaul> So if 4760 is not the way, some other chip eventually will.. i guess
<wolfspraul> if Ingenic wants to build great hardware that works well with free software, and help us with documentation, learn about how to be efficient about upstream, etc. then I can continue with them.
<kristianpaul> And what they tought about that?
<wolfspraul> 4760 is on the table, I was just saying that I don't PUSH right now towards a 4760-based Ya
<kristianpaul> sure
<wolfspraul> I'm not fixing Ingenic's internal problems (as I see them) for free. not interested.
<wolfspraul> for example they suffer from some internal wishful thinking culture, i.e. the tech people just say "this or that works", when it actually doesn't.
<wolfspraul> and the executive people don't take the time to proove them wrong.
<wolfspraul> well then
<wolfspraul> another big problem is that they have this idea of a 'unified' driver set across OS'es
<kristianpaul> Is not that what happen mostly everywhere? ;-)
<wolfspraul> so they acknowledge that they are failing to upstream things, but instead of fixing that in a way that I believe is good, they fix it by going in exactly the opposite direction.
<wolfspraul> so they introduce 'Ingenic layers' to make it easier to hop from one Linux kernel to another, or even across other kernels like proprietary real-time kernels.
<wolfspraul> naturally that will totally break-down at some point, but as long as they can pay the bills, who cares :-)
<kristianpaul> :-)
<wolfspraul> you expect me to continue to clean this up? for free? for how long?
<wolfspraul> I should rally unpaid free software developers to fix what XX Ingenic employees do wrong?
<wolfspraul> and then Ingenic grows to 2*XX employees, so we got to work twice as hard to fix it?
<wolfspraul> then they go to 3*xx people?
<wolfspraul> and so on
<wolfspraul> no way
<wolfspraul> :-)
<kristianpaul> Well the product is out there (nanonote)
<wolfspraul> yes, and it develops nicely.
<wolfspraul> kristianpaul: how is your m1 and scope doing?
<kristianpaul> scope i did some other self calibration, now i need more time to inject some simulated signals
<kristianpaul> M1 as i said before was already flashed from scratch (i erased whole flash)
<kristianpaul> Now, i'm reading about rtems, to get some similiar working env to the one i had on SIE so i can migrate smoothly
<kristianpaul> My idea so far i get some nfs/ftp mount point, and a working tty by the jtag-serial cable
<kristianpaul> As i had some basic experience with my avnet board and the MM SoC that is the last part i'll look at, now RTEMS is my home work
<wolfspraul> nice, sounds good
<kristianpaul> In theory dint look so hard to program (rtems), i'm just ready to posibly find some bugs on ethernet part as sebastien warned. so lets see what came up :-)
<kristianpaul> ah i also tested and wired the Scope to my home network, wich works and is helfull to export data from screen
<kristianpaul> In the other side about gps-sdr i'm working with a guy called Fabrizio Tapper, wich is suporting me on the sofware part for initial analisys of already dumped data from sige board
<kristianpaul> I insisted him to join irc, but i guess is busy, but he is very kind and is helping me a lot with some doubds and also code
<kristianpaul> s/doubds/douts
<kristianpaul> doubts*
<kristianpaul> argg englush complicated words :p
<kristianpaul> So thats the all for now
<kristianpaul> btw i dint noticed bibrations from the scope yet..
<kristianpaul> well, i'm off for now
<kristianpaul> wolfspraul: i'll try to send a gps-sdr update to mail-list follwing wpwrak wpan news :-)
<wolfspraul> yeah
<wolfspraul> Werner's mail was so heavy that I'm still digesting :-)
<wolfspraul> but it's all good stuff of course
<wolfspraul> only nobody is able to give any meaningful reaction, he he
<kristianpaul> I hope find more people intereted in analize data from scope wich is on download.qi-hw.com btw !
<wolfspraul> good idea!
<kristianpaul> interested*
<wolfspraul> you should not find those vibrations
<wolfspraul> hopefully
<kristianpaul> ahh ;-)
<kristianpaul> well mine will not be so heavy i hope :-)
<wolfspraul> I am very very careful if I sell something, or ask someone to pay part of the costs, that really only good stuff goes out.
<wolfspraul> it's like 'full disclosure'
<wolfspraul> so with the scope, one day you may notice, but then there should be a workaround (just turn off and back on)
<wolfspraul> let's see