Linux & NSLU2
The NSLU2 is a commercial product that has been widely hacked to produce a very lightweight general purpose Linux box. Its original intention was to provide network storage. The main site for hacking into this box is http://www.nslu2-linux.org
This contribution is from Mike at http://www.phosco.com who is using an NSLU2 connected to a BV4221 to drive I2C equipment. He has discovered some peculiarities in the way it works. This may help others in the same situation. The problem and solution are presented below. Mike has also kindly sent his code for driving the BV4221.
"My code works fine on my desktop (AMD64 running Linux), but my target
machine
is an ARM embedded device (a Linksys NSLU2 also running Linux, AKA the Slug.).
Compiling the code natively on the slug using the same gcc compiler but with
the ARM target CPU gives me an executable with exactly the same compilation
messages that works on the desktop.
On the Slug, the code writes to the I2c bus fine, and I get back the "0xnn>"
prompts, and I get a version number from the command "V". Any of the
"s...."
commands, however, give me "Error 3 <CR>0xnn>", which is strange, as if I use
a terminal on the slug and give the exact same "s" commands, they work fine!
I don't understand why they work OK via terminal on both my desktop and on the
slug, and OK by program on the desktop, but give this error by program on the
slug."
The solution turned out to be:
"I've discovered now that on the NSLU2, as a general user (not root or
superuser) even if you have permissions set to use the USB serial device, it
behaves slightly differently than it does if you are root or a superuser.
If you are root or su, it works fine with unbuffered terminal calls, otherwise
with "s" commands only it gives "Error 3".
This behaviour is not seen on AMD64 Linux. I suspect a bug in a slightly older
version of the driver on the NSLU2, perhaps something timing dependent. I
can't go much further without a lot of effort, and since a bypass is easy, I
don't propose to.
So, just for your information so you can tell anyone who hits the same on the
NSLU2 or similar hardware running back versions of Linux and the usbserial
drivers:
1) use unbuffered I/O
2) run as superuser."