[ECOS] Re: Serial communications

[ECOS] Re: Serial communications

[Nick Garnett]

graham.labdon@cranems.co.uk writes:

> Hello Nick,
> Please forgive the direct approach but this issue has become a show
> stopper on my project.

I'm CC'ing this reply to the list, since it may be of use to others.
(Of course direct one-to-one consultancy is available, at a price.)


> As discussed in the forum I am unable to send more than ~128 bytes
> at time to my ecos program.  I am running this on the STM3210E dev
> kit and have tried testing it with minicom and an program of my own.
> I have tried reading the bytes as one block and reading the bytes
> individually.
> 
> within the ecos configuration tool I have set the serial buffer size
> to 512 and have changed the buffer size in stm32_serial.c
> 
> I have tried a variety of baud rates from 200 - 115200
> 
> Is there anything else I need to do?
> have you seen serial comms (not the ecos tests) working with data > 128 bytes?

The eCos test programs are a fairly good test of serial
functionality. That, after all, is what they were designed to do. Part
of these tests is to exchange varying sizes of data from a few bytes
to several K. These are all checked for integrity.

You may simply be suffering from the slowness of the external
SRAM. When you consider that you are fetching every instruction and
reading/writing all data over the same 16 bit external memory bus,
without any caches or prefetch buffers, then performance will not be
great. The STM32 is very much oriented to running code out of on-chip
flash.

You may need to switch to a ROM based application in order to get full
speed from the device. If you have a working RAM application,
switching to ROM startup should be easy. Of course a JTAG debugger
would make this very easy.

-- 
Nick Garnett                                       eCos Kernel Architect
eCosCentric Limited    http://www.eCosCentric.com       The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.      Tel: +44 1223 245571
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

Re: [ECOS] Serial communications

[grahamlab]

I decided to try and get the serial tests working but have run into some
problems - here is what I do

In a cmd window I type the command 'ser_filter -t 9000 /dev/ttyS0 38400'
this gives the following output - [b7cc18c0 Tu 07:33:38]
ConnectSocketToSerial : socket 3 <--> /dev/ttyS0 [b7cc18c0 Tu 07:33:38]
Applysettings baud=38400 bParity=0 stopbits=1 databits=8 [b7cc18c0 Tu
07:33:38] Changing configuration...
[b7cc18c0 Tu 07:33:38] Done.
[b7cc18c0 Tu 07:33:38] ConnectSocketToSerial: waiting for connection...

In another cmd window I type the command arm-eabi-gdb  -x gdb.init
../../DevBoard_install/tests/io/serial/v3_0/tests/serial3
At the gdb prompt I type the following commands set remotebaud 38400 set
remote memory-write-packet-size 64 target remote localhost:9000

The ser_filter program shows that a connection has been made - [b7cc18c0 Tu
07:43:12] Connection accepted from localhost - socket 5 [b7cc18c0 Tu
07:43:12] ConnectSocketToSerial: connected

At the gdb prompt I type 'c' but nothing further happens.

What am I doing wrong?

-- 
View this message in context: http://www.nabble.com/Re%3A-Serial-communications-tp24354870p24368135.html
Sent from the Sourceware - ecos-discuss mailing list archive at Nabble.com.


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

[ECOS] Re: Serial communications

[John Dallaway]

Hi Graham

grahamlab wrote:

> I decided to try and get the serial tests working but have run into some
> problems - here is what I do
> 
> In a cmd window I type the command 'ser_filter -t 9000 /dev/ttyS0 38400'
> this gives the following output - [b7cc18c0 Tu 07:33:38]
> ConnectSocketToSerial : socket 3 <--> /dev/ttyS0 [b7cc18c0 Tu 07:33:38]
> Applysettings baud=38400 bParity=0 stopbits=1 databits=8 [b7cc18c0 Tu
> 07:33:38] Changing configuration...
> [b7cc18c0 Tu 07:33:38] Done.
> [b7cc18c0 Tu 07:33:38] ConnectSocketToSerial: waiting for connection...
> 
> In another cmd window I type the command arm-eabi-gdb  -x gdb.init
> ../../DevBoard_install/tests/io/serial/v3_0/tests/serial3
> At the gdb prompt I type the following commands set remotebaud 38400 set
> remote memory-write-packet-size 64 target remote localhost:9000
> 
> The ser_filter program shows that a connection has been made - [b7cc18c0 Tu
> 07:43:12] Connection accepted from localhost - socket 5 [b7cc18c0 Tu
> 07:43:12] ConnectSocketToSerial: connected
> 
> At the gdb prompt I type 'c' but nothing further happens.
> 
> What am I doing wrong?

Assuming eCos is built for RAM startup, you will need to use the GDB
"load" command to download the test to your target:

  (gdb) target remote localhost:9000
  (gdb) load
  (gdb) continue

John Dallaway

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

Re: [ECOS] Serial communications

[grahamlab]

John Dallaway-2 wrote:
> 
> Hi Graham
> 
> grahamlab wrote:
> 
>> I decided to try and get the serial tests working but have run into some
>> problems - here is what I do
>> 
>> In a cmd window I type the command 'ser_filter -t 9000 /dev/ttyS0 38400'
>> this gives the following output - [b7cc18c0 Tu 07:33:38]
>> ConnectSocketToSerial : socket 3 <--> /dev/ttyS0 [b7cc18c0 Tu 07:33:38]
>> Applysettings baud=38400 bParity=0 stopbits=1 databits=8 [b7cc18c0 Tu
>> 07:33:38] Changing configuration...
>> [b7cc18c0 Tu 07:33:38] Done.
>> [b7cc18c0 Tu 07:33:38] ConnectSocketToSerial: waiting for connection...
>> 
>> In another cmd window I type the command arm-eabi-gdb  -x gdb.init
>> ../../DevBoard_install/tests/io/serial/v3_0/tests/serial3
>> At the gdb prompt I type the following commands set remotebaud 38400 set
>> remote memory-write-packet-size 64 target remote localhost:9000
>> 
>> The ser_filter program shows that a connection has been made - [b7cc18c0
>> Tu
>> 07:43:12] Connection accepted from localhost - socket 5 [b7cc18c0 Tu
>> 07:43:12] ConnectSocketToSerial: connected
>> 
>> At the gdb prompt I type 'c' but nothing further happens.
>> 
>> What am I doing wrong?
> 
> Assuming eCos is built for RAM startup, you will need to use the GDB
> "load" command to download the test to your target:
> 
>   (gdb) target remote localhost:9000
>   (gdb) load
>   (gdb) continue
> 
> John Dallaway
> 
> -- 
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
> 
> 
> 
When I use load I get the same result!!
-- 
View this message in context: http://www.nabble.com/Re%3A-Serial-communications-tp24354870p24369885.html
Sent from the Sourceware - ecos-discuss mailing list archive at Nabble.com.


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

Re: [ECOS] Serial communications

[Nick Garnett]

grahamlab <graham.labdon@cranems.co.uk> writes:

> I decided to try and get the serial tests working but have run into some
> problems - here is what I do
> 
> In a cmd window I type the command 'ser_filter -t 9000 /dev/ttyS0 38400'
> this gives the following output - [b7cc18c0 Tu 07:33:38]
> ConnectSocketToSerial : socket 3 <--> /dev/ttyS0 [b7cc18c0 Tu 07:33:38]
> Applysettings baud=38400 bParity=0 stopbits=1 databits=8 [b7cc18c0 Tu
> 07:33:38] Changing configuration...
> [b7cc18c0 Tu 07:33:38] Done.
> [b7cc18c0 Tu 07:33:38] ConnectSocketToSerial: waiting for connection...
> 
> In another cmd window I type the command arm-eabi-gdb  -x gdb.init
> ../../DevBoard_install/tests/io/serial/v3_0/tests/serial3
> At the gdb prompt I type the following commands set remotebaud 38400 set
> remote memory-write-packet-size 64 target remote localhost:9000
> 
> The ser_filter program shows that a connection has been made - [b7cc18c0 Tu
> 07:43:12] Connection accepted from localhost - socket 5 [b7cc18c0 Tu
> 07:43:12] ConnectSocketToSerial: connected
> 
> At the gdb prompt I type 'c' but nothing further happens.
> 
> What am I doing wrong?

OK, I've just tried this all out myself. Admittedly using a STM3210C
rather than an E board, but there should be no differences at this
level. I used the serial4 test built for RAM startup and I was running
from a SuSE 11.0 host system.

Appended are the trace from ser_filter and my entire GDB session. As
you can see, it all seems to be working for me. Take a look at these
and see if there is anything I'm doing that you are not, or vice
versa.

Note that the set remotebaud and set remote memory-write-packet-size
may not have much effect, I would leave them out.






$ ser_filter -t 1234 /dev/ttyUSB0 38400
[f7e2f6c0 Tu 11:04:39] ConnectSocketToSerial : socket 3 <--> /dev/ttyUSB0
[f7e2f6c0 Tu 11:04:39] Applysettings baud=38400 bParity=0 stopbits=1 databits=8
[f7e2f6c0 Tu 11:04:39] Changing configuration...
[f7e2f6c0 Tu 11:04:39] Done.
[f7e2f6c0 Tu 11:04:39] ConnectSocketToSerial: waiting for connection...
[f7e2f6c0 Tu 11:04:48] Connection accepted from localhost - socket 5
[f7e2f6c0 Tu 11:04:48] ConnectSocketToSerial: connected
[f7e2f6c0 Tu 11:05:22] Applysettings baud=38400 bParity=0 stopbits=1 databits=8
[f7e2f6c0 Tu 11:05:22] Changing configuration...
[f7e2f6c0 Tu 11:05:22] Done.
[f7e2f6c0 Tu 11:05:23] Applysettings baud=9600 bParity=0 stopbits=1 databits=8
[f7e2f6c0 Tu 11:05:23] Changing configuration...
[f7e2f6c0 Tu 11:05:23] Done.
[f7e2f6c0 Tu 11:05:23] Applysettings baud=38400 bParity=0 stopbits=1 databits=8
[f7e2f6c0 Tu 11:05:23] Changing configuration...
[f7e2f6c0 Tu 11:05:23] Done.
[f7e2f6c0 Tu 11:05:23] Applysettings baud=9600 bParity=0 stopbits=1 databits=8
[f7e2f6c0 Tu 11:05:23] Changing configuration...
[f7e2f6c0 Tu 11:05:23] Done.
[f7e2f6c0 Tu 11:05:25] Applysettings baud=14400 bParity=0 stopbits=1 databits=8
[f7e2f6c0 Tu 11:05:25] Applysettings baud=9600 bParity=0 stopbits=1 databits=8
[f7e2f6c0 Tu 11:05:25] Changing configuration...
[f7e2f6c0 Tu 11:05:25] Done.
[f7e2f6c0 Tu 11:05:26] Applysettings baud=19200 bParity=0 stopbits=1 databits=8
[f7e2f6c0 Tu 11:05:26] Changing configuration...
[f7e2f6c0 Tu 11:05:26] Done.
[f7e2f6c0 Tu 11:05:26] Applysettings baud=9600 bParity=0 stopbits=1 databits=8
[f7e2f6c0 Tu 11:05:26] Changing configuration...
[f7e2f6c0 Tu 11:05:26] Done.
[f7e2f6c0 Tu 11:05:26] Applysettings baud=19200 bParity=0 stopbits=1 databits=8
[f7e2f6c0 Tu 11:05:26] Changing configuration...
[f7e2f6c0 Tu 11:05:26] Done.
[f7e2f6c0 Tu 11:05:28] Applysettings baud=19200 bParity=1 stopbits=1 databits=8
[f7e2f6c0 Tu 11:05:28] Changing configuration...
[f7e2f6c0 Tu 11:05:28] Done.
[f7e2f6c0 Tu 11:05:28] Applysettings baud=19200 bParity=0 stopbits=1 databits=8
[f7e2f6c0 Tu 11:05:28] Changing configuration...
[f7e2f6c0 Tu 11:05:28] Done.
[f7e2f6c0 Tu 11:05:28] Applysettings baud=19200 bParity=1 stopbits=1 databits=8
[f7e2f6c0 Tu 11:05:28] Changing configuration...
[f7e2f6c0 Tu 11:05:28] Done.
[f7e2f6c0 Tu 11:05:29] Applysettings baud=19200 bParity=0 stopbits=1 databits=8
[f7e2f6c0 Tu 11:05:29] Changing configuration...
[f7e2f6c0 Tu 11:05:29] Done.
[f7e2f6c0 Tu 11:05:30] Applysettings baud=19200 bParity=1 stopbits=2 databits=8
[f7e2f6c0 Tu 11:05:30] Changing configuration...
[f7e2f6c0 Tu 11:05:30] Done.
[f7e2f6c0 Tu 11:05:30] Applysettings baud=19200 bParity=0 stopbits=1 databits=8
[f7e2f6c0 Tu 11:05:30] Changing configuration...
[f7e2f6c0 Tu 11:05:30] Done.
[f7e2f6c0 Tu 11:05:30] Applysettings baud=19200 bParity=1 stopbits=2 databits=8
[f7e2f6c0 Tu 11:05:30] Changing configuration...
[f7e2f6c0 Tu 11:05:30] Done.
[f7e2f6c0 Tu 11:05:31] Applysettings baud=19200 bParity=0 stopbits=1 databits=8
[f7e2f6c0 Tu 11:05:31] Changing configuration...
[f7e2f6c0 Tu 11:05:31] Done.
[f7e2f6c0 Tu 11:05:32] Applysettings baud=19200 bParity=0 stopbits=2 databits=8
[f7e2f6c0 Tu 11:05:32] Changing configuration...
[f7e2f6c0 Tu 11:05:32] Done.
[f7e2f6c0 Tu 11:05:32] Applysettings baud=19200 bParity=0 stopbits=1 databits=8
[f7e2f6c0 Tu 11:05:32] Changing configuration...
[f7e2f6c0 Tu 11:05:32] Done.
[f7e2f6c0 Tu 11:05:32] Applysettings baud=19200 bParity=0 stopbits=2 databits=8
[f7e2f6c0 Tu 11:05:32] Changing configuration...
[f7e2f6c0 Tu 11:05:32] Done.


GNU gdb (eCosCentric GNU tools 4.3.2a) 6.8.50.20080706
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-eabi".
For bug reporting instructions, please see:
<http://bugzilla.ecoscentric.com/>...
Redefine command "bdm"? (y or n) [answered Y; input not from terminal]
(gdb) target remote localhost:1234
Remote debugging using localhost:1234
0x800242e:	bx	lr
0x0800242e in ?? ()
(gdb) break cyg_test_exit 
Breakpoint 1 at 0x20003f34: file /home/nickg/local/ecos/ecoscentric_common/ecos/packages/infra/current/src/tcdiag.cxx, line 309.
(gdb) load
Loading section .rom_vectors, size 0x8 lma 0x20001000
Loading section .text, size 0x577c lma 0x20001008
Loading section .rodata, size 0x8ac lma 0x20006788
Loading section .data, size 0x2f0 lma 0x20007038
Start address 0x20001009, load size 25376
Transfer rate: 2 KB/sec, 295 bytes/write.
(gdb) c
Continuing.
INFO: <code from 0x20001008 -> 0x20006784, CRC b869>
INFO:<Serial device /dev/ser1>
[f] Dispatching command PING.
[f] Command PING completed.
INFO:<CONFIG:15:8:1:0:0!>
[f] Dispatching command CONFIG.
[f] Parsed Config baud=9600, bParity=0, stopbits=0, databits=8
[f] Parsed Config xonxoff_rx=0,tx=0, rtscts_rx=0,tx=0, dsrdtr_rx=0,tx=0
[f] Config change succeeded.
[f] Command CONFIG completed.
INFO:<BINARY:128:1!>
[f] Dispatching command BINARY.
[f] Finished write, waiting for target echo.
[f] Command BINARY completed.
PASS:<Binary test completed>
INFO:<BINARY:256:0!>
[f] Dispatching command BINARY.
[f] Command BINARY completed.
PASS:<Binary test completed>
INFO:<CONFIG:16:8:1:0:0!>
[f] Dispatching command CONFIG.
[f] Parsed Config baud=14400, bParity=0, stopbits=0, databits=8
[f] Parsed Config xonxoff_rx=0,tx=0, rtscts_rx=0,tx=0, dsrdtr_rx=0,tx=0
[f] Command CONFIG completed.
INFO:<CONFIG:16:8:1:0:0!- skipped by host!>
Host didn't accept config (45, 52).
INFO:<CONFIG:17:8:1:0:0!>
[f] Dispatching command CONFIG.
[f] Parsed Config baud=19200, bParity=0, stopbits=0, databits=8
[f] Parsed Config xonxoff_rx=0,tx=0, rtscts_rx=0,tx=0, dsrdtr_rx=0,tx=0
[f] Config change succeeded.
[f] Command CONFIG completed.
INFO:<BINARY:128:1!>
[f] Dispatching command BINARY.
[f] Finished write, waiting for target echo.
[f] Command BINARY completed.
PASS:<Binary test completed>
INFO:<BINARY:256:0!>
[f] Dispatching command BINARY.
[f] Command BINARY completed.
PASS:<Binary test completed>
INFO:<CONFIG:17:8:1:1:0!>
[f] Dispatching command CONFIG.
[f] Parsed Config baud=19200, bParity=1, stopbits=0, databits=8
[f] Parsed Config xonxoff_rx=0,tx=0, rtscts_rx=0,tx=0, dsrdtr_rx=0,tx=0
[f] Config change succeeded.
[f] Command CONFIG completed.
INFO:<CONFIG:17:8:3:1:0!>
[f] Dispatching command CONFIG.
[f] Parsed Config baud=19200, bParity=1, stopbits=2, databits=8
[f] Parsed Config xonxoff_rx=0,tx=0, rtscts_rx=0,tx=0, dsrdtr_rx=0,tx=0
[f] Config change succeeded.
[f] Command CONFIG completed.
INFO:<CONFIG:17:8:3:0:0!>
[f] Dispatching command CONFIG.
[f] Parsed Config baud=19200, bParity=0, stopbits=2, databits=8
[f] Parsed Config xonxoff_rx=0,tx=0, rtscts_rx=0,tx=0, dsrdtr_rx=0,tx=0
[f] Config change succeeded.
[f] Command CONFIG completed.
INFO:<BINARY:128:1!>
[f] Dispatching command BINARY.
[f] Finished write, waiting for target echo.
[f] Command BINARY completed.
PASS:<Binary test completed>
INFO:<BINARY:256:0!>
[f] Dispatching command BINARY.
[f] Command BINARY completed.
PASS:<Binary test completed>
PASS:<serial4 test OK>
EXIT:<done>
[Switching to Thread 2]
0x20003f34 <cyg_test_exit>:	ldr.w	lr, [pc, #72]	; 0x20003f80 <cyg_test_exit+76>
Current language:  auto; currently c++

Breakpoint 1, cyg_test_exit () at /home/nickg/local/ecos/ecoscentric_common/ecos/packages/infra/current/src/tcdiag.cxx:309
(gdb) 


-- 
Nick Garnett                                       eCos Kernel Architect
eCosCentric Limited    http://www.eCosCentric.com       The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.      Tel: +44 1223 245571
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

Re: [ECOS] Serial communications

[grahamlab]

Well I have some improvement - it ran a test but FAILED! - here is what I
got
ser_filter output
[b7d558c0 Tu 11:55:22] CeCosTestPlatform::Load
[b7d558c0 Tu 11:55:22] CeCosTestPlatform::LoadFromDir
/home/graham/.eCosPlatforms
[b7d558c0 Tu 11:55:22] ConnectSocketToSerial : socket 3 <--> /dev/ttyS0
[b7d558c0 Tu 11:55:23] Applysettings baud=38400 bParity=0 stopbits=1
databits=8
[b7d558c0 Tu 11:55:23] Changing configuration...
[b7d558c0 Tu 11:55:23] Done.
[b7d558c0 Tu 11:55:23] ConnectSocketToSerial: waiting for connection...
[b7d558c0 Tu 11:57:20] Connection accepted from localhost - socket 5
[b7d558c0 Tu 11:57:20] ConnectSocketToSerial: connected
[b7d558c0 Tu 11:58:31] Applysettings baud=38400 bParity=0 stopbits=1
databits=8
[b7d558c0 Tu 11:58:31] Changing configuration...
[b7d558c0 Tu 11:58:31] Done.
[b7d558c0 Tu 11:58:32] Applysettings baud=9600 bParity=0 stopbits=1
databits=8
[b7d558c0 Tu 11:58:32] Changing configuration...
[b7d558c0 Tu 11:58:32] Done.
[b7d558c0 Tu 11:58:32] Applysettings baud=38400 bParity=0 stopbits=1
databits=8
[b7d558c0 Tu 11:58:32] Changing configuration...
[b7d558c0 Tu 11:58:32] Done.
[b7d558c0 Tu 11:58:32] Applysettings baud=9600 bParity=0 stopbits=1
databits=8
[b7d558c0 Tu 11:58:32] Changing configuration...
[b7d558c0 Tu 11:58:32] Done.
[b7d558c0 Tu 11:58:36] SSRead socket error - Read operation after socket
closed
[b7d558c0 Tu 11:58:36] ConnectSocketToSerial : done
[b7d558c0 Tu 11:58:36] ConnectSocketToSerial : socket 3 <--> /dev/ttyS0
[b7d558c0 Tu 11:58:36] Applysettings baud=38400 bParity=0 stopbits=1
databits=8
[b7d558c0 Tu 11:58:36] Changing configuration...
[b7d558c0 Tu 11:58:36] Done.
[b7d558c0 Tu 11:58:36] ConnectSocketToSerial: waiting for connection...

and the gdb output
(gdb) load
Loading section .rom_vectors, size 0x8 lma 0x68008000
Loading section .ARM.exidx, size 0x10 lma 0x68008008
Loading section .text, size 0x5e2c lma 0x68008018
Loading section .rodata, size 0x624 lma 0x6800de48
Loading section .data, size 0x3f4 lma 0x6800e478
Start address 0x68008019, load size 26716
Transfer rate: 445 bytes/sec, 31 bytes/write.
(gdb) c
Continuing.
[f] Dispatching command PING.
[f] Command PING completed.
INFO:<CONFIG:15:8:1:0:0!>
[f] Dispatching command CONFIG.
[f] Parsed Config baud=9600, bParity=0, stopbits=0, databits=8
[f] Parsed Config xonxoff_rx=0,tx=0, rtscts_rx=0,tx=0, dsrdtr_rx=0,tx=0
[f] Config change succeeded.
[f] Command CONFIG completed.
INFO:<BINARY:128:1!>
[f] Dispatching command BINARY.
[f] Finished write, waiting for target echo.
[f] Command BINARY completed.
PASS:<Binary test completed>
INFO:<BINARY:256:0!>
[f] Dispatching command BINARY.
FAIL:<target timed out>
[f] **** Timed out while reading -- resuming as null filter
[f] Data received 0 bytes (of 4) from target:
[f] <end>

Program terminated with signal 0, Signal 0.
The program no longer exists.
(gdb) 

This looks like my original problem!!

-- 
View this message in context: http://www.nabble.com/Re%3A-Serial-communications-tp24354870p24371241.html
Sent from the Sourceware - ecos-discuss mailing list archive at Nabble.com.


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

Re: [ECOS] Serial communications

[grahamlab]

As per Nick's last suggestion I dropped the baud rate to 1200 - still no joy
I added some diag_printf to the serial driver ISR to catch any status bits
that might be set  -they are not.

When I run serial3 it successfully receives 16 and 128 bytes. When 256 bytes
are requested I am geting a timeout.

There must be a reason for this!!!

Please can anyone suggest something else

Graham
-- 
View this message in context: http://www.nabble.com/Re%3A-Serial-communications-tp24354870p24377163.html
Sent from the Sourceware - ecos-discuss mailing list archive at Nabble.com.


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

Re: [ECOS] Serial communications

[Daniel Morris]

On Tue, Jul 07, 2009 at 09:46:19AM -0700, grahamlab wrote:
> 
> 
> As per Nick's last suggestion I dropped the baud rate to 1200 - still no joy
> I added some diag_printf to the serial driver ISR to catch any status bits
> that might be set  -they are not.
> 
> When I run serial3 it successfully receives 16 and 128 bytes. When 256 bytes
> are requested I am geting a timeout.
> 
> There must be a reason for this!!!

Bad board? Bad cable? Bad serial port? Can you take a few steps back and
try to eliminate any changes or customisations you've made and run on a
vanilla evaluation board? 

 Daniel


%<----------------------------------------------------------------------
  Daniel Morris - Sales & Marketing Director
  eCosCentric - The eCos and RedBoot experts
  Tel: +44 1223 245 571 - info@eCosCentric.com
  DDI: +44 1269 591 171 - danielm@eCosCentric.com


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

Re: [ECOS] Serial communications

[grahamlab]

I have tried a variety of cables and tried a clean build of ecos - all lead
to the same result

-- 
View this message in context: http://www.nabble.com/Re%3A-Serial-communications-tp24354870p24388705.html
Sent from the Sourceware - ecos-discuss mailing list archive at Nabble.com.


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

Re: [ECOS] Serial communications

[Sergei Gavrikov]

On Wed, Jul 08, 2009 at 03:05:06AM -0700, grahamlab wrote:
> 
> I have tried a variety of cables and tried a clean build of ecos - all lead
> to the same result

Hi

Graham, I remember that in a past you had reported that your eCos
environment was Linux is running on some sort of a virtual machine.
What do you use today? What is your environment? Do you use virtual
serial ports still? Sorry, if I missed the answers.

Sergei

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

Re: [ECOS] Serial communications

[grahamlab]

Sergei Gavrikov-4 wrote:
> 
> On Wed, Jul 08, 2009 at 03:05:06AM -0700, grahamlab wrote:
>> 
>> I have tried a variety of cables and tried a clean build of ecos - all
>> lead
>> to the same result
> 
> Hi
> 
> Graham, I remember that in a past you had reported that your eCos
> environment was Linux is running on some sort of a virtual machine.
> What do you use today? What is your environment? Do you use virtual
> serial ports still? Sorry, if I missed the answers.
> 
> Sergei
> 
> -- 
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
> 
> 
> 
Hello Sergei
I run Sun Virtual box on a lap top and have USB to serial converters.
I have tried the serial tests via an environment with 'real' serial ports
and get the same results.
It seems to me that the when sending lots of bytes some are missed by the
serial device driver  -I dont know why this happens as Nick can run with no
problem.
Do you have any ideas I can try?

Graham
-- 
View this message in context: http://www.nabble.com/Re%3A-Serial-communications-tp24354870p24389918.html
Sent from the Sourceware - ecos-discuss mailing list archive at Nabble.com.


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

Re: [ECOS] Serial communications

[Sergei Gavrikov]

On Wed, Jul 08, 2009 at 04:41:31AM -0700, grahamlab wrote:
> I run Sun Virtual box on a lap top and have USB to serial converters.
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

IMO, it can be an issue: virtual comms + FTDI USB-serial driver. Your
environment is the very virtual thing :-(

> I have tried the serial tests via an environment with 'real' serial ports
> and get the same results.
> It seems to me that the when sending lots of bytes some are missed by the
> serial device driver  -I dont know why this happens as Nick can run with no
> problem.
> Do you have any ideas I can try?

Yet another thought. Do you noticed the sporadic resets on the boards?
Does your Laptop's USB port give 500 mA? I thought if your board get a
power supply from USB..., it can be yet another "under-water stone".
If your noticed the resets, try to use self-powered hub
http://en.wikipedia.org/wiki/Usb_hub

But, that is my guess only.

Sergei

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

Re: [ECOS] Serial communications

[grahamlab]

Sergei Gavrikov-4 wrote:
> 
> On Wed, Jul 08, 2009 at 04:41:31AM -0700, grahamlab wrote:
>> I run Sun Virtual box on a lap top and have USB to serial converters.
>         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> IMO, it can be an issue: virtual comms + FTDI USB-serial driver. Your
> environment is the very virtual thing :-(
> 
>> I have tried the serial tests via an environment with 'real' serial ports
>> and get the same results.
>> It seems to me that the when sending lots of bytes some are missed by the
>> serial device driver  -I dont know why this happens as Nick can run with
>> no
>> problem.
>> Do you have any ideas I can try?
> 
> Yet another thought. Do you noticed the sporadic resets on the boards?
> Does your Laptop's USB port give 500 mA? I thought if your board get a
> power supply from USB..., it can be yet another "under-water stone".
> If your noticed the resets, try to use self-powered hub
> http://en.wikipedia.org/wiki/Usb_hub
> 
> But, that is my guess only.
> 
> Sergei
> 
> -- 
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
> 
> 
> 
The board does not reset and has an indepedant power supply
-- 
View this message in context: http://www.nabble.com/Re%3A-Serial-communications-tp24354870p24391031.html
Sent from the Sourceware - ecos-discuss mailing list archive at Nabble.com.


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

RE: [ECOS] Serial communications

[Paul D. DeRocco]

> From: grahamlab
>
> The board does not reset and has an indepedant power supply

Do you have another identical board lying around? If so, try it. Hardware
occasionally does fail.

Beyond that, I think I would be looking for evidence that the system is
freezing momentarily. A scope can be helpful for this, especially if you
populate your code with things that pulse various unused port pins at
various points. That's generally better than diagnostic output, because it
takes nearly zero time.

Basically, though, this sounds like it needs hands-on debugging, not
speculation by other people. You may need to write your own tests. Heck, in
the end, you may need to write your own serial driver.

--

Ciao,               Paul D. DeRocco
Paul                mailto:pderocco@ix.netcom.com


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

RE: [ECOS] Serial communications

[grahamlab]

Paul D. DeRocco wrote:
> 
>> From: grahamlab
>>
>> The board does not reset and has an indepedant power supply
> 
> Do you have another identical board lying around? If so, try it. Hardware
> occasionally does fail.
> 
> Beyond that, I think I would be looking for evidence that the system is
> freezing momentarily. A scope can be helpful for this, especially if you
> populate your code with things that pulse various unused port pins at
> various points. That's generally better than diagnostic output, because it
> takes nearly zero time.
> 
> Basically, though, this sounds like it needs hands-on debugging, not
> speculation by other people. You may need to write your own tests. Heck,
> in
> the end, you may need to write your own serial driver.
> 
> --
> 
> Ciao,               Paul D. DeRocco
> Paul                mailto:pderocco@ix.netcom.com
> 
> 
> -- 
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
> 
> 
> 
Would someone please tell me how often the Serial_ISR and Serial_DSR
functions get called
Thanks
-- 
View this message in context: http://www.nabble.com/Re%3A-Serial-communications-tp24354870p24405660.html
Sent from the Sourceware - ecos-discuss mailing list archive at Nabble.com.


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

Re: [ECOS] Serial communications

[Nick Garnett]

grahamlab <graham.labdon@cranems.co.uk> writes:

> Would someone please tell me how often the Serial_ISR and Serial_DSR
> functions get called
> Thanks

Essentially once per character, there are no FIFOs so the ISR has to
get each byte out of the receive register before the next arrives. If
the ISR is sufficiently delayed it might be able to fetch two
characters from the device if it happens to run at exactly the right
time. The DSR will be scheduled every time a character is put into the
rx buffer. The DSRs might also be delayed, so when it runs it might
find several interrupts have happened and there are several characters
in the rx buffer. It will then deal with all of those before
returning. The purpose of the rx buffer is to decouple the DSR from
the actual hardware, so only ISR latency actually matters.

However, unless you are seeing any of the status error bits I
mentioned being set, or the rx buffer is overflowing, I don't think
that the problem lies in the latency of the ISR or DSR. I believe you
also tried reducing your baud rate to 1200, where the ISR has a
luxurious 8ms to respond, and it still failed. So I cannot see that
the problem is in either the serial device or the driver. 

You mentioned that you were using Linux in VirtualBox with USB serial
convertors. When you tried running with real serial devices, was this
also using VirtualBox? If so I know where I am tempted to point the
finger. Are you able to run Linux on a real machine, or use a Windows
based terminal emulator for your testing?

-- 
Nick Garnett                                       eCos Kernel Architect
eCosCentric Limited    http://www.eCosCentric.com       The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.      Tel: +44 1223 245571
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

Re: [ECOS] Serial communications

[grahamlab]

Thanks for the info Nick

Well I got an old PC with 2 serial ports and loaded Linux.

LOW and BEHOLD it worked


-- 
View this message in context: http://www.nabble.com/Re%3A-Serial-communications-tp24354870p24425136.html
Sent from the Sourceware - ecos-discuss mailing list archive at Nabble.com.


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

Re: [ECOS] Serial communications

[Sergei Gavrikov]

On Fri, Jul 10, 2009 at 03:43:02AM -0700, grahamlab wrote:
> Well I got an old PC with 2 serial ports and loaded Linux.
> 
> LOW and BEHOLD it worked

It is just interesting, and what the issue was in? Were those virtual
serial ports or USB-to-Serial converters, or ... even all together?  If
your old PC has NIC, use remote shell client on laptop (telnet, ssh) to
interact with GDB on Linux box. IMO, old PC under a desk with the real
serial ports + Linux can be a better choice than laptop + usb-serial
convertors + cygwin.

Sergei

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

Re: [ECOS] Serial communications

[Nick Garnett]

grahamlab <graham.labdon@cranems.co.uk> writes:

> Thanks for the info Nick
> 
> Well I got an old PC with 2 serial ports and loaded Linux.
> 
> LOW and BEHOLD it worked

While I appeciate this has all been a PITA for you, I cannot help
feeling relieved that this was not a problem with the STM32 serial
drivers itself :-/

If nothing else, this has provided a useful pointer to why things
might not be working for others in the future. Virtual environments
are becoming more common, but it is clear that they leave something to
be desired in the area of real time behaviour (as one would expect, to
be fair).

-- 
Nick Garnett                                       eCos Kernel Architect
eCosCentric Limited    http://www.eCosCentric.com       The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.      Tel: +44 1223 245571
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

Re: [ECOS] Serial communications

[grahamlab]

Nick Garnett wrote:
> 
> grahamlab <graham.labdon@cranems.co.uk> writes:
> 
>> Thanks for the info Nick
>> 
>> Well I got an old PC with 2 serial ports and loaded Linux.
>> 
>> LOW and BEHOLD it worked
> 
> While I appeciate this has all been a PITA for you, I cannot help
> feeling relieved that this was not a problem with the STM32 serial
> drivers itself :-/
> 
> If nothing else, this has provided a useful pointer to why things
> might not be working for others in the future. Virtual environments
> are becoming more common, but it is clear that they leave something to
> be desired in the area of real time behaviour (as one would expect, to
> be fair).
> 
> -- 
> Nick Garnett                                       eCos Kernel Architect
> eCosCentric Limited    http://www.eCosCentric.com       The eCos experts
> Barnwell House, Barnwell Drive, Cambridge, UK.      Tel: +44 1223 245571
> 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
> 
> 
> 
Thanks for the advice given, if nothin else I have learnt alot!!
I have just started another thread -I am trying to get cygwin working but
when I execute the arm-eabi-gdb command I get returned to the command prompt
immediately
any ideas?

-- 
View this message in context: http://www.nabble.com/Re%3A-Serial-communications-tp24354870p24427037.html
Sent from the Sourceware - ecos-discuss mailing list archive at Nabble.com.


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

Re: [ECOS] Serial communications

[Nick Garnett]

grahamlab <graham.labdon@cranems.co.uk> writes:

> Thanks for the advice given, if nothin else I have learnt alot!!
> I have just started another thread -I am trying to get cygwin working but
> when I execute the arm-eabi-gdb command I get returned to the command prompt
> immediately
> any ideas?

I'm afraid that is one area I have little experience of. I do all my
work under (real!) Linux, and try to stay as far away from Windows and
Cygwin as possible.

John has already responded in that thread, and he is the best person
to try and sort out your problem.

-- 
Nick Garnett                                       eCos Kernel Architect
eCosCentric Limited    http://www.eCosCentric.com       The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.      Tel: +44 1223 245571
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

Re: [ECOS] Serial communications

[Bessemer]

On Fri, Jul 10, 2009 at 1:31 PM, Nick Garnett<nickg@ecoscentric.com> wrote:
> While I appeciate this has all been a PITA for you, I cannot help
> feeling relieved that this was not a problem with the STM32 serial
> drivers itself :-/
This is still a bit unsatisfactory though; presumably the makers of
your USB-to-serial device have tested it extensively so are we saying
that the STM32 serial driver depends on some aspect of RS232 comms
hardware that we don't really understand?

B.

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