Framing errors with serial communication.

[bask185]

I am building a Gui in QtCreator on my windows 7 PC, but sometimes I have framing frame errors when sending a byte to my test arduino. I do not have this problem when I use my processing application, but that app does not run that well on my raspberry Pi (< end device which must run the app) so now I am trying to create the same GUI in Qt for use on the Pi.

#include "mainwindow.h"
#include "ui_mainwindow.h"
#include <QPixmap>
#include <QDebug>
#include <QPalette>
#include <QtSerialPort>
QSerialPort serial;

int lettres[5][40][16];

MainWindow::MainWindow(QWidget *parent) :
    QMainWindow(parent),
    ui(new Ui::MainWindow)
{
    ui->setupUi(this);

    serial.setPortName("COM4");
    serial.open(QIODevice::ReadWrite);
    serial.setBaudRate(QSerialPort::Baud115200);
    serial.setDataBits(QSerialPort::Data8);
    serial.setParity(QSerialPort::NoParity);
    serial.setStopBits(QSerialPort::OneStop);
    serial.setFlowControl(QSerialPort::NoFlowControl);
    //serial.open(QIODevice::ReadWrite);

    QPixmap logo(":/resources/img/logo.jpg");
    int w = ui->label->width();
    int h = ui->label->height();
    ui->label->setPixmap(logo.scaled(w,h,Qt::KeepAspectRatio));
}

MainWindow::~MainWindow()
{
    delete ui;
}

void MainWindow::on_F1_clicked()
{
   serial.write("0x96");
}

void MainWindow::on_F2_clicked()
{
  serial.write("H");
  qDebug() << "H";
}

void MainWindow::on_F3_clicked()
{
  serial.write("L");
  qDebug() << "L";
}

Code is simple really, I press a button and a byte gets sent. With Debug and the flashing receiving LED I can see that a byte is sent. As said before the problem is not caused by the arduino. Qt is in fact the first software which has ever given me a framing error.

I tried to outcomment the flow controll and to use one and a half stopbit, but that makes no change. Also swapped the location of "serial.open(QIODevice::ReadWrite);" but also here.. no effect. There are no parity bits involved and I use just 1 stop bit

Sooo. what am I doing wrong?

[bask185]

With great shame I must admit that it was me who made an epic mistake.

The arduino has a handshaking function. the thing keeps sending 0x1c untill it receives 0x96 <- however this should not have interfered with all the other functions. But by my fails.. it did.

long story short: in the main loop there was 2x a if statement with if(Serial.available() > 0) and one of those would handle all normal function and the other the handshaking. So depending where the arduino was in his code one of two got executed, so whether an H or L would have effect was complete random to me, thus letting me think of framing errors. And because processing answers the handshaking and I would do it myself in realterm I had no problems with those programs.. so Qt had to be the problem... it had to be -.-"

Anyways sorry for wasting your time, I'll leave now in shame :(

[kuzulis]

Check your code on Arduino and of "your processing application". Maybe there are really used "wrong" settings, I mean not a "115200, 8, none, one, noflow" but something else.

[VRonin]

What does serial.write() return?

From http://doc.qt.io/qt-5/qiodevice.html#write-1

Writes data from a zero-terminated string of 8-bit characters to the device. Returns the number of bytes that were actually written, or -1 if an error occurred.

if it returns -1 you can use qDebug() << serial.error() << serial.errorString(); to get a clue of what went wrong.

serial.write("0x96");

I don't think this does what you think it does. this will write 4 bytes

[bask185]

@kuzulis have you not read this sentence "Qt is in fact the first software which has ever given me a framing error."

Arduino nor processing never have framing errors, that simply does not occur. By default paritity bits are disabled, 1 stop bit is used and there are 8 data bits.
All you do in arduino code is writing in the setup Serial.begin(115200); that is it, this does not fail, not ever.

Syntax for processing is almost identical, cannot fail either.

I have not ever had framing frames in my life before, not with arduino, not with raspberries, not with processing, not with anything... except Qt which it's overcomplicated syntax.

@VRonin

void MainWindow::on_F1_clicked()
{
    int c = serial.write("H");
    qDebug() << c;
}
void MainWindow::on_F2_clicked()
{
  int c = serial.write("L");
  qDebug() << c;
}

With every push on a button, serial.write returns 1, so Qt is sending 1 byte every time I click a button, but I could already see on the arduino Rx LED that there was activity when I clicked. But sometimes I need to press 4 or 5 times on the button before I can turn off/on the onboard LED of pin 13, which should happen with just 1 click.

The arduino code looks as follows

if(Serial.available() > 0) { // if a byte is received...
  char c = Serial.read();     // read the byte and store under 'c'
  if (c == 'H') digitalWrite(LED, HIGH); // if c = H turn LED on
  if (c == 'L') digitalWrite(LED, LOW); // if c == L turn LED off
}

This code is flawlessly simple, it never failed me before with processing or with Wifi or with Bluethooth modules etc.

This is why I am convinced I am having framing errors which are caused by Qt.

And about:

serial.write("0x96");

I don't think this does what you think it does. this will write 4 bytes

This was a typo fail on my end. I am in fact using

serial.write("\x96");

instead, so my bad.

Also I am using one paratity bit it from now on (employer forgot to tell me this). Again processing + arduino work without flaw.

[kuzulis]

This is why I am convinced I am having framing errors which are caused by Qt.
...
Also I am using one paratity bit it from now on (employer forgot to tell me this). Again processing + arduino work without flaw.

WOW What turn of this story! :)

[bask185]

@kuzulis please, either help or don't post. This is just annoying, I'm sorry

[mrjj]

@bask185
Hi
Maybe check with sample ?
http://doc.qt.io/qt-5/qtserialport-terminal-example.html

[Rondog]

I would investigate your hardware and settings.

A framing error means that received data doesn't fit what was expected. For example, 8 data, 1 stop, and no parity has a 10 bit frame (there is always a start bit). If you add parity the frame size becomes 11 bits. Framing errors are generated at hardware level.

USB-Serial adapters can be troublesome especially at higher baud rates. I assume this is what you are using on Win7. Try a more standard rate such as 9600 if possible.

If you suspect your problem is Qt try writing a simple serial program in something other than Qt. I would do this as a simple console application (in C even) where you handle serial directly using the Win32 API. There are many samples of how to do this on the internet. I suspect that you will find Qt works properly and problems you have will appear in this second method.

[bask185]

This post is deleted!

[bask185]

With great shame I must admit that it was me who made an epic mistake.

The arduino has a handshaking function. the thing keeps sending 0x1c untill it receives 0x96 <- however this should not have interfered with all the other functions. But by my fails.. it did.

long story short: in the main loop there was 2x a if statement with if(Serial.available() > 0) and one of those would handle all normal function and the other the handshaking. So depending where the arduino was in his code one of two got executed, so whether an H or L would have effect was complete random to me, thus letting me think of framing errors. And because processing answers the handshaking and I would do it myself in realterm I had no problems with those programs.. so Qt had to be the problem... it had to be -.-"

Anyways sorry for wasting your time, I'll leave now in shame :(