RE: can4linux for the BananaPi

A few years ago when I attended the CiA conference in Germany there were several positive presentations on CANOpen and Linux.  The discussion behind the scenes however was that in general, a Linux based system was slow and had the potential for dropping messages.  So I can see the desire for an expansion board that has intelligence, even if just to offload the ‘real time’ aspects of timely SYNC messages.  
 
As a stand-alone product one has to ask what market it addresses?  Yet more add on cards for functionality?  Normally it’s less expensive to just build a custom board with everything on it than two boards with an interconnect.
 
But, there is an application out there called LinuxCNC and a specific port of it that runs on the BeagleBone Black http://blog.machinekit.io/ using a real time variant of Debian.
And there are a number of capes that use the BBB as the processor and provide stepper motor drives, thermistor sensing and relay or FET outputs all for the RepRap 3D printer world.
 
As there is already a cape for a CAN bus driver but not a port of the real time Debian Linux for CANOpen perhaps that’s the first place to start.  Keep that open source and provide an application framework for user applications running on the BBB with the LCD capes that are also available.  
 
If there is a desire to pursue an open hardware cape, then the first step shouldn’t be the processor choice.  The first step should be the functionality of the hardware.  How many CAN ports? How many I/O ports, A/D? D/A? Hardware RTC?  Terminal Strips? Plugs?  And most important and often forgotten is packaging.  DIN Rail? Sealed water tight box?  Connectors on the box or access to the uSD card.
 
Once those specifications are outlined it’s time to look at what’s available for processors rather than compromising the design or development environment around a processor.
 
For example.  The target market is CANOpen.  Is the intention that the hardware cape design be open source but the CANOpen stack is closed and requires a hefty price relative to the cost of the BBB by itself?  Or, if only two CAN ports are needed on the target board then Microchip’s PIC32 family is suddenly attractive because the development environment can be as low as $0 and they provide a free CANOpen stack.  It might have bugs but here’s the perfect opportunity to improve on something that’s already in the public domain as long as it’s used on Microchip products.  
 
Or maybe part of the design specification is that it be solely a LINUX development environment both for the BBB applications and the cape. If so then which PC board Schematic and Layout package is part of the equation?  Can’t insist on Linux firmware development and not also insist on that for the hardware design.  Not everyone can afford or will want to afford Altium non Windows.
 
These are the questions I’m asking myself when I started thinking about a cape for my BBB.  I’m not a Linux person.  Don’t really even like it that much.  Too bloated for embedded applications.  Seems like every few months there is a new flavor out there along with comments like the new version of Debian won’t support the real time extensions for LinuxCNC.  
 
John Dammeyer
 
 
From: [email protected] [mailto:[email protected]] On Behalf Of Kent Rybar
Sent: August-20-14 6:11 AM
To: [email protected]
Subject: Re: [CANLIST] can4linux for the BananaPi
 
Gentlemen,

It seems the discussion on Beagle Board & Co. is getting more interesting.
There are but a couple of questions to answer first.

I would appreciate if experienced can list users answer those to help me understand the idea behind such boards. 

What are the benefits of developing of a fully capable CAN/CANopen board that works as an extention to a Beagle Board (as a cape) and its future development as well as being capable to work as a stand alone CAN/CANopen board?
Who is interested in that. A privat lab or rather an R&D of a company?

Will the board (as a cape) be able to support sophisticated CANopen profiles such as motion control (CiA 402) or lift control (CiA 417)?

What are the maximal and minimal requirements to the micro-controller (cpu and memory), CAN controller (how many controllers) for an advanced CANopen design including CANopen protocol stack, object dictionary, application, e.g. for 20 TPDOs and RPDOs, 5 SDO channels, 5000 CANopen objects. NMT manager, SDO manager, Network redundancy capability?

Is the cape or a standalone board be capable to fulfill those requirements?

Should the board (as a cape or a standalone version)  be a development (designed for a particular application) and/or an evaluation board (designed for various applications, supporting future versions of a micro-controller, CAN controller, CAN transceiver which are surface mounted using BGA package)?
Does it make sense to have also a kind of adapter boards for connecting raspberry pi  and shields from arduino?
Much appreciated.
 
Regards.
  <https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif> 
 
Kent