Looking for driver for RS-232 serial card PCI.
Teuniz
size of 16 bytes, I bought a Brainbox PCI-card, model UC-246 which has
a FIFO of 128 bytes
I hoped it should be recognized by OpenSUSE because the company
released sourcecode to compile a module for the 2.4.24 and the 2.4.25
kernel.
Unfortunately, it's not recognized by OpenSuse.
lspci shows:
04:01.0 Multiport serial controller: Brain Boxes Device 0aa2 (rev 01)
dmesg I grep tty shows:
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
00:09: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
00:0a: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
which are my other two normal serial ports.
My questions:
Does anybody know a solution?
If not, does anybody know where else to look for a solution?
I haven't contact the manufacturer yet.
My hope is that somebody dealt with this before and can tell me what
to do.
Best regards.
Bob Bob
functionality into a 2.6 kernel a few years ago.
It may be worthwhile having a look at the on board chips to see if they
are used by another manufacturer. Kernel module source code is often
sprinkled with reference to chip part numbers. It has a BB16PCI958 UART.
Also have a look at "setserial". That is how you configure such things
that are non standard.
Do you see a kernel module (lsmod) for the BB card? I dont have the
kernel source loaded at the moment but if I did I'd try a grep -R in the
tree for the UART and board names. If you find it just load the module
manually and have a look at syslog.
If you draw a blank get back to me and I'll have a hunt around.
Cheers Bob
J G Miller
> I hoped it should be recognized by OpenSUSE because the company released
> sourcecode to compile a module for the 2.4.24 and the 2.4.25 kernel.
From the Brainboxes web site
QUOTE
The drivers were written for Linux Red Hat kernels 2.4.24 and 2.4.25 and
should work, or be easily modified to work, in most flavours of Linux.
If modifications are required to provide support for large volume
requirements contact sa...@brainboxes.com for details.
The drivers below are provided 'as is' and are unsupported by Brainboxes.
They were written for Linux Suse 7.1 and should work, or be easily modified
to work, in most flavours of Linux.
UNQUOTE
It would appear that this company only made a token gesture towards
supporting its products under GNU/Linux. So either you revert to
SuSE 7.1 or pay them to provide an updated driver.
You would be better to choose an equivalent product from another company
which is committed to providing functionality under GNU/Linux rather
than just being devoted to Micro$loth Windoze, which is clearly emphasized
in their news section.
QUOTE
Brainboxes, first Serial card Manufacturer to achieve
Windows 7 Signed Drivers
UNQUOTE
J G Miller
> You would be better to choose an equivalent product from another company
> which is committed to providing functionality under GNU/Linux
VSCOM claim that their PCI 128 bit FIFO serial/parallel card is supported
under Linux kernel 2.6
Also, the specifications of the card appear to be much higher than those
of the Brainbox UC-246.
Moe Trin
<ab6be716-d119-48fb...@n35g2000yqm.googlegroups.com>, Teuniz
wrote:
NOTE: Posting from groups.google.com (or some web-forums) dramatically
reduces the chance of your post being seen. Find a real news server.
>Because I need an RS-232 interface with a larger FIFO than the normal
>size of 16 bytes, I bought a Brainbox PCI-card, model UC-246 which has
>a FIFO of 128 bytes
Hmmm... 16650 had a 32 byte buffer, and a 16750 was 64 bytes, and they
acted otherwise like the classic 16550A.
>I hoped it should be recognized by OpenSUSE because the company
>released sourcecode to compile a module for the 2.4.24 and the 2.4.25
>kernel.
Oh, that's ancient. 2.4.24 was released January 5, 2004, and 2.4.25
was released February 18, 2004. The 2.6.x kernels were being released
by then... 2.6.3 was released the same day as 2.4.25. Perhaps the
2.6 kernel never picked up the code as it was after the fork from
2.5.75 in July 2003.
>lspci shows:
>
>04:01.0 Multiport serial controller: Brain Boxes Device 0aa2 (rev 01)
135a Brain Boxes
0a61 UC-324 [VELOCITY RS422/485]
and that's the only entry in the PCI identification list - which
implies no one is using it. http://pciids.sf.net/
Looking at the kernel devices list (from the kernel documentation at
http://www.lanana.org/docs/device-list/ or
ftp://ftp.kernel.org/pub/linux/docs/device-list/), I don't see it
listed either.
>If not, does anybody know where else to look for a solution?
Well, you are posting from a search engine - have you tried looking
there?
>I haven't contact the manufacturer yet.
That might be a solution, but I doubt they are seeing that much Linux
related activity.
>My hope is that somebody dealt with this before and can tell me what
>to do.
Purely a guess, but I suspect that this UART differs significantly
from the classic National Semiconductor specifications, such that the
factory driver is needed to talk to the port. You may well be out of
luck in that case.
Old guy
EHWollmann
> that are non standard.
>
> Do you see a kernel module (lsmod) for the BB card? I dont have the
> kernel source loaded at the moment but if I did I'd try a grep -R in the
> tree for the UART and board names. If you find it just load the module
> manually and have a look at syslog.
>
> If you draw a blank get back to me and I'll have a hunt around.
>
> Cheers Bob
>
> Teuniz wrote:
>> Because I need an RS-232 interface with a larger FIFO than the normal
>> size of 16 bytes, I bought a Brainbox PCI-card, model UC-246 which has
>> a FIFO of 128 bytes
> functionality into a 2.6 kernel a few years ago.
>
> It may be worthwhile having a look at the on board chips to see if they
> are used by another manufacturer. Kernel module source code is often
> sprinkled with reference to chip part numbers. It has a BB16PCI958 UART.
> Also have a look at "setserial". That is how you configure such things
static int setup_serial(*handle, * info, unsigned int iobase, int irq)
Look under initial setup, it's like the following setup but not exact wording.
info->port.fifosize = SAB82532_XMIT_FIFO_SIZE;
So that's where you would need to change your FIFO size, but find the card's source code first.
Bob Bob
>> It may be worthwhile having a look at the on board chips to see if they
>> are used by another manufacturer. Kernel module source code is often
>> sprinkled with reference to chip part numbers. It has a BB16PCI958 UART.
>
>
> I thought this is funny but I tried Bob's suggestion any way, Bob's saying Linux Kernel developers are stupid to control UART from Kernel level rather from serial driver. I searched your Linux kernel src and I don't see any shit there referring to BB16PCI958 UART.
That isnt what Bob is saying. I am glad however there is no egested
material in there, it would be a health hazard to distrubute such
organic soup with source code. Did you know that "VB" is an Australian
beer? Kernel modules are a far easier way to incorporate specialized or
unique hardware. It is true that many types of serial ports are already
contained in the current kernel (incl multiport ones). In fact in 2.6
kernels this seems to be in monololithic mode. Earlier 2.4 kernels had
the serial device as a module but I believe (havent checked) that there
is no reason you couldnt do the same in a 2.6 kernel. Building a module
doesnt (always) require a full kernel rebuild so you save development
time as well.
I havent looked into kernel soruce code for a while but you ceratinly
appear to have found something with your SAB82532_XMIT_FIFO_SIZE
reference. This however seems to be the TX buffer size. The reason for
serial port buffers is however more for RX data to avoid producing too
many interrupts and thus hogging CPU time. This use to be a huge problem
in early Windows installations for anything over a 4800BPS modem and the
8250 UART. Its 2 byte buffer would often overflow whilst Windows was
using CPU time for something else. Use to work okay with DOS and
Desqview but until the 16550 type devices came out the problem wasnt
really solved.
>> Also have a look at "setserial". That is how you configure such things
>
> Wrong Bob, It's called---------> setup_serial()
PS. Pls note that Bob is never wrong.
Have a look at /etc/rc.d/setserial or if you dont like symlinks
/etc/init.d/setserial. You modify this file for port addresses and
interrupts that are not discovered or probed properly during boot. Very
important if you are using an old ISA multiport card, not so problematic
with more modern PCI cards. Also useful on (ISA) "standard" add-on cards
that have to be configured for 3e8 and 2e8. There are also some real
useful (ISA) Fax 2.0 cards that have to be configured that way. (2.0 and
2 are cards that do a lot of preprocessing of fax data so that the main
CPU doesnt have to be synchronously grabbed to do so. A problem with
"Winmodems" and the like on slower PC's)
You can also often specify hardware device information at the module
insert level (insmod or modprobe). Handy whilst experimenting. Single
device modules (being relatively "small" code wise) are also easier to
work through and adapt from one manufacturer to another.
> static int setup_serial(*handle, * info, unsigned int iobase, int irq)
>
> Look under initial setup, it's like the following setup but not exact wording.
>
> info->port.fifosize = SAB82532_XMIT_FIFO_SIZE;
>
> So that's where you would need to change your FIFO size, but find the card's source code first.
Great to talk to you Wally
Cheers Bob
FatBytestard
In an earlier post this lying bastard claimed to be a first time user.
It is clearly evident that all he is is a troll, and a very poor one at
that.
You lose, Hollerman. Go do your pathetic, childish hollering somewhere
else, boy.
Teuniz
Sorry for my late reaction.
I did some investigation and I found some answers which I want to
share.
First, I discovered that some stupid programmer decided that the Linux
kernel should support a maximum of 4 serial ports.
So, when you want to use setserial, and you don't want to hack the
kernel, make sure that you use ttyS0, ttyS1, tttyS2 or ttyS3.
On most pc's, ttyS2 and ttyS3 are available (not used by the onboard
hardware).
Because the card id is not recognised by the kernel, you have to use
setserial.
In order to use setserial you need the know io port address and
interrupt of the card and the uart type.
The first two can be found by the command lspci -v.
On my pc it gives the following output:
04:01.0 Multiport serial controller: Brain Boxes Device 0aa2 (rev 01)
Subsystem: Brain Boxes Device 0403
Flags: medium devsel, IRQ 17
Memory at dfafff80 (32-bit, non-prefetchable) [size=128]
I/O ports at dc80 [size=128]
I/O ports at dc40 [size=64]
I/O ports at dc30 [size=16]
Memory at dfafff40 (32-bit, non-prefetchable) [size=64]
Memory at dfafff30 (32-bit, non-prefetchable) [size=16]
Capabilities: [40] Power Management version 2
Keep in mind that these addresses and interrupt are dynamically chosen
by the PCI-controller in your pc.
Fortunately, they stay the same as long as you don't change the
hardware configuration.
Putting the card into another PCI-slot can change the interrupt and or
address as well!
An employee of Brainboxes told me that I have to select the address of
the second io-port
and that the card will emulate a 16C750 UART with a 64 bytes FIFO.
http://www.brainboxes.com/Resources/j/j/n/BB16PCI958.pdf
So, the resulting setserial command will be (in my case):
setserial /dev/ttyS2 port 0xdc40 irq 17 uart 16750 ^fourport
Now, the card works.
Am I happy? No, I'm not happy because this way, the card will use a
FIFO buffersize of 64 bytes instead of
128 and unfortunately, Linux does not allow me (without hacking the
driver) to change the FIFO
interrupt trigger level like I can do on windows after installing the
windows drivers from Brainboxes.
Linux sets the RX interrupt trigger level at 32 bytes.
/usr/include/linux/serial_reg.h
#define UART_FCR 2 /* Out: FIFO Control Register */
#define UART_FCR_ENABLE_FIFO 0x01 /* Enable the FIFO */
#define UART_FCR7_64BYTE 0x20 /* Go into 64 byte mode (TI16C750) */
#define UART_FCR_R_TRIG_10 0x80
/usr/src/linux-2.6.25.20-0.5/drivers/serial/8250.c
[PORT_16750] = {
.name = "TI16750",
.fifo_size = 64,
.tx_loadsz = 64,
.fcr = UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_10 |
UART_FCR7_64BYTE,
.flags = UART_CAP_FIFO | UART_CAP_SLEEP | UART_CAP_AFE,
},
I know, this is not the fault of Linux, it's the fault of Brainboxes
who should supply a descent driver.
But it doesn't change the situation.
The reason I do need the full 128 byte FIFO and the configurable
interrupt trigger level, is that in my application
the RX FIFO get overrun. The device I connect to the serial port
produces a continuous datastream of 9220 bytes per second.
Port params are 115K2 8N1 no flowcontrol.
With a normal comport (16c550A with a FIFO buffersize of 16 bytes), an
interrupt will occur when there are 14 bytes in the FIFO.
At the time the operatingsystem is ready to call the serial port
driver, more bytes have arrived, overwriting the older bytes in the
FIFO.
On windows and using the Brainboxes card, I was able to get rid of the
RX overruns by adjusting the the RX interrupt trigger level to 15% of
the FIFO buffer size
(19 bytes?). That means that when there are 19 bytes in the FIFO, an
interrupt will be generated. This way, there is still place
for 109 bytes before the FIFO get overrun (128 - 19 = 109). And that
means more time for the operatingsystem when it is very busy
(multitasking, whatever).
I want to make my application platform independant but this way I have
to hack the kernel which I don't like,
apart from the fact that I don not have any experience in
kernelhacking.
Anyway, I'm going to ask Brainboxes if thay can give me the full spec
of the BB16PCI958 chip on their serial card.
Maybe somebody can help me to "fix" Linux' serial driver for this
card...
Best regards,
Teunis van Beelen
Moe Trin
<1cf1fed7-08f4-4b65...@m3g2000yqf.googlegroups.com>, Teuniz
wrote:
NOTE: Posting from groups.google.com (or some web-forums) dramatically
reduces the chance of your post being seen. Find a real news server.
>First, I discovered that some stupid programmer decided that the Linux
>kernel should support a maximum of 4 serial ports.
http://www.lanana.org/docs/device-list/ or
ftp://ftp.kernel.org/pub/linux/docs/device-list/
4 char TTY devices
0 = /dev/tty0 Current virtual console
1 = /dev/tty1 First virtual console
...
63 = /dev/tty63 63rd virtual console
64 = /dev/ttyS0 First UART serial port
...
255 = /dev/ttyS191 192nd UART serial port
[compton ~]$ ls /dev/ttyS*
/dev/ttyS0 /dev/ttyS1 /dev/ttyS2 /dev/ttyS3 /dev/ttyS4 /dev/ttyS5
[compton ~]$
You may have a udev configuration problem, but 192 serial ports should
be available. If your system is NOT using udev, 'man MAKEDEV'. If
your system _is_ using udev, 'apropos udev' (or start at 'man udev').
>An employee of Brainboxes told me that I have to select the address of
>the second io-port
^^^^^^
>and that the card will emulate a 16C750 UART with a 64 bytes FIFO.
OK
>setserial /dev/ttyS2 port 0xdc40 irq 17 uart 16750 ^fourport
^^^^^^^^^^
ttyS2 is the _third_ port. Start from zero, not one.
>Now, the card works.
Good
>The reason I do need the full 128 byte FIFO and the configurable
>interrupt trigger level, is that in my application
>the RX FIFO get overrun. The device I connect to the serial port
>produces a continuous datastream of 9220 bytes per second.
>Port params are 115K2 8N1 no flowcontrol.
The reason the 16650 and 16750 were developed was to handle a higher
port speeds associated with ISDN. The /usr/include/termbits.h file
should allow speeds far above 115200 - look around lines 140-160.
Whether your application is aware/capable of those speeds is another
matter. In most cases, if you specify an incorrect value, the
application/kernel ignore your statement leaving the port set "as it was".
Old guy
Dennis Golden
>>If not, does anybody know where else to look for a solution?
>
> Well, you are posting from a search engine - have you tried looking
> there?
>
>>I haven't contact the manufacturer yet.
>
> That might be a solution, but I doubt they are seeing that much Linux
> related activity.
>
>>My hope is that somebody dealt with this before and can tell me what to
>>do.
>
> Purely a guess, but I suspect that this UART differs significantly from
> the classic National Semiconductor specifications, such that the factory
> driver is needed to talk to the port. You may well be out of luck in
> that case.
Why not use Comtrol RocketPort? These are fully intelligent accelerated
serial solutions. They are supported on the current kernels and they are
reliable.
Regards,
Dennis
--
Dennis Golden
Golden Consulting Services
Change 'invalid' to 'com' to reply by email.
Teuniz
They emulate a 16550 uart which has a 16 bytes deep FIFO.
I need a 128 bytes deep FIFO and a Linux-driver that lets me adjust
the RX interrupt triggerlevel.
Teuniz
I contacted them. They wrote me that it is not possible to configure
the RX interrupt trigger level with their serial cards on Linux.
So far their Linux commitment...
The problem with all those "Linux committed" companies is that they
rely on the standard serial driver of Linux.
As soon as you want to enable the 128 bytes deep FIFO and/or want to
configure the RX/TX interrupt trigger level, you are alone in the
dark.
These things are only possible on windows (after installing their
proprietary windowsdriver ofcourse).
Dennis Golden
Well, yes the emulate a 16550, but I believe that the receive FIFO is at
least 1024. I don't know if you can change the RX interrupt triggerlevel.
Is that a requirement and if so, why?
Teuniz
wrote:
>
> Well, yes the emulate a 16550, but I believe that the receive FIFO is at
> least 1024. I don't know if you can change the RX interrupt triggerlevel.
> Is that a requirement and if so, why?
The reason we do need the full 128 byte FIFO and the configurable
interrupt trigger level, is that in this application
the RX FIFO get overrun. The ADC-box produces a continuous datastream
of 9220 bytes per second.
Port params are 115K2 8N1 no flowcontrol.
With a normal comport (16c550A with a FIFO buffersize of 16 bytes), an
interrupt will occur when there are 14 bytes in the FIFO.
At the time the operatingsystem is ready to call the serial port
driver, more bytes have arrived,
overwriting the older bytes in the FIFO. This is because the
serialdriver needs to service the uart within
0.3 milli-Seconds after an interrupt took place.
On windows and using the Brainboxes card, I was able to get rid of the
RX overruns by adjusting the RX interrupt
trigger level to 15% of the FIFO buffer size (19 bytes?). That means
that when there are 19 bytes in the FIFO,
an interrupt will be generated. This way, there is still place for 109
bytes before the FIFO get overrun
(128 - 19 = 109). And that means more time for the operatingsystem
when it is very busy(multitasking, whatever).
With this setting the serialdriver needs to service the uart within 12
milli-Seconds after an interrupt took place.
On Linux, I had less frequent "sync errors" with the normal onboard
serial port (/dev/ttyS0) than with the
UC-246 serial PCI-card. Probably because the onboard serial port has
it's own exclusive hardware interrupt line.
A PCI device shares it's interrupt with other devices. In my case,
when using the standard onboard serial port on Linux,
I got sync errors only when I inserted an USB-stick into to the pc...
On windows, on the other hand, it was impossible to use this
application with the standard onboard serial port.
http://www.teuniz.net/12-ch_ADC-board/
Next project I will use the USB-port using the FTDI UM245R USB-
Parallel FIFO Development Module.
I already did some tests with it and it works flawlessly on Linux
without the need to install any drivers. It's plug and play.
I was stupid not use it for this project as wel...
Dennis Golden
> On 3 dec, 01:51, Dennis Golden <dgol...@golden-consulting.invalid>
> wrote:
>>
>> Well, yes the emulate a 16550, but I believe that the receive FIFO is
>> at least 1024. I don't know if you can change the RX interrupt
>> triggerlevel. Is that a requirement and if so, why?
>
> The reason we do need the full 128 byte FIFO and the configurable
> interrupt trigger level, is that in this application the RX FIFO get
> overrun. The ADC-box produces a continuous datastream of 9220 bytes per
> second.
> Port params are 115K2 8N1 no flowcontrol.
>
Well all I can say is that I have never over-run the RocketPort cards,
even when running the ISA version. The obsolete PCI version that I now
run will support up to 460 Kbps with a 1024 FIFO. This does not USE 16550
serial ports. It uses ASIC processors running at 36 MHz for each 8 ports.
You might want to look at this obsolete card specifications at:
http://www.comtrol.com/products/family/rp_pci
There are still some new ones available on EBAY now and the for about
$100 US.
Just my 2 cents.
Dennis
PS, I don't work for Comtrol. I've just had good luck using them. YMMV