Porting documentation?

[robmilne]

Hi,

I've successfully installed Erika and run the example demos for the DEMO9S12XSFAME board. I would like to use ERIKA with different S12X variants as well as the S08. Is there porting documentation?

The wiki doesn't have explicit porting instructions but the "RT-Druid and OIL code generation using XML and XSLT transformations" tutorial looks promising. Please advise.

-rob

[paolo.gai]

Hi Rob!

Thanks for your e-mail...

About the porting information:

- we try to maintain a comprehensive porting documentation on the wiki. It's in the main page of the wiki,
http://erika.tuxfamily.org/wiki/index.p ... controller

- The XSLT tutorial is also useful and comes into the game once you have a working version with a "fake" RT-Druid generated code.

Just let us know your progress and we'll help you in doing the porting!(and it would be nice if you could share it afterwards...)

Ciao,

PJ

[robmilne]

Hi Paolo,

Thanks! Right in front of my face - sorry for not seeing the obvious. I'll definitely kick back anything useful for the community.

-rob

[paolo.gai]

No problem at all... just let us know whether you'll need help ... it could always be a good occasion to improve the wiki!

PJ

[robmilne]

Hi Paolo,

Before I try my hand at adding new hardware I want to resolve the errors generated by eclipse. This is from test5 of the multistack examples for hs12xs. I set the reset vector in Vectors.c to this function in CPU12ISRs.c...

Code: Select all

#include "hidef.h" /* this file declares symbols user by the CodeWarrior environment */

//#include "VTypes.h"
//#include "XDP512Regs.h"
//#include "Globals.h"
//#include "Car.h"
//#include "main.h"
#include "start12.h"		     /* to call the C-startup code */
#include "CPU12ISRs.h"
#include "mcu/hs12xs/inc/mc9s12xs128.h"

#include "ee.h"
//#include "test/assert/inc/ee_assert.h"


#pragma CODE_SEG __NEAR_SEG NON_BANKED  // make sure this code is located in non banked 

interrupt void S12X_EntryPoint(void) {
  COPCTL = 0;         // disable the watchdog & clock monitor timers.
  PLLCTL_PLLON = 1;   // turn on the PLL
  REFDV = 0;          // set the REFDV register.
  SYNR = 9;           // set the SYNR register to give us a 40.0 MHz E-clock.
  asm nop;
  asm nop;
  asm nop;
  asm nop;
  while(!CRGFLG_LOCK); // wait here for PLL to lock.
  CLKSEL_PLLSEL = 1;   //  switch the bus clock to the PLL.

  asm jmp _Startup
} 

..however eclipse UI is compaining in the "Problems" tab. Below are a few examples.

Description Resource Path Location Type
Field 'REFDV' could not be resolved CPU12ISRs.c /erika_test5 line 27 Semantic Error
...
Type 'EE_TYPEASSERTVALUE' could not be resolved main.c /erika_test5 line 53 Semantic Error

The code I added is executing as per the debugger so I know that everything is compiling properly. How do I get eclipse to clean-up these non-errors? The IDE is new to me so I do not understand the pathing. My guess is that eclipse has no knowledge of CodeWarrior's native pathing (ie: I cannot access hidef.h via eclipse). If I cannot resolve these dependency issues I will not be able to build with confidence using the IDE.

-rob

[nicola.serreli]

Hello,

some of errors in the "Problems tab" are not c/c++ errors, i.e. if you compile the code "using erika makefiles" everything works.
This means that makefile provides to compiler/linker/... the correct list of files and defines, but some of them are not visible to eclipse cdt.

New versions of RT-Druid contains some features to reduce the impact of this problems:
- through project's properties, it is possible to "include" in the project all .h erika files as read only or all erika files as read/write.
Doing that, eclipse is able to solve inclusions of erika header files.
- eecfg.h contains a section with (almost) all "defines" required by your code. (note that eecfg.h is created by RT-Druid from conf.oil during the build)

Than, if you want to remove all errors, you need
1) start a build (at least the RT-Druid configuration phase) after every change on conf.oil, in order to fill the eecfg.h
2) ensure that all defines required by your code are available to eclipse (in the eecfg.h or in the project properties). Some architectures add defines inside makefiles that are not known/handled by RT-Druid. To solve the problem, you can add them to conf.oil in the EEOPT fields.
3) if the build requires external .h files (like ones provided with the compiler), you should add also them to the project, or directly coping/linking them or using the cdt project's properties.

I hope that this can help.
Regads,
Nicola

ps. Asap I'll try to add to the wiki a few lines/images about how add include paths

[robmilne]

Hi Nicola,

Thanks for the response.

I did spend time trying to add include paths to properties->C/C++ General->Code Ananlysis->Paths and Symbols but wasn't successful in removing the eclipse errors. I'm using windows so the forward-reverse slash is also a source of confusion. I will give it another try.

Question: How do I find the list of oil file options that are available for a specific architecture or board? In my case I had to search through some of the example projects to find a MCU_DATA option that enabled the UART.

-rob

[paolo.gai]

Hi!

I'm Paolo. The wiki for S12 does not contain yet the list of OIL options for each driver implemented (we are anyway trying to improve the wiki in many parts... maybe you want to update it as long as your work proceeds...).

To get the list of OIL options, you can do as follows:
Window / Show View / Other...

then:

RT-Druid / Active OIL Implementation

Then look for the MCU part. The S12 target has the following for the MCU:

Code: Select all

            DEMO9S12XSFAME {
                ENUM [
                    POTENTIOMETEER,
                    ADC,
                    BUTTONS,
                    LEDS,
                    LIGHT_SENSOR,
                    ALL
                ] OPTIONS[];
            },
            TWRS12G128 {
                ENUM [
                    SCI,
                    BUTTONS,
                    LEDS,
                    ALL
                ] OPTIONS[];

"SCI" should be the UART...

I hope it helps!

PJ

[nicola.serreli]

Hello,

I did spend time trying to add include paths to properties->C/C++ General->Code Ananlysis->Paths and Symbols but wasn't successful in removing the eclipse errors. I'm using windows so the forward-reverse slash is also a source of confusion. I will give it another try.

Do you mean Project properties->C/C++ General->Paths and Symbols (i.e. without Code Ananlysis) as attached?
It should be the right place to add references to external .h files. Note that there is a set of "include directories" for each language and (at least in my case) the default one is Assembly, than if you have to select GNU C before add the reference (or add it to all languages).
Complex projects have also mode than one Configuration, than you have to be sure to add the reference to all configuration that need it.
As last point (probably a stupid point), the path of include directory and the path/name in the #include <..> directive should work together, i.e. the concatenation of both is the path in the filesystem of the required file.


After everything work, you can add more flexibility to your project using variables, as shown in the attached image. In this way you can move the project on distinct computers without change it (just adjust the environment/eclipse variable value).


A complete different approach is to "link" the include file/directory to your project. The easiest way to do it it to drag the file/directory from the filesystem browser (like explorer) and drop it inside the eclipse "project explorer" view in the eclipse gui (or similar views, like "project navigation" view); doing that, eclipse ask if link or copy the file/directory. Also in this case, be sure that the path relative to the project root is compatible with the content of the #include <..> directive.
Even if is a little more complex, also links can be done through variables.

The main difference between two approaches is that the first one searches only .h files and consider them read-only files, while the second one shows all files and considered them as project files (you can modify them as you want, and there are more eclipse functionalities that can be apply on them).


Regarding the list of eeopts, as told by Paolo, there is not a complete list of all valid options. First places where search are the wiki and the Active OIL Implementation view. Note that RT-Druid 2.0 contains a new editor with content assist, providing the list of valid options in a specific point of the oil file (the default shortcut is crtl-space)

Regards,
Nicola