[ECOS] AT91 serial port usage

[ECOS] AT91 serial port usage

[harri.siirtola]

Does this work with the latest AT91 port: having both AT91 serial ports
interrupt driven and port 0 used as /dev/ttydiag at the same time? I try to
configure with these checked:

ARM Architecture
	Atmel evaluation board (EB40)
		Startup type		RAM
		Debug serial port		0
		Diagnostic serial port	0
		Console/GDB baud rate	38400

TTY-mode serial device drivers
	HAL/diag serial device drivers
	Console device name		"/dev/ttydiag"
	TTY mode HAL/diag channel

Hardware serial drivers
	Atmel AT91 serial device drivers
		Atmel AT91 serial port 0 driver
			device name		"/dev/ser0"
			baud rate		38400
			buffer size		128
		Atmel AT91 serial port 1 driver
			device name		"/dev/ser1"
			baud rate		38400
			buffer size		128

Thanks,
	Harri

Re: [ECOS] AT91 serial port usage

[Jonathan Larmour]

harri.siirtola@vtt.fi wrote:
> 
> Does this work with the latest AT91 port: having both AT91 serial ports
> interrupt driven and port 0 used as /dev/ttydiag at the same time? I try to
> configure with these checked:

Should do. If it doesn't you'll have to say what happens! Preferably after
a bit of debugging.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

Re: [ECOS] AT91 serial port usage

[Gary Thomas]

On 14-Aug-2001 Jonathan Larmour wrote:
> The only oddities I see are:
> 
> - start_xmit and stop_xmit both write the same thing to the IER which seems
> curious, but possible

The 'stop_write' function should really write to IDR (Interrupt Disable Register)

Re: [ECOS] AT91 serial port usage

[Jonathan Larmour]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2118 bytes --]

harri.siirtola@vtt.fi wrote:
> 
> >> Does this work with the latest AT91 port: having both AT91 serial ports
> >> interrupt driven and port 0 used as /dev/ttydiag at the same time? I try to
> >> configure with these checked:
> >
> >Should do. If it doesn't you'll have to say what happens! Preferably after
> >a bit of debugging.
> 
> After some digging: if I enable "Debug I/O sub-system", I get the following:
> Init device '/dev/ser0'
> AT91 SERIAL init - dev: FFFD0000.2
> Set output buffer - buf: 2071A78 len: 128
> Set input buffer - buf: 2071AF8 len:
> 128½)+??'*Ù¥?*??½'*Ù½Í*ÉÅ?5)QåÅ?M\x15I%1?¥¹¥Ñ?
> µ?'*Ùé?ÿFFFCC000.3
> Set output buffer - buf: 2071B78 len: 128
> Set input buffer - buf: 2071BF8 len: 128
> Init device '/dev/ttydiag'
> Init tty channel: 206024C
> Init device '/dev/haldiag'
> HAL/diag SERIAL init
> 
> So there's garbage instead of "Init device /dev/ser1" etc. After this,
> printf works though. Should there be a delay between inits?

It's the PLLs resyncing even though the baud rate hasn't actually changed.
A delay may not necessarily help as it may need traffic to sync properly.
You could try it though.

> Another problem is, I can't seem to get port 1 rx interrupts triggering (tx
> works ok). With my own experimental port (derived from Carl's port just as
> this one)

This port wasn't derived from Carl's.

> it triggered, I just can't find any significant differences.
> Chars appear in USART1_RHR and IMR bits 0 & 1 are set.

Don't know. Can't see any reason why not, like you. If nothing else -
there's no difference between the driver for ports 0 and 1 except obviously
the base address and interrupt number; nothing specific to port 1.

The only oddities I see are:

- start_xmit and stop_xmit both write the same thing to the IER which seems
curious, but possible
- the ISR doesn't OR in CYG_ISR_HANDLED

I wouldn't think this would cause what you see though.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

Re: [ECOS] AT91 serial port usage

[harri.siirtola]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1303 bytes --]

>> Does this work with the latest AT91 port: having both AT91 serial ports
>> interrupt driven and port 0 used as /dev/ttydiag at the same time? I try to
>> configure with these checked:
>
>Should do. If it doesn't you'll have to say what happens! Preferably after
>a bit of debugging.

After some digging: if I enable "Debug I/O sub-system", I get the following:
Init device '/dev/ser0'
AT91 SERIAL init - dev: FFFD0000.2
Set output buffer - buf: 2071A78 len: 128
Set input buffer - buf: 2071AF8 len:
128½)+‹'•Ù¥•½'•Ù½Í•Éŝ5)QåŁM\x15I%1¥¹¥Ñ
µ'•ÙéÿFFFCC000.3
Set output buffer - buf: 2071B78 len: 128
Set input buffer - buf: 2071BF8 len: 128
Init device '/dev/ttydiag'
Init tty channel: 206024C
Init device '/dev/haldiag'
HAL/diag SERIAL init

So there's garbage instead of "Init device /dev/ser1" etc. After this,
printf works though. Should there be a delay between inits?

Another problem is, I can't seem to get port 1 rx interrupts triggering (tx
works ok). With my own experimental port (derived from Carl's port just as
this one) it triggered, I just can't find any significant differences.
Chars appear in USART1_RHR and IMR bits 0 & 1 are set.

>
>Jifl

Thanks for your help,
	Harri