2011-07-07 01:02 The build was successfull, see images here: http://fidelio.qi-hardware.com/~xiangfu/compile-log/openwrt-xburst.full_system-07052011-2120/ 2011-07-07 01:34 wolfspraul: did you see the discussion here ? http://www.heise.de/meldung/Bericht-Microsoft-bittet-Samsung-fuer-Android-zur-Kasse-1274692.html 2011-07-07 01:34 wolfspraul: nobody thinks free software is dead ;-) they all see pretty clearly where the problem is 2011-07-07 01:35 heise is not read by newcomers 2011-07-07 01:35 duh. Bild then ? ;-) 2011-07-07 01:43 hmm, read it 2011-07-07 01:49 I'm surprised that you can still read the heise comments. I just click on a few, see all the screaming, trolling, bad jokes etc. and stop 2011-07-07 01:49 not 1 original thought in 100 of them, or so 2011-07-07 01:58 oh, i usually just pick a few. to see if there's anything interesting 2011-07-07 03:01 wolfspraul: by the way, i relived a bit of an openmoko experience today. tried to build the cross-toolchain of openwrt, to pick up some new features. 2011-07-07 03:01 wolfspraul: the experience reminded me very much of OE at openmoko ... 2011-07-07 03:03 what feature were you missing? 2011-07-07 03:04 we are trying to release prebuilt toolchains, but I guess it didn't help (I saw the chat) 2011-07-07 03:04 wolfspraul: so i'm afraid the core of the problem is still the complexity of a "desktop" distribution. you can try to escape it by starting with something much simpler (like you did with openwrt), but once you bring it up to speed, it'll be difficult, too. it's not quite as bad as OE, where your only choice was to ask the priests of the inner circle for some magic modifications/commands, but still not user-friendly 2011-07-07 03:04 (feature) SDL_gfx 2011-07-07 03:04 (chat) ah, good. then i don't need to repeat it all :) 2011-07-07 03:05 how ironic trying to fix my camera shuter when not having another camera to take pics of the disasembling process~ :-/ 2011-07-07 03:06 the best approach would be to have an environment with a minimum toolchain to get started plus the ability to install packages into that environment 2011-07-07 03:06 kristianpaul: ;-))) 2011-07-07 03:06 kristianpaul: you could remember the tradition of biologists in ancient times and make drawings :) 2011-07-07 03:07 wolfspraul: even the "default" minus "modules" (not quite sure what they are) is fairly heavy. a minimum core with gcc and libc should be much smaller. 2011-07-07 03:08 i think i will later this month, for now no camera to carry :( 2011-07-07 03:08 if you fail at pygames for the "base", you know something is a little off :) 2011-07-07 03:27 talking about games i think zear_ is in the same path of wpwrak, finding a non problematic way of porting games to the nn 2011-07-07 03:28 atrf-rssi isn't exactly a game, but ... ;-) 2011-07-07 03:28 you could use atrf-path as a game, though :) 2011-07-07 03:29 well, no that wpwrak will port games but youget the idea 2011-07-07 03:29 if i had brought a usb hub (or a laptop with more than 1 host port) to fisl, we could have had some fun with atrf-path :) 2011-07-07 03:31 kristianpaul: truth be told, what i find most worrying about today's experience is that i realized that people either have to use some fairly old toolchain, which was easy to build and works, or they should either have had some questions or be very independent. 2011-07-07 03:33 yeah, i agree, it was easy to build.. 2011-07-07 03:34 shame i deleted that folder.. when trying to get latest stuff 2011-07-07 03:34 ;-) 2011-07-07 03:34 first lesson: rename, don't delete :) 2011-07-07 03:34 too much renames, more when the thing is about 10GB big ! 2011-07-07 03:35 but anyway, i think wiki could be improved easilly, just with the well experience from xiangfu and kyak for example :) 2011-07-07 03:35 i'm now back tp the configuration of 9 months ago. which - oddly enough - seems to be more modern than the one from ~1.5 months ago 2011-07-07 03:35 i think the wiki is up to date now 2011-07-07 03:35 good ! 2011-07-07 03:35 not sure about the .config 2011-07-07 03:36 but there's also the quirk that uClibc regresses 2011-07-07 03:36 just use minimal, and grown from that 2011-07-07 03:37 well, may be you can find something more stable from openwrt upstream for backfire 2011-07-07 03:37 but of course no the same feeds will be there.. 2011-07-07 03:37 it seems that this is what that ABI breakage is about 2011-07-07 03:37 i didn't quite realize there was an ABI barrier until today 2011-07-07 03:38 hum.. 2011-07-07 03:39 ABI incompatibilities are very very bad. means that you can't easily try and then decide whether to proceed or revert 2011-07-07 03:39 at least not when changing one thing at a time 2011-07-07 03:39 so this sort of thing should be headline news, along with a migration plan 2011-07-07 03:40 could be that i just overlooked it, though 2011-07-07 06:24 wpwrak: yeah, it make sense - combination of toolchain-mipsel_gcc-4.3.3+cs_uClibc-0.9.30.1 is the correct one 2011-07-07 06:27 wpwrak: so how is sdl-gfx doing? You should have it in your toolchain now 2011-07-07 06:28 wpwrak: perhaps at some point earlier you switched over to uClibc 0.9.32, but this is not right. Backfire uses 0.9.30.1, trunk uses 0.9.32 and it breaks binary compatibility 2011-07-07 06:30 wpwrak: i suggest that you also flash the latest release image to your Ben, it could be that you have one of the images when we switched over to 0.9.32 shortly, but then went back to 0.9.30.1 2011-07-07 10:57 kyak: (sdl-gfx) surprisingly, it doesn't seem to be there 2011-07-07 10:58 kyak: (backfire vs. trunk) what's the plan for the future anyway ? do you intend to switch one day from backfire ? 2011-07-07 11:03 kyak: i quite dislike the strtof regression in backfire. not being able to compile perfectly posix-compliant code without a warning isn't nice. 2011-07-07 11:07 wpwrak: the builds in buildhost are already based on trunk. 05-28 was the last backfire-based release 2011-07-07 11:08 and sdl-gfx has to be there :) 2011-07-07 11:08 grep libsdl-gfx .config 2011-07-07 11:08 should be =y 2011-07-07 11:09 and sdl-config and sdl libraries and headers should all be installed 2011-07-07 11:09 CONFIG_PACKAGE_libsdl-gfx=y 2011-07-07 11:10 ls staging_dir/target-mipsel_uClibc-0.9.32/usr/lib/libSDL_gfx.* 2011-07-07 11:10 should be your target-mipsel_uClibc.. 2011-07-07 11:10 No such file or directory 2011-07-07 11:11 target is target-mipsel_uClibc-0.9.30.1 anyway 2011-07-07 11:11 yeah 2011-07-07 11:11 this is strange 2011-07-07 11:11 ah yes, the library is there ... 2011-07-07 11:11 ah, includes too :) 2011-07-07 11:11 i looked under toolchain-mipsel_gcc-4.3.3+cs_uClibc-0.9.30.1 2011-07-07 11:12 it's target 2011-07-07 11:12 let's see what this changes .... 2011-07-07 11:12 anyway, locate the sdl-config 2011-07-07 11:12 it will give you the right path 2011-07-07 11:13 sdl-config is somewhere here: ./staging_dir/target-mipsel_uClibc-0.9.32/host/bin/sdl-config 2011-07-07 11:13 $ ./staging_dir/target-mipsel_uClibc-0.9.32/host/bin/sdl-config --libs 2011-07-07 11:13 -L/home/bas/build/openwrt-xburst/staging_dir/target-mipsel_uClibc-0.9.32/usr//lib -lSDL -lpthread 2011-07-07 11:14 grmbl. no cross-toolchain under target. that's where the problem comes from 2011-07-07 11:14 the toolchain is under the toolchain* 2011-07-07 11:14 does gcc have target in its include search list ? 2011-07-07 11:15 if you split toolchain and target (and don't add target to gcc in some other way) all the automatic searches fail 2011-07-07 11:15 that's why you need hacks like STAGING_DIR 2011-07-07 11:15 now it all begins to make sense ;-) 2011-07-07 11:15 it works fine from within openwrt build system 2011-07-07 11:16 because all the necessary variables are passed to configure/make 2011-07-07 11:16 yes, because you override all the search paths :) 2011-07-07 11:17 that's an exquisitely inconvenient way to do cross-compilations. instead of just having to rename your compiler, you need to pass the directory structure into the makefiles 2011-07-07 11:18 i'm sure there is a perfect explanation for that. I'm just not an expert regarding openwrt build system 2011-07-07 11:18 where's xMff when we need him ? :) 2011-07-07 11:19 and again, you don't need to pass anything to makefile in most cases 2011-07-07 11:19 well designed applications a ported like that 2011-07-07 11:20 but i need to pass -L$(TARGET)/usr/lib and -I$(TARGET)/usr/include, right ? 2011-07-07 11:20 $(STAGING_DIR)/usr/... 2011-07-07 11:20 at least if i'm compiling outside the openwrt build system 2011-07-07 11:20 so STAGING_DIR = ..../target..., okay 2011-07-07 11:21 yes 2011-07-07 11:21 xMff: why are you making this so complex ? :) 2011-07-07 11:21 xMff: if you had everything in the same hierarchy, gcc would automatically pick the right includes and libraries 2011-07-07 11:22 thats wichful thinking 2011-07-07 11:22 *wishful 2011-07-07 11:22 xMff: works great on jlime ;-) 2011-07-07 11:22 its already hard enough to get autofail to not act up 2011-07-07 11:22 well whenever I hear from Oe its people having troubles compiling :) 2011-07-07 11:22 (autocrap) well, that's certainly true :) 2011-07-07 11:23 (oe) i think the secret is to let others do the compiling for you :) 2011-07-07 11:23 bbl work 2011-07-07 11:24 e.g., i've never ever compiled an entire redhat, debian, or ubuntu from sources. maybe a source package every few years. why should we have to work so much harder in the embedded world ? :) 2011-07-07 11:30 wonders if one couldn't just symlink the target tree into the toolchain tree. there are a few duplicate files that need looking at 2011-07-07 11:50 because most software simply sucks at cross compiling 2011-07-07 11:50 last time I checked not even gcc could compile itself without patches 2011-07-07 11:51 *cross-compile itself 2011-07-07 11:54 perl does not cross compile 2011-07-07 11:54 ruby does not cross compile 2011-07-07 11:54 most libtool deployments do not cross compile either 2011-07-07 11:54 libtool is a losing proposition anyway :) 2011-07-07 11:54 many autotools based packages fail in configure due to AC_TRY_RUN checks 2011-07-07 11:55 autoreconf is not possible because automake broke its own api 2011-07-07 11:55 it's amazing how creative people are inventing solutions that just break things in more obscure ways 2011-07-07 11:55 autocrap is another set of problems, yes 2011-07-07 11:55 i was more thinking of sane developers who stay away from all such mess 2011-07-07 11:56 and in openwrt we split toolchain and target because we support multiple targets with the same toolchain 2011-07-07 11:56 munching that together breaks that completely 2011-07-07 11:56 oh. that makes merging hard :-( 2011-07-07 11:57 i knew there was a reason for splitting it! :) 2011-07-07 11:58 until recently we had to support gcc 3.x etc. 2011-07-07 11:58 now that this is gone we can maybe thing about --sysroot 2011-07-07 11:58 *think 2011-07-07 12:00 that sounds promising 2011-07-07 12:02 kyak: regarding backfire vs. trunk, what's the migration plan ? and what bnary compatibility does exactly break ? the kernel ABI ? the libc ABI ? a set of things scattered all over the place ? 2011-07-07 12:02 (multiple "yes" answers are possible ;-) 2011-07-07 12:03 hmm, yes, no, yes, yes? 2011-07-07 12:03 play blind answering 2011-07-07 12:03 stefan_schmidt: the good new: i had dirtpan send pings around. the bad news: RTT is horrible. dirtpan times out all the time and retries something like 10-20 times for each packet. 2011-07-07 12:04 wpwrak: ups 2011-07-07 12:04 stefan_schmidt: (1011) not a bad choice :) 2011-07-07 12:04 stefan_schmidt: i think if i relaxed the timeouts in dirtpan it would be happier. but the root cause is the 10 ms interrupt synchronization delay 2011-07-07 12:04 wpwrak: int missing or something else 2011-07-07 12:05 stefan_schmidt: naw, i think everything works as planned 2011-07-07 12:05 stefan_schmidt: just the plan needs some improvements :) 2011-07-07 12:05 wpwrak: ok, so it is the delay 2011-07-07 12:05 i'm now trying a different approach for synchronizing that shouldn't need the delay 2011-07-07 12:06 wpwrak: I was just going to prepare my little lowpan-perf tool for a run 2011-07-07 12:06 wpwrak: (w/o delay) cool 2011-07-07 12:07 (perf) good. then we can compare before and after :) 2011-07-07 12:15 has anybody found out about atben/atusb sales numbers now? 2011-07-07 12:16 maybe we have to do without them... 2011-07-07 12:16 wolfspraul: i haven't made it that far in my telepathy course yet ... 2011-07-07 12:16 wpwrak: the libc abi will break 2011-07-07 12:16 wpwrak: the uClibc binary compatibility is broken between backfire and trunk.. For the migration plan, i think xiangfu wanted to make a release couple of week after the next openwrt release (not sure when it would happen now though). Anyway, the trunk is already stable enough and all development is carried out in trunk only 2011-07-07 12:17 also the threading system changes 2011-07-07 12:17 from linuxthreads.old to ntpl 2011-07-07 12:17 yeah, the nptl thing 2011-07-07 12:18 okay, so host toolchain, libs, root image, extra packages, and local developments are affected 2011-07-07 12:19 yep 2011-07-07 12:19 will the names of the tools change as well ? (away from mipsel-openwrt-linux-uclibc-*) 2011-07-07 12:20 nah, these names remain the same 2011-07-07 12:23 good. so just a re-make will do for posix things 2011-07-07 12:25 pity openwrt doesn't use eglibc. otherwise, we could even have binary compatibility with jlime 2011-07-07 12:26 it allows to use eglibc 2011-07-07 12:27 oh, great ! what's the experience with it ? good ? 2011-07-07 12:28 no 2011-07-07 12:28 you trade one bag of annying bugs against another one :) 2011-07-07 12:28 what are the problems ? 2011-07-07 12:28 ;-)) 2011-07-07 12:29 well dunno, one has to try it again 2011-07-07 12:29 its been a while since it was added and only recently some work was invested in it 2011-07-07 12:29 ... again 2011-07-07 12:40 funny. atusb is making a little bit of noise when transmitting :) 2011-07-07 12:41 stefan_schmidt: things are still slowish. grmbl. 2011-07-07 12:45 wpwrak: hmm 2011-07-07 12:53 362 packets transmitted, 361 received, +1055 duplicates, 0% packet loss 2011-07-07 12:54 it's a feature: enhanced redundancy :) 2011-07-07 12:58 heh. and i found another bug in at86rf230.c ;-) 2011-07-07 13:20 hmm, a good marketing slogan for advertizing 64 vs. 32 bits just occurred to me: "pointer enlargement" 2011-07-07 13:20 lol 2011-07-07 13:22 wpwrak: have the same feeling you had with your ubuntu today with my debian 2011-07-07 13:22 been a while since the last update ? :) 2011-07-07 13:22 wpwrak: the kvm install I have had not a signle devel package installed. no pck-config, bison or whatever 2011-07-07 13:23 interesting errors to figure out what is missing 2011-07-07 13:23 yuck :) 2011-07-07 13:23 finally got lowpan-tools with my measurement tool compiled 2011-07-07 13:26 [commit] Werner Almesberger: at86rf230: we may be in BUSY_RX after commanding RX_ON (ben-wpan-stefan) http://qi-hw.com/p/qi-kernel/e21c6ed 2011-07-07 13:28 wpwrak: Received 10 from 10 packets 2011-07-07 13:28 Arithmetic mean rountrip time: 0.000000 seconds and 193495.203125 usecs 2011-07-07 13:28 wpwrak: thats roundtrip on lowpan level 2011-07-07 13:29 no re-transmit and other fancy stuff build in yet :) 2011-07-07 13:29 one meter distance directly next to an wifi AP :) 2011-07-07 13:30 wpwrak: 100 also without problem, going 1000 now 2011-07-07 13:30 interesting. you really have picosecond resolution ? ;-) 2011-07-07 13:31 ~200 ms. damn slow. lemme finish debugging my improved delay system 2011-07-07 13:32 wpwrak: nope, standard timeval, need to clean it up 2011-07-07 13:32 wpwrak: what wonders me is how reliable it is 2011-07-07 13:33 printf("%lu.%06lu", (unsigned long) tv_sec, (unsigned long) tv_usec); ? :) 2011-07-07 13:33 you can try a few times and see if the value is stable 2011-07-07 13:34 Received 1000 from 1000 packets 2011-07-07 13:34 Arithmetic mean rountrip time: 0.000000 seconds and 177617.531250 usecs 2011-07-07 13:34 Minimal time 0.000000 seconds and 161797.000000 usecs 2011-07-07 13:34 Maximal time 0.000000 seconds and 226437.000000 usecs 2011-07-07 13:34 pity you don't have any ben+atben. there, things are faster. 2011-07-07 13:34 looks consistent 2011-07-07 13:34 wpwrak: getting the 4 atusb from the university was all I asked for :) (I bought 2 myself) 2011-07-07 13:35 no lost package 2011-07-07 13:35 thats good. Now we can make it faster :) 2011-07-07 13:37 you said your work was on delay-tolerant networks. seems like the ideal playground ;-) 2011-07-07 13:37 heh 2011-07-07 13:37 point taken 2011-07-07 13:38 wpwrak: so your dirtpan retransmissions come due to lower backoff timer values? 2011-07-07 13:40 yes 2011-07-07 13:40 well, too low ACK timeouts to be precise 2011-07-07 13:40 dirtpan takes the klingon approach and never backs off :) 2011-07-07 13:40 heh 2011-07-07 13:41 never, listen, never I say I will backoff :) 2011-07-07 13:42 wpwrak: wrt driver name and location. It feels like it should move to drivers/ieee802154/ 2011-07-07 13:42 name I don't care much 2011-07-07 13:42 But its not that easy to share code with atben anymore it seems 2011-07-07 13:43 not sure it is worth the sharing 2011-07-07 13:43 yeah, they've diverged a bit. just a few infrastructure bits are common. 2011-07-07 13:44 oh delay tolerant networks! 2011-07-07 13:44 would be confusing just for the generic spi_master bits imho 2011-07-07 13:44 also, a lot of the code in atben was there just for demonstration purposes, e.g., the classifier or the interrupt forwarding. atben doens't need any of this 2011-07-07 13:44 if there are pointers to apps/libs that we can port to the Ben, please post 2011-07-07 13:44 wolfspraul: yup, doing it as my diploma thesis with 802154 :) 2011-07-07 13:45 I just want to make sure we create openwrt packages and get it to the Ben... 2011-07-07 13:45 (confusing) agreed. not really worth the trouble for maybe 50 lines 2011-07-07 13:45 I assume there will be some middleware/libs or what not 2011-07-07 13:45 wolfspraul: using ibr-dtn here (implementation for the institute I'm working at). They already use openwrt for other systems and its all free software 2011-07-07 13:46 wolfspraul: its the daemon for the protocol and some tools that work with it. Let me search the URI 2011-07-07 13:47 wolfspraul: http://www.ibr.cs.tu-bs.de/projects/ibr-dtn/getstarted.html 2011-07-07 13:47 wolfspraul: overview: http://www.ibr.cs.tu-bs.de/projects/ibr-dtn/ 2011-07-07 13:47 wolfspraul: btw,july news on sunday ? you once mentioned 10 days :) 2011-07-07 13:48 wolfspraul: should be easy to grab the openwrt recipes(?) and integrate it with your build 2011-07-07 13:48 wpwrak: so we leave both drivers on its own 2011-07-07 13:48 wpwrak: but both should be in drivers/ieee802154 as they rely on at86rf230 anyway. 2011-07-07 13:53 wpwrak: no way, I'm behind some serious todos, need to do those first 2011-07-07 13:54 hmm, maybe you could do the news for relaxation? :) 2011-07-07 13:55 wpwrak: Received 1998 from 2000 packets 2011-07-07 13:56 stefan_: good. so you could test the pakcet loss handling as well :) 2011-07-07 13:57 wpwrak: thats with 7byte payload btw, lets see what happens with a full payload 2011-07-07 13:59 yes, the delay difference would be quite interesting 2011-07-07 14:01 wpwrak: going to get my other parts running now. Measurements and DTN daemon. Once this is in place and I can have real numbers I'll come back to the driver level and work on auto ack and re-submit 2011-07-07 14:01 might take some time so 2011-07-07 14:01 great 2011-07-07 14:01 wpwrak: will keep you in the loop with measurement numbers 2011-07-07 14:02 will track the driver closely for all improvements :) 2011-07-07 14:02 heh :) 2011-07-07 14:03 more serious, I will come back but time constraints push me to do some other things now. 2011-07-07 14:04 Received 2000 from 2000 packets 2011-07-07 14:04 Arithmetic mean rountrip time: 0.000000 seconds and 199789.437500 usecs 2011-07-07 14:04 thats with full payload 2011-07-07 14:05 so that's a difference of how many bytes ? 2011-07-07 14:07 and the full payload gets sent both ways ? or is it large foward packed and a small ack back ? 2011-07-07 14:14 wpwrak: 110 bytes difference and the full data is send both ways 2011-07-07 14:15 wpwrak: at86rf230 spi32766.0: invalid PHR 0xdd 2011-07-07 14:15 wpwrak: so it was not only a problem for you alone :) 2011-07-07 14:18 corruption does happen :) 2011-07-07 14:20 let's do the math ... the difference is about 22 ms. of this, 2*110*8/250 = 7 ms are spent actually sending data over the air. leaving 15 ms for copying to and from atusb 2011-07-07 14:21 the copying happens 4 times. so 3.75 ms per copy. that's about 30 kB/s. hmm. pretty slow. 2011-07-07 14:22 wpwrak: what worries me more is the overall high timing value we start with for a small package 2011-07-07 14:22 of course :) 2011-07-07 14:22 its factor 10 higher then it should be :) 2011-07-07 14:23 the driver does a lot of register accesses. maybe they're slow. need to check. 2011-07-07 14:23 but atben would do the same 2011-07-07 14:23 maybe the usb overhead is really that high? 2011-07-07 14:24 yes, that's what i mean 2011-07-07 14:24 ah, now we understand each other ;) 2011-07-07 14:24 the spi is about as fast as possible in atben 2011-07-07 14:24 <[g2]> Hey stefan_ !Â Â Long time 2011-07-07 14:25 wpwrak: I'm going to work on my little lowpan-perf pet. Will push it out later and let you know so you can test it on yours ben's if you like 2011-07-07 14:25 [g2]: indeed, quite some time. Still embedded linux is a small village ;) 2011-07-07 14:25 [g2]: how are you? 2011-07-07 14:25 <[g2]> well thx, hope you and yours are the same. 2011-07-07 14:26 [g2]: little bit stress to finally get my studies done and doing freelance work in parallel, but nothing dramatic :) 2011-07-07 14:26 <[g2]> I'm looking at the 6lopan stuff as of a week or two ago and found my new bff wpwrak that did the atben/atusb 2011-07-07 14:28 <[g2]> I'm just about done with the layout for mcu, I'm hoping to start the RF layout later this week 2011-07-07 14:29 [g2]: atusb starts to work since last night. :) 2011-07-07 14:29 <[g2]> sweet, you just built the hw ? 2011-07-07 14:29 [g2]: I just ordered it :) 2011-07-07 14:29 <[g2]> got my test atben boards yesterday 2011-07-07 14:30 [g2]: needed some 802154 hardware for my diploma thesis and added some on top for myself 2011-07-07 14:34 <[g2]> stefan_, can you say what you are making ? 2011-07-07 14:35 [g2]: sure, delay tolerant networking over ieee802154 networks 2011-07-07 14:36 [g2]: university website is only in german, sorry. 2011-07-07 14:36 <[g2]> are you going to add QoS for the long delays :) 2011-07-07 14:37 [g2]: but I worked on this topic earlier: http://datenfreihafen.org/~stefan/papers/study-thesis-final.pdf 2011-07-07 14:37 [g2]: we don't care of the delays, thats the trick :) 2011-07-07 14:37 [g2]: My job is to write/extend a convergence laer between the ieee802154 stack under linux for our dtn implementation 2011-07-07 14:40 <[g2]> well if you don't care about delay just add a MicroSD card :) @ 250Kbps you could store years of traffic if one waits. 2011-07-07 14:41 <[g2]> stefan_, it's like getting a message from the Moto E780 ??Â Â iirc that was the model of our Linux phone before openmoko. 2011-07-07 14:42 [g2]: A780, yes :) 2011-07-07 14:42 <[g2]> still has his, but I really don't know why 2011-07-07 14:42 <[g2]> yes A780 2011-07-07 14:42 [g2]: still have one around, ... somewhere 2011-07-07 17:15 http://press.web.cern.ch/press/PressReleases/Releases2011/PR08.11E.html 2011-07-07 17:29 fossrox: kewl. that article even uses almost the same words we do ;-) 2011-07-07 17:29 :) 2011-07-07 17:31 it someone has contacts to CERN, perhaps they should ask if we could get an invited talk at that workshop. after all, we've been there, done that :) (and if the HEP community should get interested in sponsoring some of our work, that wouldn't be amiss either) 2011-07-07 17:34 wpwrak, ask terpstra on #milkymist, he's one of the GSI guys working on the "white rabbit" project talked about in the linked CERN courrier issue 2011-07-07 17:34 I think we definitely can take part in the workshop 2011-07-07 17:34 (and should) 2011-07-07 17:37 I wonder if they still have space in the speaker schedule though ... 2011-07-07 17:38 oh, and that's before "13th International Conference on Accelerator and Large Experimental Physics Control Systems" 2011-07-07 17:39 since registration is 550E, i'll probably try gate-crashing :) 2011-07-07 17:41 also, regarding "invited" talks. usually, it's very difficult to get them at academic conferences. 2011-07-07 17:41 most of the times, speakers (or their employers) even pay for the expensive conference registration, paper publishing fees, etc. 2011-07-07 17:41 plus travel, of course 2011-07-07 17:44 lekernel: (terpstra) perfect. according to http://www.ohwr.org/projects/ohr-meta/wiki/OHWorkshop , they have room for more 2011-07-07 17:45 lekernel: more EUR 50 than 550: http://icalepcs2011.insight-outside.fr/Visitors/index.php?onglet=4&idUser=&emailUser= 2011-07-07 17:45 that's for the open hardware workshop 2011-07-07 17:45 but if you want to go to International Conference on Accelerator and Large Experimental Physics Control Systems, it's 550 2011-07-07 17:46 or gatecrash for free, there's usually little (if any) security in those events 2011-07-07 17:46 that's how you learn physics 2011-07-07 17:47 <[g2]> LMAO 2011-07-07 17:48 lekernel: okay, of you want to attend the HEP part, too :) sure, then the usual rules apply 2011-07-07 17:51 ok so what do we submit? 2011-07-07 17:52 I can propose a lecture on the intrinsics of FPGA synthesis and P&R for session 3. there are potentially good engineers there, so it might be worth putting them on free synthesizer projects :) 2011-07-07 17:57 perhaps someone could give a presentation of qi-hardware, maybe based on my FISL slides 2011-07-07 17:57 describe what we're doing and especially what tools we have 2011-07-07 18:04 the Dangerous prototype people have what seems to be a sustainable business model 2011-07-07 18:04 http://dangerousprototypes.com/2011/07/07/dangerous-prototypes-about-us/ 2011-07-07 18:12 rjeffries: sounds like ours, just higher frequency and apparently more profitable :) 2011-07-07 18:17 rjeffries: yeah 2011-07-07 18:21 well they are doing lesser projects, but yes, similar goals indeed 2011-07-07 18:22 Adafruit and Sparkfun likewise, but they ar esomehwat more derivative 2011-07-07 18:28 aren't they all doing devices for hobbyist? 2011-07-07 18:29 hobbyist = low price + low volume = low technology 2011-07-07 18:29 = boring (for me at least) 2011-07-07 18:30 lekernel they are not doing anything close to as complex as Milkymist. but some of their projects are well above hobbyist 2011-07-07 18:30 and in some cases they have decent volume. 2011-07-07 18:31 they are not attempting any consumer electronics, which is what Nanonote wants to be 2011-07-07 18:32 call me again when they're doing chip bonding, soc design, millimeter wave circuits, etc. 2011-07-07 18:35 rjeffries: i am full with you. 2011-07-07 18:35 last week, I learnt about IMPATT diodes. it's amazing how much stuff the average electronics enthusiast totally ignores. to their credit, they won't let me order some easily. 2011-07-07 18:35 rjeffries: less complex means also more market. i like that 2011-07-07 18:36 no, less complex doesn't mean more market, lol 2011-07-07 18:36 look at the iphone 2011-07-07 18:36 lekernel: arduino has more market than mm for sure. simply because there are more people who understand what they can do with it. 2011-07-07 18:37 also because there are more people with enough money to even dare to try. 2011-07-07 18:37 maybe, but this has nothing to do with complexity 2011-07-07 18:37 also. people are afraid of complexity. 2011-07-07 18:37 also, i'd never have made an arduino because I find it's plain boring 2011-07-07 18:37 they're not afraid of the complexity in the iphone, are they? 2011-07-07 18:38 because its abstracted away. to be fair.. I dont have interrest in fpgas right now. why? because the sw toolchain is _SHIT_ 2011-07-07 18:38 also, the m1 is not a geek toy or a computer. 2011-07-07 18:38 so just ignore it, there are tons of ways you could use the m1 without touching any of the fpga software 2011-07-07 18:39 compared to what we have with broken sw like gcc in the compile world for computers, the xilix/altera/lattice tools all suck 2011-07-07 18:39 also if it's shit, you are welcome to contribute to llhdl 2011-07-07 18:39 lekernel: you dont understand that there are people who have more interresting things to do in life that compilerdesign? 2011-07-07 18:39 compiler design is interesting 2011-07-07 18:39 roh: what could that possibly be ? 2011-07-07 18:39 lekernel: from my pov: fpgas will stay playthings to a very small group of people till that changes. 2011-07-07 18:40 a lot more interesting than many aspects of arduinos, in my opinion 2011-07-07 18:40 lekernel: i bet roh hasn't designed a compiler yet ;-) 2011-07-07 18:40 also, the M1 is NOT a FPGA platform for most people. 2011-07-07 18:41 wpwrak: true. but ive had enough close friends do so in university to know that its nothing 'entertaining' or completely groundbreaking which can be learnt. its boring. 2011-07-07 18:41 it has been a bit of that so far, but this is definitely going to change 2011-07-07 18:41 wpwrak: something for people who find graph-theory fun. i dont. 2011-07-07 18:42 most things in the M1 are abstracted billions of kilometers away from the FPGA, you know 2011-07-07 18:42 the FPGA design is just one more thing you can play with, if you wish. but you don't have to. 2011-07-07 18:43 roh: hmm, i'd count cooking up new compilers among the more fun moments of my life. i'm admittedly a bit weak on the theoretical side. 2011-07-07 18:43 i know. but i also have no usecase for a that fast non-mmu cpu or something with vga to do visuals.. so i need to find some serious usecase. 2011-07-07 18:45 i really like the idea of a foss soc tho. thats why i even invest so much time in this project 2011-07-07 18:46 bbl 2011-07-07 18:52 <[g2]> writing compilers is over-rated :) 2011-07-07 18:53 depends on the compiler, but I'd generally agree 2011-07-07 18:58 lekernel would havingt linux on milkymist make it easier to attache standard mass market (low cost) USB periferams, e.g. any USB keyboard, not just a hand selecte dto work keyboard? 2011-07-07 18:59 and to have a righeous linux milkymist SOC needs at least a simple MMU 2011-07-07 18:59 not all USB keyboards work simply because of bugs in the softusb firmware which are a pain and time sink to fix, and no one including me feels motivated to do that, so we just ship a known good keyboard. 2011-07-07 18:59 ok the MMU topic is coming all the time, won't you just please FDI? 2011-07-07 19:10 FDI ?? 2011-07-07 19:12 rjeffries: Foreign Direct Investment. he wants your money :) 2011-07-07 19:12 what a sweetheart. ;) 2011-07-07 19:13 (any other interpretation, like the one offered by urbandictionary, would be rude ;-) 2011-07-07 19:13 i'll c heck that out. I can not imagine lekernel ever being rude, even accidentally 2011-07-07 19:14 ah yes. good point, except that is not my skill set. 2011-07-07 19:14 im-pens-able 2011-07-07 19:15 rjeffries: so you're a creationalist ? created with a fixed skill set ? :) 2011-07-07 19:15 <[g2]> looks at urban dictionary on the android 2011-07-07 19:15 rjeffries: meanwhile us atheists happily learn new things ;-) 2011-07-07 19:15 I have other fish to fry. pretty interesting fish (to me) 2011-07-07 19:17 rjeffries: well, i hope she's pretty ;-) 2011-07-07 19:17 lekernel /sebastian needs to attract a couple of more hardcore people like himself 2011-07-07 19:17 no, I need to sell the current stuff to VJs, musicians, etc. 2011-07-07 19:18 you assume a she. well, so does my wife 2011-07-07 19:18 cherchez la femme ;-) 2011-07-07 19:18 lekernel understood. 2011-07-07 19:19 tbh from a technical point of view I find the MMU a bit boring and unneeded anyway for my purposes 2011-07-07 19:20 plus, why should I do it for the sake of a free SoC? I get so few contributions to the FPGA design on this project. 2011-07-07 19:22 lekernel: mmu -> linux -> a chance to escape driver hell. so there should be value for you. but i understand that you have other things to do at the moment 2011-07-07 19:23 there's no driver hell. USB gadgets are not supported, period. 2011-07-07 19:25 one could conclude that open hardware (great concept) is a non-starter for SOC 2011-07-07 19:25 lekernel: you'll write your fingers fuzzy with that ;-) 2011-07-07 19:25 rjeffries, oh yeah, maybe you are right, heh. 2011-07-07 19:26 did you just accuse me of being RIGHT? omg 2011-07-07 19:26 ;) 2011-07-07 19:27 but also keep in mind Mako's statistics which say that the vast majority of open source projects have ONE developer 2011-07-07 19:27 stuff built by "the community" rarely happens 2011-07-07 19:28 http://mako.cc/writing/hill-when_free_software_isnt_better.html the corresponding talk is also interesting to watch 2011-07-07 19:30 <[g2]> wpwrak, I've got a kicad question on the atmega board I'm working on. 2011-07-07 19:31 lekernel:Â Â i often see a pattern of one main developer and people contributing on the side. that's what makes most sense anyway, each doing what "scratches their itch" 2011-07-07 19:31 [g2]: fire away :) 2011-07-07 19:31 <[g2]> something is happening with the libraries/modules where the footprint of the resonator doesn't seem to get picked up. 2011-07-07 19:31 [g2]: is it listed in *.pro ? 2011-07-07 19:31 <[g2]> yes, I'm pretty sure 2011-07-07 19:32 [g2]: you can edit *.pro from within kicad, but it's very inconvenient. easier to just exit kicad and edit it with a text editor 2011-07-07 19:32 <[g2]> It's seen in the schematic, but not on the board file 2011-07-07 19:32 [g2]: library (.lib) and footprint (.mod) are different things 2011-07-07 19:32 <[g2]> right. 2011-07-07 19:33 [g2]: how did you make the footprint ? with kicad's footprint editor or fped ? 2011-07-07 19:33 <[g2]> I tried grapping other modules from the links on kicad.org 2011-07-07 19:34 that can work, too :) 2011-07-07 19:34 <[g2]> later today I was going to post the whole project on github or something similar. 2011-07-07 19:35 <[g2]> then, you can point and laugh at my errors :) 2011-07-07 19:35 in *.pro, you should have a section [pcbnew/libraries] and there you should have an entry LibName#=path/to/your/file 2011-07-07 19:35 <[g2]> correct. I do. 2011-07-07 19:36 # is a number. numbers must be consecutive. so if you have a LibName1 and LibName2, the next must be LibName3. 2011-07-07 19:36 the path can be relative, which i'd recommend to use 2011-07-07 19:36 furthermore, the file name probably must be without the .mod 2011-07-07 19:37 if you have all this, then you should be at least able to place the footprint in pcbnew with "Add modules" (the chip symbol, 4th from the top) 2011-07-07 19:38 now, that's not what you want to do, but it's a test that everything else works as it shuold 2011-07-07 19:39 (i.e., try to place the footprint/module and see if it looks right. if all is well, exit without saving. or if you've saved, delete it the next time.) 2011-07-07 19:39 <[g2]> checking on laptop 2011-07-07 19:45 <[g2]> wpwrak, the footprint is there in pcbnew and I do the add module. 2011-07-07 19:46 [g2]: excellent. now, quit pcbnew and fire up eeschema. then invoke cvpcb. there, you should see the component in question. is a footprint associated with it yet ? 2011-07-07 19:47 <[g2]> wpwrak,Â Â Ok, will do, but I didn't change anything in the .pro 2011-07-07 19:47 that's okay. the .pro seems to be fine 2011-07-07 19:49 <[g2]> ahh.. It's case-sensitive right ? 2011-07-07 19:49