trouble talking to serial port

2008-07-07 Thread Anthony Roberts
I'm working with a Portwell NAR-5520 (dmesg follows). These machines have
an LCD on the front that uses a serial port to talk to the OS. I've been
having trouble with these:

# stty 2400 < /dev/tty01
...hangs forever...
^Cksh: cannot open /dev/tty01: Interrupted system call
# stty -f /dev/tty01 2400
# stty -f /dev/tty01
speed 19200 baud;
lflags: echoe echoke echoctl
cflags: cs8 -parenb
# python
Python 2.5.2 (r252:60911, Mar 10 2008, 16:28:59)
[GCC 3.3.5 (propolice)] on openbsd4
Type "help", "copyright", "credits" or "license" for more information.
>>> f=open("/dev/tty01", "w")
...hangs forever...
^CTraceback (most recent call last):
  File "", line 1, in 
KeyboardInterrupt

This same stuff works fine running Linux on the same hardware:

[EMAIL PROTECTED]:~# stty 2400 < /dev/ttyS1
[EMAIL PROTECTED]:~# stty < /dev/ttyS1
speed 2400 baud; line = 0;
min = 1; time = 0;
-brkint -icrnl -imaxbel
-opost
-isig -icanon

I can also write messages to the LCD from Linux.

Both OSes detect the same hardware for the serial ports:

OpenBSD:
# dmesg | grep pccom
pccom0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
pccom0: console
pccom1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo

Linux:
# dmesg | grep 16550A
[   47.459103] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[   47.495182] serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
[   47.531631] 00:06: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[   47.565162] 00:07: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A

In both cases, I'm using pccom0/tty00/ttyS0 as a serial console. If I
"stty com1 2400" for OpenBSD at the boot prompt, it sets com0 to 2400 and
I get gibberish on the console until I set my terminal app to 2400.

Does anyone have any suggestions? I'm kinda stumped.

Thanks,

Anthony

OpenBSD 4.3 (GENERIC.MP) #5: Tue May  6 13:34:02 MDT 2008
[EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Intel(R) Core(TM)2 CPU 4300 @ 1.80GHz ("GenuineIntel" 686-class)
1.81 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,EST,TM2,CX16,xTPR
real mem  = 1063743488 (1014MB)
avail mem = 1020473344 (973MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 03/05/08, BIOS32 rev. 0 @ 0xfa710,
SMBIOS rev. 2.2 @ 0xf (40 entries)
bios0: vendor Phoenix Technologies, LTD version "6.00 PG" date 03/05/2008
acpi0 at bios0: rev 0
acpi0: tables DSDT FACP MCFG APIC
acpi0: wakeup devices PEX0(S5) PEX1(S5) PEX2(S5) PEX3(S5) PEX4(S5)
PEX5(S5) HUB0(S5) UAR1(S5) UAR2(S5) USB0(S1) USB1(S1) USB2(S1) USB3(S1)
USBE(S1) AC97(S5) AZAL(S5) PCI0(S5)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: apic clock running at 200MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM)2 CPU 4300 @ 1.80GHz ("GenuineIntel" 686-class)
1.81 GHz
cpu1:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,EST,TM2,CX16,xTPR
ioapic0 at mainbus0: apid 4 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 0, remapped to apid 4
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (PEX0)
acpiprt2 at acpi0: bus 2 (PEX1)
acpiprt3 at acpi0: bus 3 (PEX2)
acpiprt4 at acpi0: bus 4 (PEX3)
acpiprt5 at acpi0: bus -1 (PEX4)
acpiprt6 at acpi0: bus -1 (PEX5)
acpiprt7 at acpi0: bus 5 (HUB0)
acpicpu0 at acpi0
acpicpu1 at acpi0
acpitz0 at acpi0: critical temperature 60 degC
acpibtn0 at acpi0: PWRB
bios0: ROM list: 0xc/0xac00! 0xcc000/0x1000 0xef000/0x1000!
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
pchb0 at pci0 dev 0 function 0 "Intel 82945G Host" rev 0x02
agp0 at pchb0: aperture at 0xd000, size 0x1000
vga1 at pci0 dev 2 function 0 "Intel 82945G Video" rev 0x02
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
ppb0 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x01: apic 4 int
16 (irq 9)
pci1 at ppb0 bus 1
em0 at pci1 dev 0 function 0 "Intel PRO/1000MT (82573L)" rev 0x00: apic 4
int 16 (irq 9), address 00:90:fb:11:75:9e
ppb1 at pci0 dev 28 function 1 "Intel 82801GB PCIE" rev 0x01: apic 4 int
17 (irq 10)
pci2 at ppb1 bus 2
em1 at pci2 dev 0 function 0 "Intel PRO/1000MT (82573L)" rev 0x00: apic 4
int 17 (irq 10), address 00:90:fb:11:75:9f
ppb2 at pci0 dev 28 function 2 "Intel 82801GB PCIE" rev 0x01: apic 4 int
18 (irq 5)
pci3 at ppb2 bus 3
em2 at pci3 dev 0 function 0 "Intel PRO/1000MT (82573L)" rev 0x00: apic 4
int 18 (irq 5), address 00:90:fb:11:75:a0
ppb3 at pci0 dev 28 function 3 "Intel 82801GB PCIE" rev 0x01: apic 4 int
19 (irq 11)
pci4 at ppb3 bus 4
em3 at pci4 dev 0 function 0 "Intel PRO/1000MT (82573L)" rev 0x00: apic 4
int 19 (irq 11), address 00:90:fb:11:75:a1
uhci0 at pci0 dev 29 function 0 "Intel 82801GB USB" rev 0x01: apic 4 int
23 (irq 10)
uhci1 at pci0 dev 29 function 1 "Intel 82801GB USB" rev 0x0

Re: trouble talking to serial port

2008-07-07 Thread Brynet

Hi,

In this case, you need to use the "callout" device for the first serial 
port, /dev/cua00 in this case.


Good luck, see tty(4) or cua(4).



Re: trouble talking to serial port

2008-07-07 Thread Anthony Roberts
> In this case, you need to use the "callout" device for the first serial
> port, /dev/cua00 in this case.
>
> Good luck, see tty(4) or cua(4).

Hi,

Thanks for the response. :)

It looks like I was indeed supposed to use cua, and I can now get a file
descriptor. However, I'm still not able to set the baud rate, it's stuck
at 19200 whether I try to set it with tty01 or cua01. cua00 corresponds
with tty00, which is the serial console, so I shouldn't use that.

Thanks,

Anthony



Re: trouble talking to serial port

2008-07-07 Thread Anthony Roberts
> It looks like I was indeed supposed to use cua, and I can now get a file
> descriptor. However, I'm still not able to set the baud rate, it's stuck
> at 19200 whether I try to set it with tty01 or cua01. cua00 corresponds
> with tty00, which is the serial console, so I shouldn't use that.

BTW, using stty to set the baud rate for tty00/cua00 has no problems.
Exactly the same command lines for tty01/cua01 just don't work.



Re: trouble talking to serial port

2008-07-07 Thread Philip Guenther
On Mon, Jul 7, 2008 at 4:43 PM, Anthony Roberts
<[EMAIL PROTECTED]> wrote:
> It looks like I was indeed supposed to use cua, and I can now get a file
> descriptor. However, I'm still not able to set the baud rate, it's stuck
> at 19200 whether I try to set it with tty01 or cua01. cua00 corresponds
> with tty00, which is the serial console, so I shouldn't use that.

I don't recall where this is documented, but terminal devices reset
their settings when the last fd open to them is closed.

# stty /dev/cua01

That opens /dev/cua01 for read/write on fd 3, then runs "stty 2400"
with fd 3 dup'ed to fd  0 (so the stty sees the cua device), and then
runs the python script with the cua device still open on fd 3.  How to
access fd 3 from the script is up to you...


Philip Guenther



Re: trouble talking to serial port

2008-07-07 Thread Theo de Raadt
> > It looks like I was indeed supposed to use cua, and I can now get a file
> > descriptor. However, I'm still not able to set the baud rate, it's stuck
> > at 19200 whether I try to set it with tty01 or cua01. cua00 corresponds
> > with tty00, which is the serial console, so I shouldn't use that.
> 
> I don't recall where this is documented, but terminal devices reset
> their settings when the last fd open to them is closed.

Let's simplify that:

All devices reset their settings when the last open to them is closed.

It is entirely obvious.  Otherwise, every application would have to
have a ton of reset code in it.  And that would be really stupid.