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
