MOXA multiserial card C-104UL V2

QNX Newsgroups (Archives) qnx.rtos
1

Hello, has anybody experience with MOXA multiserial cards ?
I want use PCI card MOXA C-104UL V2 with 4 serial ports.
But with this card in PC , qnx630 stop boot process.
When a disable devc-ser8250 in /etc/system/enum/devices/char
qnx630 start.

Thanks
David

#pci -v

Class = Communication (Serial Controller)
Vendor ID = 1393h, Moxa Technologies Co Ltd
Device ID = 1041h, Unknown Unknown
PCI index = 0h
Class Codes = 070002h
Revision ID = 0h
Bus number = 2
Device number = 2
Function num = 0
Status Reg = 200h
Command Reg = 1h
Header type = 0h Single-function
BIST = 0h Build-in-self-test not supported
Latency Timer = 20h
Cache Line Size= 8h un-cacheable
PCI IO Address = c800h length 32 enabled
PCI IO Address = c400h length 64 enabled
PCI IO Address = c000h length 16 enabled
Subsystem Vendor ID = 1393h
Subsystem ID = 1041h
Max Lat = 0ns
Min Gnt = 0ns
PCI Int Pin = INT A
Interrupt line = 10
CPU Interrupt = ah

2

Try to start devc-ser8250 manually, with address c400, irq 10.

Pavol Kycina

“David Brdièka” <dbrdicka@retia.cz> wrote in message
news:d7pqmj$cv3$1@inn.qnx.com…

Hello, has anybody experience with MOXA multiserial cards ?
I want use PCI card MOXA C-104UL V2 with 4 serial ports.
But with this card in PC , qnx630 stop boot process.
When a disable devc-ser8250 in /etc/system/enum/devices/char
qnx630 start.

Thanks
David

#pci -v

Class = Communication (Serial Controller)
Vendor ID = 1393h, Moxa Technologies Co Ltd
Device ID = 1041h, Unknown Unknown
PCI index = 0h
Class Codes = 070002h
Revision ID = 0h
Bus number = 2
Device number = 2
Function num = 0
Status Reg = 200h
Command Reg = 1h
Header type = 0h Single-function
BIST = 0h Build-in-self-test not supported
Latency Timer = 20h
Cache Line Size= 8h un-cacheable
PCI IO Address = c800h length 32 enabled
PCI IO Address = c400h length 64 enabled
PCI IO Address = c000h length 16 enabled
Subsystem Vendor ID = 1393h
Subsystem ID = 1041h
Max Lat = 0ns
Min Gnt = 0ns
PCI Int Pin = INT A
Interrupt line = 10
CPU Interrupt = ah

3

Thanks,

but when I use this line in /etc/system/enum/devices/char (see. char.dat)
driver(devc-ser8250 “-u1 3f8,4 -u2 2f8,3 -u3 c400,10 -u4 c408,10 -u5
c410,10 -u6 c418,10”)
devc-ser8250 start but there are three devc-ser8250 ???

#pidin arg
…
94224 devc-ser8250 -u1 3f8,4 -u2 2f8,3 -u3 c400,10 -u4 c408,10 -u5
c410,10 -u6 c418,10
94225 devc-ser8250 -u1 3f8,4 -u2 2f8,3 -u3 c400,10 -u4 c408,10 -u5
c410,10 -u6 c418,10
94226 devc-ser8250 -u1 3f8,4 -u2 2f8,3 -u3 c400,10 -u4 c408,10 -u5
c410,10 -u6 c418,10
…

There are some errors in communication.
(I use #cat /dev/serX , and echo"1234567890" >/dev/serY)

When I slay them and run:
devc-ser8250 -u1 3f8,4 -u2 2f8,3 -u3 c400,10 -u4 c408,10 -u5 c410,10 -u6
c418,10
from command line it looks better , but there are still some wrong in
communication
between ser1,2 (on board) and ser3,4,5,6 (ports on MOXA card).???
Port setting is equivalent.

Please how must look devc-ser8250 section in /etc/system/enum/devices/char
???
Thanks
David


begin 666 char.dat
M(PHC($1E9FEN:71I;VYS(&9O<B!C:&%R86-T97(@9&5V:6-E<PHC"F1E=FEC
M92AP8VDL(“YC;&%S<STD*%!#25]#3$%34U]#3TU-2P@+G-U8F-L87-S/20H
M4$-)7T-/34U?4T5224%,2P@+G!R;V=I9CTP,BD9&5V:6-E’!N<&)I;W,L
M(“YT>7!E/20H4$Y00DE/4U]465!%7T-/34TI+” N<W5B='EP93TD*%!.4$))
M3U-?0T]-35]315))04PI0ID979I8V4H:7-A+" N='EP93TD$E305]465!%
M7T-/34TI+” N<W5B=‘EP93TD*$E305]#3TU-7U-%4DE!3"DL("YP<F]G:68]
M,# I"F1E=FEC92AP8VUC:6$L(“YT>7!E/20H4$-#05)$7U194$5?0T]-32DL
M(“YS=6)T>7!E/20H4$-#05)$7T-/34U?4T5224%,2P@+G!R;V=I9CTD%!#
M0T%21%]#3TU-7U-%4DE!3%])1BDI”@H@(&1R:79E<BAD979C+7-E<C@R-3 @
M(BUU,2 S9C@L-” M=3(@,F8X+#,@+74S(&,T,# L,3 @+74T(&,T,#@L,3 @
M+74U(&,T,3 L,3 @+74V(&,T,3@L,3 B0H)87!P96YD&QE9V%C>2P@(BQC
M:&MS97(L)"MI;W!O<G0])"AI;W!O<G0IS<L:7)Q/20H:7)Q20M(BD*“75N
M:7$H<V5R;G5M+”!D979C+7-E<BP@,2D*(R!D<FEV97(H9&5V8RUS97(X,C4P
M(“0H4T527T]05$E/3E,I+” B+74D*’-E<FYU;2D@)“AI;W!O<G0I+“0H:7)Q
M2(I"@EW86ET9F]R”]D978O<V5R)“AS97)N=6TI0H)96YU;65R871O<BAS
M97(@+V1E=B]S97(D’-E<FYU;2DI”@ID979I8V4H<&-M8VEA+”!V96X],#$V
M8RP@9&5V/3 P,#8I"@EA<’!E;F0H;&5G86-Y+" B+&-H:W-E<BPDVEO<&]R
M=#TD&EO<&]R="DK-RQI<G$])"AI<G$I)“TB0H)=6YI<2AS97)N=6TL(&1E
M=F,M<V5R+" Q0HC(”!D<FEV97(H9&5V8RUS97(X,C4P(“0H4T527T]05$E/
M3E,I+” B+74D*’-E<FYU;2D@)"AI;W!O<G0I+“0H:7)Q2(I"@EW86ET9F]R
M”]D978O<V5R)“AS97)N=6TI0H)96YU;65R871O<BAS97(@+V1E=B]S97(D
M’-E<FYU;2DI”@ID979I8V4H<&YP8FEO<RP@+G1Y<&4])"A03E!"24]37U19
M4$5?0T]-32DL(“YS=6)T>7!E/20H4$Y00DE/4U]#3TU-7U!!4D%,3$5,2D
M9&5V:6-E*&ES82P@+G1Y<&4])“A)4T%?5%E015]#3TU-2P@+G-U8G1Y<&4]
M)"A)4T%?0T]-35]005)!3$Q%3"DL(“YP<F]G:68],# I”@ET86<H<’)I;G1E
M<BD"6%P<&5N9"AL96=A8WDL(”(L;F]P87(B0H)=6YI<2AP87)N=6TL(&1E
M=F,M<&%R+" Q0H)9’)I=F5R*&1E=F,M<&%R(“0H4$%27T]05$E/3E,I(“UP
M,’@D*&EO<&]R=“DL0H)=V%I=&9O<B@O9&5V+W!A<B0H<&%R;G5M2D*“65N
M=6UE<F%T;W(H<&%R(”]D978O<&%R)“AP87)N=6TI0H)=7-E’-Y;6)O;&EC
M/7-P;V]L97(@<&%T:#TO9&5V+W!A<B0H<&%R;G5M2D"F1E=FEC92AP;G!B
M:6]S+” N=‘EP93TD*%!.4$))3U-?5%E015])3E!55"DL(“YS=6)T>7!E/20H
M4$Y00DE/4U])3E!55%]+15E"3T%21"DI”@EA<’!E;F0H;&5G86-Y+” B+&YO
M:V(B0H)=&%G&-O;G-O;&4I”@ER97%U:7)E<RAD979C+6-O;BPD*$-/3E-/
M3$5?3U!424].4RDI”@HC"4AA;F1L92!A;GD@8VAA<B!T>7!E(&1E=FEC92!T
M:&%T(&1O97-N)W0@;6%T8V@N+BX9&5V:6-E’!N<&)I;W,L(“YT>7!E/20H
M4$Y00DE/4U]465!%7T-/34TI0ID979I8V4H<&YP8FEO<RP@+G1Y<&4])"A0
M3E!"24]37U194$5?24Y0550I0H)96-H;RAC:&%R(&)U<SUP;G!B:6]S(&1E
M=FED/20H9&5V:60I(‘1Y<&4])"AT>7!E2!S=6)C;&%S<STD’-U8G1Y<&4I
M(’!R;V=I9CTD*’!R;V=I9BDL(”]E=&,O<WES=&5M+W1R87 O=6YK;F]W;BD*
M9&5V:6-E*’!C:2P@+F-L87-S/20H4$-)7T-,05-37T-/34TI0ID979I8V4H
M<&-I+" N8VQA<W,])"A00TE?0TQ!4U-?24Y0550I0H)96-H;RAC:&%R(&)U
M<SUP8VD@=F5N/20H=F5N2!D978])"AD978I(&-L87-S/20H8VQA<W,I(’-U
M8F-L87-S/20H<W5B8VQA<W,I(’!R;V=I9CTD’!R;V=I9BD@<W5B=F5N/20H
M<W5B=F5N*2!S=6)S>7,])“AS=6)S>7,I+” O971C+W-Y<W1E;2]T<F%P+W5N
':VYO=VXI”@``
`
end

4

In article <d81dfh$s28$1@inn.qnx.com>, dbrdicka@retia.cz says…

Thanks,

but when I use this line in /etc/system/enum/devices/char (see. char.dat)
driver(devc-ser8250 “-u1 3f8,4 -u2 2f8,3 -u3 c400,10 -u4 c408,10 -u5
c410,10 -u6 c418,10”)
devc-ser8250 start but there are three devc-ser8250 ???

#pidin arg
…
94224 devc-ser8250 -u1 3f8,4 -u2 2f8,3 -u3 c400,10 -u4 c408,10 -u5
c410,10 -u6 c418,10
94225 devc-ser8250 -u1 3f8,4 -u2 2f8,3 -u3 c400,10 -u4 c408,10 -u5
c410,10 -u6 c418,10
94226 devc-ser8250 -u1 3f8,4 -u2 2f8,3 -u3 c400,10 -u4 c408,10 -u5
c410,10 -u6 c418,10
…

There are some errors in communication.
(I use #cat /dev/serX , and echo"1234567890" >/dev/serY)

When I slay them and run:
devc-ser8250 -u1 3f8,4 -u2 2f8,3 -u3 c400,10 -u4 c408,10 -u5 c410,10 -u6
c418,10
from command line it looks better , but there are still some wrong in
communication
between ser1,2 (on board) and ser3,4,5,6 (ports on MOXA card).???
Port setting is equivalent.

Please how must look devc-ser8250 section in /etc/system/enum/devices/char
???

You may write this file and put it in /etc/system/enum/oem directory
(and return back the file you altered)

/etc/system/enum/oem/moxa={

Definitions for Moxa card (Ugly, for particular system

and particular PCI slot)

MOXA C-104UL V2 with 4 serial ports

This file should be placed in /etc/system/enum/oem directory

and it is used by QNX enumerator during system start up.

(see documentation for enum-devices in QNX Utilities Reference)

device(pci, ven=1393, dev=1041)
uniq(s0, devc-ser, 1)
uniq(s1, devc-ser, 1)
uniq(s2, devc-ser, 1)
uniq(s3, devc-ser, 1)
driver(devc-ser8250 “-u$(s0) c400,10 -u$(s1) c408,10 -u$(s2)
c410,10 -u$(s3) c418,10”)
waitfor(/dev/ser$(s0))
waitfor(/dev/ser$(s1))
waitfor(/dev/ser$(s2))
waitfor(/dev/ser$(s3))
enumerator(ser /dev/ser$(s0))
enumerator(ser /dev/ser$(s1))
enumerator(ser /dev/ser$(s2))
enumerator(ser /dev/ser$(s3))
#############################################
}

Note: backslash means it is a long single line without backslash.

And here is my question - how to evaluate address knowing offset in
enumerator config file? Like:

driver(devc-ser8250 “-u$(s0) $(ioport1),$(irq) -u$(s1) $(ioport1)+8,
$(irq) -u$(s2) $(ioport1)+16,$(irq) -u$(s3) $(ioport1)+24,$(irq)”)

I guess it won’t work.

Eduard.

Thanks
David

5

“David Brdièka” <dbrdicka@retia.cz> wrote in message
news:d81dfh$s28$1@inn.qnx.com…

Thanks,

but when I use this line in /etc/system/enum/devices/char (see. char.dat)
driver(devc-ser8250 “-u1 3f8,4 -u2 2f8,3 -u3 c400,10 -u4 c408,10 -u5
c410,10 -u6 c418,10”)
devc-ser8250 start but there are three devc-ser8250 ???

#pidin arg
…
94224 devc-ser8250 -u1 3f8,4 -u2 2f8,3 -u3 c400,10 -u4 c408,10 -u5
c410,10 -u6 c418,10
94225 devc-ser8250 -u1 3f8,4 -u2 2f8,3 -u3 c400,10 -u4 c408,10 -u5
c410,10 -u6 c418,10
94226 devc-ser8250 -u1 3f8,4 -u2 2f8,3 -u3 c400,10 -u4 c408,10 -u5
c410,10 -u6 c418,10
…

There are some errors in communication.
(I use #cat /dev/serX , and echo"1234567890" >/dev/serY)

When I slay them and run:
devc-ser8250 -u1 3f8,4 -u2 2f8,3 -u3 c400,10 -u4 c408,10 -u5 c410,10 -u6
c418,10
from command line it looks better , but there are still some wrong in
communication
between ser1,2 (on board) and ser3,4,5,6 (ports on MOXA card).???
Port setting is equivalent.

Probably MOXA is 8 times faster than normal serial ports (to be able to go
faster than 115200). Try to set line speed of 9600 on normal ports and 1200
on MOXA ports…

Please how must look devc-ser8250 section in /etc/system/enum/devices/char
???
Thanks
David

6

Run “pci” command under QNX to get PCI information of the MOXA PCI card.
pci - v > pci.inf

Search the MOXA PCI card information with vender ID 1393h in “pci.inf”,
then get the I/O address and IRQ :
Class = Communication (Serial Controller)
Vendor ID = 1393h, Moxa Technologies Co Ltd
Device ID = 1680h, Unknown Unknown
PCI index = 0h
Class Codes = 070080h
Revision ID = 2h
Bus number = 0
Device number = 9
Function num = 0
Status Reg = 280h
Command Reg = 3h
Header type = 0h Single-function
BIST = 0h Build-in-self-test not supported
Latency Timer = 0h
Cache Line Size= 8h un-cacheable
PCI IO Address = d800h length 128 enabled
PCI IO Address = d400h length 64 enabled <------------- I/O base
address
PCI IO Address = d000h length 16 enabled
Max Lat = 0ns
Min Gnt = 0ns
PCI Int Pin = INT A
Interrupt line = 10
<---- IRQ
3. Run command under QNX to load driver (I/O is d400, d408 … and IRQ is 10
in this case) :
devc-ser8250 -u3 d400,10 -u4 d408,10 -u5 d410,10 -u6 d418,10 -u7 d420,10
-u8 d428,10 -u9 d430,10 -u10 d438,10
4. The C168H/PCI will be installed on /dev/ser3 ~ /dev/ser10.
5. End.

Note : If you use MOXA H series ISA card with High speed mode (C104H,
C168H …) or MOXA PCI card, the real working baud rate is exactly 8 times
of the setting speed. That is, if you set 1200 bps, the real working baud
rate is 9600 bps.

7

Thanks, it works.
Now qnx starts with two devc-ser8250.
94224 devc-ser8250 -u1 3f8,4 -u2 2f8,3
94227 devc-ser8250 -u3 c400,10 -u4 c408,10 -u5 c410,10 -u6 c418,10

Only in this line is problem:

driver(devc-ser8250 “-u$(s0) $(ioport1),$(irq) -u$(s1) $(ioport1)+8,
$(irq) -u$(s2) $(ioport1)+16,$(irq) -u$(s3) $(ioport1)+24,$(irq)”)

adresses are c400, c400+8 , c400+16 , c400+24

David


“ed1k” <ed1k@fake.address> pí¹e v diskusním pøíspìvku
news:MPG.1d0ec3d38743534f9896c3@inn.qnx.com…

In article <d81dfh$s28$> 1@inn.qnx.com> >, > dbrdicka@retia.cz > says…

You may write this file and put it in /etc/system/enum/oem directory
(and return back the file you altered)

/etc/system/enum/oem/moxa={

Definitions for Moxa card (Ugly, for particular system

and particular PCI slot)

MOXA C-104UL V2 with 4 serial ports

This file should be placed in /etc/system/enum/oem directory

and it is used by QNX enumerator during system start up.

(see documentation for enum-devices in QNX Utilities Reference)

device(pci, ven=1393, dev=1041)
uniq(s0, devc-ser, 1)
uniq(s1, devc-ser, 1)
uniq(s2, devc-ser, 1)
uniq(s3, devc-ser, 1)
driver(devc-ser8250 “-u$(s0) c400,10 -u$(s1) c408,10 -u$(s2)
c410,10 -u$(s3) c418,10”)
waitfor(/dev/ser$(s0))
waitfor(/dev/ser$(s1))
waitfor(/dev/ser$(s2))
waitfor(/dev/ser$(s3))
enumerator(ser /dev/ser$(s0))
enumerator(ser /dev/ser$(s1))
enumerator(ser /dev/ser$(s2))
enumerator(ser /dev/ser$(s3))
#############################################
}

Note: backslash means it is a long single line without backslash.

And here is my question - how to evaluate address knowing offset in
enumerator config file? Like:

driver(devc-ser8250 “-u$(s0) $(ioport1),$(irq) -u$(s1) $(ioport1)+8,
$(irq) -u$(s2) $(ioport1)+16,$(irq) -u$(s3) $(ioport1)+24,$(irq)”)

I guess it won’t work.

Eduard.

8

We have been successful in getting the C-104 and the C-168 serial
controllers up and running. I received the following patch from the Moxa
company. Be careful with the devu-ser8250 patch that you include the
correct number of channels and I draw your attention to the final sentence
concerning the baud rate setting, Best of luck

Run “pci” command under QNX to get PCI information of the MOXA PCI card.

pci - v > pci.inf

Search the MOXA PCI card information with vender ID 1393h in “pci.inf”,
then get the I/O address and IRQ :
Class = Communication (Serial Controller)
Vendor ID = 1393h, Moxa Technologies Co Ltd
Device ID = 1680h, Unknown Unknown
PCI index = 0h
Class Codes = 070080h
Revision ID = 2h
Bus number = 0
Device number = 9
Function num = 0
Status Reg = 280h
Command Reg = 3h
Header type = 0h Single-function
BIST = 0h Build-in-self-test not supported
Latency Timer = 0h
Cache Line Size= 8h un-cacheable
PCI IO Address = d800h length 128 enabled
PCI IO Address = d400h length 64 enabled<- I/O base address
PCI IO Address = d000h length 16 enabled
Max Lat = 0ns
Min Gnt = 0ns
PCI Int Pin = INT A
Interrupt line = 10 <---- IRQ

Run command under QNX to load driver (I/O is d400, d408 … and IRQ is 10 in
this case) :
devc-ser8250 -u3 d400,10 -u4 d408,10 -u5 d410,10 -u6 d418,10 -u7 d420,10
-u8 d428,10 -u9 d430,10 -u10 d438,10

The C168H/PCI will be installed on /dev/ser3 ~ /dev/ser10.

Note : If you use MOXA H series ISA card with High speed mode (C104H,
C168H …) or MOXA PCI card, the real working baud rate is exactly 8 times
of the setting speed. That is, if you set 1200 bps, the real working baud
rate is 9600 bps.

9

Thanks , communication is without problem now.
David

Probably MOXA is 8 times faster than normal serial ports (to be able to go
faster than 115200). Try to set line speed of 9600 on normal ports and
1200
on MOXA ports…

10

david chivers wrote:

Note : If you use MOXA H series ISA card with High speed mode (C104H,
C168H …) or MOXA PCI card, the real working baud rate is exactly 8 times
of the setting speed. That is, if you set 1200 bps, the real working baud
rate is 9600 bps.

The devc-ser8250 -c option might tidy that one up:

-c clock[/divisor]
Define a custom clock rate, in hertz, and divisor for the serial port.
The default (-c 1843200/16) is suitable for compatible PC serial ports.


Evan

11

In article <d83l05$i8s$1@inn.qnx.com>, dbrdicka@retia.cz says…

Thanks, it works.
Now qnx starts with two devc-ser8250.
94224 devc-ser8250 -u1 3f8,4 -u2 2f8,3
94227 devc-ser8250 -u3 c400,10 -u4 c408,10 -u5 c410,10 -u6 c418,10

Only in this line is problem:

driver(devc-ser8250 “-u$(s0) $(ioport1),$(irq) -u$(s1) $(ioport1)+8,
$(irq) -u$(s2) $(ioport1)+16,$(irq) -u$(s3) $(ioport1)+24,$(irq)”)

adresses are c400, c400+8 , c400+16 , c400+24

I know that. That was my question, not example for config file, and I
hope someone will comment that. Are there any math primitives in the
enumerator config file syntax? I didn’t find any in doc, nor any example
how to do a simple calculation. I hope I missed something and there is a
simple way to calculate base addresses of the UARTs. If not, QSS you can
see off this thread it is something really needed.

Eduard.

David

12

Here is the methid I used for the MOXA 168 series PCI

In the /etc/system/enum/eom directory – a file ‘moxa-168’

Definitions for character devices

device(pci, 1393, 1681)
uniq(sernum, devc-ser, 1)
start("/usr/local/bin/enum_start.sh 8 $(irq) $(ioport1) 8
devc-ser8250 $(SER_OPTIONS) -c14745600,16 -u$(sernum)")

The above two lines are actually a single line !! (No trailing \ on

first line}
uniq(sernum, devc-ser, 1)
uniq(sernum, devc-ser, 1)
uniq(sernum, devc-ser, 1)
uniq(sernum, devc-ser, 1)
uniq(sernum, devc-ser, 1)
uniq(sernum, devc-ser, 1)
uniq(sernum, devc-ser, 1)


and the corrsponding script in ‘/usr/local/bin’

#!/bin/ksh

Set up serial card with multiple ports

echo “count :” $1

echo “irq :” $2

echo “port :” $3

echo “inc :” $4

echo “command :” $5

echo

set -x

Count = number of ports on this card

integer count=$1

irq = the relevant IRQ for the card $(irq)

integer irq=$2

port = port address of the first port on the card $(ioport1)

typeset -i10 port=16#$3

distance = distance between each port

integer distance=$4

shift 4

Seed the command with the rest of the parameters

export command=$*

Add another port to the command

while [ count -gt 0 ]
do
command="$command $(printf “%x,%u” $port $irq )"
#echo “count $count port $port command $command”
let port=$port+$distance
let count=$count-1
done

Do it !

$command &

return



ed1k wrote:

In article <d83l05$i8s$> 1@inn.qnx.com> >, > dbrdicka@retia.cz > says…

Thanks, it works.
Now qnx starts with two devc-ser8250.
94224 devc-ser8250 -u1 3f8,4 -u2 2f8,3
94227 devc-ser8250 -u3 c400,10 -u4 c408,10 -u5 c410,10 -u6 c418,10

Only in this line is problem:

driver(devc-ser8250 “-u$(s0) $(ioport1),$(irq) -u$(s1) $(ioport1)+8,
$(irq) -u$(s2) $(ioport1)+16,$(irq) -u$(s3) $(ioport1)+24,$(irq)”)

adresses are c400, c400+8 , c400+16 , c400+24



I know that. That was my question, not example for config file, and I
hope someone will comment that. Are there any math primitives in the
enumerator config file syntax? I didn’t find any in doc, nor any example
how to do a simple calculation. I hope I missed something and there is a
simple way to calculate base addresses of the UARTs. If not, QSS you can
see off this thread it is something really needed.

Eduard.


David

13

In article <d857u2$o22$1@inn.qnx.com>, warren.deitch@transtoll.com
says…

Here is the methid I used for the MOXA 168 series PCI

Thank you for the example. I would consider that as a workaround. In my
opinion, this doesn’t look like something that hardware manufacturer
could provide to the customer. Also there is some disadvantages of this
method, for example tacking of command line for driver, or lack thereof.
Actually it’s not a big deal to write an enumerator, let’s say ‘enum-
moxa’ (well, I don’t work for moxa, so I’d not write that one :astonished:)) But.
Do we really need it? Is it any good to add one more bus? We already
have “lptenum”, “serenum” buses. We have a sophisticated config file
with a lot of clauses that lacks at least one more clause, let say
“offset”.
I would love to have something like this:

device(pci, ven=1393, dev=1041)
uniq(s0, devc-ser, 1)
uniq(s1, devc-ser, 1)
uniq(s2, devc-ser, 1)
uniq(s3, devc-ser, 1)
offset(io1, $(ioport1), :sunglasses:
offset(io2, $(io1), :sunglasses:
offset(io3, $(io2), :sunglasses:
driver(devc-ser8250 $(SER_OPTIONS), “-u$(s0) $(ioport1),$(irq) -u$(s1)
$(io1),$(irq) -u$(s2) $(io2),$(irq) -u$(s3) $(io3),$(irq)”)

Eduard.

P.S. Probably the best workaround is to write a custom devc- driver that
will autodetect all boards and ports of that manufacturer and will use
hardware appropriately, not in a generic way. But QNX is not the OS
number one for the company where I work right now. We can’t spend time
and money supporting QNX at that level (I do not even calculate QNX
licensing or alliance payments that QNX expects from us. Isn’t that
ridiculous). However, this is my personal opinion, not a point of
company where I work (maybe they’re working hard on QNX stuff, who
knows).

In the /etc/system/enum/eom directory – a file ‘moxa-168’

Definitions for character devices

device(pci, 1393, 1681)
uniq(sernum, devc-ser, 1)
start("/usr/local/bin/enum_start.sh 8 $(irq) $(ioport1) 8
devc-ser8250 $(SER_OPTIONS) -c14745600,16 -u$(sernum)")

The above two lines are actually a single line !! (No trailing \ on

first line}
uniq(sernum, devc-ser, 1)
uniq(sernum, devc-ser, 1)
uniq(sernum, devc-ser, 1)
uniq(sernum, devc-ser, 1)
uniq(sernum, devc-ser, 1)
uniq(sernum, devc-ser, 1)
uniq(sernum, devc-ser, 1)


and the corrsponding script in ‘/usr/local/bin’

#!/bin/ksh

Set up serial card with multiple ports

echo “count :” $1

echo “irq :” $2

echo “port :” $3

echo “inc :” $4

echo “command :” $5

echo

set -x

Count = number of ports on this card

integer count=$1

irq = the relevant IRQ for the card $(irq)

integer irq=$2

port = port address of the first port on the card $(ioport1)

typeset -i10 port=16#$3

distance = distance between each port

integer distance=$4

shift 4

Seed the command with the rest of the parameters

export command=$*

Add another port to the command

while [ count -gt 0 ]
do
command="$command $(printf “%x,%u” $port $irq )"
#echo “count $count port $port command $command”
let port=$port+$distance
let count=$count-1
done

Do it !

$command &

return



ed1k wrote:
In article <d83l05$i8s$> 1@inn.qnx.com> >, > dbrdicka@retia.cz > says…

Thanks, it works.
Now qnx starts with two devc-ser8250.
94224 devc-ser8250 -u1 3f8,4 -u2 2f8,3
94227 devc-ser8250 -u3 c400,10 -u4 c408,10 -u5 c410,10 -u6 c418,10

Only in this line is problem:

driver(devc-ser8250 “-u$(s0) $(ioport1),$(irq) -u$(s1) $(ioport1)+8,
$(irq) -u$(s2) $(ioport1)+16,$(irq) -u$(s3) $(ioport1)+24,$(irq)”)

adresses are c400, c400+8 , c400+16 , c400+24



I know that. That was my question, not example for config file, and I
hope someone will comment that. Are there any math primitives in the
enumerator config file syntax? I didn’t find any in doc, nor any example
how to do a simple calculation. I hope I missed something and there is a
simple way to calculate base addresses of the UARTs. If not, QSS you can
see off this thread it is something really needed.

Eduard.


David
\

14

ed1k wrote:

In article <d857u2$o22$> 1@inn.qnx.com> >, > warren.deitch@transtoll.com
says…
Here is the methid I used for the MOXA 168 series PCI


Thank you for the example. I would consider that as a workaround. In my
opinion, this doesn’t look like something that hardware manufacturer
could provide to the customer. Also there is some disadvantages of this
method, for example tacking of command line for driver, or lack thereof.
Actually it’s not a big deal to write an enumerator, let’s say ‘enum-
moxa’ (well, I don’t work for moxa, so I’d not write that one > :astonished:> )) But.
Do we really need it? Is it any good to add one more bus? We already
have “lptenum”, “serenum” buses. We have a sophisticated config file
with a lot of clauses that lacks at least one more clause, let say
“offset”.
I would love to have something like this:

device(pci, ven=1393, dev=1041)
uniq(s0, devc-ser, 1)
uniq(s1, devc-ser, 1)
uniq(s2, devc-ser, 1)
uniq(s3, devc-ser, 1)
offset(io1, $(ioport1), > :sunglasses:
offset(io2, $(io1), > :sunglasses:
offset(io3, $(io2), > :sunglasses:
driver(devc-ser8250 $(SER_OPTIONS), “-u$(s0) $(ioport1),$(irq) -u$(s1)
$(io1),$(irq) -u$(s2) $(io2),$(irq) -u$(s3) $(io3),$(irq)”)

Eduard.

P.S. Probably the best workaround is to write a custom devc- driver that
will autodetect all boards and ports of that manufacturer and will use
hardware appropriately, not in a generic way.

Which is what the QNX4/6 Comtrol RocketPort drivers do.

If use of dumb 8250/68450 derived UART’s is essential, it would not be
difficult to add the appropriate PCI code to devc-ser8250 so that it
could figure it out also, with the vendor ID and possibly device ID’s of
the installed cards passed in on the command line. Or perhaps even
customised for a particular manufacturer. I’m not sure, however, how
QSSL feels about such modifications.

While at it, one could also dramatically improve the UART handling code
by taking it all out of the ISR’s.

Geoff.


But QNX is not the OS
number one for the company where I work right now. We can’t spend time
and money supporting QNX at that level (I do not even calculate QNX
licensing or alliance payments that QNX expects from us. Isn’t that
ridiculous). However, this is my personal opinion, not a point of
company where I work (maybe they’re working hard on QNX stuff, who
knows).

In the /etc/system/enum/eom directory – a file ‘moxa-168’

Definitions for character devices

device(pci, 1393, 1681)
uniq(sernum, devc-ser, 1)
start("/usr/local/bin/enum_start.sh 8 $(irq) $(ioport1) 8
devc-ser8250 $(SER_OPTIONS) -c14745600,16 -u$(sernum)")

The above two lines are actually a single line !! (No trailing \ on

first line}
uniq(sernum, devc-ser, 1)
uniq(sernum, devc-ser, 1)
uniq(sernum, devc-ser, 1)
uniq(sernum, devc-ser, 1)
uniq(sernum, devc-ser, 1)
uniq(sernum, devc-ser, 1)
uniq(sernum, devc-ser, 1)


and the corrsponding script in ‘/usr/local/bin’

#!/bin/ksh

Set up serial card with multiple ports

echo “count :” $1

echo “irq :” $2

echo “port :” $3

echo “inc :” $4

echo “command :” $5

echo

set -x

Count = number of ports on this card

integer count=$1

irq = the relevant IRQ for the card $(irq)

integer irq=$2

port = port address of the first port on the card $(ioport1)

typeset -i10 port=16#$3

distance = distance between each port

integer distance=$4

shift 4

Seed the command with the rest of the parameters

export command=$*

Add another port to the command

while [ count -gt 0 ]
do
command="$command $(printf “%x,%u” $port $irq )"
#echo “count $count port $port command $command”
let port=$port+$distance
let count=$count-1
done

Do it !

$command &

return



ed1k wrote:
In article <d83l05$i8s$> 1@inn.qnx.com> >, > dbrdicka@retia.cz > says…

Thanks, it works.
Now qnx starts with two devc-ser8250.
94224 devc-ser8250 -u1 3f8,4 -u2 2f8,3
94227 devc-ser8250 -u3 c400,10 -u4 c408,10 -u5 c410,10 -u6 c418,10

Only in this line is problem:

driver(devc-ser8250 “-u$(s0) $(ioport1),$(irq) -u$(s1) $(ioport1)+8,
$(irq) -u$(s2) $(ioport1)+16,$(irq) -u$(s3) $(ioport1)+24,$(irq)”)

adresses are c400, c400+8 , c400+16 , c400+24



I know that. That was my question, not example for config file, and I
hope someone will comment that. Are there any math primitives in the
enumerator config file syntax? I didn’t find any in doc, nor any example
how to do a simple calculation. I hope I missed something and there is a
simple way to calculate base addresses of the UARTs. If not, QSS you can
see off this thread it is something really needed.

Eduard.


David
\

15

Geoff Roberts wrote:

ed1k wrote:

In article <d857u2$o22$> 1@inn.qnx.com> >, > warren.deitch@transtoll.com
says…

Here is the methid I used for the MOXA 168 series PCI


Thank you for the example. I would consider that as a workaround. In my
opinion, this doesn’t look like something that hardware manufacturer
could provide to the customer. Also there is some disadvantages of this
method, for example tacking of command line for driver, or lack thereof.
Actually it’s not a big deal to write an enumerator, let’s say ‘enum-
moxa’ (well, I don’t work for moxa, so I’d not write that one > :astonished:> )) But.
Do we really need it? Is it any good to add one more bus? We already
have “lptenum”, “serenum” buses. We have a sophisticated config file
with a lot of clauses that lacks at least one more clause, let say
“offset”.
I would love to have something like this:

device(pci, ven=1393, dev=1041)
uniq(s0, devc-ser, 1)
uniq(s1, devc-ser, 1)
uniq(s2, devc-ser, 1)
uniq(s3, devc-ser, 1)
offset(io1, $(ioport1), > :sunglasses:
offset(io2, $(io1), > :sunglasses:
offset(io3, $(io2), > :sunglasses:
driver(devc-ser8250 $(SER_OPTIONS), “-u$(s0) $(ioport1),$(irq) -u$(s1)
$(io1),$(irq) -u$(s2) $(io2),$(irq) -u$(s3) $(io3),$(irq)”)

Eduard.

P.S. Probably the best workaround is to write a custom devc- driver that
will autodetect all boards and ports of that manufacturer and will use
hardware appropriately, not in a generic way.

Moxa claims to support QNX for those boards.
Bug them about it.

John Nagle

16

Hi,

Geoff Roberts schrieb:

ed1k wrote:

In article <d857u2$o22$> 1@inn.qnx.com> >, > warren.deitch@transtoll.com
says…

Here is the methid I used for the MOXA 168 series PCI


Thank you for the example. I would consider that as a workaround. In my
opinion, this doesn’t look like something that hardware manufacturer
could provide to the customer. Also there is some disadvantages of this
method, for example tacking of command line for driver, or lack thereof.
Actually it’s not a big deal to write an enumerator, let’s say ‘enum-
moxa’ (well, I don’t work for moxa, so I’d not write that one > :astonished:> )) But.
Do we really need it? Is it any good to add one more bus? We already
have “lptenum”, “serenum” buses. We have a sophisticated config file
with a lot of clauses that lacks at least one more clause, let say
“offset”.
I would love to have something like this:

device(pci, ven=1393, dev=1041)
uniq(s0, devc-ser, 1)
uniq(s1, devc-ser, 1)
uniq(s2, devc-ser, 1)
uniq(s3, devc-ser, 1)
offset(io1, $(ioport1), > :sunglasses:
offset(io2, $(io1), > :sunglasses:
offset(io3, $(io2), > :sunglasses:
driver(devc-ser8250 $(SER_OPTIONS), “-u$(s0) $(ioport1),$(irq) -u$(s1)
$(io1),$(irq) -u$(s2) $(io2),$(irq) -u$(s3) $(io3),$(irq)”)

Eduard.

P.S. Probably the best workaround is to write a custom devc- driver that
will autodetect all boards and ports of that manufacturer and will use
hardware appropriately, not in a generic way.


Which is what the QNX4/6 Comtrol RocketPort drivers do.

If use of dumb 8250/68450 derived UART’s is essential, it would not be
difficult to add the appropriate PCI code to devc-ser8250 so that it
could figure it out also, with the vendor ID and possibly device ID’s of
the installed cards passed in on the command line. Or perhaps even
customised for a particular manufacturer. I’m not sure, however, how
QSSL feels about such modifications.

you do not need to use vendor specific code in the devc-ser8250. For our
multi serial cpci card I wrote a very short program (in our case
devc-asio4), which you use like devc-ser8250. This program searches our
card on the pci bus and uses “execvp” to run the devc-ser8250 with a
modified arglist. So we can deliver a full style resource-manager for
our card with just two pages of sourcecode. You only need devc-ser8250
in the execution path.

-Michael


While at it, one could also dramatically improve the UART handling code
by taking it all out of the ISR’s.

Geoff.



But QNX is not the OS
number one for the company where I work right now. We can’t spend time
and money supporting QNX at that level (I do not even calculate QNX
licensing or alliance payments that QNX expects from us. Isn’t that
ridiculous). However, this is my personal opinion, not a point of
company where I work (maybe they’re working hard on QNX stuff, who
knows).


In the /etc/system/enum/eom directory – a file ‘moxa-168’

Definitions for character devices

device(pci, 1393, 1681)
uniq(sernum, devc-ser, 1)
start("/usr/local/bin/enum_start.sh 8 $(irq) $(ioport1) 8
devc-ser8250 $(SER_OPTIONS) -c14745600,16 -u$(sernum)")

The above two lines are actually a single line !! (No trailing \ on

first line}
uniq(sernum, devc-ser, 1)
uniq(sernum, devc-ser, 1)
uniq(sernum, devc-ser, 1)
uniq(sernum, devc-ser, 1)
uniq(sernum, devc-ser, 1)
uniq(sernum, devc-ser, 1)
uniq(sernum, devc-ser, 1)


and the corrsponding script in ‘/usr/local/bin’

#!/bin/ksh

Set up serial card with multiple ports

echo “count :” $1

echo “irq :” $2

echo “port :” $3

echo “inc :” $4

echo “command :” $5

echo

set -x

Count = number of ports on this card

integer count=$1

irq = the relevant IRQ for the card $(irq)

integer irq=$2

port = port address of the first port on the card $(ioport1)

typeset -i10 port=16#$3

distance = distance between each port

integer distance=$4

shift 4

Seed the command with the rest of the parameters

export command=$*

Add another port to the command

while [ count -gt 0 ]
do
command="$command $(printf “%x,%u” $port $irq )"
#echo “count $count port $port command $command”
let port=$port+$distance
let count=$count-1
done

Do it !

$command &

return



ed1k wrote:

In article <d83l05$i8s$> 1@inn.qnx.com> >, > dbrdicka@retia.cz > says…


Thanks, it works.
Now qnx starts with two devc-ser8250.
94224 devc-ser8250 -u1 3f8,4 -u2 2f8,3
94227 devc-ser8250 -u3 c400,10 -u4 c408,10 -u5 c410,10 -u6 c418,10

Only in this line is problem:

driver(devc-ser8250 “-u$(s0) $(ioport1),$(irq) -u$(s1) $(ioport1)+8,
$(irq) -u$(s2) $(ioport1)+16,$(irq) -u$(s3) $(ioport1)+24,$(irq)”)

adresses are c400, c400+8 , c400+16 , c400+24



I know that. That was my question, not example for config file, and I
hope someone will comment that. Are there any math primitives in the
enumerator config file syntax? I didn’t find any in doc, nor any example
how to do a simple calculation. I hope I missed something and there is a
simple way to calculate base addresses of the UARTs. If not, QSS you can
see off this thread it is something really needed.

Eduard.



David
\

17

In article <ruhln2-m2r.ln1@comm.esd>, michael.tasche@esd-electronics.com
says…

P.S. Probably the best workaround is to write a custom devc- driver that
will autodetect all boards and ports of that manufacturer and will use
hardware appropriately, not in a generic way.


Which is what the QNX4/6 Comtrol RocketPort drivers do.

If use of dumb 8250/68450 derived UART’s is essential, it would not be
difficult to add the appropriate PCI code to devc-ser8250 so that it
could figure it out also, with the vendor ID and possibly device ID’s of
the installed cards passed in on the command line. Or perhaps even
customised for a particular manufacturer. I’m not sure, however, how
QSSL feels about such modifications.

you do not need to use vendor specific code in the devc-ser8250. For our
multi serial cpci card I wrote a very short program (in our case
devc-asio4), which you use like devc-ser8250. This program searches our
card on the pci bus and uses “execvp” to run the devc-ser8250 with a
modified arglist. So we can deliver a full style resource-manager for
our card with just two pages of sourcecode. You only need devc-ser8250
in the execution path.

-Michael

Wow! That’s interesting point. I do not think QNX needs that because
they have an enumerator. “QNX support” for hardware vendors often means
readme file that describe how to manually start the standard driver (at
least it seems to be true for moxa). First thing I did in my current job
I wrote a config file for QNX enumerator that starts devc-ser8250 with
recommended parameters for our boards. We don’t have a problem with math
in the enum config file because every port has base I/O in a BAR. If 6
BARs aren’t enought for all ports on board, board is a multifunction PCI
device.

While at it, one could also dramatically improve the UART handling code
by taking it all out of the ISR’s.

Geoff.

Well, there are lot of improvements that could be done. I don’t think
the standard driver has to know all ever possible PCI&Vendor IDs to deal
with every particular board. This is kinda Linux way. In Linux world,
every driver starts and tries to find hardware (well, only those drivers
that you answered ‘y’ making ‘make menuconfig’ while compiling kernel).
Every next world is similar to previous except a few small details. QNX
world has an enumerator, and this is their fault it’s not used widely
(or mainly unknown for hardware vendors… though every heard of .inf
for windows). Idea is very good, it works for desktop and easily can be
eliminated for embedded target (searching for unexisting devices in a
deeply embedded system would cost a lot). What standard devc-ser8250
lacks is a support for c650-c950 UARTs, it also may be an option to
driver (I know which device which UART uses, so I can put appropriate
option into config file). QNX is not in a market position to expect a
lot of drivers from hardware manufactures or to support every possible
device. But they need to support some standard hardware and interfaces.

Cheers,
Eduard

18

ed1k schrieb:

In article <> ruhln2-m2r.ln1@comm.esd> >, > michael.tasche@esd-electronics.com
says…

P.S. Probably the best workaround is to write a custom devc- driver that
will autodetect all boards and ports of that manufacturer and will use
hardware appropriately, not in a generic way.


Which is what the QNX4/6 Comtrol RocketPort drivers do.

If use of dumb 8250/68450 derived UART’s is essential, it would not be
difficult to add the appropriate PCI code to devc-ser8250 so that it
could figure it out also, with the vendor ID and possibly device ID’s of
the installed cards passed in on the command line. Or perhaps even
customised for a particular manufacturer. I’m not sure, however, how
QSSL feels about such modifications.

you do not need to use vendor specific code in the devc-ser8250. For our
multi serial cpci card I wrote a very short program (in our case
devc-asio4), which you use like devc-ser8250. This program searches our
card on the pci bus and uses “execvp” to run the devc-ser8250 with a
modified arglist. So we can deliver a full style resource-manager for
our card with just two pages of sourcecode. You only need devc-ser8250
in the execution path.

-Michael



Wow! That’s interesting point. I do not think QNX needs that because
they have an enumerator. “QNX support” for hardware vendors often means
readme file that describe how to manually start the standard driver (at
least it seems to be true for moxa). First thing I did in my current job
I wrote a config file for QNX enumerator that starts devc-ser8250 with
recommended parameters for our boards. We don’t have a problem with math
in the enum config file because every port has base I/O in a BAR. If 6
BARs aren’t enought for all ports on board, board is a multifunction PCI
device.
Yes, the enumerator is the tool of choice, but I had the math-problem.

Additional I had to invent some new commandline option to switch off/on
hardware RS485 Mode.

-Michael

While at it, one could also dramatically improve the UART handling code
by taking it all out of the ISR’s.

Geoff.



Well, there are lot of improvements that could be done. I don’t think
the standard driver has to know all ever possible PCI&Vendor IDs to deal
with every particular board. This is kinda Linux way. In Linux world,
every driver starts and tries to find hardware (well, only those drivers
that you answered ‘y’ making ‘make menuconfig’ while compiling kernel).
Every next world is similar to previous except a few small details. QNX
world has an enumerator, and this is their fault it’s not used widely
(or mainly unknown for hardware vendors… though every heard of .inf
for windows). Idea is very good, it works for desktop and easily can be
eliminated for embedded target (searching for unexisting devices in a
deeply embedded system would cost a lot). What standard devc-ser8250
lacks is a support for c650-c950 UARTs, it also may be an option to
driver (I know which device which UART uses, so I can put appropriate
option into config file). QNX is not in a market position to expect a
lot of drivers from hardware manufactures or to support every possible
device. But they need to support some standard hardware and interfaces.

Cheers,
Eduard