<DocScrutinizer>
why makes me every detail of that google stuff feel like  D-:
<wpwrak>
DocScrutinizer: not |-O***** ? ;-)
<DocScrutinizer>
indeed, just my graphical skills weren't sufficient
<wpwrak>
DocScrutinizer: maybe they're just trying to piss off intel ;-)
<DocScrutinizer>
they can take their fakelocks and eat them
<DocScrutinizer>
even friggin nitdridiot on N900 NIT acts like windows 98 - "now I got control over the machine. let's make sure I don't have to share and never ever will lose it again"
<wpwrak>
DocScrutinizer: ah, i thought you were commenting on their reverse usb :)
<wpwrak>
DocScrutinizer: the locks are nice, yes. they already have quite a tradition. i think i kicked them out of the openmoko kernel, oh so many years ago :)
<unclouded>
hey xiangfu, thanks for including "man".  it looks like busybox "man" expects to find page in /usr/man ( info thanks to strace being included by default!).  the pages I just uploaded are in /usr/share/man and busybox "man" doesn't find them by default
<unclouded>
what the best way to make them work together?
<unclouded>
I could move the libsdl pages to /usr/man, or /usr/man could be a link to /usr/share/man or the other way around, or maybe busybox can be configured to look in both locations?  what the most traditional way to do it?
<xiangfu>
unclouded: have you try this setup variable " $MANPATH"
<unclouded>
xiangfu: that's the most elegant solution.  thanks!
<xiangfu>
unclouded: I still don't have one busybox that have 'man' so I can not test :(
<unclouded>
xiangfu: it works great:Â Â MANPATH=/usr/share/man man SDL_Delay
<xiangfu>
dis MANPATH support like  /usr/share/man:/usr/man ?
<unclouded>
next issue though: when I run that command, I get: sh: more: not found
<unclouded>
sh: gtbl: not found
<xiangfu>
we can export the MANPATH in '/etc/profile'
<unclouded>
that would be great.  looks like it doesn't support multiple paths though: MANPATH=/usr/man:/usr/share/man  man SDL_Delay
<unclouded>
man: no manual entry for 'SDL_Delay'
<xiangfu>
ok. then we just 'export MANPATH=/usr/share/man' in /etc/profile
<unclouded>
ok.  what about this difficulty "man" has in finding more and gtbl?
<xiangfu>
unclouded: I try to compile the busybox. with 'man' , downloading the SDK now. need 20 mis.
<scanf>
im trying to figure out if i want to go netbook or nanonote for an ROV brain
<ron_>
scanf are you talking about a computer on teh robot to use to control it, or a remote console that talks to various microcontrollers on the robot
<scanf>
computer on robot hooked to mcus
<scanf>
probably wirelessly (wifi?) linking to yet another computer
<rjeffries>
scanf Nanonote is a cute and clever little device. IMOI it is not a good match for what you need to do. very lkimited i/o ports
<rjeffries>
about a year ago there was an interesting project that married the COC used by Nanonote with an FPGA. removed keyboard, freeing a bunch of GPIOs
<rjeffries>
it implemented handy things like I2C and Ethernet and oiptionally could have an LCD
<Jay7>
don't forget about MilkyMist SoC
<rjeffries>
but that project withered on the vine
<rjeffries>
Milkymist is a possibility. it costs $500
<scanf>
i should probably just do arm cortex + linux netbook
<Jay7>
seems we are needed some board based on NN jz SoC
<kristianpaul>
rjeffries: Ethernet where?
<kristianpaul>
Jay7: may be but is not a really demanded product i think
<Jay7>
kristianpaul: but it may be 'sellable' :)
<kristianpaul>
may be :-)
<Jay7>
have bought Samsung TV..
<Jay7>
it have some ARM or MIPS board inside
<kristianpaul>
But i realize mips is not part of the DIY prototyping worl
<Jay7>
and firmware is linux-based..
<kristianpaul>
may be also a fpga
<Jay7>
but protected :(
<kristianpaul>
not released at opensource.samsung?
<Jay7>
I want a free TV one :)
<kristianpaul>
But a Analog one
<kristianpaul>
;)
<Jay7>
hehe :)
<kristianpaul>
s/But/Buy
<Jay7>
there is samygo.tv project about hacking that devices
<Jay7>
but I have latest firmware.. and not sure how hackable it is..
<wpwrak>
scanf: the ben is a good choice for tasks that require a small number of i/o signals, particularly if the device itself also has to be small. examples for this kinda of use would be user interfaces or prototyping of subsystems.
<wpwrak>
scanf: if you need more I/Os you would want a dedicated board or, if it gets really complex, a netbook plus usb-based peripherals
<wpwrak>
scanf: besides hw capabilities, you'll also want to pay attention to the porting effort involved in getting things to run on the device, and whether kernel drivers are properly mainlined
<wpwrak>
scanf: finally, anything running linux will have only limited real-time capabilities. the ben can do quite amazing things via the MMC port, including vga output, but if you continuously need operations with very precise timing and/or very short response time, you may want to consider adding some small microcontroller for this specific task.
<wpwrak>
(that's irrespective of what you use as the "brain" in the end - a netbook and even a prototyping board will have similar limitations)
<wpwrak>
scanf: in terms of hw-assisted peripherals, the ben can give you a configurable clock of up to 56 MHz, and via MMC limited-length sequences of clocked output signals (up to four of them), and probably also sequences of input signals (afaik, nobody has tried input yet, though). you can also access a UART if you don't mind a little soldering. if you have no or only limited use for the keyboard, you can use even more peripherals (SPI, etc
<rjeffries_>
wpwrak prolly a dumb question, but how general is the SPI driver in Ben? Could Ben perform as SPI slave (pure curiosity)
<rjeffries_>
this article got me thinking. actually, for general utility with an AVR/Arduino sensor node, two-way communication with Ben as Master would be great
<wpwrak>
rjeffries: no, the ben can't do SPI slave easily. its hardware SPI controller is master only. when doing it with bit-banging, you could theoretically implement slave, but you'd have to worry about timing. (i.e., the SPI clock would have to be quite slow)
<wpwrak>
rjeffries: however, since SPI data is bi-directional, there's usually no problem designing your protocol such that the Ben can be the master, and the MCU, with generally more predictable response time, can be slave
<wpwrak>
rjeffries: if the MCU needs to initiate a communication, it would use an interrupt line for this purpose
<wpwrak>
DocScrutinizer: how many (very roughly) boards would you expect to need to figure out any SMT process issues (e.g., pick and place configuration and such) ?
<wpwrak>
DocScrutinizer: and, more importantly, once the initial problems have been overcome, what yield would you expect in a small run of 100 units ?
<wpwrak>
DocScrutinizer: my guesses would be something like 10 board for debugging the SMT process, maybe less. not sure about the yield. something in the ballpark of > 90%, < 99%.
<DocScrutinizer>
extremely dependant on the fab, and competence of operators. Your numbers looks not completely insane
<DocScrutinizer>
there might be some issues like spilled header boards (reflow temp balance needs min of 10 boards to run thru until temp profile settled on 11 board which is first one expected to be "normally good"
<wpwrak>
DocScrutinizer: good ;-) yes, i know there are lots of unknowns in this equation. kinda like the drake equation :)
<wpwrak>
urgh. that would be nasty for a small run
<DocScrutinizer>
dunno, iirc at OM we had PV runs of 50
<DocScrutinizer>
or 100?
<DocScrutinizer>
you'd need that much to find issues of the more statistical class
<wpwrak>
this is a small production run of 100-130 units
<wpwrak>
nobody around here has any money for real quantities ;-)