Embedded Linux >> Changes in serial port driving from 8.0 to 9.1 and 10.0- did the device drivers inside the kernels change?

by drwho8 » Fri, 24 Sep 2004 10:46:01 GMT

Hello from Gregg C Levine
Here's the facts. 1) A program which works on Slack 8.0, but does not send data
through serial port of computer, when the same screen shows it starts on 9.1 and
10.0. Slack 8.0 used the 2.2.1x series of kernels. 9.1 and 10.0 used the 2.4.2x series
of kernels.

2) The same program built using Cygwin, works on this machine, no matter what
version of Slackware is also available.

This program was written to send data to a Sega Dreamcast via its serial port, for
development purposes.
So can anyone with more wisdom then mine remember if the device tables for the
serial character drivers changed during the transistion between the releases?
-------------------
Gregg C Levine drwho8 atsign att dot net
"This signature visits Area 51 during the daytime."



Similar Threads

1. [PATCH] changes device to driver in porting.txt

2. recent 8250 serial driver changes in 2.6.x kernels - Embedded Linux

3. Virtual Serial Port changing COM port number

I've developed a virtual serial port driver (UMDF) which uses the
built in SerialPortPropPageProvider (msports.dll) to display the port
property page.

If the COM port number has been changed in the property page, what is
the best way of restarting/reconfiguring the driver?
From what I can tell, one option is to create a co-installer to look
out for the DIF_PROPERTYCHANGE and then restart the driver. Is that
the normal way of doing it?


4. Serial ports and the Dreamcast and Slackware Linux 9.1 - Embedded Linux

5. USB Drive changes ATTRS{serial} everytime plugged in

Hello everyone,

I was trying to get udev mounting my encrypted partition automagically
when my USB drive with the key on it is plugged in. Mounting works
fine (when script is run by hand), but I didn't manage to get the udev
rule working. Now I found why.

Everytime I plug in the USB drive it gets a different ATTRS{serial} as
reported by:

udevinfo -a -p `udevinfo -q path -n /dev/sdg`| grep serial

The reported serial number is only 2 hex digits long and seems to be
random.

I have another identical USB drive (same model) which provides a quite
long number that does NOT change. That is what I do actually need...
(Please do not recommend using the other device instead -- one of them
will be plugged into my docking station, the other one is for "mobile"
use)


You know why this happens? I cannot imagine a sensible explanation.
Except this detail the USB drive works without problems -- it does not
seem to be damaged/broken.

I would be glad to get some hints what could cause this problem. If
needed I will provide more information or logs. Just ask for
particular ones.


Kind regards
Daniel Bmer, Germany

6. Change IP TOS inside ethernet driver - Linux

7. Serial port: flushing & changing baudrate problem

Hi folks,

I apologize if the following has already been discussed but googling
for old posts I didn't find what I was looking for.

My problem: I have to communicate with a device through a serial port.
Everything works properly if I communicate at 57600, but on the
attempt of changing baudrate (which also the remote device does), I
lose data coming from device.

I think the problem is a delay in one of the two (or both):
. flushing function
. new baud rate settings

Flushing.
My understanding is that tcdrain and tcflush care just about flushing
the output buffer, but there is no way of assuring that data coming
through serial are actually read before the baudrate exchange.
Am I wrong here? any hint?
The way I use tcflush / tcdrain is:
    tcflush(fd, TCIFLUSH);
or
    tcdrain(fd);

Changing the baudrate:

	tcgetattr(fd, &newopt);
        [..]
	int baud;
	switch (arg)
	{
         default:
         case 115200:
         	baud = B115200;
         	break;
         case 230400:
         	baud = B230400;
         	break;
         case 57600:
         	baud = B57600;
		break;
	 }

	cfsetispeed(&newopt, baud);
	cfsetospeed(&newopt, baud);

	//tcdrain(fd);
	int err = tcsetattr(fd, TCSANOW, &newopt);

Anything obviously wrong here?

To my understanding what really happens is that the baudrate it is
changed, but it happens too slow and on the while I miss data coming
from the serial device.

Thank you for any hint.
Mik

8. serial port permissions changing