I am brand new to PX4. Just getting started with flight controllers. My goal is to attempt to build a “glued-together” (literally) flight controller based on the Teensy4.1. I built Nuttx and successfully installed it on Teensy4.1, so the next step is to start looking at how I transition from that to a “base” PX4 port as mentioned in the Nuttx Board Porting Guide. It talks about building Nuttx with the “PX4 base layer”, but then I get lost. It points to a github repository, but I didn’t see any text that discusses how this is integrated into Nuttx.
I see there is an imxrt1062 port in the PX4 tree (fmurt1062-v1) and I was able to build that, but the IO is very different than my planned configuration.
Any pointers would sure be helpful!
Referring to “Firmware Porting Steps” on the porting guide page, I copied the content of the fmurt1062-v1 directory to a peer directory teensyport. I was able to update firmware.prototype, but then could not find any reference to VENDOR or MODEL in default.px4board. I ignored that and just tried to run make nxp_teensyport_default menuconfig. I was able to update the board to teensy4.1 in the menuconfig gui, but when I exited, there was an error…
configuration written to .config
*** End of the configuration.
*** Execute 'make' to start the build or try 'make help'.
[8/9] Running make nuttx_menuconfig then savedefconfig for nsh
LN: include/arch to arch/arm/include
LN: include/arch/board to /include
No directory at /include
tools/Makefile.unix:273: recipe for target 'include/arch/board' failed
make: *** [include/arch/board] Error 1
Looking around 273 of ./platforms/nuttx/NuttX/nuttx/tools/Makefile.unix…
@echo "LN: include/arch/board to $(BOARD_DIR)/include"
apparently BOARD_DIR is not set when that makefile is invoked.
Now I’m wondering if the fact that I could not set VENDOR and MODEL (above), those settings may have something to do with this variable not being defined…
@dagar Any chance you can help with this?
If you’re close to current PX4 master the board vendor and model are no longer set explicitly and now simply come from the directory structure.
The Teensy 4.1 is an interesting board, if you’re able to open a pull request or share your branch I can take a look at the build failures.
Thanks for the reply…
Yea, I like the board. Lots of horsepower, well designed and cheap!
I cloned the source yesterday (git clone GitHub - PX4/PX4-Autopilot: PX4 Autopilot Software --recursive),
so I guess I don’t need the VENDOR/MODEL stuff.
I haven’t changed anything, simply copied boards/nxp/fmurt1062-v1 to boards/nxp/teensyport.
WIth that I was then able to run “make nxp_teensyport_default” successfully.
The next step was to run “make distclean; make nxp_teensyport_default menuconfig” just to change the board to teensy4.1. Then upon exiting menuconfig, the above error came out. It appears to be caused by an unset BOARD_DIR variable accessed in Makefile.unix sometime after menuconfig gui closes.
If you can you attempt that to see the error, I’d sure appreciate it!
The PX4 boards are “custom” NuttX boards (CONFIG_ARCH_BOARD_CUSTOM, CONFIG_ARCH_BOARD_CUSTOM_DIR, etc) that are stored out of tree. By changing the NuttX menuconfig board you’re repointing it to the teensy4.x board actually in the NuttX tree (NuttX/boards/arm/imxrt/teensy-4.x at ec8f6f56050033cc46a099f084f82137e08fa619 · PX4/NuttX · GitHub).
Ok, I think I see what you’re saying…
I misinterpreted what “custom” meant here.
In this case (correct me if I’m wrong), “custom” means it’s not a standard NuttX port; rather, it is a port that needs to include code from outside the default NuttX tree. Is that the case?
More1: I’ve already built NuttX alone for teensy4.1 and it installs and runs as is.
More2: The fact that I created the new boards/nxp/teensyport directory is apparently all I need to get started then, true?
@dagar Well I managed to get a hacked version of the fmurt1062-v1 port to build, install and run (well… limp). I’m connected to the console UART (TX7 on Teensy4.1) and after bootup (with lots of error messages) I can interact with nsh>.
Right now I just use the teensy_loader tool to transfer the .hex file to my Teensy4.1. Is there any reason not to just stick with that? Do any of the tools within the PX4 space already support the Teensy model of loading?
hi @edsut, do you have any updates on this? How far did you manage to get?