<kyak>
unclouded: hi, did you actually get nightsky working?
<kyak>
because 1) it won't build, but i fixed it with -rpath-link and 2) it runs, but hangs and does nothing
<unclouded>
kyak: yes, I installed the package to my NN and it started
<kyak>
hm, that's strange
<unclouded>
does it write anything to stdout before hanging?
<kyak>
do you have the latest everthing?
<kyak>
no, it writes nothing
<unclouded>
afaik
<kyak>
when i strace it, the last line is getuid() = 0 and then nothing
<unclouded>
it's looking for the user's home directory
<kyak>
yeah, i know
<unclouded>
the next call should get getpwuid
<kyak>
i tried to change it (i.e. hardcode the path to yml file), but it still hangs
<kyak>
in a weirdest way
<kyak>
there are two ioctl's, and after that - nothing
<unclouded>
scratches head
<unclouded>
is path_to_data set to some really long path or is it the default?
<unclouded>
also, I thought the Makefile used rpath-link already?
<unclouded>
kyak, could it be RAM?  how much free RAM have you got?
<kyak>
for the RAM, i have swap enabled, so should be no problem
<kyak>
i have warnings about rpath-link not enabled that prevent from building.. so i had to add it manually to TARGET_LDFLAGS in openwrt's Makefile
<kyak>
then it builds.. i rememeber you use openwrt SDK instead of toolchain, could it be the difference between us?
<kyak>
i tried to printf path_to_data, but it won't output (i.e. it doesn't even call "write")
<kyak>
it hangs somewhere before
<kyak>
and the strangest thing is, when i uncomment this line where is checks for home dir, strace output is finished after getuid()
<kyak>
unfortunately, i can't check anything right now.. would be good to check this path_to_data before call to getuid()
<unclouded>
which is the SDK and which is the toolchain?  Just now I did git pull on openwrt-xburst  and did package/nightsky/{clean,install} V=99, reinstalled in on the NN and that works
<kyak>
than it's toolchain that you have
<kyak>
i me, too
<kyak>
we should be on the same level then
<kyak>
with the same hardware :)
<kyak>
weird!
<unclouded>
exactly.  we shouldn't see any differences! :(
<unclouded>
could it being a glibc/uClibc thing?
<kyak>
did you do make package/symlinks?
<kyak>
i think recently they switched to uClibc-0.9.32
<kyak>
do you have it in your build_dir?
<unclouded>
I don't remember.  probably not, just scripts/feeds update -a && scripts/feeds install -a
<unclouded>
let me check
<kyak>
ah, this is the same
<unclouded>
no, I've got: build_dir/toolchain-mipsel_gcc-4.3.3+cs_uClibc-0.9.30.1
<unclouded>
kyak, I rebuilt my OpenWRT from clean with "make tools/install toolchain/install package/nightsky/install" and it built ok.  hope yours rebuilds ok from clean
<kyak>
tslib.cpp:42:19: error: tslib.h: No such file or directory
<kyak>
stupid qt4 won't compile again
<kyak>
Clock.h:10:21: error: SDL/SDL.h: No such file or directory
<kyak>
this is nightsky
<kyak>
actually, something is wrong with your toolchain
<kyak>
it should NOT compile nightsky
<kyak>
because it depends on sdl, and by make package/nightsky/install you don't  build dependcies
<kyak>
at what point exactly was your libsdl and sdl-image build exactly after cleanup?
<unclouded>
true.  I didn't rm build_dir as you did
<unclouded>
so libsdl must still have been lurking there
<kyak>
indeed
<kyak>
now i'll just wait for someone to fix qt4
<kyak>
(as usual)
<kyak>
damn i get so pissed every time is is broken AGAIN upstream
<kyak>
how are they testing??
<unclouded>
can you build libsdl and libsdl-image without building qt4?
<kyak>
i'd like to avoid it
<kyak>
it means manually building dependencies for libsdl and libsdl-image and dependencies of depenedcies.. and so on]
<unclouded>
not fun
<unclouded>
shame the build system can't do it auto.  the data is there
<unclouded>
once a package has been ported to openwrt-packages, what has to happen before it's available for installation via opkg?
<kyak>
i think it has to be included in the next build :)
<kyak>
i mean, next release of image for Ben
<qi-bot>
[commit] Werner Almesberger: Setting the transmit power was broken. (And LQ works, by the way.) http://qi-hw.com/p/ben-wpan/2514804
<wolfspraul>
kyak: when you say qt4 is broken 'upstream' - where do you mean?
<wolfspraul>
in openwrt?
<wolfspraul>
I think mirko is quite active on all things qt4
<wolfspraul>
does he know what is broken? what is broken? :-)
<kristianpaul>
wpwrak: hey
<kristianpaul>
you planning use CPLD to interface SPI?
<kristianpaul>
hmm i have XC2C64A board from digilentic if you need try a core or something
<kristianpaul>
i need SPI plus some glue logic too
<wpwrak>
kristianpaul: i was inquiring about how hard/easy it would be to make an SPI to SPI bridge for the software-defined GPS wolfgang is considering. it would basically be a chip that outputs an SPI-like stream of quadrature samples at a few Mbps.
<wpwrak>
kristianpaul: since the ingenic cpu can only be an spi master, not an spi slave, we would need some glue logic with a (very) little buffer to translate between the two.
<wpwrak>
kristianpaul: my question is just if the simplest and cheapest CPLD is already good enough or this or if we need something more powerful. i'd leave the implementation to the experts ;-)
<kristianpaul>
:)
<wpwrak>
(well, if sebastien one day writes a free synthesis tool for fgpas and such, i might be interested to play with programmable logic. verilog looks kinda nice :)
<kristianpaul>
yeah is nice :)
<kristianpaul>
i'm learning using the MM SoC
<wpwrak>
nice way to get started ;-)
<kristianpaul>
i can acept Xilinx for now is the only non-free stuff i use in electronics
<kristianpaul>
btw are your aware of GPS signaniling and processign ?
<kristianpaul>
i'm just learning too amazinf topic btw
<kristianpaul>
amazing*
<kristianpaul>
ah i founded losts of free sofware projects involved around, great !
<wpwrak>
i have one non-free thing crawling about on my systems, and that's the windows-only (and non-wine) 3d scanning application. that's already more than enough for my taste ...
<kristianpaul>
i have my heekscad is okay for my 3d needs
<wpwrak>
(gps) i don't really know about. wolfgang just asked me a few questions about which rf frontends would generally fit, assuming you want to do as much as possible in software. there's someone else working on a dsp-based gps reciver we could then adapt. (or that's the theory)
<kristianpaul>
i see
<wpwrak>
alas, heekscad doesn't speak the proprietary protocol my cnc mill uses when scanning :-( and reverse-engineering it isn't quite easy either. it's already hard to snoop it in a useful way :-(
<kristianpaul>
:(
<kristianpaul>
3d is hobbiest so i dont hurge for high advanced features
<wpwrak>
well, one day i'll try ... but for now, i'll just live with having an enemy (i.e., a windows box) in my camp
<wpwrak>
very high-end 3D gets expensive anyway ;-)
<kristianpaul>
if you can handle is okay
<kristianpaul>
indeed
<kristianpaul>
btw what do you think is the trugput that the Ben Xbust can support on its gpio pins?
<kristianpaul>
i dint check datasheets in depth hoping find that info
<wpwrak>
hmm, you mean the highest frequency at which you can toggle a gpio ?
<kristianpaul>
yeap
<kristianpaul>
(sorry my english dictionaary is small)
<wpwrak>
i would expect a few dozen mhz. almost certainly < 100 MHz, though. the limiting factor should be cpu cycles and the internal busses.
<kristianpaul>
ok
<kristianpaul>
good
<wpwrak>
you can write a little assembler program that sets a gpio on and off. you probably need to unroll the loop, though, for an accurate measuement.
<kristianpaul>
any Xburst hacker around?
<kristianpaul>
ywah i was thinking in asm right now
<kristianpaul>
i need fast gpio response
<kristianpaul>
and i dont trust linux for that !
<kristianpaul>
i guess will be slow
<wpwrak>
linux will be slow :) my guess would be that a memory/register access costs you at least 2 cycles, so a "write 0" followed by "write 1", infinitely unrolled, would need 4 cpu cycles per cycle of the signal. so that's 84 Mhz.
<kristianpaul>
yeah i think i need check code examples from SIEÂ Â Unal guys did great work documenting gpio and low level stuff
<kristianpaul>
s/Unal/UNAL
<wpwrak>
if you want to, say, output some data in parallel, a la SPI, that would be  shift_data(1), write_carry(2), write0(2), write1(2) = 7 cycles or 48. this is quite optimistic. not sure if the xburst can be so efficient. if it needs an add or, worse, a jump in this case, expect even less
<kristianpaul>
well may the CPLD save the day, just in case ;)
<wpwrak>
bit-banging serial protocols almost always sucks :)
<kristianpaul>
or a dual core Xburst :D
<kristianpaul>
yeah :(
<kristianpaul>
well i pics (my previous experience) is okay for simple stuff but well protocols with Mhz is soemthing i need to deal with
<kristianpaul>
s/i/in
<wpwrak>
hmm yes, i'll have to speed up the little spi in my rf board as well. right now, it should be crawling at less than 1 Mbps ... (not that it matters so far)
<wpwrak>
and then there's of course the frequency counter board that stubbornly refuses to do anything. that one should work up to 6 MHz, although with hardware support.
<kristianpaul>
oh thats hihg
<kristianpaul>
high*
<wpwrak>
the latter is for calibrating my crystals. the idea is to count the 1/2/4/... MHz clock derived from the crystal, then compare this with NTP time. after a day or so, i should have 1 ppm accuracy :)
<kristianpaul>
ohh
<wpwrak>
saves me buying a USD 3000 frequency counter :)
<wpwrak>
(of course, the latter would still be nice to have. ah, prorities, priorities ...)