Simple serial comms

[grahamlab]

Hello everyone
I am developing an ecos application using the STM3210E dev kit.
I want to do some serial comms but cannot receive more than 128 bytes.
I have tested this program using minicom to send the bytes

Does anyone know how I can configure it to receive more bytes?

rawRead.cpp

Thanks Graham

[Simon Kallweit]

grahamlab wrote:
> Hello everyone
> I am developing an ecos application using the STM3210E dev kit.
> I want to do some serial comms but cannot receive more than 128 bytes.
> I have tested this program using minicom to send the bytes

You may have to reconfigure the rx/tx buffer length for the serial. The
default is 128 bytes. The following configuration options are used to
configure the buffer size:

CYGNUM_IO_SERIAL_CORTEXM_STM32_SERIAL0_BUFSIZE
CYGNUM_IO_SERIAL_CORTEXM_STM32_SERIAL1_BUFSIZE
CYGNUM_IO_SERIAL_CORTEXM_STM32_SERIAL2_BUFSIZE
CYGNUM_IO_SERIAL_CORTEXM_STM32_SERIAL3_BUFSIZE
CYGNUM_IO_SERIAL_CORTEXM_STM32_SERIAL4_BUFSIZE



Simon

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[grahamlab]

Simon Kallweit wrote:

grahamlab wrote:
> Hello everyone
> I am developing an ecos application using the STM3210E dev kit.
> I want to do some serial comms but cannot receive more than 128 bytes.
> I have tested this program using minicom to send the bytes

You may have to reconfigure the rx/tx buffer length for the serial. The
default is 128 bytes. The following configuration options are used to
configure the buffer size:

CYGNUM_IO_SERIAL_CORTEXM_STM32_SERIAL0_BUFSIZE
CYGNUM_IO_SERIAL_CORTEXM_STM32_SERIAL1_BUFSIZE
CYGNUM_IO_SERIAL_CORTEXM_STM32_SERIAL2_BUFSIZE
CYGNUM_IO_SERIAL_CORTEXM_STM32_SERIAL3_BUFSIZE
CYGNUM_IO_SERIAL_CORTEXM_STM32_SERIAL4_BUFSIZE



Simon

I have these set to 256 but still no change

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[Nick Garnett]

grahamlab <graham.labdon@...> writes:

> Hello everyone
> I am developing an ecos application using the STM3210E dev kit.
> I want to do some serial comms but cannot receive more than 128 bytes.
> I have tested this program using minicom to send the bytes
>
> Does anyone know how I can configure it to receive more bytes?
>
> http://www.nabble.com/file/p24306125/rawRead.cpp rawRead.cpp

I just happened to be doing some serial testing on an STM32 board
here, so I gave your test a go. I don't see any problems. As you can
see from the output below, I can just lean on a key and it comes
through in ~30 character chunks. So buffer sizes don't seem to be a
problem.

How are you sending the bytes?
The USART does not have a FIFO, so in the absence of flow control,
characters might be missed.

I was running this out of on-chip RAM rather than external RAM. That
might make a difference. Although, at 9600 baud this is unlikely.

What sort of RS232 device are you using on the host side? I have seen
some odd behaviour from USB to RS232 adaptors. But that was mostly
around flow control behaviour. I was using an FTDI based adaptor for
the test below.



opened port
EAGIN res -11 msglen 0

EAGIN res -11 msglen 0

EAGIN res 0 msglen 2
ff
EAGIN res 0 msglen 30
ffffffffffffffffffffffffffffff
EAGIN res 0 msglen 30
ffffffffffffffffffffffffffffff
EAGIN res 0 msglen 30
ffffffffffffffffffffffffffffff
EAGIN res 0 msglen 30
ffffffffffffffffffffffffffffff
EAGIN res 0 msglen 30
ffffffffffffffffffffffffffffff
EAGIN res 0 msglen 30
ffffffffffffffffffffffffffffff
EAGIN res 0 msglen 30
ffffffffffffffffffffffffffffff
EAGIN res 0 msglen 30
ffffffffffffffffffffffffffffff
EAGIN res 0 msglen 30
ffffffffffffffffffffffffffffff
EAGIN res 0 msglen 30
ffffffffffffffffffffffffffffff
EAGIN res 0 msglen 30
ffffffffffffffffffffffffffffff
EAGIN res 0 msglen 30
ffffffffffffffffffffffffffffff
EAGIN res 0 msglen 30
ffffffffffffffffffffffffffffff
EAGIN res 0 msglen 29
fffffffffffffffffffffffffffff
EAGIN res 0 msglen 30
ffffffffffffffffffffffffffffff
EAGIN res 0 msglen 30
ffffffffffffffffffffffffffffff
EAGIN res 0 msglen 30
ffffffffffffffffffffffffffffff
EAGIN res 0 msglen 30
ffffffffffffffffffffffffffffff
EAGIN res 0 msglen 30
ffffffffffffffffffffffffffffff
EAGIN res 0 msglen 30
ffffffffffffffffffffffffffffff
EAGIN res 0 msglen 30
ffffffffffffffffffffffffffffff
EAGIN res 0 msglen 23
fffffffffffffffffffffff



--
Nick Garnett                                       eCos Kernel Architect
eCosCentric Limited    http://www.eCosCentric.com       The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.      Tel: [phone]
Registered in England and Wales:                         Reg No: 4422071


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[grahamlab]

grahamlab <[e-mail]> writes:

> Hello everyone
> I am developing an ecos application using the STM3210E dev kit.
> I want to do some serial comms but cannot receive more than 128 bytes.
> I have tested this program using minicom to send the bytes
>
> Does anyone know how I can configure it to receive more bytes?
>
> http://www.nabble.com/file/p24306125/rawRead.cpp rawRead.cpp

>I just happened to be doing some serial testing on an STM32 board
>here, so I gave your test a go. I don't see any problems. As you can
>see from the output below, I can just lean on a key and it comes
>through in ~30 character chunks. So buffer sizes don't seem to be a
>problem.

>How are you sending the bytes?
I can also make my program behave like this. The problen arises when I send the data in a chunk > 128 bytes - either using minicom or another program.

>What sort of RS232 device are you using on the host side? I have seen
>some odd behaviour from USB to RS232 adaptors. But that was mostly
>around flow control behaviour. I was using an FTDI based adaptor for
>the test below.
I
have a lap top with usb->serial adapters

The problem is when a block of data is sent

[Nick Garnett]

grahamlab <graham.labdon@...> writes:

>
> >How are you sending the bytes?
> I can also make my program behave like this. The problen arises when I send
> the data in a chunk > 128 bytes - either using minicom or another program.

In that case I suspect that enabling flow control might be
necessary. If you can use harware flow control that would be best,
otherwise use software flow control.


--
Nick Garnett                                       eCos Kernel Architect
eCosCentric Limited    http://www.eCosCentric.com       The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.      Tel: [phone]
Registered in England and Wales:                         Reg No: 4422071


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[grahamlab]

grahamlab <[e-mail]> writes:

>
> >How are you sending the bytes?
> I can also make my program behave like this. The problen arises when I send
> the data in a chunk > 128 bytes - either using minicom or another program.

In that case I suspect that enabling flow control might be
necessary. If you can use harware flow control that would be best,
otherwise use software flow control.


I have tried flow control but to no avail
there must be a way to receive more than 128 bytes has anybody got any other suggestions

Graham

[Paul D. DeRocco]

> From: grahamlab
>
> I have tried flow control but to no avail
> there must be a way to receive more than 128 bytes has anybody
> got any other suggestions

Do you mean that it receives 128 bytes and then completely dies? Or just
that if you send bursts of more than 128 bytes, you lose some of them?

--

Ciao,               Paul D. DeRocco
Paul                mailto:pderocco@...


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[grahamlab]

Paul D. DeRocco wrote:

> From: grahamlab
>
> I have tried flow control but to no avail
> there must be a way to receive more than 128 bytes has anybody
> got any other suggestions

Do you mean that it receives 128 bytes and then completely dies? Or just
that if you send bursts of more than 128 bytes, you lose some of them?

I mean that if I send more that 128 bytes some go missing.
If I set the read to block and then send my bytes the ecos program blocks until several messages of 128 bytes have been receeived before unblocking and when it unblocks the message received is corrupted

Graham

[Paul D. DeRocco]

> From: grahamlab
>
> I mean that if I send more that 128 bytes some go missing.
> If I set the read to block and then send my bytes the ecos program blocks
> until several messages of 128 bytes have been receeived before unblocking
> and when it unblocks the message received is corrupted

It looks to me like this serial driver uses an interrupt per byte. My guess
is one of the following is wrong: 1) you've selected a very high bit rate;
2) you've misconfigured eCos, and the CPU is running at a slow clock rate,
or 3) there is some other source of interrupts erroneously keeping the CPU
busy.

If the answer is 1, and you really need to speed things up, this driver
could be rewritten to use DMA. I would recommend using DMA into a buffer
large enough to capture, say, 15ms worth of data, and then using the 10ms
timer interrupt to transfer data from the DMA buffer to the user buffer. But
that would be a complete rewrite. You'd learn quite a bit about the eCos
interrupt and device driver structure, but it's nontrivial.

--

Ciao,               Paul D. DeRocco
Paul                mailto:pderocco@...


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[grahamlab]

> From: grahamlab
>
> I mean that if I send more that 128 bytes some go missing.
> If I set the read to block and then send my bytes the ecos program blocks
> until several messages of 128 bytes have been receeived before unblocking
> and when it unblocks the message received is corrupted

It looks to me like this serial driver uses an interrupt per byte. My guess
is one of the following is wrong: 1) you've selected a very high bit rate;
2) you've misconfigured eCos, and the CPU is running at a slow clock rate,
or 3) there is some other source of interrupts erroneously keeping the CPU
busy.

If the answer is 1, and you really need to speed things up, this driver
could be rewritten to use DMA. I would recommend using DMA into a buffer
large enough to capture, say, 15ms worth of data, and then using the 10ms
timer interrupt to transfer data from the DMA buffer to the user buffer. But
that would be a complete rewrite. You'd learn quite a bit about the eCos
interrupt and device driver structure, but it's nontrivial.



I have a standard ecos - I have not changed many settings
where is the driver code located?
what could be a source of spurious interrupts?

[Paul D. DeRocco]

> From: grahamlab
>
> I have a standard ecos - I have not changed many settings
> where is the driver code located?

packages/devs/serial/cortexm/stm32/v3_0/

> what could be a source of spurious interrupts?

Depends upon what else you're doing besides receiving bytes. Perhaps
something to do with wherever the bytes are going? Any other threads doing
anything else?

What bit rate are you using? What clock rate are you running the CPU at?This
isn't a screamingly fast CPU, but I would think it would handle
115200bps--I've done that speed on a slow Atmel ARM7 chip, and that driver's
ISR and DSR code looks even less efficient.

--

Ciao,               Paul D. DeRocco
Paul                mailto:pderocco@...


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[Nick Garnett]

grahamlab <graham.labdon@...> writes:

>
> I have tried flow control but to no avail
> there must be a way to receive more than 128 bytes has anybody got any other
> suggestions

Flow control should entirely solve your problem. Did you enable the
same kind of flow control at both ends of the connection?

I have run tests that successfully transfer larger quantities of data
at higher baud rates for long periods. So I don't believe there is a
significant problem with the basic driver code.

Some other things to try:

- Test against a host with a real RS232 device. USB adaptors can do
  weird things. It is worth eliminating this as a cause of problems,
  particularly with regard to flow control.

- Try increasing STM32_RXBUFSIZE in the driver source to 128 or
  more. Also add a diag_printf() to the overflow branch in the ISR to
  see if it triggers.

- Avoid diag_printf() calls while waiting for data. If you are running
  via GDB these calls can cause interrupts to be disabled while the
  output is being sent. This may cause the driver to miss characters.

- It may be instructive to work out exactly which bytes are lost in
  each message. This may give a clue as to which FIFO or buffer is
  filling up.


--
Nick Garnett                                       eCos Kernel Architect
eCosCentric Limited    http://www.eCosCentric.com       The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.      Tel: [phone]
Registered in England and Wales:                         Reg No: 4422071


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[grahamlab]

Nick Garnett wrote:

grahamlab <[e-mail]> writes:

>
> I have tried flow control but to no avail
> there must be a way to receive more than 128 bytes has anybody got any other
> suggestions

Flow control should entirely solve your problem. Did you enable the
same kind of flow control at both ends of the connection?

I have run tests that successfully transfer larger quantities of data
at higher baud rates for long periods. So I don't believe there is a
significant problem with the basic driver code.

Some other things to try:

- Test against a host with a real RS232 device. USB adaptors can do
  weird things. It is worth eliminating this as a cause of problems,
  particularly with regard to flow control.

- Try increasing STM32_RXBUFSIZE in the driver source to 128 or
  more. Also add a diag_printf() to the overflow branch in the ISR to
  see if it triggers.

- Avoid diag_printf() calls while waiting for data. If you are running
  via GDB these calls can cause interrupts to be disabled while the
  output is being sent. This may cause the driver to miss characters.

- It may be instructive to work out exactly which bytes are lost in
  each message. This may give a clue as to which FIFO or buffer is
  filling up.

I wont be able to test against a 'real' host until monday
I have tried a variety of values for STM32_RXBUFSIZE  but nothing changes - the overflow branch is not triggered
Is it possible for you to send me the programs you use to test the serial interface?

Graham

[Nick Garnett]

grahamlab <graham.labdon@...> writes:

> I wont be able to test against a 'real' host until monday
> I have tried a variety of values for STM32_RXBUFSIZE  but nothing changes -
> the overflow branch is not triggered
> Is it possible for you to send me the programs you use to test the serial
> interface?

These are the standard serial tests in the io/serial package. They
need the ser_filter program that is one of the host tools that come
with eCos. The documentation is here:

http://ecos.sourceware.org/docs-latest/ref/io-serial-testing-with-serfilter.html

--
Nick Garnett                                       eCos Kernel Architect
eCosCentric Limited    http://www.eCosCentric.com       The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.      Tel: [phone]
Registered in England and Wales:                         Reg No: 4422071


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[grahamlab]

Nick Garnett wrote:

grahamlab <[e-mail]> writes:

> I wont be able to test against a 'real' host until monday
> I have tried a variety of values for STM32_RXBUFSIZE  but nothing changes -
> the overflow branch is not triggered
> Is it possible for you to send me the programs you use to test the serial
> interface?

These are the standard serial tests in the io/serial package. They
need the ser_filter program that is one of the host tools that come
with eCos. The documentation is here:

http://ecos.sourceware.org/docs-latest/ref/io-serial-testing-with-serfilter.html

I am having no success with the serial tests - here is what I do
ser_filter -t 9000 /dev/ttyS0 - runs the filter, waits for a connection
arm-eabi-gdb-nw intsall/tests/io/serial/v3_0/tests/serial3 - gives me the gdb prompt
target remote localhost:9000 - gdb says debugging using localhost:9000 and returns to the gdb prompt
type 'c' - gdb says 'continuing' - then nothing else happens

What am I missing?

Graham

[Nick Garnett]

grahamlab <graham.labdon@...> writes:

> I am having no success with the serial tests - here is what I do
> ser_filter -t 9000 /dev/ttyS0 - runs the filter, waits for a connection
> arm-eabi-gdb-nw intsall/tests/io/serial/v3_0/tests/serial3 - gives me the
> gdb prompt
> target remote localhost:9000 - gdb says debugging using localhost:9000 and
> returns to the gdb prompt
> type 'c' - gdb says 'continuing' - then nothing else happens
>
> What am I missing?

You need to give the baud rate too:

$ ser_filter -t 9000 /dev/ttyS0 38400

However, if you are debugging via RedBoot, it makes more sense to
connect GDB to the serial channel that you are not using for serial
testing and use ser_filter with the -n option.


--
Nick Garnett                                       eCos Kernel Architect
eCosCentric Limited    http://www.eCosCentric.com       The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.      Tel: [phone]
Registered in England and Wales:                         Reg No: 4422071


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss