Oliver, There is a real problem with udev and TTYUSB device handle assignment, which is why we need this workaround. As a separate effort, I will try to work with the udev developers to get our functionally problem fixed so we can do this remapping thru udev rules instead of the swtch hack. But until then, shell on! -Steve
-----Original Message----- From: Oliver Hartkopp [mailto:[email protected]] Sent: Friday, April 16, 2010 12:49 PM To: Stephen Hellriegel Cc: [email protected] Subject: Re: [Socketcan-users] slcan.c patch which supports stty flag to tell which can# (or slc#) you want the driver to plumb Stephen Hellriegel wrote: > Oliver, > #define SLC_CHECK_TRANSMIT when set causes the linux kernel to panic. With > this feature turned off, we are able to get timeouts which allow us to know > that the remote hardware is not responsive. As far as I can tell, something > enabled by SLC_CHECK_TRANSMIT is broken code, I haven't dug in to find the > problem. > > slcan does not imply only low cost hardware. Low cost does not imply low > performance. Your observations are accurate for older immature USB > implementations that used HID drivers instead of BULK streaming endpoints. > Our slcan based hardware supports full streaming at 1mbit CAN rate, with > negligible processor overhead. There is nothing in the slcan protocol that > implies low cost or functionality. Our interface works as well, or better > than SJA1000 based interfaces. We just happen to connect via a "TTYUSB" > stream rather than read/writes of registers. > (We use a set of NXP 2368 ARM7 micros with 12mbit USB as the uplink, and dual > SJA1000 controllers (embedded in the silicon) for the CAN attachment) > > The acknowledges in the slcan protocol spec are bad news, and I don't know > anyone who implements them. I would like to suggest we eliminate them, as > they break the independent streaming output/input model that the linux tty > environment expects. To do them proper we would have to use the line > discipline module, and have a way to escape the flow control characters so > they don't appear in the stream of data for slcan. > To do this in USB land, we would have to implement a USB CDC ACM (abstract > control model). It's a pain, and way more obtuse than simply using the > generic_serial driver that works fine for TTYUSB communication. > Indeed. I had this feeling before. Thanks for pointing out the problem that clearly - removed the entire code for slcan.c transmit timeout handling : http://svn.berlios.de/wsvn/socketcan/?rev=1168&sc=1 Also changed slcX -> canX http://svn.berlios.de/wsvn/socketcan/?rev=1169&sc=1 > Really the problem is focused around plugging and unplugging USB devices. > SLCAN roots are true serial ports which don't have the dynamic features of > USB. > > The workaround presented in the patch does solve the problem; when a TTYUSB > enumerates, you get an unknown number for the same physical interface. You > want the network of CAN hardware attached to a device to always be referred > as the same CAN0. For example, the first time I plug in a "dongle usb->can" I > get TTYUSB0. The second time, it may be TTYUSB1. All the way up to TTYUSB127 > (or whatever the kernel is configured for) > > You need to be able know what interface enumeration you are going to come up > on as a command line argument. > Putting the data in files doesn't tie will into a script that can be fired by > udev rules. > You see, we have 4 can interfaces, and when they are reset, they come back as > different TTYUSBX. My can0 might be TTYUSB0, TTYUSB127, I don't know until > the udev system fires, and my rule triggers which plumbs the hint to the > slcan driver (via the swtch char) > > slcan is not in the mainline so the issue about what we do can be tabled > until the point mainline kernel developers want to take it on. Logically, > swtch is never going to be removed, as it is a valid required interface for > an shell module. No one will ever use a shell module on a serial port in use > as a slcan interface, so the overload is safe. > > We tried the ip link approach, but it doesn't work due to the dynamic nature > of the interface names. This was our first approach, we wouldn't have > modified a kernel driver if ip link could solve our problem! The udev naming > rules are unable to match as under the covers, the kernel still uses the > TTYUSB numbers, not the alias created by iplink. > > The approach you suggested only works in a static configuration (like a true > serial port), which isn't real world with TTYUSB. I fixed up your SWTC code patch (whitespaces!!) and applied it to the SVN in a separate commit: http://svn.berlios.de/wsvn/socketcan/?rev=1170&sc=1 Do yo have an idea, how the code can be made operational for Kernels >= 2.6.33 also? So far the patch is in a #if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,32) section ... Regards, Oliver _______________________________________________ Socketcan-users mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-users
