Introduction

What are we going to build? A CAN implementation. How? Well…. I’m nut sure myself. I will just start and write down my experiences along the way. For sure we will use our standard Board for that, the Keil LPC1768 board and we will, in parallel, implement on a PC using a USB-CAN connection. We will use Rhapsody in ‘C’ for that. C++ would be too easy…. (It’s not… but Johannes is already working on that and I don’t want to interfere with that. )

What are we exactly going to build? Years ago I did build two small apps, a master and a slave app that were exchanging info via CAN. On the Master Board you could operate the Potentiometer and the values were send to the slave board where an LED was regulated.

This is the first step we are going to build. I would like to build a different app, namely one that can log CAN messages to a PC. That would involve a PC program as well to interpret the CAN messages and display them. I’m not sure how to do that but I think we will get ideas when we start using CAN.

Preparations

First let us do some model preparation. For the first steps we need 4 Rhapsody models and, of course, the IDE projects as well.

The Rhapsody projects need to be prepared, a lot of things can be done by using profiles but unfortunately not everything. Global properties must be set in every model. (There are tricks around that, I will spend a future BLOG entry to that tricks, I promise! )

So we create the following projects:

lpc17xx
The CAN driver for the Keil board, mostly already there in CMSIS packs.
PC_sim
The CAN driver for the PC, not sure how (yet) but let’s prepare for it.
master
Communicates via CAN to the slave tha twill receive commands and executes them.
slave
Gets commands from the master and executes them.

The best way to work with these models is to load them all in Rhapsody. This can be done by creating a Project List with “File”, “Insert project”.

The following profiles must be loaded:

Rpy_C_CMSIS_Keil5_ARM_MCB1700_TD_Profile (only Master, Slave & lpc17xx)
Rpy_C_Win_VS13_PC_TD_Profile (only Master, Slave & PC_sim
WST_Types, this implies some global properties to be set:
General::Model::CommonTypes must be set to: WST_Types
General::Model::DefaultType must be set to WST_Types::uint32_t
*EDIT* – Not necessary anymore! Although the properties are “Model-level”, you can still set them in a profile. The Code Generation is done from the Component/Configuration and will therefore use the properties. Very cool. Not sure why the selection box of attributes and variables show the types but, hey, let’s not look a given horse in its mouth….
WSTProfile
WST_CG_Profile

It is convenient to include all profiles in a separate project in the beginning, you will have to change stuff often, it is better to have everything within reach.

Here is the profile that you can load to have C99 types AUTOMATICALLY! WST_Types

Set the following global properties to make working with Rhapsody easier:

Browser::Settings::ShowOrder to YES
Lets you re-order elements i teh Rhapsody browser.
Browser::Settings::ShowPredefinedPackage to NO
Removes the Predefined Types Packages from the browser
Browser::Settings::ShowSourceArtifacts to YES
Displays source-artifacts. Since we also set the Roundtripscheme to “advanced” there should be no source-artifacts.

Workflow

The idea is that we put all hardware dependant stuff in the lpc17xx and in the pc_sim models, we include these into the master and slave models to make the last ones completely hardware independent. When all is ready we start preparing the models for the implementation.

Structure:

CAN
- Model
  - LPC17XX
  - Master
  - Slave
  - PCsim
  - profiles
- Code
  - LPC17XX
  - Master
    - LPC17XX
    - PCsim
  - Slave
    - LPC17XX
    - PCsim
  - PCsim

This is a good working structure, maybe we do some fine-tuning later on.

LPC17xx Model

This will include the implementation of the hardware drivers for the MCB1700 Board. It needs some packages to store the work we do. We do reverse engineering to achieve most of that.

The next is the project where we store the generated code.

Keil Projects

In Keil we can also create a Project Space/Workspace to handle multiple projects. First create the projects themselves, Keil will not let you create an empty workspace…

First we create the empty project for the LPC17XX, select the correct CPU (NXP lpc1768) If this does not show up, you first have to install the pack from NXP. After you have done that, select the packs we need, RTOS and CAN. Don’t Worry! We can always select other packs when we need them! You do not have to click all ticks right away…

We can copy these projects to the Master and Slave directory once we are happy with them. Or we wait until we are done, that’s probably better.

PCsim Model

This is the model that contains the same as the lpc17xx model but then runnable on a PC as simulation. It is important to have something that can run on a PC to make testing much easier.

The next is the project where the generated source code is stored and compiled.

Visual Studio 2013 Project

A Microsoft Visual Studio Project. I still use 2013, that is also supported “out-of-the-box” by Rhapsody, we also have a 2015 Adapter.

Master Model

The model that contains the Master Model, the model that serves as a master in the CAN network.

Slave Model

The Rhapsody model that acts as slave. There are also projects for the source code for both ARM and PC.

CAN we?

I’m not going to write a lot about CAN itself. There are enough pages on the web that explain what it is, that it was invented by Bosch, how the priority works etc. Try Wikipedia and you will as smart as you need to be for this in minutes.

How can we model a CAN communication? Well that is not too difficult (I think) but we should ask ourselves: What do we really want to model?
I think we should use as much driver technology that is already there. On the Keil Boards that is easy: the CMSIS Packs give us a lot. We need to include it in our model somehow and then build intelligence above it.

Prepare the LPC17xx model

We will use Rhapsody Reverse Engineering to prepare it. Since we only use the outcome of this we can do reverse engineering without any other preparation (RE changes a lot to your model and your Component/Configuration, since we do not build anything here we just leave it)
We first prepare the LPC17xx Keil Project to have the sources there for RE.

Open your Keil project
Open the Pack Installer
First install all packs needed ( Left Window, Boards, MCB1700 )
Then install Examples (Select MCB1700 in left window, then right window will show you CAN Example (amongst others)
You can find the Sources (or actually the includes) to use for Reverse Engineering in:
- <Keil Install Dir>\ARM\PACK\ARM\CMSIS\<latest version>\CMSIS\Driver\Include\
Open the LPC17xx Rhapsody Model (In Rhapsody in ‘C’ please, will not work the same in ‘C++’.
Rename the Component to “reverseEngineering” and the Configuration to “keilMCB1700”
Start “Tools”, “Reverse Engineering”
- In the first screen select “model driven”, “logical modeling”
- In the second screen enter the path for the include files, then select all files. (We only need CAN but why not create a complete model right away, costs nothing and might be convenient later on)
- In the third screen, leave the top 2 fields (“ordinary model elements” and “replace existing packages” but change the 3rd to “single top leve; package”and name it “HAL”
- The fourth screen is OK, press “Finish” to perform RE. The result wil look like the picture on the right.

Now we can use this model in the other models to have a CAN driver included.

Just do an “Add to Model” in both hte Master and the Slave Model and include the “HAL.sbs” file there (As a (REF) of course )

When you have don that you can select all HAL functions with the INtellivisor ( Use “select” )

In the next part we are going to implement a simple CAN send and receive function that just sends and receives generated messages.

from there on we are ging to implement things like:

publisher subscriber, so you can subscribe to a certain kind of CAN Messages with a callback function and that will program the CAN Acceptance Filter (if there is one)
define messages for sending a value and receiving the value.

That’s it, the rest follows soon in part 2!

Happy modeling with Rhapsody if you CAN!

Walter van der Heiden ( wvdheiden@willert.de)

I just used a picture of Obama because he used the “Yes we Can” slogan in the 2008 elections and I found that a nice wordplay. Please do not assume i meant anything political with it, I never want to discuss anything even remotely political in this BLOG,
I do not want anything else than just technical discussions here.
I use other platforms to express my personal opinions.

Yes we CAN! (part 1)