NXPhlite-v3 with Leitwert's serial dma

[davids5]

This ties together the Now upstreamed DMA work from @laube and @janokle of leitwert on the current PX4 nuttx

From: #8030

This is a WIP for the NXP flight V3 HW based on the K66. It builds but is incomplete as it is missing key Nuttx support in the Kinetis architecture.

The drivers/kinetis/* is just stubbed out. There is SPI, or DMA support

Missing Components

• FPU support in the OS

• DMA (needs to be made consistent with NuttX CS and upstreamed, should also consider streaming)

• SPI - Completed

• CAN

• VBAT - for bootloader app communication.

• Timers PIT, LPTM, and FTM, PDB - for pwm, capture, tones, and hrt.

• RESET up_systemreset(void) noreturn_function;

  Incomplete Drivers:

• PWM supports only 1 chan per timer.

• USB The K66 has 2 USB USB0 is FS (Nuttx has driver) USB1 is HS (No NuttX driver!)

• UART lacking DMA kinetis_serial_dma_poll(void)
  Tested with RTS/CTS HS (RTS out of CPU is per character - Consider GPIO based SW flow control ala stm32)
  -[x] SBUS - tested working

• TERMIOS for serial

• RTC - up_rtc_getdatetime - Config issue fixed

• SDHC DMA disabled will not work with it yet

OS/System dependant SW

• Cannot use FPU yet on kinetis
• Termios
• tcgetattr
• tcsetattr
• cfsetspeed

PX4 FMUV2 Modules removed from build due to No External SPI

• drivers/bma180

• drivers/bmi160

  NOT Portable YET

• MCU version

• /Firmware/src/modules/systemlib/mcu_version.c

• drivers/pwm_input

• drivers/test_ppm

• systemcmds/hardfault_log - needs bsram

• modules/uavcan

• uavcan

• uavcan_stm32_driver - need Kinetis CAN driver

PX4 Drivers Needing porting

• drivers/kinetis/*

• [ X] drv_hrt.c

  • HRT
  • PPM

• drv_input_capture.c

• drv_io_timer.c

• drv_led_pwm.cpp

• drv_pwm_servo.c

• drivers/kinetis/adc

• drivers/kinetis/tone_alarm

• 5/31 - Need to add tone control lib. - Done

[dannyfpv]

good flight on pixhawk mini f450.
1- https://logs.px4.io/plot_app?log=859428c0-2686-498e-ab88-53dc15678737
2- https://logs.px4.io/plot_app?log=00682a3b-322e-46e7-aadf-555b92c0f31f
3- https://logs.px4.io/plot_app?log=69ccc09b-7c26-49b3-b78b-2dfb196329f4
4- https://logs.px4.io/plot_app?log=0f30bb5b-890b-4a1f-9439-98cace8e8baa

[davids5]

@dannyfpv - would you please test with 5b0ad4e on FMUv2 Pixhawk with 2 MB and Nxphlite

[dagar]

[davids5]

rebased on master

[davids5]

@LorenzMeier -

I was a tad perplexed as to how the minimal changes done to PX4 to bring in Kinetis, could affect the V2 build spilling over by 1028 bytes. Boaty indicated it was the ROMFS.

There were 3 lines added to the rcS recently but it caused a 1028 spill over. This makes sense
From reading https://www.kernel.org/doc/Documentation/filesystems/romfs.tx

Another thing to note is that romfs works on file headers and data
aligned to 16 byte boundaries, but most hardware devices and the block
device drivers are unable to cope with smaller than block-sized data.
To overcome this limitation, the whole size of the file system must be
padded to an 1024 byte boundary.

@dagar and I spent some time looking at memory usage.
There is still the 9.5K to get back from mavlink.
There are 41 K of strings for the logger field decoding. ~3 K can be recovered by encoding the types as ordinals not strings in the orb_*._fields

@dagar volunteered to pymavlink PR doen, that will buy us some time, but may take time to come in upstream.

I can not get this branch merged until master get cleaned has some room.

[davids5]

rebased dropping
DO NOT MERGE TO MASTER: Lower avionics check thresholds 0de1f02

[dagar]

copyright

[dagar]

Can't we set the platform define automatically from ${CONFIG_ARCH_CHIP}?

[davids5]

@dagar I see your point and yes we could. But relative to
-DUAVCAN_${UAVCAN_PLATFORM_UPPER}_${OS_UPPER}=1
we have to consider the coupling of 2 libraries we do not have direct control over.

Uavcan use this set of defines in its drivers.

UAVCAN_KINETIS_NUTTX
UAVCAN_STM32_CHIBIOS
UAVCAN_STM32_NUTTX
UAVCAN_STM32_BAREMETAL
UAVCAN_STM32_FREERTOS

The choice was to stay consistent with uavcan. If we choose to use CONFIG_ARCH_CHIP it will break the stm32f7 usage. So defaulting it to stm32 and having the ability to override it seemed like a good choice for flexibility and decoupling.

So I would prefer to stick with it, unless you see otherwise.

[davids5]

rebased on current master and copyright dates fixed