Import KickCAT as third party lib to nuttx app

[trns1997]

Create a simple nuttx ethercat app using kickcats slave stack.

• Build xmc4800 board using CMake (build xmc4800-relax using CMake apache/nuttx#11679)
• Create simple app inspired from @Rdk-T amazing work
• I was thinking of building the kickcat lib using conan (so once we're happy with the slave stack then we should consider tagging a new version and updating the recipe)
• If all goes well "maybe" build the board and app using Makefile

[trns1997]

@leducp @Rdk-T i would like your input regarding how to efficiently integrate KickCat. Let us take the arduino due with the lan92 shield. If we follow the nuttx driver convention, then the lan92 driver should be in nuttx, which means that slave stack would communicate with the shield via /dev/lan92 file probably. But in the case of our POC in KickCat we have the driver integrated here which uses the spi driver from nuttx. Both approaches work but i was wondering if KickCat should be the one responsible to provide drivers? From what i see:

Case 1: We provide driver (using arduino-due + lan92 shield as an example)

1. nuttx-app will have a lan92-ethercat-example
2. nuttx arduino-due board will have to provide the correct spi driver
3. Build the example which will have our packaged lan92 driver

Case 2: Use nuttx lan92 driver

1. nuttx-app will have a ethercat-example
2. nuttx arduino-due board will activate the lan92 driver in the form /dev/ethercat
3. Build the example and the slave stack will take a /dev/ethercat file and use that as the driver to do it's ethercat stuff

Each case has it's pros and cons. I have a hard time figuring out which approach it better, in case 1 we will have to pass a variable to Kickcat to tell it what driver to use or we end up with different apps based on the driver/board we choose. In case 2 we can have a single example which exploits the nuttx driver provided called something generic like /dev/ethercat and what ever board we choose as long as we provided the driver with the right name it will work ideally. Let me know what you guys think.

[leducp]

I prefer to handle the case 1: the KickCAT codebase is more generic this way. Note that it can be useful to have the case 2, but it is more work since it means:

• adding a driver in the NuttX codebase
• adding an interface to support NuttX ESC generic interface in KickCAT
• keeping the lan92 ESC implementation in KickCAT for other platforms

I think we just don't have the manpower to handle this (case 2).