RSS Feed

Embedded Systems Blog

Free CANopen Configuration and Test Utility

October 27th, 2015 Comments off

At today’s 15th international CAN conference Olaf Pfeiffer of Embedded Systems Academy presented a paper about testing of highly dynamic CANopen systems. Such systems support plug-and-play and node ID assignment by LSS (Layer Setting Services, node ID gets assigned through the network). As a result, devices may change their node ID, making tests more challenging.

One of the test utilities introduced in this paper is now available as free download from ESAcademy’s web pages. It supports the extended concise DCF (Device Configuration File) as introduced in the paper. It allows you to easily write down configuration or test sequences in a table (save as .csv) and execute them using the free CANopen File Player.

The file format, the concise Default Configuration File is part of the basic CANopen definitions and has been in use for quite some time. The extension to it is simply a definition of a set of commands introducing the option to control things like addressing specific devices (identify by CANopen Identity record 1018h) and time delays / timeouts or user interactions.

In addition, the utility can re-play previously made CAN trace recordings, supporting a wide variety of formats from Vector, PEAK and others.

For more information on the format of the extended CDCF see the manual or download the free utility.

Impressions from the Embedded World 2015

March 2nd, 2015 Comments off

With about 900 exhibitors the Embedded World reached a size where it is impossible to “see it all”. Yes, you can still walk by all booths in a day, but you might easily miss hidden highlights. It was quite obvious that IoT – the Internet of Things – is a current hype. To me this is quite astonishing as already some 10+ years ago we built an “Embedded Internet Demo” – at that time based on a Philips 8051 with a dial-up modem connected. The main difference between now and then is that now smart phones are widely spread and we are “always online” and now can access our embedded devices “at any time”. Among the visitors one could recognize a lot of skepticism for what exactly we really need the IoT, other then it being hip and cool to be able to control “everything” with our smart phone.

An unusual approach to get remote access to embedded applications was shown by Raisonance (http://www.iotize.com) – they have a miniature NFC or Bluetooth module that connect to the JTAG/SWD debug port of an application. So it can be added to any application with debug port, sometimes even without the need to re-compile the code, if you have the knowledge where in memory the variables are that you want to have remote access to. A great tool to get started with IoT without requiring a re-design of existing hardware.

At the CiA (CAN in Automation) booth a CAN FD demo integrated devices and tools from multiple vendors. CAN FD (Flexible Data) allows higher bit rates and longer contents (up to 64 bytes) of the data frame. Especially bootloader applications and other software update features benefit from the higher data throughput. For such applications it seems to be possible to increase the effective data throughout 8 fold easily, potentially even more.

We at ESAcademy further enhanced our portfolio of CANopen Diag products. There is now a second hardware, based on PEAK’s mini Display, that offers a subset of the diagnostic features provided at a price point of well below 1000 Euro. The CANopen Test Machine System part of the CANopen Diag now allows to create tests based on MS Visio graphs. The transitions in a state diagram can be used to transmit or receive a CAN/CANopen message or to influence/set/test/query variables or timers. More details and examples will be published shortly.

Visit us at the Embedded World 2015 in Nuremberg

February 16th, 2015 Comments off

This year the Embedded World (www.embedded-world.de) in Nuremberg expects 30k+ vistors from 35+ countries. Show days are from 24th to 26th of February. For companies “into CAN” one of the hot topics is CAN FD – more and more products (microcontrollers as well as interfaces) are now available supporting the new standard supporting higher data rates. You can see the Bosch CAN FD demonstrator at the CiA booth (booth 608 in hall 1). This demo includes our CANopen Magic software connected to a CAN FD bus using the latest PEAK CAN interface. If you have questions and would like to meet us, come over to our partner PEAK System (booth 606, hall 1, just next to the CiA booth). Looking forward to seeing you!

Micro CANopen update, latest conformance test

December 17th, 2013 Comments off

ESAcademy recently released an update for its Micro CANopen source code software including an update to the CANopen Architect EDS editor and code generator. This update includes changes that were made to pass the latest Version 1.0.1 of the official CANopen conformance test by the CiA. The changes required mainly consisted of adapting SDO abort codes to the required values. For further changes, please refer to the release notes of the individual products. Customers with ongoing support service may download the latest versions from www.esacademy.org

Micro CANopen Source Code V6.11 released

May 10th, 2013 Comments off

Today we released a new version of our Micro CANopen source code. Updates and changes made include requirements from the latest CANopen conformance test as well as updates to the CiA 447 specific examples. Besides two bug fixes, the changes are:

Device switch themselves automatically to pre-operational when they detect a loss of a heartbeat that they are consuming. In the past this was application code specific, but as the conformance test requires it, we moved this function into the stack. In CiA 447 this is only done for the loss of the gateway’s heartbeat. Reaction to other heartbeat losses remains application code specific.

For CiA 447 devices, the shut down sequence is now also initiated if a gateway is not present. As before, devices wait for the next wake-up message before they try to communicate again.

Micro CANopen customers with a current maintenance and support contract may download this latest version from our servers as described on the delivery note for each product.

Potential risk warning for CiA 443 sub-sea systems supporting a bit rate change via Layer Setting Services

April 22nd, 2013 2 comments

Although ESAcademy is not an active member of the CiA 443 group, we have several customers and business partners using CiA 443 and came across a potential reliability issue in regards to bit rate changes.

It is our understanding that the reliability requirements for CiA 443 sub-sea applications are very high. Bootloaders are written and tested in a way that even power failures at any time or severe communication errors can not break the system. In worst case, an application is not programmed and a device remains in bootloader mode and is simply re-programmed again.

However, allowing the CAN bit rate to change with the currently specified mechanisms bears the risk of one or multiple devices failing. If in a CAN network devices are not configured to use the same bit rate, communication fails at a very low level. Devices will recognize that there are errors on the bus and potentially take themselves offline (bus off). If the devices are configured to use these different bit rates, then this error state can not be resolved.

How could such a situation occur?

The Layer Setting Services (LSS, see CiA 305) allow the setup of a bit rate, if all devices connected to a network support these services. Although the method of when exactly to do the bit rate change is very well specified and synchronized, the actual storing of this information (nodes copying this information to their local non-volatile memory) is not. It happens “one-by-one” and as no timings specified, this could be within seconds or even minutes. If there are severe bus communication errors during this time or even a power failure, then all devices will not have the same bit rate configured.

Possible solutions:

1.) Do not use switching of CAN bit rates by LSS, only use it for node ID assignments

2.) Use a power-on default bit rate. Any change to the bit rates is not stored in non-volatile memory, it is only temporary. With each reset or power cycle all devices fall back to their initial default bit rate.

3.) Use auto detect. Note: this only works if not all nodes are doing it, there must be at least one node communicating for the others to be able to do an auto detection. This feature is not available with all CAN controllers (requires passive listen-only mode).

4.) Check with CiA 305 group what else can be done to make the bit rate switch safer, for example by not only synchronizing the time of the physical switch, but also the time when this information is stored into non-volatile memory.

Until this is solved we recommend all existing systems to not make use of the bit rate switching by LSS.

Categories: CANopen Tags: , , ,

CANopen and J1939 co-processors, free eval kits at int. CAN Conference March 5th/6th

February 9th, 2012 Comments off

On March 5th, ESAcademy will conduct the following classes at the iCC together with NXP Semiconductors:

08:30 to 09:30 Everything CAN and NXP CAN Controller Intro
A 30 year old technology, here to stay for another 30 years

An overview of the almost 30 year old CAN technology, where it came from and where it goes. CAN is used in many new electronic designs, also thanks to continuous advancements in CAN controller technology. Comparison of various CAN controller technologies.

09:45 to 10:30 CANopen Essence
New to CANopen? Learn the key features in just 45 Minutes

With its 4000+ pages the CANopen drafts and standards are overwhelming to newcomers. Join this class to get an overview of the common technical key features that make CANopen work.

11:30 to 13:00  Introduction to NXP CAN microcontrollers and Co-Processors
CAN controllers, CANopen Co-Processor, J1939 Co-Processor

Specialties of NXP CAN controllers and how an LPC11C24 can be used as a communication Co-Processor. Using the LPC11C24 with integrated CAN transceivers to implement a Co-Processor to implement and handle a higher-layer protocol, offloading this task from a host processor system. The host system communicates with the gateway via
UART, I2C or SPI.

Participants may qualify for a free NXP Evaluation Kit (must be present to qualify, 50 kits available).

For more information about the international CAN conference visit: www.can-cia.org

Categories: CAN, CANopen Tags: ,

Car add-on networking CiA447 goes V2.0

July 19th, 2011 Comments off

The CAN in Automation documents known as CiA447 describe how CANopen is used in automotive “add-on electronics” applications. These are electronics not added by the car manufacturer, but at a later point. Most common usage is for electronics used in taxis, emergency response vehicles and police cars.

Recently CiA447’s functionality was enhanced and especially the new power-down and wake-up procedures required a version step upwards, as they are not backward compatible.

Today, Daimler is the only manufacturer already offering cars with CiA447 interface. However, several other car manufacturers have already shown prototypes.

One of the biggest benefits of CiA447 is, that it offers add-on electronics access to some of the cars displays and buttons. In modern cars, there is typically no physical room to add electronics near the dashboard, as all space is used up. CiA447 allows “sharing” some of the cars displays and buttons, so that the electronic components themselves do not need to be mounted near the dashboard.

We at ESAcademy have now updated all our CANopen products for CiA447 to implement the latest V2.0 enhancements and changes. This includes our Micro CANopen source code solutions, our CANopen Magic line of analyzers and our CiA447 gateway simulator. Contact us, if you need to bring CiA447 to your electronics.

Categories: CANopen Tags:

CAN bit rates beyond 1MBps

May 16th, 2011 Comments off

For many years the maximum bit rate of CAN (Controller Area Network) has been 1Mbps. Not only was it a maximum for the bit rate, it also resulted in a “touchy” physical layout: cable length restrictions were as low as 30m.

The limits of speed vs. cable length comes from the requirement, that in CAN a bit needs to be stable on the entire bus, before the next bit may start. Some bits can be over-written, a feature which is used for arbitration, acknowledgments and error handling.

Bosch, the inventor of CAN, now introduced a white paper “CAN with Flexible Data-Rate” showing how a higher data rate can be achieved. The main suggested feature here is to allow switching between a low (backward compatible) bit rate and a much higher bit rate within a single message.

In short, a single CAN message consist of control data at the beginning and the end of a message with the data field “in the middle”. The core idea is to use the lower bit rate for the control data and the higher bit rate for the data field only. In addition the maximum data field size is increased from previously 8 bytes to now 64 bytes.

If the higher bit rate is 8 times higher than that of the base rate it would be possible to achieve an 8 times higher data-throughput WITHOUT changing the real-time behavior.

For more info, see the white paper at:
www.semiconductors.bosch.de/media/pdf/canliteratur/can_fd.pdf

Categories: CAN Tags: ,

NXP introduces dual-core ARM Microcontroller

November 3rd, 2010 Comments off

The new LPC4000 family of microcontrollers from NXP Semiconductors combines two powerful ARM Cortex cores in one microcontroller. The integrated Cortex-M4 and Cortex-M0 can run asymmetrically at up to 150MHz and have access to internal memory of up to 1MB Flash and 264k of RAM.
A multilayer bus matrix with 4 separate RAM blocks ensures that both microcontrollers have independent, fast access to “their” memory, minimizing wait-states.
Next to the “usual” LPCxxx peripherals the new devices also feature high-speed USB and an AES decryption engine for security.
There are several applications that benefit from a dual core solution. If a lot of communication is required, like handling complex communication protocols with specific timing requirements, a dual-core solutions allows using one core as a communication co-processor, clearly separating communication and process handling.
For more information, see NXP’s web pages.