As investigated by Thorsten Godau the bitrate can only be set after the
slcan adapter is in 'close' state.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Tested-by: Thorsten Godau <dl9sec@gmx.net>
<linux/tty.h> anyway but needs to be written as module alias
tty-ldisc-17 slcan
So we remove the annoying #error output and use the correctly defined
'17' from Kernel 2.6.25+ as default.
via serial (or quasi serial via USB) lines.
This driver is partly derived from linux/net/driver/slip.c and uses a new
tty line discipline (N_SLCAN) analogue to N_SLIP to encapsulate can_frames
sent to a slc* netdevice for the serial line and vice versa.
As only the sending and receiving of can_frames is implemented, this driver
should work with the (serial/USB) CAN hardware from:
> www.canusb.com / www.can232.com / www.mictronic.com / www.canhack.de <
The sending and receiving frames format is pretty common. The other settings
and the 'open' command 'O' of the specific adapters may be set with a
terminal programm (like minicom) before switching the CAN data stream to
the slc* netdevice using the slcan_attach userspace tool.
Feel free to send patches / extensions to slcan.c / slcan_attach.c :)
ps. There had been no performances measurements until now. As long as the
data fit's through the 'serial' line it works obviously well. The slcan-driver
nor the Linux network layer will definitely have no problems to process
the received data. Remember the 'low-cost' hardware approach. We'll see ...