<tux7>
new online community www.blitzpost.com (email, blog, chat, photos..)
<qi-bot>
[commit] Werner Almesberger: KiCad dislikes dots in file names: renamed u.fl-receptacle to u-fl-receptacle http://qi-hw.com/p/ben-wpan/7c2542e
<xiangfu>
kyak: thanks for fixed "Partition offset"
<bartbes>
so did anybody have a working method of making a ben talk to an arduino without hardmodding either?
<wpwrak>
bartbes: does the arduino have usb ?
<bartbes>
usb client
<wpwrak>
bartbes: then you could use a pc as a relay. ben sends stuff to relay program on the pc, pc sends stuff to the arduino, and vice versa
<bartbes>
but that's not what I want..
<bartbes>
I'm more interested in serial comms between the two
<bartbes>
iirc there's ttl on it
<wpwrak>
bartbes: alright, if this fits your definition of "not hardmodding", you could make a uSD-shaped pcb that plugs into the ben's uSD slot and that connects on the arduino on the other side. then define your own serial protocol over it.
<bartbes>
oh yes, because I have the tools to do that..
<bartbes>
anyway, there was some dude who was working with it
<bartbes>
but who..
<wpwrak>
bartbes: if the arduino isn't 3.3 V compatible, you'd need some level adaptation. probably not more than some resistors.
<wpwrak>
bartbes: you mean Ornotermes ?
<wpwrak>
bartbes: (tools) tools to make a PCB in general or to cut one in that shape ?
<bartbes>
both
<wpwrak>
hmm. your choices seem to be very limited :) does the arduino have wifi ?
<bartbes>
no
<bartbes>
I just remember some guy hooking it up to the serial outputs on the nn
<wpwrak>
but isn't that "hardmodding" ?
<bartbes>
not if those were the ones beneath the battery
<wpwrak>
like, opening it, soldering wires into it.
<wpwrak>
okay. then it should be quite feasible. you just have to determine if the arduino is 3.3 V-friendly.
<bartbes>
it's 5V, I guess
<wpwrak>
the you'll need a voltage divider arduino->ben. add some 100 Ohm series resistor in the other direction too, as protection.
<kyak>
mirko: the problems you experience with gcc-mips appear when you build on 64bit host?
<mirko>
kyak: yep
<kyak>
hm, okay.. need to find 64bit to see what's going on
<mirko>
kyak: as our buildhosts are 64bit i had mark it as broken for now
<mirko>
didn't have time to investigate - was sth. like sizeof failed or so
<kyak>
the problem is known
<kyak>
i'll contact wolfspraul for an account on build host
<kyak>
then i would be able to investigate
<mirko>
kyak: if wolfgang agrees but has no time to do so yet, i could create you one as well
<mirko>
jfi
<kyak>
ok, thanks
<kristianpaul>
bartbes: beneath battery is not recommended
<kristianpaul>
bartbes: i think tuxbrain said is alaso 3v3 compatible...
<kristianpaul>
but not sure
<kristianpaul>
just try feed it with 3v3 and see how it goes
<wpwrak>
kristianpaul: hmm, what's this burnt smell ? :)
<steve|m>
or how my grandfather used to say: "the smell of radio" :)
<kristianpaul>
wpwrak: :p
<kristianpaul>
ok lests wai tusbrain and tell us his experiences
<kristianpaul>
or dig on the list i'm sure he said something about ti
<rafa>
I can not believe his questions.. and maybe he is just kidding
<rafa>
no idea
<kristianpaul>
how i can do a nanosecond delay...
<rafa>
kristianpaul: man nanosleep?
<wpwrak>
kristianpaul: man nanosleep :)
<kristianpaul>
ahh
<kristianpaul>
soryy !
<rafa>
haha
<rafa>
werner is smart :D
<kristianpaul>
ah as simple as islep
<kristianpaul>
uslepp*
<kristianpaul>
usleep*
<wpwrak>
rafa: let's see how it takes him to find out what these functions really do :-)
<wpwrak>
rafa: (wiki) well, the front page could be a bit less yahoo and a bit more google :)
<kristianpaul>
". The suspension time may be longer than requested because the argument value is rounded up to an integer multiple of the sleep resolution or because of the scheduling of other activity by the system" Waht??
<kristianpaul>
i may better follow  the RTC
<wpwrak>
rafa: he's quick :)
<wpwrak>
kristianpaul: inside the kernel, you have udelay and such, which don't sleep but busy-loop
<rafa>
wpwrak: (wiki): yeah.. but it does not give him reasons to ask stupid questions :)
<kristianpaul>
yeah sorry i should g00gl3d before
<wpwrak>
rafa: i find his way of asking questions quite interesting. he asks as if he would ask on behalf of others, like a reporter.
<rafa>
kristianpaul: are you replying about "stupid questions"?.. I was talking about that "Ron"
<kristianpaul>
rafa: ah yes about that :p
<kristianpaul>
i just feel that  i shoudl supposed that if i  was using usleep there was a nanosleep as well
<kristianpaul>
ok rafa
<kristianpaul>
wpwrak: Linux deprecates the usleep( ) function, replacing it with nanosleep( ), which pro-
<kristianpaul>
vides nanosecond resolution, and a smarter interface:
<kristianpaul>
according to Linux System programing book
<wpwrak>
kristianpaul: what are you trying to do ? send a pulse of a precise width ?
<kristianpaul>
wpwrak: yeap
<kristianpaul>
well more o less precise
<wpwrak>
kristianpaul: how precise ? ;-)
<wpwrak>
i.e., what are the upper and lower bounds ?
<kristianpaul>
min 10ns
<kristianpaul>
max...  well there is no max value in the datasheet...
<wpwrak>
perfect :)
<wpwrak>
this is running on the ben ?
<kristianpaul>
Xbusrt right
<wpwrak>
then you probably don't need any delay. just set and immediately clear. you'll get something like a 200 ns pulse.
<wpwrak>
(if in doubt, check with a scope :)
<kristianpaul>
arggg !
<kristianpaul>
i DONT hace a scope fot measure that yet :(
<kristianpaul>
i'm working on that too :-)
<wpwrak>
good :) you need a decent scope for this sort of work. or a lot of patience and extreme luck ;-)
<kristianpaul>
i realized that some weeks ago
<kristianpaul>
200ns pulse?? is linux soo slow???
<kristianpaul>
wpwrak: whats the min pulse you got and luckylly measured?
<kristianpaul>
ha
<wpwrak>
linux has very little to do with this :) remember that i get ~2 Mbps when i do one-way "SPI".
<wpwrak>
ah, let's see ...
<kristianpaul>
if iw was supposing to measure a max of 12ns clock delay is inposible using the Xburst IO then?
<kristianpaul>
yeah i saw the mail
<kristianpaul>
anf the graphs ..
<kristianpaul>
and*
<kristianpaul>
wpwrak: you meant is hardware fault?
<wpwrak>
what exactly do you want to measure ? the duration of a pulse ? whether a pulse has happened ?
<wpwrak>
yup, hardware isn't so fast
<wpwrak>
190-200 ns per cycle. so the pulse is about 100 ns
<wpwrak>
gcc unrolls the loop a little (2x), but there's no difference in the signal. so the speed is determined by the bus, not the core. (as expected)
<kristianpaul>
measure <- the duration of a pulse
<wpwrak>
will there be many pulses or just one ?
<kristianpaul>
many
<kristianpaul>
is a clock
<kristianpaul>
data is synced with clock and SYNC sinal
<kristianpaul>
signal
<wpwrak>
naw, i think there's no way to do this with just the cpu. it's too fast.
<wpwrak>
10 ns is actually even difficult for many scopes.
<kristianpaul>
well my second option is just follwo the SYNC pulse
<kristianpaul>
an catch the 3 bits data
<kristianpaul>
s/3/4
<wpwrak>
kristianpaul: but what are you trying to do anyway ? it's not your GPS stuff. that one is much much slower.
<kristianpaul>
SYNC pulse is 2.048 M/s
<kristianpaul>
wpwrak: in part the question was related to GPS
<kristianpaul>
stuff
<wpwrak>
which chip is it again ? 4162 ?
<kristianpaul>
yup
<kristianpaul>
clock signal is 8.192 MHz btw
<kristianpaul>
wait a min
<kristianpaul>
yes i was reading the Logic Timing Characteristics
<kristianpaul>
and units are ns
<kristianpaul>
wpwrak: in full datasheet is page 16
<wpwrak>
oh, but why do you care about this parameter ? just sample on the rising edge, not falling edge+tDEL
<kristianpaul>
hmm
<wpwrak>
of course, you're probably still too slow to catch data going at 8 MHz. let's see ....
<kristianpaul>
sure
<wpwrak>
yup. 10 Mreads in 2.75 s. that's about 3.6 Mreads/s. peak may be a bit higher. i didn't raise the priority or such. let's say, maybe 4 Mreads/s
<wpwrak>
but that's what you have an FPGA for ;-)
<wpwrak>
or CPLD)
<kristianpaul>
yeah sure
<kristianpaul>
but i'm trying to use what we already have and more coming
<kristianpaul>
this little computer called nanonote :p
<kristianpaul>
then if is really inposible move to FPGA stuff
<kristianpaul>
as you with wpan
<wpwrak>
don't you have a SIE ?
<kristianpaul>
i do
<kristianpaul>
is on righ now actually
<kristianpaul>
actually i'm trying to read ADC using C code not C++ wich i dont uderstand :-/
<kristianpaul>
on Jlime :D
<wpwrak>
so there's the solution :) the ben can't do this without extra hardware. so you can develop first with the SIE and then make some optimized hardware
<kristianpaul>
well yes
<kristianpaul>
but Wolfagang insist in look the single Ben first
<kristianpaul>
SIE was second
<kristianpaul>
i dont want conclude tha the Ben is not capable of
<kristianpaul>
yet
<kristianpaul>
i need do more test
<kristianpaul>
ah sure i cant meaure clock
<kristianpaul>
and by then data...
<kristianpaul>
just a SYNC pulse :-|
<kristianpaul>
i just tought, okay, i can wait for SYNC then capture the data in the spected time
<kristianpaul>
and verify timing later..
<viric>
kristianpaul: what do you try to do btw?
<kristianpaul>
but not make sense because i cant follow rise edge at 8Mhz..
<kristianpaul>
viric: hello
<viric>
hello. Sorry for coming late :)
<viric>
I was just curious
<kristianpaul>
sure
<wpwrak>
kristianpaul: you could perhaps add a flip-flop to toggle on each SYNC. the use this as nSS for SPI.
<wpwrak>
that way, we will receive at least some data
<wpwrak>
but what a mess :) better to use a SIE. make things work at all first, then optimize the implementation