CANBus Payload Extraction

[williamsk]

I have the CANBus sending working fine. And my custom function for receiving a CANBus frame triggers when I send one. I can even read the payload size and the frame ID in the debugger. But when I try to read the payload, I get <not accessible>, or in the case of the QString a 10000 character string.

Here is my code.

 const QCanBusFrame frame = device->readFrame();
 const quint8 dataLength = frame.payload().size();
 const quint16 id = frame.frameId();
 const auto &payload = frame.payload();
 const QByteArray data = payload.data();
 QString stringData = frame.toString();

The frame.toString() at the end is what Qt has in their CANBus example code so I figured I'd try it.

So I get the frame payload size and the CAN Frame ID which is correct. But I can't get the data out. What am I missing or forgetting to do here?

[aha_1980]

HI @williamsk, welcome.

What happens if you debug-print to the console?

qDebug() << frame.toString();

Also, can you provide some more information? Which operating system is that, which Qt version, which compiler?

And finally, which CAN hardware and therefore which CAN bus plugin are you using?

Also please note that this:

 const auto &payload = frame.payload();
 const QByteArray data = payload.data();

is wrong, as frame.payload() already is a QByteArray, and by accessing the data() (which is a char *) you might truncate it at the first 0x00. So what you really want to do is: const QByteArray data = frame.payload().

Regards

[williamsk]

@aha_1980

Okay! So qDebug works and prints the correct data to the console. So why then, when I try to extract this data to a variable, the debugger says <not accessible>? Is this a deficiency in the debugger? If I simply try to use the data, will the screen respond appropriately? I just have to do a lot of parsing and processing on this data so being able to see it in the debugger would be immensely helpful.

As for more information, I'm running a Toradex iMX6 SoM. It is running the standard Boot2Qt image which I think is based on Debian. I'm using Qt Creator 4.13.1 based on Qt 5.15.1 using mingw32 as the compiler. I'm using the on-chip CAN interface and using canutils and libsocketcan to talk to it.

And thanks for the notes. I was just trying everything I could think of to see the data in the debugger. qDebug is probably the first thing I should have tried.

[aha_1980]

Hi @williamsk

Okay! So qDebug works and prints the correct data to the console.

Good. At least you know your hardware and software is working then.

So why then, when I try to extract this data to a variable, the debugger says <not accessible>? Is this a deficiency in the debugger?

Probably. I had problems debugging a lambda the last time I tried. Is your code in a real function? Try something like this:

void slotFramesReceived()
{
  const QCanBusFrame frame = device->readFrame();
  const quint8 dataLength = frame.payload().size();
  const quint16 id = frame.frameId();
  const QByteArray data =  frame.payload();
  constQString stringData = frame.toString();
  qDebug() << stringData; // break here
}

Then you should be able to see all the variables - or there is really a problem with the debugger

If I simply try to use the data, will the screen respond appropriately? I just have to do a lot of parsing and processing on this data so being able to see it in the debugger would be immensely helpful.

Agreed.

As for more information, I'm running a Toradex iMX6 SoM. It is running the standard Boot2Qt image which I think is based on Debian.

At least it should be some Linux, so the plugin is socketcan.

I'm using Qt Creator 4.13.1 based on Qt 5.15.1 using mingw32 as the compiler.

As the board is running Linux, that's probably some kind of cross-gcc? Is you Host running Windows? (That's just a side question out of curiosity, I've never cross-compiled from Windows to Linux)

And thanks for the notes. I was just trying everything I could think of to see the data in the debugger. qDebug is probably the first thing I should have tried.

Sometimes good old printf is indeed the rescue.

Regards

[williamsk]

@aha_1980

I'm not sure what you mean by "real function". The code is in a function that is declared in the public slots. I tried using the code as you have it written. Here is what I get out of qDebug in the terminal:

"     06E   [8]  48 65 6C 6C 6F 21 21 21"

And here is what the debugger shows:

So I guess I'll have to make heavy use of qDebug to get it all parsed correctly.

And yes, I'm developing on a Windows machine. MinGW stands for Minimalist GNU for Windows and is a cross compiler supplied by Toradex, the SoM manufacturer.

Thanks for the help. I'll update this thread if I stumble across a way to get the debugger to display correctly.

[aha_1980]

Hi @williamsk

I'm not sure what you mean by "real function".

I meant not a lambda, as I encountered problems within there.

Did you break after all variable assignments have been made? And did you use a Debug build?

If the problem persists, the Views > Debugger Log window might give more insight.

Regards

[williamsk]

And I just did. Simple matter of changing the display format from Automatic to Raw. Now I can see my payload in both my QByteArray and my QString.

It's always the simplest thing. Thanks again!

[aha_1980]

@williamsk

Ah, cool. So as your problem is solved, please mark this topic as SOLVED too (button Topic Tools).

Thanks and regards