Page 1 of 2

win32: simulated IO issue?

Posted: Tue Mar 04, 2014 4:55 am
by russian
I have recently discovered the magic of win32 ChibiOS port and I was hoping to use it for functional testing of my project.
Unfortunately I am having some weirdness with I-O which I am able to reproduce even with ch.exe - the Win32 demo:

connect to ch.exe via putty, paste a magic line into putty:

Code: Select all

q1q2q3q4q5w1w2w3w4w5r1r2r3r4r5t1t2t3t4t5y1y2y3y4y5

but on the screen you get

Code: Select all

q1q2q3q4q5w1w2w3t2t3t4t5y1y2y3y4 ?

The problem is not that the line is truncated, it has some of the characters missing! After 'w3' I am expecting to see 'w4' but I get 't2'? The whole 'r1' section is missing!!
Here is a screenshot:
Image

I am using 2.6.3, I am compiling with cygwin toolchain - I had to change one line in the Makefile and add winsock import into serial.h to get this compile.

As a reference, here is the same magic line sent into stm32f4-discovery-mems demo:
Image
On this screenshot you see that the whole line is there, it is not truncated and nothing is missing.

Please confirm that I am not crazy :)

Re: win32: simulated IO issue?

Posted: Tue Mar 04, 2014 9:09 am
by Giovanni
Hi,

It is just that the shell has an hard limit for input lines, 64 bytes if I remember well. After the limit the line is processed.

Giovanni

Re: win32: simulated IO issue?

Posted: Tue Mar 04, 2014 1:34 pm
by russian
The problem is not that the line is truncated, it has some of the characters missing! After 'w3' I am expecting to see 'w4' but I get 't2'? The whole 'r1' section is missing!!

This works one way with stm32f4 and anther way with win32? Different buffer size?

Also, my magic line is 50 characters long.

Re: win32: simulated IO issue?

Posted: Tue Mar 04, 2014 4:11 pm
by russian
I've tried to investigate and here are my first findings:

original code of Win32/serial_lld.c is

Code: Select all

static bool_t inint(SerialDriver *sdp) {

  if (sdp->com_data != INVALID_SOCKET) {
    int i;
    uint8_t data[32];


    /*
     * Input.
     */
    int n = recv(sdp->com_data, data, sizeof(data), 0);


Here is an interesting observation: if I REDUCE this socket read buffer, I get DIFFERENT results - at least the bytes are not missing. The red is a picture with original ChibiOS code, the green is with REDUCED socket read buffer:

Image

Image

I am sorry but this does not look right at all. I would be happy to see a truncated message in Shell, but I need reliable IO which does not take random bytes out.

Re: win32: simulated IO issue?

Posted: Tue Mar 04, 2014 8:23 pm
by Giovanni
This looks like some error in the simulated I/O, I will add this to the TODO list, not an high priority however.

Giovanni

Re: win32: simulated IO issue?

Posted: Tue Mar 04, 2014 8:30 pm
by russian
Giovanni wrote:not an high priority however.

This is understandable.

Do you want me to create a defect in SF tracker so that there is a ticket to track this issue?

Re: win32: simulated IO issue?

Posted: Tue Mar 04, 2014 8:43 pm
by Giovanni
Sure, create it. Just put a link here as documentation.

Giovanni

Re: win32: simulated IO issue?

Posted: Tue Mar 04, 2014 9:38 pm
by russian
https://sourceforge.net/p/chibios/bugs/468/

Also here is funny observation: in the q1q2q3q4q5w1w2w3t2t3t4t5y1y2y3y4 line it looks like we have 16 characters, then exactly 16 characters are missing and then the transfer resumes. This must mean something :)

Re: win32: simulated IO issue?

Posted: Tue Mar 04, 2014 9:42 pm
by Giovanni
Probably this is related to sockets being able to fill the input queue faster than the simulated ChibiOS application is able to consume, the result is the lost data.
You may try increasing the queue size in halconf.h.

Giovanni

Re: win32: simulated IO issue?

Posted: Tue Mar 04, 2014 9:49 pm
by theShed
Exacly the same thing happens with the POSIX (Linux) version.

Try changing the serial buffer size in the apps halconf.h to match the serial_lld buffer size
#define SERIAL_BUFFERS_SIZE 32
That seems to fix the Linux build.

I suspect that the input queue buffer is overflowing when it tries to jam 32 bytes into a 16 byte buffer.
Giovanni will have a better understanding of exactly what happens....

--
mike