I would like to know if there has been some progress with CAN Bus for Photon?
I’m interested in it because I would like to control some ESC’s over CAN bus. https://pixhawk.org/firmware/px4esc <- Specially these (when they get released )
Pixhawk devices use UAVCAN protocol to communicate with flight controller (in my case Photon)
I have a crazy idea to build a fast line follower robot with brushless motors using mainly common hobby parts and I will need CAN bus to work on Photon to make this project happening.
We don’t have any high-level APIs for the CAN bus, although in the upcoming 0.4.2 release you’ll be able to write code that interfaces with CAN2 peripheral and handle the associated interrupts.
I hope gives you the tools to connect CAN devices. Please let us know how that goes for you and if there’s more that’s needed to access the CAN bus.
to access interrupts, use the attachSystemInterrupt() function (coming in 0.4.2, already available in the develop branch if building locally.)
the photon runs on FreeRTOS - I’m not sure how much RTOS integration is needed (some of our periperal drivers don’t touch FreeRTOS at all and work fine.)
I have posted my opinion about CAN in another thread but I will post it here too.
I work with CAN daily at my “real job” and I firmly believe the particle devices should only provide the basic CAN read and write functions.
The others can create libraries to sit on top of the basic CAN functionality to provide high level protocols such as J1939, CANopen, Keyword Protocol, etc.
As all people know protocol stacks can consume a lot of memory, and high level CAN protocols are no different. But if every particle device packed one protocol in it would be that much less space for everything else. Depending on the region of the world, the preferred CAN protocols change dramatically.
I know one other thread was pushing for native support for CANopen. I beg that this is not the case.
With the 0.4.2 release, application/library firmware can take control of the can Interrupts for the CAN2 bus, so it’s possible to use the STM32 Peripheral Library can functions. One, with candor, can can the can bus into a nice easy to use package - or canister - with the canned can bus exposing the basic functions needed to later implement higher level protocols.
With a canonical implementation in place, we’ll celebrate candidly with canola canapés in candlelit cantinas playing canasta cantata against a canvas of candescence.
@Bspranger: you seem like a strong candidate! we appreciate your advice here, and any input you have about implementing the can bus.
I got my photons today and I also have a CAN transceiver. So maybe in the next few weeks (I have two young kids) I can find time to play with the photon and CAN.
There are no CAN drivers. There is a hook for the CAN2 interrupt and the ST peripheral functions. Do you have any recommendations about which driver library we should use?
I’d really like to use CAN on the Photon, but I’m struggling with this ‘new’ Arduino way of doing things - coming from a true embedded background at the nuts and bolts level workign with AVR.
If there are pointers on what to do, I’d get involved and give it a go.
I am looking to make a device to remotely control the CAN on my car. I am thinking the electron would be the best choice for that. Has anybody gotten the native CAN controller on the photon working?
I started to work on the can driver tonight. I have a lot of work left but I think I am approaching the integration into the particle kernel correctly.
I have not contributed to the particle os before. How can I make some of this public for others to view so I can get some feedback?
when I try to create a new pull request the button is greyed out.
But as for my progress so far. I basically copied all the USART related files and renamed them to CAN.
Then I started to replace the contents of the functions to work with the stm32f2xx_can drivers. I know I still have work to do there, especially around the interrupts. I implemented all this for the stm32f2xx about 5-6 years ago. I sure wish I could remember it all.
the functionality should be similar to the UART, but there are obvious differences.
UART does not have message IDs, 8 byte packet limits, etc. So I created a structure that the user fills in to transmit, or passes in to receive.
I do have the buffers in the driver so once all the interrupts are working the kernel will be able to queue the messages up for the application.
One thing i noticed is that once we get multi threading, the queues are probably not thread safe… This goes for the serial too.
with all that said… my project (firmware) builds via the NetBeans IDE Project that was created for the Windows Toolchain.
)
