search

intel-aero / meta-intel-aero

Yocto layer to support Intel Aero platform
https://github.com/intel-aero/meta-intel-aero
GNU General Public License v2.0
218 stars 119 forks source link

Supporting faster Baud rates to Pixhawk (460800 is unreliable for ULog) #138

Closed mindThomas closed 7 years ago

mindThomas commented 7 years ago

Which baud rates are supported to the Pixhawk? It seems like it is only possible to use 460800 which seem to create a bottleneck for logging (Ulog). With 460800 we seem to be limited to a logging rate of only 4.8 KB/s with a lot of dropouts too. This is way below average and more or less useless.

Any clues?

lucasdemarchi commented 7 years ago

There are 2 problems on increasing it... On the Linux side and on the stm32 side. We were on 1500000 before but lowered that due to the issues below:

For now I don't have an estimate when this will be done though.

lucasdemarchi commented 7 years ago

See #24 for more details. I'm closing this as a duplicate of that issue, ok?

mindThomas commented 7 years ago

It's OK that you close this as a duplicate. Sadly it seems like these problems are related to hardware issues rather than software :(

Well, may I ask you if it came to any surprise to you that the flight controller needed a UART interface? It seems like the hardware planning went wrong when you designed the Aero compute board and did not connect the UART port directly to the Intel SoC? Routing the UART through the FPGA, requiring that all transfers happens between the SoC and FPGA over the SPI bus, seems unplanned. And no hardware flow control either doesn't make the problem any better.

Did you consider placing an inexpensive FT232 chip (or similar) on the Aero compute board to connect the UART port of the flight controller to a USB port of the SoC instead?

lucasdemarchi commented 7 years ago

It's OK that you close this as a duplicate. Sadly it seems like these problems are related to hardware issues rather than software :(

It's actually a mix of software and hardware as explained above.

Well, may I ask you if it came to any surprise to you that the flight controller needed a UART interface?

I understand your frustration, but this is no place for sarcasm.

It seems like the hardware planning went wrong when you designed the Aero compute board and did not connect the UART port directly to the Intel SoC? Routing the UART through the FPGA, requiring that all transfers happens between the SoC and FPGA over the SPI bus, seems unplanned.

Here you have the wrong assumption that there's a SPI <-> UART bridge. There isn't. The SoC's HSUART1 (see section 17.4 from http://www.intel.com/content/www/us/en/processors/atom/atom-z8000-datasheet-vol-1.html) is connected to the FPGA. The FPGA here acts as a switch, connecting one pin to another while being able to act as a level shifter (in this case it doesn't, though... but you have to remember that the processor is 1.8V level and the stm32 is 3.3V... so there needs to be a voltage translation there nonetheless). See https://github.com/intel-aero/intel-aero-fpga/blob/master/aero_rtf_kit/RTL/top.v#L131-L132 (and disregard the name... it has nothing to do with xbee).

And no hardware flow control either doesn't make the problem any better.

Yep... flow control should indeed be there.

mindThomas commented 7 years ago

Hi @lucasdemarchi Sorry for the delayed response. Apologies for my ignorance, frustration and sarcarsm. We have managed to complete our project which will be published online soon, including several guides on how to get started and get around some of the issues we've encountered.

May I know if you expect to resolve the UART Baud rate issue such that a faster communication rate to the PX4 can be achieved, allowing a proper Ulog rate for debugging purposes? And will such a fix be software applicable (eg. updating the FPGA or Kernel drivers)?

lucasdemarchi commented 7 years ago

I tried to fix it sometimes. In my last effort raising the kernel to 4.9.x helped (the message that there's too much work on irq went away) but it was still not sufficient. The fix looks to be on kernel and I know I will work on this again looking for a software-only fix, but unfortunately I don't have an ETA (or even if it will be indeed possible).

mindThomas commented 7 years ago

Why do you fear that it should not be possible? If you use a USB to UART converter it is possible? So why wouldn't it be possible with an internal UART of the processor itself (where faster rates by intuition should be possible)?