Hi Tony / Linux-serial mailing list-
I tested this on windows with the proper jumper settings per your PNG
graphic and it still works fine on windows.
I spent all day today having the standard 2.4 linux kernel driver detect
this as ST16654 UARTS (it's register compatible) but I cannot for the
life of me get it to transmit anything out the pins like windows does!
Here's the outputs from my changes (2.4.29 kernel -- old but has worked
fine and we haven't migrated to 2.6 on all of our projects yet):
Serial driver version 5.05c (2001-07-08) with MANY_PORTS MULTIPORT
SHARE_IRQ SERIAL_PCI enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
Setup PCI/PNP port: port 1400, irq 9, type 0, port_high: 0
ttyS04 at port 0x1400 (irq = 9) is a ST16654
Setup PCI/PNP port: port 1408, irq 9, type 0, port_high: 0
ttyS05 at port 0x1408 (irq = 9) is a ST16654
Upon opening a port:
ST16C1050: Enable PCI IRQs
ST16C1050 @ I/O 0x1400
ST16C1050 Num Ports: 2, Dev Info Reg: 0x13
ST16C1050 Interface Info Reg0: 0x18, IRQ Mask Req: 0x03
ST16C1050 Intrrupt Poll Reg: 0xff
ST16C1050: Enable PCI IRQs
ST16C1050 @ I/O 0x1408
ST16C1050 Num Ports: 2, Dev Info Reg: 0x13
ST16C1050 Interface Info Reg0: 0x18, IRQ Mask Req: 0x03
ST16C1050 Intrrupt Poll Reg: 0xff
When application transmits data:
serinfo:1.0 driver:5.05c revision:2001-07-08
0: uart:16550A port:3F8 irq:4 baud:115200 tx:12083 rx:206 RTS|CTS|DTR|DSR|CD
1: uart:16550A port:2F8 irq:3 tx:0 rx:0 CTS|DSR|CD
4: uart:ST16654 port:1400 irq:9 baud:9600 tx:126 rx:0 RTS|CTS|DTR|DSR|CD|RI
5: uart:ST16654 port:1408 irq:9 baud:9600 tx:126 rx:0 RTS|CTS|DTR|DSR|CD|RI
No bytes on the scope, none received. Same hardware setup works fine on
windows.
Same application code works fine on a different board that has genuine
Oxford Semi 16C950/954 UARTs.
I noticed in the 2.4 and 2.6 drivers from sysbas that they do a few
things with the Option I/O registers.
In particular:
Enable PCI IRQs by writing 0xFF to IMR (interrupt mask register in the
Option I/O regs that live at 0x1440 (32 bytes long)). I do this on
initialization and it does make the card have IRQs happen on IRQ9 and
data gets written to the UART (show in /proc/tty/driver/serial).
Without this particular mod, I was not getting any IRQs, so I think a
timer they use for timing out was showing the tx count incrementing very
late and IRQ count of zero in /proc/interrupts. So I know this is for
certain needed just to get IRQs with this -- I don't know why they don't
just rely on the standard IER register...
In the IRQ handlers rs_interrupt (used when both ports are open) and
rs_interrupt_single (which is used when only 1 port is open), I have it
write a 0x00 to the IMR (Int mask reg) in the option registers at 0x1440
at start of IRQ handler and write a 0xFF to the IMR at end of IRQ
handler. I was thinking the chip needs this global IMR disabled and
re-enabled to "ack" the interrupt even though it's normally done when
reading the standard data register for instance to clear the data
received IRQ (or maybe it's the reading of the LSR that would actually
clear the interrupt, I'm not sure). Either way, I'm surprised this chip
seems to require disabling the global interrupt mask register and
re-enabling when the equivalent reads of registers from the standard
16550 register set should work...
It's very disappointing that this UART chip doesn't seem to be just
16550A compatible in the true sense.
Maybe since the kernel thinks it has the STARTECH features (which it
does!) it puts it into a bad state where it won't really transmit
anything. I'm very skeptical of that.
I'm getting to the point where I may have to table this. Do you have
any info from the manufacturer sysbas as to what on earth needs to be
twiddled with this thing to get it to simply transmit chars. There must
be some voodoo going on in the windows driver they never did in the
linux drivers. Any further info would be appreciated. It really looks
like it thinks it's transmitting, but nothing coming out... it's got to
be something simple I would think -- I've exhausted every possiblity I
would come up with the datasheet and in looking at the sysbas version of
their modified 2.4 and 2.6 drivers.
I'm copying the linux kernel mailing list (using my home e-mail address)
to see if any ideas are fourthcoming from the kernel developers.
-Eric Malkowski
tony@xxxxxxxxxxxxxx wrote:
Hi,Eric,
Here is the some information for setting .
I still waiting more information.
Regards,
Tony
----- Original Message -----
From:
"Eric Malkowski" <EMalkowski@xxxxxxxxxxxxxxx>
To:
"Eric Malkowski" <EMalkowski@xxxxxxxxxxxxxxx>, "Tony Pridopia"
<tony@xxxxxxxxxxxxxx>
Cc:
Sent:
Wed, 1 Dec 2010 21:59:15 -0500
Subject:
RE: Mi-PCI-03 issues
Tony-
The card I brought home works fine on a windows laptop with the
windows driver.
This is good news as at least we know the hardware is good.
I tried typing chars between two hyperterminal windows on ports 1
and 2 with them jumpered for RS-422 on the overall board
RS422/RS485 jumper selection (same as factory default) and I set
the jumpers for PORT_1_RT and PORT_2_RT for "RS422" (all makes
logical sense).
With the ports wired loopback pins like this:
1 <-> 3
2 <-> 4
3 <-> 1
4 <-> 2
I'm able to do my typing tests at both 9600 bps and 460800 bps
(our target speed)
Tomorrow I'll make sure the board can talk at 460800 to our
embedded hardware and then we'll know the hardware should be fine.
The concern is using this with linux.
I'm hoping the manufacturer (your guys in Taiwan or the people
from sysbas who make the UART chip) has any pointers to better
linux drivers. Or -- is it possible they could send me a snippet
of the sourcecode for the windows driver that actually initializes
the chip -- I'm guessing there may be some things that need to be
done in the option register to get the chip to transmit and
generate interrupts properly. Again I'm surprise the standard
linux serial driver won't work.
In the meantime I've downloaded the datasheet from sysbas for the
SB16C1052 PCI chip.
I may try to make the necessary mods to make it work with the
standard linux serial driver -- that would really be the best
situation as the main serial driver is at least maintained by the
linux kernel folks... I'm also going to send an e-mail to the
linux-serial@xxxxxxxxxxxxxxx <mailto:linux-serial@xxxxxxxxxxxxxx>
mailing list to see if anyone on there has made a sysbas UART work
with linux at all or any other tips they could offer.
Thanks for looking into this. I'll hold on to the hardware for
now and keep working at this as I'm confident it should work...
it may take me a while, but I can't imagine there are that many
extra things that need to be done beyond a standard UART to use
this thing!
-Eric Malkowski
-----Original Message-----
From: Eric Malkowski
Sent: Wed 12/1/2010 6:24 PM
To: Tony Pridopia; Eric Malkowski
Subject: Re: Mi-PCI-03 issues
Yes -- I'm going to try the card in a windows laptop tonight at
home. I
don't really have a windows setup I can try it in at work.
I'll try to send come characters from one port to the other with a
RS422
Null type setup and a couple of hyperterminal windows or something.
It would certainly be good to at least know I have good hardware to
start with!!!!
I have some more test information on the linux side -- with a scope,
there is simply no data coming out of any pins 1-4 on the DB-9 cable.
We're using 2 channels on a scope to look for the differential voltage
between Tx+ and Tx- pins 1 & 2. We checked pins 3 & 4 just in
case the
manual was wrong.
The only activity we can get out of this is to put the board into
RS-485
mode (both jumper blocks -- the 3 x jumper pins for each port set to
"485" per the manual for PORT1_RT and PORT2_RT and then the 4 x jumper
pins we place those two jumpers on the middle two which say RS485
on the
board). If we run a small application program that sends
characters at
9600 bps, we get nothing. Then we kill the application and run it
again, and on the 2nd run we get a single trigger on the scope
where it
drives the line the opposite of idle (like one single bit!) and then
shortly it goes back to idle. It's almost like it tries to take the
RS485 bus and then not transmit anything.
Anyway -- this is not very useful as we want to do RS-422 Point to
Point
no echo mode (4 wire full duplex), but we were trying in
desperation to
get ANYTHING to come out on the pins
So I built up the 2.6 kernel driver with my 2.6 setup which is
designed
for somewhere around kernel 2.6.19 but I'm running 2.6.28.4 so I
had to
port some of the data structure changes.
The 2.6 kernel driver actually identifies both ports as RS-422
Point to
Point with no echo -- clearly the 2.4 driver doesn't identify the
board
right. Makes wonder what else is wrong.
But -- when I tried to transmit, the kernel was crashing -- I found
there were some locking primitives that were removed in the newer 2.6
kernel, so I remove the equivalent ones in their driver and it doesn't
seem to work right. Perhaps my porting efforts aren't quite right
-- it
doesn't even think it's transmitting characters (the counters in
/proc/tty/driver/multiport don't increase). So I wasn't able to have
any further success with the 2.6 driver other than seeing it seem to
identify the ports correctly when jumpered for RS422PTP no echo -- I
don't really have time to try and debug why that driver won't even
think
characters are transmitted.
I'm willing to use a functioning 2.4 driver for this that is
systembase's custom driver, but it would be even better if the
standard
serial driver could work with this board.
The registers are 16550 compatible at the PCI address space (there
are 2
banks of 8 registers for the 2 ports that are standard 16550 set of 8
registers (Tx/Rx, LCR, MCR, FCR etc. etc.). I'm surprised they went
through the trouble of re-inventing the linux serial driver when the
standard driver should work! I'd be curious to hear if they have any
idea if the board can work with the standard serial driver -- I
originally made some quick mods to get the standard driver to
detect the
UARTs as 16650 STARTECH style UARTs, but when trying to transmit data,
no interrupts would occur indicating perhaps one can only use their
proprietary global interrupt register to deal with IRQs from the
board... this is disappointing.
Anyway -- I'll let you know the results of trying this on windows.
If they don't work on windows, I'll need to send the boards back
so you
or your folks in Taiwan can test them!
Lastly -- if systembase has and "newer" more current linux drivers
that
are tested and verified to work with your hardware, I would like
to get
my hands on those.
I'm not convinced these linux drivers have ever worked properly with
your hardware!
Thanks -- I'm trying really hard here to make this work and would
really
like to use your boards over the other ones I've found, but again it's
not looking very good!
-Eric Malkowski
Tony Pridopia wrote:
> Sorry about your problem, we pass all your problem to
manufacture, I am waiting their response. Sorry for the late..
>
> Can you find one laptop with mini pci slot, and test this card
in windows first, make sure no problem first.
>
> Regards,
> Tony
>
> Sent from my iPhone
>
> On 30 Nov 2010, at 22:31, Eric Malkowski
<emalkowski@xxxxxxxxxxxxxxx <mailto:emalkowski@xxxxxxxxxxxxxxx>>
wrote:
>
>
>> Hi Tony-
>>
>> I received the 2 Mi-PCI-03 serial boards.
>> I set the PORT1_RT and PORT2_RT jumpers for "422" as I want
RS-422 full duplex (4 wire mode), I do NOT want RS485 multidrop 2
wired mode as shown in the manual.
>> I left the jumpers that select RS422 or RS485 mode (not
documented in the manual!) set for RS422 as they are from the
factory (this is a row of 8 pins where the "outer most" two are
populated with jumpers).
>>
>> By the way -- what does this thing do if the PORT1_RT and
PORT2_RT are set to the "NONE" position? As you can see below I
tried that position in desperation.
>>
>> I built the 2.4 linux kernel driver for my 2.4.29 target kernel.
>> When the driver loads, the first part that seems wrong is the
following:
>>
>> ==============================================
>> MultiPorts/PCI Board Installation version: 3.0
revision: 2009-06-22
>> email : <tech@xxxxxx <mailto:tech@xxxxxx>>
==============================================
>> 2 board(s) installed. 4 ports availabe.
>> Board No.0 Multi-2 PCI (rev b0) ttyMP0 ~ ttyMP1 using IRQ9
>> 1 port --- RS422 and Point to Point mode
>> 2 port --- RS232
>> Board No.1 Multi-2 PCI (rev b0) ttyMP2 ~ ttyMP3 using IRQ11
>> 1 port --- RS422 and Point to Point mode
>> 2 port --- RS232
>>
>> It's claiming the second port on each board is setup for RS-232
mode -- not sure why -- that is really wrong.
>> I'm using your cables that came with the boards and made an
RS-422 null modem by wiring the DB-9 pins with a simple loopback
setup as follows:
>>
>> Pin 1 TxD+ to Pin 3 RxD+
>> Pin 2 TxD- to Pin 4 RxD-
>> Pin 3 RxD+ to Pin 1 TxD+
>> Pin 4 RxD- to Pin 2 TxD-
>>
>> The driver reports the application trying to send data, but no
matter what no data is received (and I'm not sure if it's actually
transmitting as I haven't put a scope on there yet, I won't get to
that until tomorrow).
>> The Driver shows the following:
>>
>> / # cat /proc/tty/driver/multiports
>> *** MultiPorts Information :1.1 driver:3.0 revision:2009-06-22
>> 0: Multi-2 PCI(rev b0) uart:SB16C1050 port:1400 irq:9
osc:14.7456Mhz baud:9600 tx:56 rx:0 RTS|CTS|DTR|DSR|CD|RI
>> 1: Multi-2 PCI(rev b0) uart:SB16C1050 port:1408 irq:9
osc:14.7456Mhz tx:0 rx:0 RTS|CTS|DTR|DSR|CD|RI
>> 2: Multi-2 PCI(rev b0) uart:SB16C1050 port:1480 irq:11
osc:14.7456Mhz baud:9600 tx:56 rx:0 RTS|CTS|DTR|DSR|CD|RI
>> 3: Multi-2 PCI(rev b0) uart:SB16C1050 port:1488 irq:11
osc:14.7456Mhz tx:0 rx:0 CTS|DSR|CD|RI
>>
>> I have been trying port 1 on the first board (line #0 from
above) to port 1 on the second board (line #2 from above) since
the driver reports the first port on each board as RS422 point to
point mode.
>> I also tried having just ports 1 and 2 on the first board talk
w/o the second board installed
>> I tried configuring for 485 mode and all permutations of the
jumpers in case they weren't documented right -- still no luck --
it thinks it's transmitting (the 56 bytes from above) but nothing
comes in
>>
>> I also tried having my application do the proprietary ioctl(fd,
TIOCSPTPNOECHO, NULL) after opening the port thinking that maybe
the systembase chip needs to be told to do RS422 point to point w/
no echo in software -- the ioctl call is accepted, but still
cannot get data to be received.
>>
>> Have you had anyone successfully use this board in RS-422 point
to point (4 wire) mode with the 2.4 linux kernel driver as
delivered on the CD from systembase?
>>
>> Tomorrow I may try to build up the 2.6 kernel module against a
different setup of our software (we have a 2.6 kernel setup for
another project, but I really need this board for the 2.4 project)
just to see if that driver is plagued with the same problems. If
that one works, then I will certainly compare how the UARTs are
being handled in the 2.6 stuff versus 2.4 -- perhaps systembase's
2.4 driver is flawed -- just by the output above from inserting
the kernel module where it things the 2nd port is RS232 is a
pretty good indication this thing has serious problems!
>>
>> I'll also get an oscilloscope on there to see if anything is
coming off the pins. It's not looking very good...
>>
>> As a last resort I'll put one of the boards in a windoze laptop
and try the windoze driver to see if I can get ports 1 and 2 to
talk to each other. This will at least be a baseline that the
hardware actually works.
>> I'm not really convinced these boards work unfortunately.
>>
>> Is there anyone from systembase you can put me in touch with to
try and get this to work???
>> Any other info would be greatly appreciated... I've been very
thorough about this -- I'm losing confidence quickly
unfortunately. I've made many many serial boards work on linux
(PCI, ISA, USB, etc. etc.) and never had such difficultly was this
one is presenting.
>>
>> I'll get back to you tomorrow, but I'm hoping you might have
some info by the time the first half of your day over in the UK is
over.
>> I'm really hoping I can get this to work -- my only other
option is a board that has only 16550 UARTs which may not work
very well at 460800 bps.
>>
>> --
>> Eric Malkowski
>> MagneMotion, Inc.
>>
>>
------------------------------------------------------------------------
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
