C# Serialport.Write()

[Jan L. (jan_l)]

Hey
also ich benutze die serialport.write Methode um befehle an mein Board 
zu senden (via bluetooth) und im zb. mitzuteilen, das er doch bitte 
Beschleunigungsdaten senden soll.

if (accelCheck.Checked)                         
                sPort.Write("a");
            else if (!(accelCheck.Checked))
                sPort.Write("A");

if (rot_mat_Check.Checked)                         
                sPort.Write("r");
            else if (!(accelCheck.Checked))
                sPort.Write("R");

das sieht dann in etwa so aus.
Wenn ich beide Aktiviert habe, kommt leider manchmal nur einer der 
beiden Werte an. Ich kann auch keine regelmäßigkeit feststellen...
D.h. manchmal passiert es schon beim ersten Durchlauf manchmal aber auch 
erst bei 4. Aber kommen tut der Fehler irgendwann.

Ausser, ja ausser ich setzte Breakpoints genau auf die sPort.Write()'s. 
Naja das sagt mir ja schonmal das es wohl irgendwas mit der Zeit zutun 
hat. Also habe ich nach jedem sPort.Write() ein sleep von 50ms gesetzt 
leider keine Verbesserung.

Kennt ihr das Problem vielleicht? oder wisst ihr was da los ist?

[Peter II (Gast)]

das Problem würde ich mehr beim empfangen suchen, beim senden kann da 
nicht schief gehen. Hast du beachtet das c# mit unicode arbeitet? Ich 
bin mir nicht sicher was er wirklihc sendet wenn man mit Strings 
arbeiten (richtig codierung einschalten!).

[Jan L. (jan_l)]

also er sendet alles und auch richtig, ich lasses mir momentan auf der 
"boardseite" noch ausgeben.

und wenn ich die breakpoints rein setzte gibt er mir ja auch ohne 
probleme die daten richtig aus...

Das heist senden un empfangen klappt nur hat er wahrscheinlich irgendwo 
ein problem mit der geschwindigkeit sonst würde es ja beim debuggen auch 
nicht funktionieren....

[Peter II (Gast)]

Jan L. schrieb:
> Das heist senden un empfangen klappt nur hat er wahrscheinlich irgendwo
> ein problem mit der geschwindigkeit sonst würde es ja beim debuggen auch
> nicht funktionieren....

Beim senden kann es aber kein timing Problem gehen, nur beim empfangen. 
Wenn du dort nicht sauber mit puffern arbeitest.

[Jan L. (jan_l)]

ja dann kanns sicher daran liegen das ich beim empfangen garnicht mit 
puffern arbeite...

werd mal schaun was ich da machen kann :P

[Jonas B. (jibi)]

Und achte darauf einen eigenen Thread zum Empfangen der Daten zu starten 
- ansosnten stoppt der Empfang sporadisch wenn du deien Gui bedienst.

Gruß Jonas

[Jan L. (jan_l)]

meinst du den empfang von den sonsor daten? das hab ich auch schon 
gemerkt das er da ab und an hackt.

allerdings schreib ich alle Werte in ne Queue und da ich (immoment) noch 
keinen Wert darauf lege die Werte live zu sehen stört mich das erstmal 
wenig.

Dazu kommt, dass während dem Empfang der Daten momentan auch alle gui 
elemente deaktiviert sind, so dass man warten muss bis alle daten da 
sind oder ich auf den Stopbutton klick.

[Jonas B. (jibi)]

Du kannst zusätzlich noch die Puffergröße (größer machen) umd das 
"Connection Timeout" (länger machen) der seriellen Verbindung anpassen. 
Das brachte einiges bei mir.

Gruß Jonas

[Jan L. (jan_l)]

ich arbeite mit ner api und muss jetzt grad erst mal schaun das ich nen 
empfangs puffer auf mein Board bekomm...

diese blöde api verursacht mehr probleme als sie löst -.-

[Peter II (Gast)]

Ich kann jetzt irgendwie nicht folgen..

Du sendest von C# an ein Board. Dabei gehen zeichen verloren. Bei senden 
wartet aber C#, damit kann man beim senden eigentlich nichts falsche 
machen.

Also kann das Problem nur beim empfangen oder der eigentlichen 
Kommunikation liegen.

[Jan L. (jan_l)]

also ich ruf den sende befehl auf und wenn ich ihn dann zb mit dem 
debugger die sende befehle langsam abarbeite bekommt und verarbeitet die 
andere seite auch alles.

wenn ich das programm aber einfach laufen lass kommen nicht alle befehle 
an.
hab da auch was in der api gefunden. nämlich die funktion die die daten 
empfängt ist folgendermaßen kommentiert

/*  Expect only one UART data at a time or the last one */

[Jan L. (jan_l)]

würde es auch funktionieren, statt eines Buffers eine art 
acknowledgement einzubaun?

hab mir das so gedacht, dass ich einfach ein "send" auf der C# Seite 
mache und auf der C Seite, nach der Bearbeitung des Befehls, zb ein 
'!'(oder irgendein anderes Zeichen) zurück sende und dann, wiederum auf 
der C# Seite solange warte bis das Zeichen da ist und dann erst den 
nächsten send Befehl schicke.

edit: also es sieht soweit ganz gut aus und scheint zu funktionieren...
hab zwar noch paar komische exceptions ab und an aber an sich läufts 
wesendlich besser und zumindest werden immer alle befehle übertragen und 
ausgewertet

[Christoph (Gast)]

Jan L. schrieb:
> hab mir das so gedacht, dass ich einfach ein "send" auf der C# Seite
> mache und auf der C Seite, nach der Bearbeitung des Befehls, zb ein
> '!'(oder irgendein anderes Zeichen) zurück sende und dann, wiederum auf
> der C# Seite solange warte bis das Zeichen da ist und dann erst den
> nächsten send Befehl schicke.

gehen schon, aber performanter wäre es schon mit einem Puffer...

[Jan L. (jan_l)]

das problem ist das ich dazu in die api "rein" muss... glaub ich 
zumindest und ich da nicht alles verstehe...

ich glaub, dass das die stelle ist die meine Bytes empfängt

/**
 *  @brief  Interrupt handler.
 *  When an RX interrupt is detected, a callback function (if one is
 *  registered) is executed with the RX byte as a parameter.
 */
#pragma vector=UART_VEC
__interrupt void UART_ISR(void)
{
    switch(__even_in_range(IV,4)) {
        case 2:     /* RX interrupt. */
            /* Check if previous data processed*/
          if(rx_new==0){
            rx_new=1;
            rx_data = RXBUF;
          }
            break;
        case 4:     /* TX interrupt. */
            /* Place next byte on buffer. */
            if (uart.length) {
                TXBUF = uart.data[0];
                uart.data++;
                uart.length--;
            } else {
                IFG &= UCTXIFG;
                uart.is_busy_writing_data_right_now = 0;

            }
            break;
        case 0:     /* No interrupt. */
        default:
            break;
    }
}


/*  Expect only one UART data at a time or the last one */
void msp430_get_uart_rx_data(unsigned char *uart_data){
  *uart_data = rx_data;
}

... allerdings ist "verstehen" was anderes ...

[bluppdidupp (Gast)]

Ich kenne jetzt das System nicht, aber müsste rx_new nicht irgendwo 
wieder auf 0 gesetzt werden, damit weitere Bytes nicht mehr 
weggeschmissen werden?
Hätte ich in der msp430_get_uart_rx_data() vermutet, die vermutlich vom 
eigenen Code aufgerufen wird?

[Jan L. (jan_l)]

ja in meiner main klasse hab ich es gefunden

//TODO: eingabe
static void handle_input(void) {
  char c;

  rx_new = 0;

  if (check_uart_mode_enabled)
    msp430_get_uart_rx_data((BYTE*) &c);

  memset(&hal.rx.header, 0, sizeof(hal.rx.header));


  // opt = 1
  if(c >= 0x80)
  {
    char temp;
    temp = c << 1;
    c = temp >> 1;

    int value = (int)c;
    time = value * 1000;
    ack();
  }else
.
.
.

das ist die funktion mit der ich meine eingaben verwerte. Seh ich das 
richtig, dass der buffer dann hier in die else müsste?

#pragma vector=UART_VEC
__interrupt void UART_ISR(void)
{
    switch(__even_in_range(IV,4)) {
        case 2:     /* RX interrupt. */
            /* Check if previous data processed*/
          if(rx_new==0){
            rx_new=1;
            rx_data = RXBUF;
          }else buffer  // <---
            break;

[bluppdidupp (Gast)]

rx_new = 0; gehört meiner Meinung nach in die letzte Zeile der Funktion 
msp430_get_uart_rx_data()

Es sieht mir bei dem Problem so aus, als würden die Daten schneller 
ankommen als du sie verarbeitet bekommst.
Wenn das nur gelegentlich so ist, könnte ein Puffer helfen, ansonsten 
wäre die Problemlösung vllt. einfach die Verringerung der 
Übertragungsrate?