Hello, I am trying to access a counter device via ftdi_sio usb to serial convertor and under i386 it is working splendid but on my mini2440 it is not working, does anybody know what is different on both systems or can give me some clue why? The 2440 is running a homebrew busy box/uClibc and kernel 2.6.32.2 (paul jones patches) I am really stuck here and don't see why code doesn't works on the ARM but does on i386. http://www.japie.deserver.nl/ftp/Code/
If you give us some more information what problems you face on your Mini2440 we may can give you some hints. "not working" is not a real information.
Sorry Juergen, Somehow the serial communication is failing but I have no idea why, I added some debug information to the code to see why but my experience isn't that high and base of the code was written by a friend but he doesn't understand why it's not working on the ARM so that is why I posted with a link to the code. If I run the debug version on i386 I get: Header place in array: 2 And on the 2440: Header place in array: 20 There is a frequency counter attached to the usb port with ftdi chip onboard, kernel driver is loaded and the device is assigned to ttyUSB0 so the kernel does seem to work but serial communication is giving trouble. I can't see why this can be different on other architecture so my main question was if somethings are different that we overlooked. Sorry that I can't give more detailed information...
Maybe the CPU speed is relevant here. The Mini2440's processor is slower than your x86 based system. And the Mini2440 has only full speed USB host controller and I guess your x86 system has a high speed USB controller (which makes a difference when you connect your own device through a high speed HUB).
The first thing that popped up over here, the device is plugged in a 2.0 hub but on the other hand so are 2 other devices and they work fine. (one 1-wire adapter and a usb voltmeter that is seen as a HID) I tried increasing the wait times between communication steps but that didn't help, I never changed the baud rate but 115200 shouldn't be a problem on usb-1.1.
p.s. forgot to write that without hub the result is the same...
Yes, 115200 Bd should not be a problem for USB1.1, but maybe the latency is. And a high speed HUB connected to an EHCI at the host side asks a connected USB1.1 device more often (-> lower latency) then a USB1.1 host itself does (-> higher latency, refer 'frames' versus 'micro frames').
To rule out HUB trouble I tested the device without it but that gave the same result, the ftdi chip used is as far as I know also USB1.1 and the amount of transferred data is very small. I don't believe the hardware is the issue since all of the parts function. Kernel header stuff isn't it to since things are platform independent but maybe there is something different in uclibc compared to glibc/eglibc? Or something arm cpu specific?
A high speed HUB only acts differently when it is connected to a high speed host. In your case it is connected to a full speed host. In this case there is no difference in connecting your device to the HUB or to the host itself. Maybe you should re-try with a recent kernel instead of this ancient 2.6.32 one. I do not understand why everyone seems to work with these old kernels. We are at 2012 and the current kernel is 3.3.3.
Why change if it works? (well not in this case then) With a public server or high end desktop I can imagine the need to keep up to date due to security, performance or hardware drivers but in case of an embedded device without network access? Will try with something more recent but my current kernel is performing very well due to Con Colivas bfs patches. I do understand what you are saying but without the hub attached the result is the same...
Could it be related to endianness? Device sending little and the ARM being bi?
Hello,
Problem was in the older ftdi_sio driver which seem to need more options to
initialize properly, with the following I had suxes so for the record:
cfsetispeed(&options, B115200);
cfsetospeed(&options, B115200);
options.c_lflag &= ~(ECHO | ECHONL | ICANON | IEXTEN | ISIG);
options.c_iflag &= ~(IGNBRK | BRKINT | ICRNL | INLCR | PARMRK | INPCK |
ISTRIP | IXON);
options.c_oflag = 0;
options.c_cflag &= ~(CSIZE | PARENB );
options.c_cflag |= CS8;