Re: can4linux for the BananaPi

Am Mittwoch, 20. August 2014, 09:17:53 schrieb John Dammeyer:
> 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.

Still partly true. Related to dropped messages, not. SJA1000 based have a receive FIFO, FlexCAN implementations can realize a receive FIFO, others too. Also CPU is increasing every year. May be this was true for ARM7 based embedded Linux systems. But even there, we used the EMS EtherCAN V2.0 without such problems at bit rates up to 250k. It has a SJA1000 and we used can4linux which is more stream lined then SocketCAN.

>  
> 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.

I asked all of you already to wait for the outcome of the next CiA meeting handling this topic. What I understand is, that CiA likes to offer a set of hard- and software for immediately start with CAN. And both should be reusable (in Design) to build custom boards. 


>  
> 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.

I too are very curious on that. In the hardware world too a set of exchange formats exist for the layout and schematic.

>  
> 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.

Use Linux where it makes sense to have all the flexibility and functionality it provides - of the cost of consuming large resources.

>  
> John Dammeyer
>  

Because CiA is promoting its activity an different media and not only to CiA members, I suggest that you send your questions and suggestions to [email protected] 


Best regards
  Heinz

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAABAgAGBQJT9NtTAAoJENViPQy9fcm7jDsIANZ5nG5b2LhWkCvWckKsZlSW
YDSsw3/l1fzYylmc+UDK8p1MiLTMNx6xa56t1yRgYRA34sWhVUPU+tysi37gCy9L
x7Vr6k0trfkbC2DftoU8f3NTpfVYb4hdsWlcCPMSWrMKDhK2XGZpG4y3XuN1ZOp+
t3e5G2GJNoiXuaiUGi0RUMBXQS8vhBzYWJELbpb1jlqXiKkTV/rb59v2e7ezyKXC
NKcZbHPokJcefC696lgFRHewZmTl1Y4+0GReXL3KUZeAxlHSg9G9Mv4OeGa0dhxg
FAANpdTilWSSbBdNTSsGDparp5aZFMQMf3du7Ha0XTp4GbNpKo5x6QH6AoEzA6Y=
=dUTr
-----END PGP SIGNATURE-----