Project - RS232 Gadgeteer <=> PC Round-n-Round (1)

[RoSchmi]

I just posted RS232 Gadgeteer <=> PC Round-n-Round (1) on Codeshare. Feel free to discuss and make suggestions here.

[dspacek]

I am using MF version 4.2 and Visual Studio 2010. Could you post a version compiled for this version of MF?

[RoSchmi]

This was copied from the thread:

https://www.ghielectronics.com/community/forum/topic?id=16336&page=4

@dspacek

I adapted your program for NETMF 4.2 and VS2010 by creating a new Gadgeteer project and inserting your code into it. I changed the baud rate to 115200, and the received data dropped a character after a few minutes. I see that it took longer to show the problem, 2061 messages, probably because there is nothing else for the cpu to do.

I send to PC: Hello from Gadgeteer to all other computers in the world. Message No. 02061

I received back from PC: ello from Gadgeteer to all other computers in the world. Message No. 02061

I changed two of your functions to save the last string transmitted in StringSent, so I can compare that with the string received in dataLine, and break when they are different.

        void mySerialReadManager_DataByteArrayReceived(SerialReadManager sender, byte[] data, int startIndex, int ByteCount)
        {
            MySerialBuffer.LoadSerial(data, 0, ByteCount);
            //Debug.Print("..");
            string dataLine = string.Empty;
            while ((dataLine = MySerialBuffer.ReadLine()) != null)
            {
                StringToSend = dataLine.Substring(0, dataLine.Length - 6);  // Take away the message number at the ent of the string
                StringMayBeSent = true;
                Debug.Print("I received back from PC: " + dataLine + "\r\n");
                if (StringSent.TrimEnd() != dataLine.TrimEnd())
                    Debug.Print("Sent string does not match received string");
                // parse the data sentence here if needed
            }
        }

        string StringSent;

        void timerSendData_Tick(GT.Timer timer)
        {
            if (StringMayBeSent)
            {
                StringSent = StringToSend + X_Stellig.Zahl(SendCounter.ToString(), 5) + "\r\n";
                SendData(StringSent);
                //SendData(StringToSend + X_Stellig.Zahl(SendCounter.ToString(), 5) + "\r\n");
                StringToSend = "";
                StringMayBeSent = false;
                SendCounter++;
            }
            else
            {
                //Debug.Print("Could not send");
            }
        }

@dspacek

I made the string longer, and the dropped character happened sooner.

I send to PC: Hello from Gadgeteer to all other computers in the world. Hello from Gadgeteer to all other computers in the world. Hello from Gadgeteer to all other computers in the world. Hello from Gadgeteer to all other computers in the world. Message No. 01903

I received back from PC: Hello from Gadgeteer to all other computers in the world. Hello from Gadgeteer to all other computers in the world. Hllo from Gadgeteer to all other computers in the world. Hello from Gadgeteer to all other computers in the world. Message No. 01903

@RoSchmi

I think that 115200 baud is a rather high baudrate to send over a cable of 1 meter or 2 meter lenght. I remember that when we had connected the terminals in our office to the server over RS232 (distance 10 to 20 meters) we had to use a Baudrate of 9600 (19200 was critiacal). I can imagine that with 115200 it can be a lack of sufficient electrical signal quality. I will try here with longer strings.

[RoSchmi]

Just tried with a longer string with a length of around 200 Byte at a Baudrate of 38400.
I stopped it at 17592 rounds (~ 3,5 MByte) with no data corruption.

[Dave_McLaughlin]

@RoSchmi

I think that 115200 baud is a rather high baudrate to send over a cable of 1 meter or 2 meter lenght. I remember that when we had connected the terminals in our office to the server over RS232 (distance 10 to 20 meters) we had to use a Baudrate of 9600 (19200 was critiacal). I can imagine that with 115200 it can be a lack of sufficient electrical signal quality. I will try here with longer strings.

[/quote]

With good cable you can get a reasonable distance with RS232. About 25 years ago (hell, it don’t feel like that long ago) we used to send survey data for a video overlay one way and ROV data the other and this was over a 100m cable from our control shack to the survey shack. We ran this at 9600 bps and never had any failures.

Mind you, in those days the driver IC’s had some clout and where powered from +12 and -12V real supplies and not the current, charge pump drivers of today’s devices.

[dspacek]

So you have demonstrated that a program dedicated to receiving serial port data, with nothing else to do, and a low enough baud rate, will not drop characters. My program has many other real time functions to perform, it has other devices to monitor on other serial ports, a KP16 keypad to scan, a touch screen, a temp/humidity sensor to monitor. Please answer me, what is wrong with having the CPU perform other tasks while waiting for serial port received data? Is there a hardware generated interrupt for received characters in the MF 4.2? If so, why does it matter if my program is performing many tasks? The interrupt service routine should buffer all received characters and not lose any.

[RoSchmi]

@ Dave McLaughlin -
Hi,
Yes, times are changing, my first serial interface (36 years ago) was to a teletype. 60 Volts, 75 bps I think. As these machines had no buffer the carriage return had to be performed as fast as the usual characters (need to cover the ears when nearby).
This little app is only intended to show that the firmware handles transmission without data corruption (at least in a program environment with no potentially interfering other threads). It was not intended to test the maximal possible datarate.

[dspacek]

Yes, you put your finger on my problem exactly - I have other threads. Why do they interfere with the serial port firmware? I have to have other threads, and they should not be a problem for the firmware causing it to lose data from the serial port hardware. It is not the data rate that is causing me problems. I can go at a lower baud rate, I tried. Even at 9600 baud, the serial port hands me messages with bytes missing. The problem is worse at lower buad rates. Is this acceptable to you? That a program for the serial port can do only one function, no other threads can run, and use only one serial port?

[Iggmoe]

@ dspacek - Does your application use Gadgeteer? And if so, maybe you can refactor it to use plain NETMF? I use serial heavily in tandem with monitoring/control functions. I have not encountered the issues that you are seeing, but maybe because I’ve always stuck with vanilla NETMF. I’ve heard Gadgeteer can be a resource hog, and that the Gadgeteer core simplifies/automates certain tasks in the background, possibly yielding unexpected results elsewhere.

[EDIT]
Also – what is expected data throughput (not just baud) of each of your 4 ports?

[dspacek]

Please, if you have any suggestions for me, any rules or guidelines to solve the dropped character problem, and yet have other threads doing things, and other serial ports in use ( I have four) please help.

[RoSchmi]

I see, I’m late with my answer.

@dspacek

Please answer me, what is wrong with having the CPU perform other tasks while waiting for serial port received data? If so, why does it matter if my program is performing many tasks?

We are agreed, there is nothing wrong. The CPU and firmware must satisfy these demands.
But there are still two possible reasons for the malfunction of your program (I mean: combination of your application, firmware and hardware).

1. faulty CPU-firmware-system,
2. not yet recognized bug in your application.
   My way to find the reason would be to start with a working serial port solution and add step by step the possibly interfering factors of your special application. I would not blame the CPU-firmware-system before a have set up a simple application in which there is no reasonable doubt that it should work and I find that it does not.

Is there a hardware generated interrupt for received characters in the MF 4.2?

I do not know so much about this. As far as I know these demands are handled in native code behind the scenes of NETMF. Each incoming character induces an interrupt and in the interrupt routine the byte is transferred into a FiFo-buffer from where the bytes can be read by the NETMF serialPort.Read() function. These functions must be so fast that no byte is missed. The scenario when the buffer is full, must be handled by “hardware” handshake but I’m quite sure that this does not play a role when a low datarate of 38400 baud is used and only short command and data messages are sent.

The interrupt service routine should buffer all received characters and not lose any

Yes.