<wpwrak>
anyway, how is it going ? lots of people admiring the goodies you brought ?
<tuxbrainfosdem>
yes a lot!! also some sales :) a promising contacts :)
<wpwrak>
great !
<tuxbrainfosdem>
the designer of that tiny board sais its posible to make it work only with two free gpios, so maybe we can have another addon card on the way :P
<wpwrak>
heh, why not :)
<kyak>
xMff: gettext-full still fails to build. It seems that the suggested patch is not there...
<kyak>
(bug #8413)
<tuxbrainfosdem>
sure wolfspraul will love that one: we have sell 5 units to Valladolid university to use it to study computer architecture :)
<tuxbrainfosdem>
I have here by myside a guy that works on atmel any question for him?
<wolfspraul>
tuxbrainfosdem: that's great news [university]
<tuxbrainfosdem>
wolfspraul: yeah I know , I pretty happy on the result on fordem, my NN has the fingerprits of thousand of hands :)
<kristianpaul>
fosdem ! :-)
<kristianpaul>
tuxbrainfosdem: ask him for a atmel touch screen that fit on current nanonote LCM and can re-use the on on-board serial por for comunications
<kristianpaul>
computer architecture <-- You should also recomend buy some other MM1 later :-)
<wolfspraul>
tuxbrainfosdem: true! milkymist one is _the_ way to study computer architecture
<kristianpaul>
I have a friend is interested in give the "operating system" course with milkymist and rtems ;-)
<kristianpaul>
"Linux is to complex for me he saids"
<kristianpaul>
wpwrak: I think is false (yday question)
<kristianpaul>
sorry i was out for party so no time for answer yday
<tuxbrainfosdem>
kristianpaul: he will redirect me to a company that maybe is interested to work with us with our volume :), when we reach the 100000 units year we can then talk to them directly :)
<kristianpaul>
haha
<tuxbrainfosdem>
if another visitor askme if it has wifi I will scream....
<Jay7>
have asked about wifi/usb host on Chaos Constructions by every visitor
<Jay7>
s/have/was/ may be..
<tuxbrainfosdem>
well I'm "lucky" then, just the 96% of them :),
<Jay7>
you have more visitors, I'm sure :)
<tuxbrainfosdem>
yes this is madnes, I have barelly no voice now
<kristianpaul>
tuxbrainfosdem: actualli i think,  there is a missing space for a chip that can handle i2c, so phisically and now that tiny boards are getting common around here
<kristianpaul>
wait for a pic plus sch
<kristianpaul>
just a minute
<kristianpaul>
tuxbrainfosdem: you will said, NO WIFI, is SLOW FII
<wolfspraul>
tuxbrainfosdem: how about Milkymist One? any leads/interested people? any sales?
<tuxbrainfosdem>
wolfspraul: mm1, interest yes , sales not (yet) but the speech of sebastien has rise a lot of heads up , and also the demo we have done with the cam , but well you know there is not much VJ arround here :)
<tuxbrainfosdem>
kristianpaul: slowfii, part of my voice is out splaining that :)
<tuxbrainfosdem>
well guys time to leave, see you tomorow
<wolfspraul>
cya
<kristianpaul>
chao
<xMff>
kyak: I'll look into it
<kyak>
xMff: thanks.. another question - there are "-liconv" in TARGET_LDFLAGS for some packages. For some reason, this must be left
<kyak>
do you think it's ok, or maybe some problem in autoconf of that packages?
<xMff>
its okay for now. I'll clean that up in the future
<xMff>
some of the flags are coming from pkg-config
<kyak>
ok, good
<xMff>
I thought about adding "-liconv" to ICONV_LDFLAGS eventually but I am not sure yet
<xMff>
I'm quite sure it will break some obscure stuff :)
<kyak>
yeah, at first i thought -liconv is already in ICONV_LDFLAGS, but then i saw inside of nls.mk that it isn't
<kyak>
so far i'm "converting" packages to $(ICONV_..) notation just fine.. apart from this gettext problem
<qwebirc34003>
hello everyone, can anyone tell me how to install Ben NanoNote's modified OpenWRT in QEMU or VMWare?
<xMff>
qwebirc34003: I suppose you can just checkout git and build vdi/vmdk images
<kristianpaul>
but the arch will be x86 right?
<xMff>
yes
<qwebirc34003>
Are there any special git repos for building images?
<kyak>
xMff: luckily, "-liconv" is the same for libiconv-full and libiconv-stub.. it won't be the same for -lncursesw and -lncurses (if the switchable solution is going to be implemented for ncurses/ncursesw)
<roh>
given my usually high tolerance for trollt.. this one got me. if i would be asked to ban him somewhere i wouldnt hesitate.
<kristianpaul>
roh: can you sell all kit for mm1 case expect the crylic part?, plus shipping to colombia, it dont want in here in next 5 days, so i can wait some weeks
<roh>
kristianpaul: huh?
<kristianpaul>
I'll try source locally laser cuted parts with this local company as see the quality, afaik they just have white-like acrylic
<kristianpaul>
s/all/me a
<roh>
i dont understand. you mean the bag with the screws and the shielding sheet?
<kristianpaul>
yes
<kristianpaul>
sorry
<roh>
for another laser machine you will need to touch the cad data i guess.
<roh>
diffrent tolerances and such
<kristianpaul>
hmm
<qwebirc34003>
xburst is the processor type, right? so I will have to ./configure && make?
<kyak>
xMff: oh, another thing i wanted to ask.. why are those stub libs get built anyway, even if BUILD_NLS is set?
<qwebirc34003>
kyak: doesn't it require autoconf? I'm on a mac and version of autoconf doesn't match.
<kyak>
xMff: i'm pretty sure they are not used by dependencies nor by .config
<kristianpaul>
roh: ok, i'll better send it to manufacture (anyway is just 10USd for all) and wait for results before ask you for the others parts to you
<kyak>
qwebirc34003: i don't know a thing about mac, sorry. I guess you can't build openwrt toolchain there
<qwebirc34003>
ok then. bye everyone!
<roh>
kristianpaul: the work to send out a package with acryllic istnt bigger than without.
<kristianpaul>
roh: So you want to mean, that all measurements are fixed to work with the mechanical setup from your CNC and is probably need more work if the laser cutter is changed?
<roh>
using white acryllic or any regular color is also quite easy
<roh>
yes. i havent seen 2 machine wich use the same preprocessed cad data
<roh>
and since the laser works directly on the dxf its that what i modify to fit
<kristianpaul>
damn
<roh>
e.g. on this machine i know it takes about 0.1mm on each side of the line away (0.2mm wide 'cuts') and the cuts arent '90°
<xMff>
kyak: since the stubs result in no .ipk, I can't add a DEPENDS:= to force them to build, the only way is a build depends spec
<roh>
whats the problem with sending packages?
<xMff>
kyak: problem is, at the time the package metadata is gathered, there is no access to .config vars, therefore I cannot make it conditional... at least I thought so
<xMff>
kyak: I've a diff you can try...
<xMff>
kyak: no actually it is already conditional... seems to not work :)
<kristianpaul>
roh: Is this what you're saying already documented somwhere, or can be considered as a soemthing all people wich drive cnc/laser cutter stuff already, know, i just wondering a future MM1 distributor want to make his own case using our copyleft plans, will sadly start over again design if he want make the case locally
<kristianpaul>
Anyway i'll let this people try out, they confirmed yday they can do it, so lets see what "moster" case came out ;-)
<kyak>
xMff: it's not a problem, just made we wonder why this happens
<xMff>
kyak: oh btw, do you know whether ncurses and ncrusesw provide identical apis?
<kyak>
ncursesw is fully compatible with ncurses as i know
<xMff>
but ...w is a superset?
<kyak>
exactly
<xMff>
that might be problematic for some packages expecting wide char functions
<roh>
kristianpaul: its machine dependant. so it makes no sense documenting the machine i have here when the next one can be different
<roh>
kristianpaul: copyleft just means that one can make derivated works. that doesnt mean that its no work ;)
<kristianpaul>
roh: yes, sure
<kyak>
xMff: such packages should be linked with -lncursesw
<kristianpaul>
Derivative is okay, i'll ask this local company for all this you already pointed me
<kristianpaul>
May be they already derivate it to fit with his machine specs, who knows..
<kyak>
"The normal ncurses libraries support 8-bit characters. The ncurses library can also be configured (--enable-widec) to support wide-characters (for instance Unicode and the UTF-8 encoding). The corresponding wide-character..
<kyak>
..ncursesw libraries are source-compatible with the normal applications. That is, applications must be compiled and linked against the ncursesw library."
<kristianpaul>
roh: No work in copying a manufacuring a desing is something i would expect, i remenber adam did recomendations to make Werner wpan board posible to be manufacture in most places round word,  at least reduce marging to avoid problems
<roh>
kristianpaul: sure. thats what cad data are for. lasers are 'special' there since you usually directly laser the
<roh>
'cad files' and not preprocess for the machine and store to another format
<xMff>
kyak: hm ok, wonder whats the point in having a non-wide ncurses at all
<kyak>
xMff: dunno.. if you are talking about openwrt, perhaps it's there for size/speed optimization
<xMff>
kyak: the diff is 131440B vs. 146815B ... hardly worth the overhead
<kristianpaul>
roh: I'll keep that in mind from now, Thanks for share you experience on this topic !
<xMff>
kyak: oh, I added your patch btw.
<kyak>
xMff: great!
<roh>
kristianpaul: i also got some more files which fo 'batches'
<roh>
4 times the side panels
<roh>
or 2 sets of top/bottom
<roh>
fits on one 32x36cm sheet
<kristianpaul>
30 cms x 27 cms here,
<kristianpaul>
and they said just one will  fit, so may be i can do more
<kyak>
xMff: btw, do you have this "ERROR: please fix package/feeds/desktop/tint2/Makefile"?
<xMff>
let's see
<xMff>
yes
<kyak>
cool, i'm not alone :)
<xMff>
in such cases you can run  TOPDIR=`pwd` make -C feeds/desktop/apps/tint2/ V=99 DUMP=1
<xMff>
this allows to debug the makefile
<xMff>
leads to  Makefile:25: /home/jow/devel/openwrt/trunk/include/cmake.mk: No such file or directory
<kyak>
oh, nice hint!
<xMff>
we added cmake support recently
<xMff>
I'll backport it shortly
<kyak>
interesting! i remember some packages in qi's openwrt-packages that already use cmake
<xMff>
it basically provides better default templates
<xMff>
and tint2 started to use it
<kyak>
yeah, this would help avoid manual construction of CMAKE_FLAGS in Makefiles.
<xMff>
the cmake stuff is now merged to backfire
<xMff>
tint2 should work now after update
<wpwrak>
tuxbrain: you can say "802.11 was yesterday. we have 802.15.4." 802.15.4 > 802.11, so it must be better :-)
<roh>
wpwrak: dont go there
<roh>
802.15.4 will not ever replace 802.11
<kyak>
xMff: thanks!
<kristianpaul>
never said never ;-)
<roh>
kristianpaul: sometimes you can. simply by comparing technologies.
<xMff>
kyak: I think I'll test if everything works with just ncursesw, if this proves successful we'll probably ditch the non-wide curses and just keep the wide on around, maybe with a flag to disable wide support
<xMff>
kyak: it'll be just ncurses then
<xMff>
might take a few days though
<B_Lizzard>
Hey tuxbrain, how's FOSDEM?
<kyak>
xMff: it could work, but i think the best would be to have ncursesw and symlinks to ncurses
<kyak>
xMff: btw, to really use wide ncurses, it is necessary to have uclibc built with locale support
<kyak>
xMff: what i'm afraid of in your suggestion that some apps may detect the ncurses (but not won't know that it is in fact ncursesw), and then disable their wide features
<xMff>
kyak: that why I want to do a survey first
<qwebirc51242>
hello everyone again
<qwebirc51242>
I have failed to install xburst-openwrt in QEMU
<qwebirc51242>
can anyone please send me the compiled image to use with QEMU? I don't have linux on my mac.
<xMff>
qwebirc51242: it is possible to compile openwrt on os x
<qwebirc51242>
but how? it requests filetools as far as i can remember and I don't have that in MacPorts repository.
<qwebirc51242>
Or I was just cloning a wrong image from git?
<qwebirc51242>
I have tried the ubi image in qemu-system-mipsel but it says qemu: Could not load MIPS bios 'mipsel_bios.bin', and no -kernel argument was specified
<xMff>
macports has fileutils afaik
<xMff>
ah, "fileutils" == "gcp"
<xMff>
that is provided by the "coreutils" macport
<qwebirc51242>
can you point me at the right git url to have the image?
<xMff>
applies to the qi-hardware tree as well, the sources differ though
<qwebirc51242>
so I need to get coreutils macport and all other things that make asks for?
<xMff>
yes
<qwebirc51242>
and which qemu to use?
<xMff>
that I don't know
<qwebirc51242>
mipsel or x86?
<xMff>
ah, well
<xMff>
you can build the "malta" target which is for qemu-mips
<xMff>
you can build generic x86 and run that on qemu x86
<qwebirc51242>
err.... how to choose the target?
<xMff>
in make menuconfig
<xMff>
there is also a versatile target which can be used with qemu-arm
<qwebirc51242>
is make menuconfig a command or what? I'm a noob...
<xMff>
uhm
<xMff>
yes
<xMff>
wait a moment
<qwebirc51242>
$ make menuconfig make: *** No rule to make target `menuconfig'.  Stop. //doesn't work :(
<qwebirc51242>
oh, I found out, I need to do that in the openwrt sources dir
<wpwrak>
roh: (802.15.4 > 802.11) hey, that's how marketing works ! ;-)
<wpwrak>
kristianpaul, roh: offsetting the toolpath by the beam radius really ought to be part of the cad-to-machine interface. this is no different from mills.
<roh>
wpwrak: thats how stupid works. sorry.. i have no fun left for marketing goons
<roh>
wpwrak: mills get pre-processed toolpaths in different formats
<roh>
e.g. gcode
<roh>
wpwrak: or to be precise: marketing goons which are too clueless and thus lie without understanding that they do.
<wpwrak>
roh: (gcode) yup. so the tool/beam size would be considered when generating the gcode. after all, the design of the part itself doesn't change just because you or your factory use(s) a different tool.
<roh>
wpwrak: true. but e.g. tool diameter is something which you select on running the job depending on availability and material.
<roh>
even if the model does work for plastic and metal you would use different milling bits, cutting speeds and thus also toolpath
<roh>
you know about high-speed milling? if you mill too slow, the bit breaks.
<wpwrak>
roh: (tool) exactly. these are changes you make in toolpath generation. so the cad design per se stays the same.
<roh>
its a weird graph and only if you cut fast and deep enough, but not too fast and too deep it works.
<roh>
the cad file is a cad file atm. so no real diff from the theoretical model. but to make it work the laser needs to remove the 0.1mm on all sides or it will not fit in reality
<kristianpaul>
yay, finally heekscad segfault is gone..
<roh>
kristianpaul: which one? ;)
<kristianpaul>
roh: hehe, the one after ./heekscad ;-)
<roh>
havent had that yet
<kristianpaul>
i had it for long time, just because i was tracking the last revision
<kristianpaul>
so i decied stay in some old point for some months  until today
<roh>
ah. i do the builds quite unregulary and mostly pick 'more stable' timeframes
<wpwrak>
roh: (0.1 mm) tool path offset. yes, that's part of toolpath generation. your cad should do this automatically. you enter the model and the tool characteristics, then it generates the toolpath.
<wpwrak>
roh: e.g., heekscad has all this.
<kristianpaul>
:D
<roh>
wpwrak: sure. still it will only fit for one machine in general. the next one could have different axis relations
<wpwrak>
alas, kicad doesn't. but then i have cameo for such things, which i actually like much better than fiddling with things in a gui :)
<wpwrak>
roh: x:y != 1:1 ? ouch !
<roh>
wpwrak: gcode often has machine specific tool options. also you could have more axis.. or even less than 3
<roh>
even the direction of axis seems to be variable
<roh>
also feed and spindlespeed is cutter dependant.  imagine you have one with 4 flutes and you have a gcode file for 2 flutes
<roh>
also clamping down workpieces is an issue.
<roh>
as you need to move the mill around the clamps and they could be somewhere else or bigger/smaller on the next machine
<roh>
i have some gcode file i could release for the case. but it has moves for how i clamped it down in there. so i am not sure it will help anybody
<wpwrak>
roh: yes, i agree with all this. but this is all part of the toolpath generation. why would your cad model have to change when you generate a toolpath for a different machine ?
<kristianpaul>
It should
<kristianpaul>
not
<roh>
wpwrak: it shouldnt. only on lasering its an issue since the fileformat is mostly the same
<roh>
wpwrak: atleast on our small machine
<roh>
bigger ones also use more complex cam and then maybe even gcode or so
<wpwrak>
ah, your laser uses dxf directly ?
<roh>
yes. atleast the control sw
<kristianpaul>
directly?? wow
<roh>
its a chinese win32 app which imports dxf (besides other stuff)
<roh>
the native format is proprietary.
<roh>
we only use dxf as 'vector input'
<kristianpaul>
ah wait, but it does some processing before start cutting, or it just read and execute it on the fly?
<wpwrak>
roh: and the control doesn't know how to compensate for the beam size. i see. okay, but that's a bug then, not a feature ;-)
<roh>
i think there is minimal processing happeningm but thats mostly parsing and translating. not really any moving of lines or so
<roh>
wpwrak: it doesnt even have a clue what the beamsize is;)
<roh>
wpwrak: tool diameter offsets is the 'most easy' possibility. think 3d and different millhead types
<wpwrak>
roh: so far, i only have gerber, excellon, gnuplot input, and gnuplot output. (with an external gnuplot to rml-1 converter)
<roh>
wpwrak: e.g. the angle on the end of the mill. etc. not everything is a 'endmill' which looks like a small round block
<wpwrak>
roh: (3D) so your 3D mill also has a dysfunctional interface ? not only your laser cutter ?
<roh>
wpwrak: no. still gcode IS machine dependant.
<wpwrak>
roh: for example, heekscad knows about tool sizes, shapes, etc.
<wpwrak>
roh: (gcode) of course it is
<roh>
think more than 3 axis. there are LOTS of possible ways to move something as soon as you have some angles of freedom
<wpwrak>
roh: that's why gcode is not a cad model exchange format ;-)
<roh>
heekscad is the first serious attempt to 'cam' in the opensource world
<kristianpaul>
agree
<roh>
iges, step are most usable
<wpwrak>
roh: (> 3 axes) alright. then you need something more powerful than heekscad.
<roh>
atleast from my perspective (when it comes to 3d)
<roh>
for 2d i stay with dxf for now. works best, has wide support.
<wpwrak>
roh: but does kristianpaul need a 4-axis mill for the mm1 case ? that's what we were discussing
<roh>
svg generates too many fuckups in my experience. (scaling issues, no serious tools for ordering and editing)
<roh>
i dont know how to mill a mm1 case atm. the slots would need to become longer since you cant mill as rectangular as you can laser easily ;)
<roh>
if you dont want to use different millheads and 'get out the corners'
<wpwrak>
roh: (slots) you'd mill into the corner
<kristianpaul>
actually the guys from wich i get quoute have a laser cutter
<roh>
wpwrak: sure. just looks different and would make it another cad model.
<roh>
slots with round corners
<roh>
i even have used 3.1mm wide slots on some cases where the side panels were from thicker acryllic
<roh>
the stuff i get from evonik (former degussa) has >10% thickness tolerance
<qwebirc51242>
OK, thanks everyone for help, bye!
<qwebirc51242>
compiles openwrt for x86
<wpwrak>
kristianpaul: i think roh is trying to say is that his toolpath generation process lacks proper tool size compensation. he "fixed" this by tweaking the model, which not is machine-specific and thus not really portable. he realizes that this is not good, but tries to defend it anyway ;-)
<kristianpaul>
wpwrak: yes, i understand
<roh>
wpwrak: nope. i am just saying that dxf doesnt say anything about toolsizes or tolerances.
<kristianpaul>
tweak model is bad for me :(
<wpwrak>
roh: also the cutting into corners is part of the toolpath generation. you need to tell the toolpath generator where you want this to happen, though.
<wpwrak>
roh: the less dxf says about the machining process, the better ;-)
<kristianpaul>
oh please roh !!
<kristianpaul>
:-)
<roh>
sure. would be nice to have that information somewhere. if it had i would be making the slots 3.1 and defining the tolerance to 0.
<kristianpaul>
roh: (dxf doesnt say anything about toolsizes or tolerances) it should not
<kristianpaul>
roh: as i dont mix C code with asm
<wpwrak>
roh: (cutting into corners) now sure how this is usually done. in cameo, you can enable some heuristics for this. you can also pass some hints in the gnuplot file, if you really have to. (ugly, but can be useful while developing a new process)
<roh>
also it seems to me that somehow people tend to ignore some of these details.. e.g. when i check ponoko or so i dont see anything about such things
<kyak>
nooooooo
<roh>
wpwrak: cameo doesnt seem to use any fileformats which are of any use.
<roh>
narf.
<kristianpaul>
Is chinesse new year over it seems ;-)
<wpwrak>
mmh, the only project where i used dogbones has the old-style cameo usage where it just added the dogbones but without handling the rest of the process.
<kristianpaul>
s/Is/The
<roh>
so i guess people just assume (atleast for lasering) that things like a 3.0mm defined slot will take a 3mm wide notch and it will slide in.
<wpwrak>
kristianpaul: let's wait for the  git commit -m hangover  then ;-)
<wpwrak>
roh: (dxf) no idea. you can probably just fail if encountering any of the more obscure options. or generate a "dumb" toolpath in a simpler format and work on that.
<roh>
hm. kicad has no proper gerber out?
<wpwrak>
roh: it has gerber out but doesn't know about tool sizes, workpiece orientation, and all this
<roh>
wpwrak: so you have no other cam before milling it?
<wpwrak>
roh: i go kicad -> cameo -> conversion to rml-1 -> mill
<wpwrak>
roh: all done my the invisible hand of a makefile :)
<wpwrak>
s/my/by/
<roh>
eeeeh. i see
<wpwrak>
roh: all that needs manual intervention are workpiece changes (and measuring the origin), and tool changes (drill vs. mill)
<roh>
thats what gcode has toolchange codes for
<wpwrak>
i now have a slightly fancier version that also does arrays. so if i want to make, say, 20 UBB boards, that's another "make" :)
<kristianpaul>
woah !
<wpwrak>
roh: lucky if you have a tool changer that's not you ;-)
<kristianpaul>
why you need wolfgang then? ;-)
<roh>
wpwrak: no. if you dont have one the machine pauses and pops up a dialog to prompt you to change it manually
<roh>
and to set the offset (if you dont have a tool length sensor)
<wpwrak>
kristianpaul: well, that's just the bare pcb. still needs etching and all that. and soldering, for anything more advanced that ubb. actually, even ubb needs soldering (for the surface finish)
<wpwrak>
roh: alas, my machine isn't so sophisticated. so i "make cng", head moves at a convenient position, i remove the old tool, insert the new one (a bit higher than needed), press "5" to move to the center of the part to be drilled/milled, press "d" to move to the head down position, release the tool and let it drop to the board, press "q" to quit, and then "make drill" or "make mill".
<roh>
wpwrak: its a default feature of emc2 (linuxcnc)
<kristianpaul>
wpwrak: sure, just kidding :-)
<wpwrak>
roh: (emc2) yeah, my mill has that crappy rml-1
<viric>
so you know how to tell it where to find the rootfs
<qwebirc60276>
um... I have never compiled it yet. used debian sometimes.
<zrafa>
qwebirc60276: are you trying with qemu?
<qwebirc60276>
zrafa: yes
<zrafa>
qwebirc60276: the screenshot says that you have not said which is the rootfs
<viric>
qwebirc60276: but do you know how to tell the rootfs to it?
<qwebirc60276>
viric: i have tried the -append and it didn't work. I have these images in the bin/x86: openwrt-x86-generic-rootfs-ext2.img openwrt-x86-generic-rootfs-ext2.img.gz openwrt-x86-generic-combined-ext2.img.gzopenwrt-x86-generic-rootfs-jffs2-128k.img openwrt-x86-generic-combined-ext2.vdiopenwrt-x86-generic-rootfs-jffs2-64k.img openwrt-x86-generic-combined-ext2.vmdkopenwrt-x86-generic-rootfs-squashfs.img openwrt-x86-generic-c
<viric>
ah you have an ext2?
<viric>
Then run -hda ....ext2.img -append root=/dev/sda
<viric>
and you build for x86?
<qwebirc60276>
yes of course!
<viric>
I thought you had a mipsel openwrt
<qwebirc60276>
viric: thanks, it finally seems to be booting!
<viric>
>B;8G=>
<viric>
But this is not a mipsel openwrt
<qwebirc60276>
now it's stuck at br-lan:port 1(eth0) entering forwarding state
<qwebirc60276>
OK, seems that I've got to the console. How to start gmenu2x then?
<kristianpaul>
wrong archicture qwebirc60276
<qwebirc60276>
kristianpaul: wrong architecture for what?
<kristianpaul>
gmenu2x port for the ben nanonote?
<kristianpaul>
At least you just want to run gmenu2x on a x86 arch...
<kristianpaul>
and port it your self, etc...
<qwebirc60276>
I'm not sure if it was in the package, I just don't see it in /bin, /sbin /usr/bin and /usr/sbin
<qwebirc60276>
ok then, I'm gonna buy a Ben NN this week, so I'll have time to play with gmenu2x. Now it's time to make apps! :D
<qwebirc60276>
thanks everyone for helping me!
<qwebirc60276>
oops forgot to include the gcc and fpc into the image D:
<kristianpaul>
(gonna buy a Ben NN this week) Thats better :-)
<qwebirc60276>
I will sell my old Chinese Cellphone (you know, 2SIM-TV-FM-etc :) and then I'll have enough money to buy a NN :)
<qwebirc60276>
Goodbye everyone! gonna go sleep, it's 2:40AM here in Ufa, Russia ;)
<kuribas>
Or I could output the data in usb, and then send it to the nanonote.
<kristianpaul>
nanonote is usb client
<kristianpaul>
You have SDIO too..
<larsc>
i2s should work well, if you are going to design your own board
<kuribas>
SDIO would be nice for an external device.
<kuribas>
How good it the battery life?  Could it run for 3 hours?
<kuribas>
"Communication with the PCM1803A is achieved through a serial interface called I2S"
<kuribas>
Interesting.
<roh>
i2s is nothing special. used a lot. also as part of ac97
<kuribas>
I see.
<roh>
its quite simple and i think could be called the de-facto standard how to serially transmit audio from chip to chip
<larsc>
kuribas: under full load the battery should laste ~6 hours
<kuribas>
That would be very good.  Of course the preamps will take a lot of current.
<larsc>
roh: i2s is not part of ac97, afaik. both are protocols to connect codecs to the cpu
<larsc>
kuribas: if the system is mostly idle and the screen is turned of it should last for a day. not sure if you need the screen while recording
<tuxbrain>
hello! guys, I just arrived to Barcelona :)
<roh>
larsc: i2s is much more low level
<kuribas>
larsc: no, the screen could turn of after a while.
<tuxbrain>
roh: common every one needs a marketing goon in his life :P
<roh>
ac97 specifies much more. like register layouts, pinouts, featuresets etc
<wpwrak>
btw, i2s is available on PD18/KEYIN1, PD19/KEYIN2, PD20/KEYIN3, PD21/KEYIN4, PD22/KEYIN5
<tuxbrain>
wpwrak: meanwhile you don't use the Keyboard :)
<wpwrak>
tuxbrain: (return to brc) wow, not even staying for beers ?
<tuxbrain>
enough beers on friday dude :P
<wpwrak>
tuxbrain: typing noise would mess up the sound anyway ;-)
<tuxbrain>
hehehe
<roh>
tuxbrain: its not a real 'includes' or 'uses' .. rather a 'newer version'
<roh>
in the end all that serial stuff is just 'aligned shift registers' ;)
<tuxbrain>
hehehe I love when you guys use the "is just..."Â Â hehehe
<tuxbrain>
I have to sleep a little and to clarify my mind with the miriad of iputs recieved, but one thing is clear among all others... if NN have Wifi We have selled a lot more and I had talk a lot more less :P
<wpwrak>
tuxbrain: with wpan you'll sell only half as many ?
<tuxbrain>
yes, even with wpan I guess people expect wireless comm on such o a portable device.
<tuxbrain>
another conclusion is that 6LoWPAN is not very well known :)
<tuxbrain>
and barely un pronunciable
<wpwrak>
yeah, it's also still quite young
<wpwrak>
"SLowPAN" ? :)
<tuxbrain>
well some contradictory feeling on that name, easy to remember and pronounce =good but I will just use le LowPAN (Low power better than slow speed ;) )
<wpwrak>
hehe :)
<tuxbrain>
also there where some interest on the expandability trhouhg sdio... how was the status on the original idea on the RJ45 ethernet dongle? I miss something or is totally stoped?
<wpwrak>
ethernet ? don't remember that. sounds scary. better connect this via wireless.
<wpwrak>
there was some talk about USB host at the same time we discussed UART. you said you'd do UART and i should do USB. now i've done UART, so USB is left for you (-:C
<tuxbrain>
:P
<wpwrak>
(not so sure if USB would make sense anyway, again because of mechanical stress)
<zrafa>
tuxbrain: but the lack of wireless if something already known . I mean, all of us know that if nn had wifi it would sell a lot more. YOu will not realize it because you were in fosdem
<tuxbrain>
me too... (even more If I have to do it myself :P)
<wpwrak>
*grin*
<tuxbrain>
zrafa..... yes I know before go there... but when about 400 people ask you this in less than two days... you have it echoing  in your mind for weeks :P
<zrafa>
tuxbrain: maybe a similar device is zipit2. Because there is some linux port for it, and wireless works there. Every time you see somebody checking if he should buy zipit2 (which has wifi) or nn he always thinks he should buy zipit2, because the nn lack wireless
<tuxbrain>
is like a brain washing doing from the mass
<tuxbrain>
yes the zipit has come some times in the conversation also, but that is clear answer, try to ask zipit for the schematics and then come again, we are doing serious work to free the hardware stack on the electronics world... and yest it doesn't have wifi move on
<tuxbrain>
of course not so rough and with a smile in my face :)
<wpwrak>
zrafa: conclusion: don't mention zipit2 and hope they won't find out on their own ;-)
<tuxbrain>
of course I have not metion zipit never on my side first :)
<zrafa>
tuxbrain: and I think that atben and atusb would fix the lack of wireless. Still if it is not wifi. But we can say, "yes, it has wireless via atben + atusb; you can use it with your pc as router or with a wifi router with usb". If they are interested for more details they will ask, if no then they just are okey with some kind of wireless connection.
<tuxbrain>
"We find a way to achive free wireless, that is our way, we prefer to innovate towards freedom than being anchored on proprietary stuff" tuxbrain dixit :P
<zrafa>
wpwrak: yeah. I dont say that we mention zipit2. People find zipit2 before nn.. and they then doub about which thing to buy
<zrafa>
wpwrak: and I am talking about typical linux pc user.. who checks for some device with linux, no about people who already know about copyleft hardware and this world.
<wpwrak>
zrafa: do they still produce the zipit2 ? i heard that one of those ben competitors was EOL already, but i don't remember which
<wpwrak>
tuxbrain: (tuxbrain dixit) beautiful :)
<zrafa>
wpwrak: I do not know... but I have seen it costs around half nn price.. and people say "and it has wifi!"
<wpwrak>
zrafa: so let's hipe it's discontinued. then the problem will solve itself ;-)
<wpwrak>
s/hipe/hope/
<zrafa>
yeah :)
<kristianpaul>
it compiless !!!!
<kristianpaul>
now i need learn how to use the api (lua with rtems)
<tuxbrain>
wpwrak: I'm still being sure one day we will be as big or more than that thing with wifi :)
<tuxbrain>
congrats kristianpaul :)!
<kristianpaul>
not yet
<tuxbrain>
ok congrats retired until you decide ;P
<wpwrak>
tuxbrain: what thing ? and what's wifi ? :)
<tuxbrain>
that's the spirit wpwrak, and also not try to not die in the way, no so easy task :)
<kuribas>
It wouldn't be possible to connect my preamp/adc to the nanonote using usb (because nanonote has only usb client)?
<kristianpaul>
Get a preamp/adc with usb host?
<roh>
sometimes i wish we could just open up something like the netwalker
<kuribas>
kristianpaul: If I do that, will it still work an a normal computer with usb host?
<tuxbrain>
ok guys , just one more thing FOSDEM sould be considered as a must visit on wathever has the minimum posiblilty to do so if is FOSS CC FSF or watherver esle related,
<tuxbrain>
good knigh
<kristianpaul>
hmm ECC ..
<kuribas>
So if my preamp/adc would have 4 channels of 24 bit audio at 96kHz, that would need 9Mbps.  That should be possible with usb2.0.
<kristianpaul>
larsc: he said ubifs is obsolte right?
<xMff>
already?
<kristianpaul>
i'm not used to this british-like acent..
<kristianpaul>
ah no
<kristianpaul>
sorry nv..
<wpwrak>
who ? and what does he say is the future then ?
<kristianpaul>
ubifs way to go .-)
<wpwrak>
ah, pity
<kristianpaul>
jffs NO
<larsc>
kristianpaul: no jffs2
<kristianpaul>
ah 2
<larsc>
wpwrak: the talk is by david woodhouse
<wpwrak>
okay, he's the man for anything flash :)
<kristianpaul>
"C as a scripting language" ohh  (watching Rusty Russell talk)
<kristianpaul>
notmuch, interesting alternative to grep?. lets see