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. 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. -Steve -----Original Message----- From: Oliver Hartkopp [mailto:[email protected]] Sent: Thursday, April 15, 2010 10:40 AM 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: > This patch uses the device prefix "can" instead of "slc". A binary library > we paid for has "can" hardcoded as the prefix of the CAN devicename; "slc" > breaks it. > Just search for the edit at slcan.c line 753 in the patch and you will see > where you can change can back to slc if you are really fond of the slc prefix > for any reason. > > If not, I would love for the default to be can instead of slc, to be > compatible with other interfaces! Hello Stephen, you are right! I also thought about creating canX instead of slcX ... will change that. But first read the stuff below, if it makes sense to stay on this naming scheme. > +/* > + * By default, do not turn on SLC_CHECK_TRANSMIT > + * when a slcan device transmits into an unconnected network, > + * the transmit timeout causes a kernel panic, this behaviour > + * should be at the choice of the user. > + */ > + > +#if 0 > #define SLC_CHECK_TRANSMIT > +#endif > + You mean, that the slcan device does not send any reply when it's CAN controller doesn't get the CAN frame onto the bus, right? If so, it would be ok for me also. The slcan stuff *is* low-cost hardware, and running any kind of acknowledges seems always to lead into problems. --- Coming to stty swtch ... > The following patch file enables a user to perform the following: > Choose which device instance number you are going to get for a slcan port. > This is really handy if you have 4 or more 1mbit slcan interfaces that come and go asynchronously in a Linux system... > > #Say you want to kick the CAN on /dev/TTYUSB9 as device can4 > stty swtch 4 -F /dev/TTYUSB9 > #now call slcand as normal > ifconfig can4 up > > > Presto, no hunting around to figure out which "slc" or "can" number the call to slcand came up on. > AFAICS this approach does not solve the problem at it's root. And i doubt this to become a functionality for mainline Linux as it 'reuses' potentially 'dead' options in a different manner ... I would propose to have a table of assignments, e.g. in /etc/slcan-devs /dev/ttyS0 can0 /dev/ttyUSB0 can3 1. The slcand may create a file in /var/whatever containing the serial device name "/dev/ttyUSB0" at netdev creation time. 2. Let's say the slcand still creates a 'slc0' netdevice with the ioctl() 3. Write a udev-rule that's invoked when the 'slc*' is created and announced to the system. This udev-rule can look through /etc/slcan-devs and then renames slc0 -> can3 with the ip-tool: ip link set slc0 name can3 4. Remove /var/whatever to be ready for the next slcan device creation That's IMHO the way this slcan 'naming problem' should be handled in the user-space. Setting "stty swtch 4 -F /dev/TTYUSB9" makes the problem a kernel problem but it does not solved the original issue. Regards, Oliver _______________________________________________ Socketcan-users mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-users
