'modprobe' is just a mechanism for loading modules (what Windows people think of as 'drivers'.)
'sudo modprobe serial' would load the 'serial.ko' module, which would allow you to access your ports - assuming that it's not already loaded (you can check that with 'lsmod'.)
The important bit that you need to do is to configure the file that controls the assignment of your serial ports; that's done via 'setserial'. Look at 'man setserial' and '/etc/init.d/setserial'.
For an excellent overall view, take a look at the serial HOWTO: http://tldp.org/HOWTO/Serial-HOWTO.html.
--
Human history becomes more and more a race between education and catastrophe. -- HG Wells
| [reply] |
modprobe is simply a Linux command to load a kernel module; a maybe-necessary prerequisite for working with hardware but probably not. (The udev facility will probably do that for you.)
The real “issue” here is device-name stability. And, looking at the big-picture here, I don't think that you should have any assumption (much less dependency) concerning the mapping of device-names to the various pieces of equipment that you will need to be talking to.
Essentially, you should assume that this mapping will change for one reason or another: controller cards can move, cables can be moved, different Linux/Unix versions, and so-on. None of which have any meaning to anyone in terms of the actual application... who have the very odd tendency to give various devices names like “Sneezy” and “Grumpy.”
Therefore... just let 'em do that. Set up a configuration file of some kind that allows them to map an arbitrary moniker to an arbitrary device-name: grumpy=/dev/ttys4 And then refer to all devices, anywhere and everywhere, by those monikers.
grumpy thus becomes an abstract, symbolic name that actually means something to somebody. When (not if...) someone moves cables around, only this file needs to be changed.
If the devices in question have some way to identify themselves, e.g. a device serial-number query or some other kind of unique-identifier, then so much the better: you can give your program both a list of devices to consider and (separately) a list of identifiers to seek.
| [reply] |
modprobe will only load the necessary kernel modules to make the chipsets on your serialport card work. To test what port gets assigned to them, maybe check the boot logs, or maybe you could loop thru the possibilities and see what happens?
#!/usr/bin/perl -w
use Device::Modem;
# fake array :-) I'm lazy
foreach my $port qw( /dev/ttyS0 .. /dev/ttyS24 ){
my $modem = new Device::Modem( log =>'file,modemlog',
port => $port ) || die "no $port: $!\n";
$modem->reset(); #hangup + attention + restore setting 0 (Z0)
}
| [reply]
[d/l] |
Thank you to the people that have responded so far.
I'll proceed with the assumption that effort will be required beyond plugging in the cards. My current assumptions are:
1) The OS will probably see the cards but there is risk of needing to figure out how to use modprobe if the cards are not seen.
2) I should plan on 5-10 minutes to reinstall Device::SerialPort. I didn't expect this but I had to install Device::SerialPort on a box this morning. As I watched the build messages on the screen it appeared that the install was system configuration dependent.
3) I am assuming that reinstalling Device::SerialPort will give me a new, clean configuration. If the new install won't cleanly cover up the old install then the old configuration might hang around to cause problems.
4) It sounds like the port names might be unstable but the "setserial" command in the first response should fix them.
Thanks,
Bruce
| [reply] |
open(PORT,"+>/dev/ttyS1") or die "Couldn't open serial port\n";
# etc etc
If you have some spare diskdpace, and can take the time to setup a dual boot, try a full-featured OS like OpenSuSE. I found that it is the best at finding and setting up hardware.
You might also want to look in your /dev after booting and see what
ttyS* links there are. Some distros do it differently, they may be real devices or links to some subdir like tts/* Finally if you don't get the chipset recognized, because it is uncommon, or your distro didn't make a module for it, you can do an lspci (assuming it's a pci card) or hwinfo, etc., to get a list of the chipsets. Then you can google for the kernel patch or module to enable that chipset.
| [reply]
[d/l] |