<wpwrak> wolfspraul: nobody thinks free software is dead ;-) they all see pretty clearly where the problem is
<wolfspraul> heise is not read by newcomers
<wpwrak> duh. Bild then ? ;-)
<wolfspraul> hmm, read it
<wolfspraul> 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
<wolfspraul> not 1 original thought in 100 of them, or so
<wpwrak> oh, i usually just pick a few. to see if there's anything interesting
<wpwrak> 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.
<wpwrak> wolfspraul: the experience reminded me very much of OE at openmoko ...
<wolfspraul> what feature were you missing?
<wolfspraul> we are trying to release prebuilt toolchains, but I guess it didn't help (I saw the chat)
<wpwrak> 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
<wpwrak> (feature) SDL_gfx
<wpwrak> (chat) ah, good. then i don't need to repeat it all :)
<kristianpaul> how ironic trying to fix my camera shuter when not having another camera to take pics of the disasembling process~ :-/
<wpwrak> 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
<wpwrak> kristianpaul: ;-)))
<wpwrak> kristianpaul: you could remember the tradition of biologists in ancient times and make drawings :)
<wpwrak> 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.
<kristianpaul> i think i will later this month, for now no camera to carry :(
<wpwrak> if you fail at pygames for the "base", you know something is a little off :)
<kristianpaul> talking about games i think zear_ is in the same path of wpwrak, finding a non problematic way of porting games to the nn
<wpwrak> atrf-rssi isn't exactly a game, but ... ;-)
<wpwrak> you could use atrf-path as a game, though :)
<kristianpaul> well, no that wpwrak will port games but youget the idea
<wpwrak> 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 :)
<wpwrak> 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.
<kristianpaul> yeah, i agree, it was easy to build..
<kristianpaul> shame i deleted that folder.. when trying to get latest stuff
<wpwrak> ;-)
<wpwrak> first lesson: rename, don't delete :)
<kristianpaul> too much renames, more when the thing is about 10GB big !
<kristianpaul> but anyway, i think wiki could be improved easilly, just with the well experience from xiangfu and kyak for example :)
<wpwrak> 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
<wpwrak> i think the wiki is up to date now
<kristianpaul> good !
<wpwrak> not sure about the .config
<wpwrak> but there's also the quirk that uClibc regresses
<kristianpaul> just use minimal, and grown from that
<kristianpaul> well, may be you can find something more stable from openwrt upstream for backfire
<kristianpaul> but of course no the same feeds will be there..
<wpwrak> it seems that this is what that ABI breakage is about
<wpwrak> i didn't quite realize there was an ABI barrier until today
<kristianpaul> hum..
<wpwrak> ABI incompatibilities are very very bad. means that you can't easily try and then decide whether to proceed or revert
<wpwrak> at least not when changing one thing at a time
<wpwrak> so this sort of thing should be headline news, along with a migration plan
<wpwrak> could be that i just overlooked it, though
<kyak> wpwrak: yeah, it make sense - combination of toolchain-mipsel_gcc-4.3.3+cs_uClibc-0.9.30.1 is the correct one
<kyak> wpwrak: so how is sdl-gfx doing? You should have it in your toolchain now
<kyak> 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
<kyak> 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
<wpwrak> kyak: (sdl-gfx) surprisingly, it doesn't seem to be there
<wpwrak> kyak: (backfire vs. trunk) what's the plan for the future anyway ? do you intend to switch one day from backfire ?
<wpwrak> kyak: i quite dislike the strtof regression in backfire. not being able to compile perfectly posix-compliant code without a warning isn't nice.
<kyak> wpwrak: the builds in buildhost are already based on trunk. 05-28 was the last backfire-based release
<kyak> and sdl-gfx has to be there :)
<kyak> grep libsdl-gfx .config
<kyak> should be =y
<kyak> and sdl-config and sdl libraries and headers should all be installed
<wpwrak> CONFIG_PACKAGE_libsdl-gfx=y
<kyak> ls staging_dir/target-mipsel_uClibc-0.9.32/usr/lib/libSDL_gfx.*
<kyak> should be your target-mipsel_uClibc..
<wpwrak> No such file or directory
<wpwrak> target is target-mipsel_uClibc-0.9.30.1 anyway
<kyak> yeah
<kyak> this is strange
<wpwrak> ah yes, the library is there ...
<wpwrak> ah, includes too :)
<wpwrak> i looked under toolchain-mipsel_gcc-4.3.3+cs_uClibc-0.9.30.1
<kyak> it's target
<wpwrak> let's see what this changes ....
<kyak> anyway, locate the sdl-config
<kyak> it will give you the right path
<kyak> sdl-config is somewhere here: ./staging_dir/target-mipsel_uClibc-0.9.32/host/bin/sdl-config
<kyak> $ ./staging_dir/target-mipsel_uClibc-0.9.32/host/bin/sdl-config --libs
<kyak> -L/home/bas/build/openwrt-xburst/staging_dir/target-mipsel_uClibc-0.9.32/usr//lib -lSDL -lpthread
<wpwrak> grmbl. no cross-toolchain under target. that's where the problem comes from
<kyak> the toolchain is under the toolchain*
<wpwrak> does gcc have target in its include search list ?
<wpwrak> if you split toolchain and target (and don't add target to gcc in some other way) all the automatic searches fail
<wpwrak> that's why you need hacks like STAGING_DIR
<wpwrak> now it all begins to make sense ;-)
<kyak> it works fine from within openwrt build system
<kyak> because all the necessary variables are passed to configure/make
<wpwrak> yes, because you override all the search paths :)
<wpwrak> 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
<kyak> i'm sure there is a perfect explanation for that. I'm just not an expert regarding openwrt build system
<wpwrak> where's xMff when we need him ? :)
<kyak> and again, you don't need to pass anything to makefile in most cases
<kyak> well designed applications a ported like that
<wpwrak> but i need to pass -L$(TARGET)/usr/lib and -I$(TARGET)/usr/include, right ?
<xMff> $(STAGING_DIR)/usr/...
<wpwrak> at least if i'm compiling outside the openwrt build system
<wpwrak> so STAGING_DIR = ..../target..., okay
<xMff> yes
<wpwrak> xMff: why are you making this so complex ? :)
<wpwrak> xMff: if you had everything in the same hierarchy, gcc would automatically pick the right includes and libraries
<xMff> thats wichful thinking
<xMff> *wishful
<wpwrak> xMff: works great on jlime ;-)
<xMff> its already hard enough to get autofail to not act up
<xMff> well whenever I hear from Oe its people having troubles compiling :)
<wpwrak> (autocrap) well, that's certainly true :)
<wpwrak> (oe) i think the secret is to let others do the compiling for you :)
<xMff> bbl work
<wpwrak> 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 ? :)
<wpwrak> wonders if one couldn't just symlink the target tree into the toolchain tree. there are a few duplicate files that need looking at
<jow_laptop> because most software simply sucks at cross compiling
<jow_laptop> last time I checked not even gcc could compile itself without patches
<jow_laptop> *cross-compile itself
<jow_laptop> perl does not cross compile
<jow_laptop> ruby does not cross compile
<jow_laptop> most libtool deployments do not cross compile either
<wpwrak> libtool is a losing proposition anyway :)
<jow_laptop> many autotools based packages fail in configure due to AC_TRY_RUN checks
<jow_laptop> autoreconf is not possible because automake broke its own api
<wpwrak> it's amazing how creative people are inventing solutions that just break things in more obscure ways
<wpwrak> autocrap is another set of problems, yes
<wpwrak> i was more thinking of sane developers who stay away from all such mess
<jow_laptop> and in openwrt we split toolchain and target because we support multiple targets with the same toolchain
<jow_laptop> munching that together breaks that completely
<wpwrak> oh. that makes merging hard :-(
<kyak> i knew there was a reason for splitting it! :)
<jow_laptop> until recently we had to support gcc 3.x etc.
<jow_laptop> now that this is gone we can maybe thing about --sysroot
<jow_laptop> *think
<wpwrak> that sounds promising
<wpwrak> 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 ?
<wpwrak> (multiple "yes" answers are possible ;-)
<stefan_schmidt> hmm, yes, no, yes, yes?
<stefan_schmidt> play blind answering
<wpwrak> 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.
<stefan_schmidt> wpwrak: ups
<wpwrak> stefan_schmidt: (1011) not a bad choice :)
<wpwrak> 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
<stefan_schmidt> wpwrak: int missing or something else
<wpwrak> stefan_schmidt: naw, i think everything works as planned
<wpwrak> stefan_schmidt: just the plan needs some improvements :)
<stefan_schmidt> wpwrak: ok, so it is the delay
<wpwrak> i'm now trying a different approach for synchronizing that shouldn't need the delay
<stefan_schmidt> wpwrak: I was just going to prepare my little lowpan-perf tool for a run
<stefan_schmidt> wpwrak: (w/o delay) cool
<wpwrak> (perf) good. then we can compare before and after :)
<wolfspraul> has anybody found out about atben/atusb sales numbers now?
<wolfspraul> maybe we have to do without them...
<wpwrak> wolfspraul: i haven't made it that far in my telepathy course yet ...
<jow_laptop> wpwrak: the libc abi will break
<kyak> 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
<jow_laptop> also the threading system changes
<jow_laptop> from linuxthreads.old to ntpl
<kyak> yeah, the nptl thing
<wpwrak> okay, so host toolchain, libs, root image, extra packages, and local developments are affected
<jow_laptop> yep
<wpwrak> will the names of the tools change as well ? (away from mipsel-openwrt-linux-uclibc-*)
<kyak> nah, these names remain the same
<wpwrak> good. so just a re-make will do for posix things
<wpwrak> pity openwrt doesn't use eglibc. otherwise, we could even have binary compatibility with jlime
<jow_laptop> it allows to use eglibc
<wpwrak> oh, great ! what's the experience with it ? good ?
<jow_laptop> no
<jow_laptop> you trade one bag of annying bugs against another one :)
<wpwrak> what are the problems ?
<wpwrak> ;-))
<jow_laptop> well dunno, one has to try it again
<jow_laptop> its been a while since it was added and only recently some work was invested in it
<jow_laptop> ... again
<wpwrak> funny. atusb is making a little bit of noise when transmitting :)
<wpwrak> stefan_schmidt: things are still slowish. grmbl.
<stefan_schmidt> wpwrak: hmm
<wpwrak> 362 packets transmitted, 361 received, +1055 duplicates, 0% packet loss
<wpwrak> it's a feature: enhanced redundancy :)
<wpwrak> heh. and i found another bug in at86rf230.c ;-)
<wpwrak> hmm, a good marketing slogan for advertizing 64 vs. 32 bits just occurred to me: "pointer enlargement"
<stefan_schmidt> lol
<stefan_schmidt> wpwrak: have the same feeling you had with your ubuntu today with my debian
<wpwrak> been a while since the last update ? :)
<stefan_schmidt> wpwrak: the kvm install I have had not a signle devel package installed. no pck-config, bison or whatever
<stefan_schmidt> interesting errors to figure out what is missing
<wpwrak> yuck :)
<stefan_schmidt> finally got lowpan-tools with my measurement tool compiled
<qi-bot> [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
<stefan_> wpwrak: Received 10 from 10 packets
<stefan_> Arithmetic mean rountrip time: 0.000000 seconds and 193495.203125 usecs
<stefan_> wpwrak: thats roundtrip on lowpan level
<stefan_> no re-transmit and other fancy stuff build in yet :)
<stefan_> one meter distance directly next to an wifi AP :)
<stefan_> wpwrak: 100 also without problem, going 1000 now
<wpwrak> interesting. you really have picosecond resolution ? ;-)
<wpwrak> ~200 ms. damn slow. lemme finish debugging my improved delay system
<stefan_> wpwrak: nope, standard timeval, need to clean it up
<stefan_> wpwrak: what wonders me is how reliable it is
<wpwrak> printf("%lu.%06lu", (unsigned long) tv_sec, (unsigned long) tv_usec); ? :)
<wpwrak> you can try a few times and see if the value is stable
<stefan_> Received 1000 from 1000 packets
<stefan_> Arithmetic mean rountrip time: 0.000000 seconds and 177617.531250 usecs
<stefan_> Minimal time 0.000000 seconds and 161797.000000 usecs
<stefan_> Maximal time 0.000000 seconds and 226437.000000 usecs
<wpwrak> pity you don't have any ben+atben. there, things are faster.
<wpwrak> looks consistent
<stefan_> wpwrak: getting the 4 atusb from the university was all I asked for :) (I bought 2 myself)
<stefan_> no lost package
<stefan_> thats good. Now we can make it faster :)
<wpwrak> you said your work was on delay-tolerant networks. seems like the ideal playground ;-)
<stefan_> heh
<stefan_> point taken
<stefan_> wpwrak: so your dirtpan retransmissions come due to lower backoff timer values?
<wpwrak> yes
<wpwrak> well, too low ACK timeouts to be precise
<wpwrak> dirtpan takes the klingon approach and never backs off :)
<stefan_> heh
<stefan_> never, listen, never I say I will backoff :)
<stefan_> wpwrak: wrt driver name and location. It feels like it should move to drivers/ieee802154/
<stefan_> name I don't care much
<stefan_> But its not that easy to share code with atben anymore it seems
<stefan_> not sure it is worth the sharing
<wpwrak> yeah, they've diverged a bit. just a few infrastructure bits are common.
<wolfspraul> oh delay tolerant networks!
<stefan_> would be confusing just for the generic spi_master bits imho
<wpwrak> 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
<wolfspraul> if there are pointers to apps/libs that we can port to the Ben, please post
<stefan_> wolfspraul: yup, doing it as my diploma thesis with 802154 :)
<wolfspraul> I just want to make sure we create openwrt packages and get it to the Ben...
<wpwrak> (confusing) agreed. not really worth the trouble for maybe 50 lines
<wolfspraul> I assume there will be some middleware/libs or what not
<stefan_> 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
<stefan_> wolfspraul: its the daemon for the protocol and some tools that work with it. Let me search the URI
<stefan_> wolfspraul: overview: http://www.ibr.cs.tu-bs.de/projects/ibr-dtn/
<wpwrak> wolfspraul: btw,july news on sunday ? you once mentioned 10 days :)
<stefan_> wolfspraul: should be easy to grab the openwrt recipes(?) and integrate it with your build
<stefan_> wpwrak: so we leave both drivers on its own
<stefan_> wpwrak: but both should be in drivers/ieee802154 as they rely on at86rf230 anyway.
<wolfspraul> wpwrak: no way, I'm behind some serious todos, need to do those first
<wpwrak> hmm, maybe you could do the news for relaxation? :)
<stefan_> wpwrak: Received 1998 from 2000 packets
<wpwrak> stefan_: good. so you could test the pakcet loss handling as well :)
<stefan_> wpwrak: thats with 7byte payload btw, lets see what happens with a full payload
<wpwrak> yes, the delay difference would be quite interesting
<stefan_> 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
<stefan_> might take some time so
<wpwrak> great
<stefan_> wpwrak: will keep you in the loop with measurement numbers
<stefan_> will track the driver closely for all improvements :)
<wpwrak> heh :)
<stefan_> more serious, I will come back but time constraints push me to do some other things now.
<stefan_> Received 2000 from 2000 packets
<stefan_> Arithmetic mean rountrip time: 0.000000 seconds and 199789.437500 usecs
<stefan_> thats with full payload
<wpwrak> so that's a difference of how many bytes ?
<wpwrak> and the full payload gets sent both ways ? or is it large foward packed and a small ack back ?
<stefan_> wpwrak: 110 bytes difference and the full data is send both ways
<stefan_> wpwrak: at86rf230 spi32766.0: invalid PHR 0xdd
<stefan_> wpwrak: so it was not only a problem for you alone :)
<wpwrak> corruption does happen :)
<wpwrak> 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
<wpwrak> the copying happens 4 times. so 3.75 ms per copy. that's about 30 kB/s. hmm. pretty slow.
<stefan_> wpwrak: what worries me more is the overall high timing value we start with for a small package
<wpwrak> of course :)
<stefan_> its factor 10 higher then it should be :)
<wpwrak> the driver does a lot of register accesses. maybe they're slow. need to check.
<stefan_> but atben would do the same
<stefan_> maybe the usb overhead is really that high?
<wpwrak> yes, that's what i mean
<stefan_> ah, now we understand each other ;)
<wpwrak> the spi is about as fast as possible in atben
<[g2]> Hey stefan_ !  Long time
<stefan_> 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
<stefan_> [g2]: indeed, quite some time. Still embedded linux is a small village ;)
<stefan_> [g2]: how are you?
<[g2]> well thx, hope you and yours are the same.
<stefan_> [g2]: little bit stress to finally get my studies done and doing freelance work in parallel, but nothing dramatic :)
<[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
<[g2]> I'm just about done with the layout for mcu, I'm hoping to start the RF layout later this week
<stefan_> [g2]: atusb starts to work since last night. :)
<[g2]> sweet, you just built the hw ?
<stefan_> [g2]: I just ordered it :)
<[g2]> got my test atben boards yesterday
<stefan_> [g2]: needed some 802154 hardware for my diploma thesis and added some on top for myself
<[g2]> stefan_, can you say what you are making ?
<stefan_> [g2]: sure, delay tolerant networking over ieee802154 networks
<stefan_> [g2]: university website is only in german, sorry.
<[g2]> are you going to add QoS for the long delays :)
<stefan_> [g2]: but I worked on this topic earlier: http://datenfreihafen.org/~stefan/papers/study-thesis-final.pdf
<stefan_> [g2]: we don't care of the delays, thats the trick :)
<stefan_> [g2]: My job is to write/extend a convergence laer between the ieee802154 stack under linux for our dtn implementation
<[g2]> well if you don't care about delay just add a MicroSD card :) @ 250Kbps you could store years of traffic if one waits.
<[g2]> stefan_, it's like getting a message from the Moto E780 ??  iirc that was the model of our Linux phone before openmoko.
<stefan_> [g2]: A780, yes :)
<[g2]> still has his, but I really don't know why
<[g2]> yes A780
<stefan_> [g2]: still have one around, ... somewhere
<wpwrak> fossrox: kewl. that article even uses almost the same words we do ;-)
<fossrox> :)
<wpwrak> 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)
<lekernel> 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
<lekernel> I think we definitely can take part in the workshop
<lekernel> (and should)
<lekernel> I wonder if they still have space in the speaker schedule though ...
<lekernel> oh, and that's before "13th International Conference on Accelerator and Large Experimental Physics Control Systems"
<lekernel> since registration is 550E, i'll probably try gate-crashing :)
<lekernel> also, regarding "invited" talks. usually, it's very difficult to get them at academic conferences.
<lekernel> most of the times, speakers (or their employers) even pay for the expensive conference registration, paper publishing fees, etc.
<lekernel> plus travel, of course
<wpwrak> lekernel: (terpstra) perfect. according to http://www.ohwr.org/projects/ohr-meta/wiki/OHWorkshop , they have room for more
<lekernel> that's for the open hardware workshop
<lekernel> but if you want to go to International Conference on Accelerator and Large Experimental Physics Control Systems, it's 550
<lekernel> or gatecrash for free, there's usually little (if any) security in those events
<lekernel> that's how you learn physics
<[g2]> LMAO
<wpwrak> lekernel: okay, of you want to attend the HEP part, too :) sure, then the usual rules apply
<lekernel> ok so what do we submit?
<lekernel> 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 :)
<wpwrak> perhaps someone could give a presentation of qi-hardware, maybe based on my FISL slides
<wpwrak> describe what we're doing and especially what tools we have
<rjeffries> the Dangerous prototype people have what seems to be a sustainable business model
<wpwrak> rjeffries: sounds like ours, just higher frequency and apparently more profitable :)
<roh> rjeffries: yeah
<rjeffries> well they are doing lesser projects, but yes, similar goals indeed
<rjeffries> Adafruit and Sparkfun likewise, but they ar esomehwat more derivative
<lekernel> aren't they all doing devices for hobbyist?
<lekernel> hobbyist = low price + low volume = low technology
<lekernel> = boring (for me at least)
<rjeffries> lekernel they are not doing anything close to as complex as Milkymist. but some of their projects are well above hobbyist
<rjeffries> and in some cases they have decent volume.
<rjeffries> they are not attempting any consumer electronics, which is what Nanonote wants to be
<lekernel> call me again when they're doing chip bonding, soc design, millimeter wave circuits, etc.
<roh> rjeffries: i am full with you.
<lekernel> 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.
<roh> rjeffries: less complex means also more market. i like that
<lekernel> no, less complex doesn't mean more market, lol
<lekernel> look at the iphone
<roh> lekernel: arduino has more market than mm for sure. simply because there are more people who understand what they can do with it.
<roh> also because there are more people with enough money to even dare to try.
<lekernel> maybe, but this has nothing to do with complexity
<roh> also. people are afraid of complexity.
<lekernel> also, i'd never have made an arduino because I find it's plain boring
<lekernel> they're not afraid of the complexity in the iphone, are they?
<roh> because its abstracted away. to be fair.. I dont have interrest in fpgas right now. why? because the sw toolchain is _SHIT_
<lekernel> also, the m1 is not a geek toy or a computer.
<lekernel> so just ignore it, there are tons of ways you could use the m1 without touching any of the fpga software
<roh> compared to what we have with broken sw like gcc in the compile world for computers, the xilix/altera/lattice tools all suck
<lekernel> also if it's shit, you are welcome to contribute to llhdl
<roh> lekernel: you dont understand that there are people who have more interresting things to do in life that compilerdesign?
<lekernel> compiler design is interesting
<wpwrak> roh: what could that possibly be ?
<roh> lekernel: from my pov: fpgas will stay playthings to a very small group of people till that changes.
<lekernel> a lot more interesting than many aspects of arduinos, in my opinion
<wpwrak> lekernel: i bet roh hasn't designed a compiler yet ;-)
<lekernel> also, the M1 is NOT a FPGA platform for most people.
<roh> 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.
<lekernel> it has been a bit of that so far, but this is definitely going to change
<roh> wpwrak: something for people who find graph-theory fun. i dont.
<lekernel> most things in the M1 are abstracted billions of kilometers away from the FPGA, you know
<lekernel> the FPGA design is just one more thing you can play with, if you wish. but you don't have to.
<wpwrak> 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.
<roh> 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.
<roh> i really like the idea of a foss soc tho. thats why i even invest so much time in this project
<roh> bbl
<[g2]> writing compilers is over-rated :)
<lekernel> depends on the compiler, but I'd generally agree
<rjeffries> 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?
<rjeffries> and to have a righeous linux milkymist SOC needs at least a simple MMU
<lekernel> 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.
<lekernel> ok the MMU topic is coming all the time, won't you just please FDI?
<rjeffries> FDI ??
<wpwrak> rjeffries: Foreign Direct Investment. he wants your money :)
<rjeffries> what a sweetheart. ;)
<wpwrak> (any other interpretation, like the one offered by urbandictionary, would be rude ;-)
<rjeffries> i'll c heck that out. I can not imagine lekernel ever being rude, even accidentally
<rjeffries> ah yes. good point, except that is not my skill set.
<wpwrak> im-pens-able
<wpwrak> rjeffries: so you're a creationalist ? created with a fixed skill set ? :)
<[g2]> looks at urban dictionary on the android
<wpwrak> rjeffries: meanwhile us atheists happily learn new things ;-)
<rjeffries> I have other fish to fry. pretty interesting fish (to me)
<wpwrak> rjeffries: well, i hope she's pretty ;-)
<rjeffries> lekernel /sebastian needs to attract a couple of more hardcore people like himself
<lekernel> no, I need to sell the current stuff to VJs, musicians, etc.
<rjeffries> you assume a she. well, so does my wife
<wpwrak> cherchez la femme ;-)
<rjeffries> lekernel understood.
<lekernel> tbh from a technical point of view I find the MMU a bit boring and unneeded anyway for my purposes
<lekernel> 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.
<wpwrak> 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
<lekernel> there's no driver hell. USB gadgets are not supported, period.
<rjeffries> one could conclude that open hardware (great concept) is a non-starter for SOC
<wpwrak> lekernel: you'll write your fingers fuzzy with that ;-)
<lekernel> rjeffries, oh yeah, maybe you are right, heh.
<rjeffries> did you just accuse me of being RIGHT? omg
<rjeffries> ;)
<lekernel> but also keep in mind Mako's statistics which say that the vast majority of open source projects have ONE developer
<lekernel> stuff built by "the community" rarely happens
<lekernel> http://mako.cc/writing/hill-when_free_software_isnt_better.html the corresponding talk is also interesting to watch
<[g2]> wpwrak, I've got a kicad question on the atmega board I'm working on.
<wpwrak> 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"
<wpwrak> [g2]: fire away :)
<[g2]> something is happening with the libraries/modules where the footprint of the resonator doesn't seem to get picked up.
<wpwrak> [g2]: is it listed in *.pro ?
<[g2]> yes, I'm pretty sure
<wpwrak> [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
<[g2]> It's seen in the schematic, but not on the board file
<wpwrak> [g2]: library (.lib) and footprint (.mod) are different things
<[g2]> right.
<wpwrak> [g2]: how did you make the footprint ? with kicad's footprint editor or fped ?
<[g2]> I tried grapping other modules from the links on kicad.org
<wpwrak> that can work, too :)
<[g2]> later today I was going to post the whole project on github or something similar.
<[g2]> then, you can point and laugh at my errors :)
<wpwrak> in *.pro, you should have a section [pcbnew/libraries] and there you should have an entry LibName#=path/to/your/file
<[g2]> correct. I do.
<wpwrak> # is a number. numbers must be consecutive. so if you have a LibName1 and LibName2, the next must be LibName3.
<wpwrak> the path can be relative, which i'd recommend to use
<wpwrak> furthermore, the file name probably must be without the .mod
<wpwrak> 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)
<wpwrak> now, that's not what you want to do, but it's a test that everything else works as it shuold
<wpwrak> (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.)
<[g2]> checking on laptop
<[g2]> wpwrak, the footprint is there in pcbnew and I do the add module.
<wpwrak> [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 ?
<[g2]> wpwrak,  Ok, will do, but I didn't change anything in the .pro
<wpwrak> that's okay. the .pro seems to be fine
<[g2]> ahh.. It's case-sensitive right ?
<wpwrak> probably, yes
<qi-bot> [commit] Werner Almesberger: atusb/fw/: added improved support for interrupt synchronization (master) http://qi-hw.com/p/ben-wpan/42483d6
<wpwrak> stefan_: the commit above explains how it all works
<kyak> "I think we're also seeing some shift from the mailing lists to IRC." - yeah, it's 2011! :)
<qi-bot> [commit] Werner Almesberger: atusb: changed interrupt synchronization from fixed delay to SPI_WRITE2_SYNC (ben-wpan-stefan) http://qi-hw.com/p/qi-kernel/b2d71a9
<wpwrak> kyak: 2011 would be "from mailing lists to facebook" ;-) 2010 it would have been twitter. 2009 ... myspace ? fads come fads go ;-)
<kyak> you are right, but what's going to be next?
<wpwrak> google+ ?
<kyak> i'm glad i'm stuck in IRC :)
<[g2]> wpwrak, THX !!  So basically what I think happened is the part didn't have a footprint associated with it until I added with cvpcb (per you great directions :)
<[g2]> not it's associated, so the layout has a footprint.
<[g2]> that's was the missing link for me.
<wpwrak> [g2]: yup, sounds right
<wpwrak> [g2]: so how's the overall kicad experience for you so far ?
<[g2]> wpwrak, pretty good actually.
<[g2]> I think for small boards, it's all very workable
<[g2]> I like eschema and the text based nature of things
<[g2]> meaning it could all be scriptable and one can do diffs
<wpwrak> [g2]: people also have hand-routed multilayer boards. lemme check how many layers ...
<wpwrak> six layers (project xue-rnc)
<[g2]> wpwrak, um 10 years ago I did the frimware for a network processor that was on a 19x22 inch board 24 layers deep. :)
<[g2]> there were several 1M+ FPGAs on the board too.
<wpwrak> whoopie
<[g2]> SER-DES links on the backplane.  We had a 1 Million+ subsciber GGSN running in 2001
<wpwrak> sounds quite massive
<[g2]> GGSN was a 3G data switch, we were ahead of our time
<wpwrak> i haven't done multilayer yet. should be fun :) i hope we can find some money for making a Ya NN. that would be the ideal opportunity to dive into such things
<wpwrak> [g2]: (3G in 2001) pretty much indeed
<[g2]> Ya NN ?
<wpwrak> [g2]: the hypothetical successor of the ben nanonote
<[g2]> Ah...
<[g2]> wpwrak, also is there a way in pcbnew to have it drag the traces around that are connected to the IC ?
<wpwrak> [g2]: unfortunately, not really. all that's there is the block move. but not a proper drag (you'd need an interactive router for this)
<[g2]> suck :(
<[g2]> kicad -1
<[g2]> pcbnew -1
<[g2]> kicad +0
<wpwrak> naw, after a while, you get good at quickly ripping up and manually re-routing things ;-)
<[g2]> practices
<stefan_> wpwrak: will test the commit tomorrow, just back from bbq, going to sleep now
<wpwrak> stefan_: (bbq) hehe :)
<[g2]> sweet dreams.
<rjeffries> wpwrak do you remember how many layers Ben NN pcb is?
<stefan_> night all
<wpwrak> stefan_: hmm, eac register read or write from user space (via USB) takes about 1 ms. so far, so good.
<wpwrak> rjeffries: i think it's 6 layers
<wpwrak> same for buffer read/write
<rjeffries> when Carlos did his SAKC I think he may have only done 4 layers? not sure
<wpwrak> could be. i think he's at 2 layers now.
<wpwrak> but a nanonote with a similar keyboard layout would need at least one additional layer
<wpwrak> and you almost certainly want a good ground plane
<wpwrak> for 4's the minimum
<wpwrak> s/for/so/