[C#] Serial port leesprobleem

[m0h4life]

Hallo,

Voor school moeten we een project maken waarbij een microcontroller, in ons geval een stm32f051, gekoppeld moet worden aan een computer applicatie.
Wij hebben ervoor gekozen dat de microcontroller ongeveer 30keer per seconde informatie stuurt naar de computer en de computer leest dit dan ook 30 keer per seconde uit.
Nu werkte dit eerst goed, zal wel niet de mooiste oplossing zijn geweest maar het werkte. Echter is er nu iets veranderd waardoor die niet meer goed loopt waarvan ik geen idee heb wat er is veranderd en waarom (Helaas hebben we daarvoor geen versiebeheer gebruikt... )

Het probleem:
De C# applicatie leest de poort uit, de eerste keer komt daar het volgende uit: 1 50 50 0 0 0 100 200 4
Een totaal van 9 bytes dus waarbij de 1 en de 4 altijd vast moeten blijven.
Eerst schoof elk karakter steeds één plekje op, waardoor die als het ware begon te lopen.
Nu heb ik als aanpassing de verbinding gesloten na het uitlezen en vervolgens weer openen als die weer terug komt in de functie. Mijn setup zorgt ervoor dat die nog maar 15x per seconden wordt uitgelezen maar dat is opzich niet erg, erger is dat ik dan het volgende krijg, continu: 0 1 50 50 0 0 0 100 200
De laatste byte valt dus af en de eerste veranderd in een 0.

Ik had eraan gedacht om de thread even te laten slapen na het uitlezen van de seriele poort, hem te sluiten en weer te openen en om de in-buffer te discarden maar geen van dit heeft geholpen.

C#: Mainform

            
//Init USB-Port
usbPort.PortName = "COM3";
usbPort.BaudRate = 57600;
usbPort.Parity = System.IO.Ports.Parity.None;
usbPort.DataBits = 8;
usbPort.StopBits = System.IO.Ports.StopBits.One;
usbPort.WriteTimeout = 100;            
usbPort.ReadTimeout = 100;
        
private void ReadSerialBus()
{
    Thread.Sleep(5);
    if (usbPort.IsOpen)
    {
        try
        {
            usbPort.Read(Game.byteBuffer, 0, 8);
            if(Game.byteBuffer[0] != 1 && Game.byteBuffer[8] != 4)
            {
                MessageBox.Show("Buffer voor correctie:" + Game.byteBuffer[0].ToString() + "|" + Game.byteBuffer[1].ToString() + "|" + Game.byteBuffer[2].ToString() + "|" + Game.byteBuffer[3].ToString() + "|" + Game.byteBuffer[4].ToString() + "|" + Game.byteBuffer[5].ToString() + "|" + Game.byteBuffer[6].ToString() + "|" + Game.byteBuffer[7].ToString() + "|" + Game.byteBuffer[8].ToString());
                txtGameTexts.AppendText("Wacht tot buffer weer klopt. \n");
                while(Game.byteBuffer[0] != 1 && Game.byteBuffer[8] != 4)
                {
                    usbPort.Close();
                    usbPort.Open();
                    Thread.Sleep(50);
                    usbPort.Read(Game.byteBuffer, 0, 8);
                 }
                 MessageBox.Show("Buffer na correctie:" + Game.byteBuffer[0].ToString() + "|" + Game.byteBuffer[1].ToString() + "|" + Game.byteBuffer[2].ToString() + "|" + Game.byteBuffer[3].ToString() + "|" + Game.byteBuffer[4].ToString() + "|" + Game.byteBuffer[5].ToString() + "|" + Game.byteBuffer[6].ToString() + "|" + Game.byteBuffer[7].ToString() + "|" + Game.byteBuffer[8].ToString());
                 txtGameTexts.AppendText("Programma hervat. \n");
            }
            usbPort.Close();
         }
        catch (Exception e)
        {
            MessageBox.Show("Er is een probleem met de verbinding .\n+ e.ToString());
            usbPort.Close();
         }
     }
    else
    {
        try 
        {
             usbPort.Open();
        }
        catch(Exception e)
        {
             MessageBox.Show("Er is een probleem met de verbinding.\n" + e.ToString());
         }
   }
}

[Verwijderd]

Kijk eens naar parity en stop bits.
En gebruik versiebeheer.

[Verwijderd]

Zou het ook niet makkelijker zijn om dit te doen?

C#:

        private void ReadSerialBus()
        {
            try
            {
                usbPort.Open();
                if (usbPort.IsOpen)
                {
                    usbPort.Read(Game.byteBuffer, 0, 8);
                    if (Game.byteBuffer[0] != 1 && Game.byteBuffer[8] != 4)
                    {
                        MessageBox.Show("Buffer voor correctie:" + Game.byteBuffer[0].ToString() + "|" + Game.byteBuffer[1].ToString() + "|" + Game.byteBuffer[2].ToString() + "|" + Game.byteBuffer[3].ToString() + "|" + Game.byteBuffer[4].ToString() + "|" + Game.byteBuffer[5].ToString() + "|" + Game.byteBuffer[6].ToString() + "|" + Game.byteBuffer[7].ToString() + "|" + Game.byteBuffer[8].ToString());
                        txtGameTexts.AppendText("Wacht tot buffer weer klopt. \n");
                        while (Game.byteBuffer[0] != 1 && Game.byteBuffer[8] != 4)
                        {
                            usbPort.Close();
                            usbPort.Open();
                            Thread.Sleep(50);
                            usbPort.Read(Game.byteBuffer, 0, 8);
                        }
                        MessageBox.Show("Buffer na correctie:" + Game.byteBuffer[0].ToString() + "|" + Game.byteBuffer[1].ToString() + "|" + Game.byteBuffer[2].ToString() + "|" + Game.byteBuffer[3].ToString() + "|" + Game.byteBuffer[4].ToString() + "|" + Game.byteBuffer[5].ToString() + "|" + Game.byteBuffer[6].ToString() + "|" + Game.byteBuffer[7].ToString() + "|" + Game.byteBuffer[8].ToString());
                        txtGameTexts.AppendText("Programma hervat.\n");
                    }
                }
            }
            catch (Exception e)
            {
                MessageBox.Show("Er is een probleem met de verbinding .\n" + e.ToString());
            }
            finally
            {
                usbPort.Close();
            }
        }

[Radiant]

Je code is nu totaal afhankelijk van op welk moment het programma de seriele poort opent (zou net halverwege een bericht kunnen zijn). Als dat niet werkt clear je de buffers en probeer je het nog een keer op dezelfde manier.
Je zou ook gewoon kunnen door kunnen lezen tot je je startconditie weer ziet, dan weet je steeds zeker dat je gesynchroniseerd bent.

[farlane]

Houd je poort gewoon continu open en bekijk op applicatieniveau waar de frames beginnen en eindigen. Dus ook niet maar 8 characters lezen, maar alles wat aanwezig is en dan uitvogelen waar begin en eind is.

Overigens, wat voor een type converter heb je er aan zitten, iets met RS485?

[m0h4life]

Verwijderd schreef op dinsdag 09 juni 2015 @ 13:17:
Kijk eens naar parity en stop bits.
En gebruik versiebeheer.

We gebruiken geen parity bit maar wel een stopbit, echter lijkt dit mij geen probleem dat te maken is met een parity bit. Ik krijg namelijk wel de goede data binnen.

Radiant schreef op dinsdag 09 juni 2015 @ 13:42:
Je code is nu totaal afhankelijk van op welk moment het programma de seriele poort opent (zou net halverwege een bericht kunnen zijn). Als dat niet werkt clear je de buffers en probeer je het nog een keer op dezelfde manier.
Je zou ook gewoon kunnen door kunnen lezen tot je je startconditie weer ziet, dan weet je steeds zeker dat je gesynchroniseerd bent.

Daar had ik dit stuk al voor geschreven:

code:

if(Game.byteBuffer[0] != 1 && Game.byteBuffer[8] != 4)
            {
                MessageBox.Show("Buffer voor correctie:" + Game.byteBuffer[0].ToString() + "|" + Game.byteBuffer[1].ToString() + "|" + Game.byteBuffer[2].ToString() + "|" + Game.byteBuffer[3].ToString() + "|" + Game.byteBuffer[4].ToString() + "|" + Game.byteBuffer[5].ToString() + "|" + Game.byteBuffer[6].ToString() + "|" + Game.byteBuffer[7].ToString() + "|" + Game.byteBuffer[8].ToString());
                txtGameTexts.AppendText("Wacht tot buffer weer klopt. \n");
                while(Game.byteBuffer[0] != 1 && Game.byteBuffer[8] != 4)
                {
                    usbPort.Close();
                    usbPort.Open();
                    Thread.Sleep(50);
                    usbPort.Read(Game.byteBuffer, 0, 8);
                 }
                 MessageBox.Show("Buffer na correctie:" + Game.byteBuffer[0].ToString() + "|" + Game.byteBuffer[1].ToString() + "|" + Game.byteBuffer[2].ToString() + "|" + Game.byteBuffer[3].ToString() + "|" + Game.byteBuffer[4].ToString() + "|" + Game.byteBuffer[5].ToString() + "|" + Game.byteBuffer[6].ToString() + "|" + Game.byteBuffer[7].ToString() + "|" + Game.byteBuffer[8].ToString());
                 txtGameTexts.AppendText("Programma hervat. \n");
            }

Of bedoel je mogelijk wat anders?

farlane schreef op dinsdag 09 juni 2015 @ 13:52:
Houd je poort gewoon continu open en bekijk op applicatieniveau waar de frames beginnen en eindigen. Dus ook niet maar 8 characters lezen, maar alles wat aanwezig is en dan uitvogelen waar begin en eind is.
Overigens, wat voor een type converter heb je er aan zitten, iets met RS485?

De poort bleef eerst continu open, waarbij die hetzelfde probleem geeft. De eerste lezing is goed maar alle andere lezingen zijn dus met alle bytes één positie opgeschoven van de start conditie.
Ik gebruik een FT232 tijdens het testen maar heb ook een MCP2201 van microchip.
Het begin en het eind van de reeks zijn bekend en dat klopt ook, het uitlezen is helaas waar het fout gaat.

EDIT: Ik heb nu het openen van de poort verplaatst naar de init van het spel, dit lijkt te werken.
Ik heb nu al vijf keer de volle speeltijd kunnen doorgaan met het "spel" zonder dat de bytes verschuiven of rare waardes.

@mostrow Thanks, dat is inderdaad handiger ja . Geen idee waarom ik dat niet meteen gedaan heb.

[ Voor 5% gewijzigd door m0h4life op 09-06-2015 19:03 ]

[jeroen3]

Het is betrouwbaarder om het bericht wat je stuurt te voorzien van een header or delimiter.
Met ASCII (leesbare tekst) is dat makkelijk. Een regeleinde (0x10 of 0x13). Maar het lijkt erop dat je gewoon direct bytes stuurt. Om dat werkzaam te maken zul je een header toe moeten voegen. Bijvoorbeeld 0x55 0xAA.
Die specifieke combinatie zogt dan voor een sync van het protocol. Zoek in het buffer naar de eerste combinatie 0x55 0xAA, en daar begint je 1e frame van 8 bytes, dan komt er weer 0x55 0xAA.

Zo ben je niet afhankelijk van de synchronisatie van de stream. Je moet er natuurlijk wel rekening mee houden dat als je data ineens 0x55 0xAA bevat, je systeem in de war loopt. Daarom is ASCII vaak geprefereerd boven ruwe bytes. ASCII introduceert wel verliezen in bandbreedte en conversie tijd.

Echter kan je ook een checksum toevoegen om te controleren of het pakket klopt. Dat kan een simpele xor som zijn, maar ook een CRC. De stm32 heeft hardware CRC32, dus daar zijn geen langzame lussen nodig. Als je wilt kun je C++ code krijgen equivalent aan het functioneren van de hardware CRC32 in de stm32. Dat zou vrij eenvoudig moeten vertalen naar C#.

Alternatieve methode is een soortgelijke methode die CAN bus gebruikt voor error frames. Een onmogelijk correct aantal NULL bytes sturen. 9 in jouw geval, want het begin en eind van jouw data lijken altijd 1 en 4.
Bij 9 keer achtereenvolgend 0 weet je dat het eerstvolgende wat komt nuttige data is.

[ Voor 11% gewijzigd door jeroen3 op 09-06-2015 19:41 ]

[Verwijderd]

@mostrow Thanks, dat is inderdaad handiger ja . Geen idee waarom ik dat niet meteen gedaan heb.

Geen probleem natuurlijk, volgens mij blocked dit ook je stream totdat je deze wegklikt.
Volgens mij kun je beter een reporting mechanisme opzetten die de stream opneemt en dat je deze eventueel (via een debugging form?) naar voren haalt om de data te inspecteren?

Ik zag ook dat de SerialPort class een DataReceived event handler heeft, misschien deze gebruiken om je stream te inspecteren / in de gaten te houden en zonodig reset / cleared? (DiscardInBuffer / DiscardOutBuffer methods?)

Ik heb zelf helaas niet de gelegenheid / expertise om hier nog verder iets nuttigs aan toe te voegen, maar misschien is het wel leuk om daarmee eens te gaan spelen.

Succes!

[farlane]

Zo ben je niet afhankelijk van de synchronisatie van de stream. Je moet er natuurlijk wel rekening mee houden dat als je data ineens 0x55 0xAA bevat, je systeem in de war loopt. Daarom is ASCII vaak geprefereerd boven ruwe bytes

Omdat zoals je al aangeeft de payload ook je headerbytes kan bevatten wordt dit vaak niet gedaan, een goede checksum in je frame geeft voldoende zekerheid dat je het begin en eind van je frame te pakken hebt. Er zijn ook (vaak oudere) protocollen die een minder sterke checksum gebruiken maar die hebben weer voorzieningen voor het escapen van de delimiters in de payload.
Overigens kun je met een LUT een CRC implementatie bouwen die qua snelheid niet veel onder doet voor simpele checksums, dus er is eigenlijk geen reden om dat niet te doen.
Volgens mij ASCII helemaal niet geprefereerd, in ieder geval niet als je een generiek of enigzins efficient protocol wilt hebben.

Verwijderd schreef op dinsdag 09 juni 2015 @ 22:12:
[...]
Ik zag ook dat de SerialPort class een DataReceived event handler heeft, misschien deze gebruiken om je stream te inspecteren / in de gaten te houden en zonodig reset / cleared? (DiscardInBuffer / DiscardOutBuffer methods?)

Het DataReceived event (naast dat het niet heel betrouwbaar is) komt op een andere thread terug, dus dat zorgt weer voor heel andere uitdagingen.

[cedric_vb]

Ik heb ook problemen met het uitlezen van data.
De µC stuurt eerst "Ready, Set, " vervolgens na het lossen van een knop stuurt hij "GO! GO! GO!".
Dan na x aantal milliseconden wordt de knop weer ingedrukt stuurt hij het aantal milliseconden door.
Nu wil ik bij de status Ready, Set, de achtergrondkleur aanpassen naar geel, hierop geeft hij volgende fout bij lijn 53.

An unhandled exception of type 'System.InvalidOperationException' occurred in System.Windows.Forms.dll

Additional information: Cross-thread operation not valid: Control 'cmbNamen' accessed from a thread other than the thread it was created on.

Ik heb al dingen opgezocht over een andere thread aanspreken maar ik geraak er niet wijs uit weet iemand nog raad?

C#:

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Windows.Forms;
using System.IO.Ports;
using System.IO;
using System.Windows.Shapes;
using System.Windows.Media;

namespace Tiklplaat
{
    public partial class Tikplaat : Form
    {
        public Tikplaat()
        {
            InitializeComponent();
        }
        private void Tikplaat_Load(object sender, EventArgs e)
        {
            try
            {
                StreamReader sr = new StreamReader(@"D:\Users\Cedric\Desktop\Namen.txt");
                string Naam = sr.ReadLine();

                while (Naam != null)
                {
                    cmbNamen.Items.Add(Naam);
                    Naam = sr.ReadLine();
                }
            }
            catch (Exception ex)
            {
                MessageBox.Show("Error : " + ex.Message);
            }
        }
        private void serialPort1_DataReceived(object sender, System.IO.Ports.SerialDataReceivedEventArgs e)
        {
            string strData = serialPort1.ReadLine();
            VerwerkData(strData);

        }

        public void VerwerkData(string strData)
        {

            if (strData == "Ready, Set, ")
            {
                this.BackColor = System.Drawing.Color.Yellow;
            }
            else if (strData == "GO! GO! GO!")
            {

                this.BackColor = System.Drawing.Color.Green;
            }    
        }

        private void btnStop_Click(object sender, EventArgs e)
        {
            serialPort1.Close();
        }


    }
} 

[jeroen3]

serialPort1_DataReceived is een event die niet in de thread van je form plaatsvind.
MSDN: SerialPort.DataReceived Event (System.IO.Ports)

[Verwijderd]

Zoals Jeroen hierboven eigenlijk al aangeeft, het datareceived event komt van een andere thread.
Je mag geen threads (UI & Serialport) kruislings met elkaar laten communiceren zonder een delegate.

Er zijn een aantal oplossing hiervoor, waarvan deze één is:

C#:

private void serialPort1_DataReceived(object sender, System.IO.Ports.SerialDataReceivedEventArgs e)
{
    VerwerkData(serialPort1.ReadLine());
}

public void VerwerkData(string strData)
{
    if (this.InvokeRequired)
        this.Invoke(new Action<string>(VerwerkData), strData);
    else
    {
        if (strData == "Ready, Set, ") this.BackColor = System.Drawing.Color.Yellow;
        if (strData == "GO! GO! GO!") this.BackColor = System.Drawing.Color.Green;
    }
}

En nu ik ook zo de documentatie bekijk van MSDN waar Jeroen naar gelinkt had, staat het er ook bij vermeld dat je een Invoke moest doen als je UI thread controls wilt bijwerken.

[ Voor 10% gewijzigd door Verwijderd op 20-06-2015 13:40 ]

[farlane]

Verwijderd schreef op zaterdag 20 juni 2015 @ 12:53:

C#:

private void serialPort1_DataReceived(object sender, System.IO.Ports.SerialDataReceivedEventArgs e)
{
    VerwerkData(serialPort1.ReadLine());
}

Een beetje flauw misschien, maar dit gaat niet goed als er twee "lines" ontvangen zijn.

[Verwijderd]

Geen idee wat het effect zou zijn, volgens de documentatie leest de method tot aan een newline dus ik verwacht dat de buffer data na de newline genegeerd zal worden?

Ik heb geen ervaring verder met het uitlezen van data via serialport e.d.
Mijn gegeven suggestie ging voornamelijk over het oplossen van de cross thread exception.
Misschien een suggestie voor een relatief simpel apparaat waarmee ik kan spelen?

[Vuikie]

Alhoewel ik geen ervaring heb met C# zou ik dit probleem anders oplossen. Het grootste probleem met seriële communicatie is de traagheid en de asynchrone aard ervan. Wij gebruiken seriële communicatie met heel veel (embedded) apparaten en hier gebruiken wij zo goed als altijd de volgende opbouw:

Het bericht wordt altijd opgebouwd uit een header en een footer en het bericht bestaat uit een fixed lengte(Dit is het makkelijkst) of de lengte van het bericht staat in de header(Is wat lastiger, maar niet onoverkomelijk)

Wij lezen het systeem buffer continue uit en plaatsen dit in een soort RAW buffer waar wij continue op zoek gaan naar de header van het bericht. Dit moet wel een buffer zijn die groot genoeg is en een FIFO of ring buffer zijn.
Als de header gevonden is, dan zoeken we de footer op de opgegeven plek. Die plek kan of-wel uit de header worden gehaald, of dit staat gewoon vast waar deze zich moet bevinden.
Dit heeft als voordeel, dat het niet uitmaakt of je het bericht nu helemaal binnen hebt of niet en het ook niet uit maakt wat er nu in je bericht staat, je doet nog niks met de RAW buffer. Als je het bericht nu gevonden hebt, dan kopieer je deze naar een verwerk buffer en flush je de RAW buffer. Nu kan je weer op zoek gaan naar een nieuw bericht.

Dit 'verwerk buffer' is een statisch buffer en kan je een eventueel CRC of andere gegevens beveiliging uitrekenen(En dan uiteindelijk het bericht goedkeuren of alsnog afkeuren) en de gegevens uit je bericht vissen. Dit kan RAW, ASCII, UTF, enz... zijn.

Dit lijkt misschien heel omslachtig en inefficient, maar dit zorgt ervoor dat je communicatie geheel asynchroon kan verlopen en reduceert de kans op data verlies of verminkte data.

Ik hoop dat je hier wat aan hebt

[farlane]

Verwijderd schreef op zondag 21 juni 2015 @ 11:35:
Geen idee wat het effect zou zijn, volgens de documentatie leest de method tot aan een newline dus ik verwacht dat de buffer data na de newline genegeerd zal worden?

Klopt, dus de tweede die er mogelijk in staat verwerk je niet en een DataReceived event komt er ook niet meer

Anyways, in mijn ervaring is het robuuster om de poort te pollen en alles aan elkaar te plakken in een andere buffer; vervolgens kun je hier in zoeken om je frames er uit te halen.

[jeroen3]

Het werken met events in windows userland heeft weinig effect op de latency t.o.v. polling mbv van een timer.
Als je de serial datastream wil voorzien van timestamps dan zul je deze bij de bron al moeten toevoegen.

CAN-bus naar USB converters voegen altijd een timestamp toe omdat je geen betrouwbare timestamp kunt maken in Windows. Je kunt ook geen nauwkeurige delta-timestamps maken, zeker niet als je cpu 100% zit en je proces is "normal" ipv "realtime".

[farlane]

Wie heeft het over timestamps dan?

Anyways, je kunt wel timestamps toevoegen, maar ze zullen niet heel erg nauwkeurig zijn. Als je ze voor applicatie-level timeouts gebruikt zijn ze zeker heel nuttig : daar hoef je iha geen us naukeurige timing voor te hebben.