UAVCAN integration with Particle Electron, Photon and Core (STM32F205 MCU)

93 views
Skip to first unread message

robb...@inanibus.com

unread,
Sep 4, 2017, 11:58:10 PM9/4/17
to UAVCAN
Hey all,

Has anyone has worked on a UAVCAN integration with the Particle Core? I am interested in doing this integration.  

Particle.io has created IoT open source development platforms based off the Arduino and it uses the Wiring language for rapid firmware development.  

I want to connect my PX4 to a cellular and/or WiFi module to transmit flight data under the UAVCAN framework.

According to the following datasheets, for hardware, all I need is a CAN transceiver module.
The devices are based off FreeRTOS and the MCU used is a:
I assume I can follow this tutorial with FreeRTOS to create a static library.
With the following build options:

UDEFS += -DUAVCAN_STM32_FREERTOS=1
         
-DUAVCAN_STM32_TIMER_NUMBER=<not_sure>   // Not sure what timer is attached
         
-DUAVCAN_STM32_NUM_IFACES=2
         
-DUAVCAN_STM32_IRQ_PRIORITY_MASK         // Do I need this?

Questions:
My goal is to create a clean integration that can be adopted into the Particle libraries although I need advice on architecture to integrate libuavcan with the Particle platform with simplicity and portability in mind.  

Cheers,

Robbie


Pavel Kirienko

unread,
Sep 6, 2017, 9:47:58 AM9/6/17
to robb...@inanibus.com, UAVCAN
Hey Robbie,

If you're keen to use the default CAN driver provided by libuavcan, you can specify any hardware timer that your application doesn't use, as described in the documentation. The driver supplied with libuavcan will configure the timer automatically, you don't need to worry about it.

The IRQ priority mask can be left unconfigured, the default is good enough for most use cases.

Concerning your questions:

1. A quick look at the docs suggests that you should be able to use the Particle's CAN driver with libuavcan with no issues. All you need is to code a simple wrapper class as described here: http://uavcan.org/Implementations/Libuavcan/Platforms/Adding_support_for_a_new_platform/. The wrapper class would adapt the Particle's CAN driver to Libuavcan.

2. Not sure I understand the question. What do you mean by inheriting functions? At any rate, rather than using the default driver, I advise you to implement an adapter class and use the Particle's default drivers.

Pavel.

--
You received this message because you are subscribed to the Google Groups "UAVCAN" group.
To unsubscribe from this group and stop receiving emails from it, send an email to uavcan+unsubscribe@googlegroups.com.
To post to this group, send email to uav...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/uavcan/a9a14092-f50f-4d8d-b73d-1941083545fc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

robb...@inanibus.com

unread,
Sep 6, 2017, 8:38:08 PM9/6/17
to UAVCAN
Hi Pavel,

Ok great the adapter class makes sense.  Forget question 2, it was worded poorly although what I was trying to ask I'll re-state below.

Particle has a cloud compiler and a standalone compiler.  Particle developers can include special community libraries into their projects that are stacked on top of Particle-core firmware.  The goal is to create a Particle library with a UAVCAN implementation.

The library will be github hosted with libuavcan listed as a submodule.  

I have to test it out, although the question in my mind was if there are build options or makefile operations in libuavcan that may cause problems with the Particle-core? Forgive me if this doesn't make sense, I'm not familiar with the terminology.  I may need to test it and get back to you with some error message.  

Robbie 

To unsubscribe from this group and stop receiving emails from it, send an email to uavcan+un...@googlegroups.com.

Pavel Kirienko

unread,
Sep 7, 2017, 4:03:09 AM9/7/17
to robb...@inanibus.com, UAVCAN
This sounds like a solid plan. The build process for libuavcan is quite straightforward - you can just compile all the library sources together with the application, so there's no need to compile a dedicated library or anything. You may encounter some difficulties with the DSDL compiler though - it is invoked during the build in order to generate the header files for the DSDL data types. I'm not familiar with the Particle's cloud compiler so can't advise on what is the best way to handle that. Perhaps there is a way to run the DSDL compiler (which is just a Python script!) in the cloud. If not, you could provide an external server that would recompile the DSDL headers and serve them to the cloud compiler somehow. I'm sure it can be done.

Pavel.

To unsubscribe from this group and stop receiving emails from it, send an email to uavcan+unsubscribe@googlegroups.com.

To post to this group, send email to uav...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages