Porting CANFestival to RTEMS

Isaac Gutekunst isaac.gutekunst at vecna.com
Thu Aug 27 16:56:10 UTC 2015

Thank you everyone for the information! It was very helpful!

I've gone ahead and made a port based on the AVR and Unix ports.

I adapted unix_timers.c and unix.c to use the RTEMS traditional API. So 
far everything appears to be working. I'll be cleaning it up and 
submitting a patch to CanFestival at some point.

I also created an "rtems" can driver port based on my unreleased RTEMS 
can API. I will be submitting a very rough version of that for review 
within a week or so.

I've also been having some trouble with RSB, but I'll save that for 
another email.


On 08/24/2015 07:03 PM, Pavel Pisa wrote:
> Hello Gedare,
> On Friday 21 of August 2015 16:46:41 Gedare Bloom wrote:
>> I believe CANFestival comes from Pavel Pisa's group. He is active with
>> RTEMS and interested in pushing forward CAN improvements, but time is
>> always a problem. He's on vacation but may get to this thread after he
>> gets back.
> no CANfestival is work of unrelated our university departmen
> and my company work. I have only contributed minimal
> LinCAN interfacing long time ago. Then even met CANfestival
> developers on some conferences and spoken with them.
> Some of my colleagues have used CANfestival on master
> and slave side to build distributed control system
> where code has been generated from Matlab/Simulink.
> Some document and archive code of that project can be read
> from lintarget site
>     http://lintarget.sourceforge.net/
> but that CANfestival part has not be ported to actual version
> of ert_linux Simulink support distribudet from Lintatget project.
> So generally, I have some knowledge about CANfestival,
> it has advantage that it is relatively simple and easy
> to understood but I have not done much with it personally.
> Our group CAN/CANopen work can be found in OrtCAN project
>    http://ortcan.sourceforge.net/
> but it tries to be dynamic and runtime configurable
> and because we have contracts and demands in different
> areas now - mostly automotive, we do not have resources
> to push it much forward now.
> But CANfestival is good choice for devices and basic
> CANopen SDO communication state automata can be used
> even for master which communicate with runtime configurable
> structure of slaves. Similar state automata can be found
> in OrtCAN VCA library as well and reused, but set is much
> more complex.
> Best wishes,
>                  Pavel

More information about the devel mailing list