Initialisation from PE occurs compiler faild

[admin]

Hi

I use for the moment CW 6.2. Processor expert has I also. If I now the initialization of the vectors table for the interruptslet make from the PE,  there is the following error:

Error : C1822: Type mismatch (expected 'void (*near)()', fiven 'unsigned int')

The code ist the following:

#ifndef UNASSIGNED_ISR
  #define UNASSIGNED_ISR 0xFFFF        /* unassigned interrupt service routine */
#endif

void (* near const _vect[])() @0xFFCE = { /* Interrupt vector table */
         Intervall1sec,               

  =>    UNASSIGNED_ISR,              /* Here is the first faild, all UNASSIGNED_ISR causes a faild

         UNASSIGNED_ISR,             

         UNASSIGNED_ISR,              

          UNASSIGNED_ISR,              

         UNASSIGNED_ISR,              

         UNASSIGNED_ISR,              

         UNASSIGNED_ISR,              

         UNASSIGNED_ISR,    

         ...   

I'm using the MC9S08QE8CWJ.        

[PEBeginnerBeh]

Hi

I solved the problem.

[PEBeginnerBeh]

Hi

Now the compiler have no problem with compiling the code. But the linker have now problem with the vector_table.

#define DEFAULT_VECTOR _Startup
   
#pragma CONST_SEG VECTORS
extern void ( *const vector_table[])(void);
#pragma CONST_SEG DEFAULT


/* vector_table.c */
#pragma CONST_SEG VECTORS
void ( * const vector_table[])(void) = {
{
Intervall1sec,
DEFAULT_VECTOR,
DEFAULT_VECTOR,
DEFAULT_VECTOR,
DEFAULT_VECTOR,            
DEFAULT_VECTOR,            
DEFAULT_VECTOR,            
DEFAULT_VECTOR,             
DEFAULT_VECTOR,             
DEFAULT_VECTOR,             
DEFAULT_VECTOR,             
DEFAULT_VECTOR,            
DEFAULT_VECTOR,          
Intervall1Min,              
DEFAULT_VECTOR,              
DEFAULT_VECTOR,              
DEFAULT_VECTOR,              
isrVtpm1ovf,                 
SIG,                        
DEFAULT_VECTOR,              
Reset_Zahler,                
isrVlvd,                     
DEFAULT_VECTOR,             
DEFAULT_VECTOR,              
_Startup                    
};
#pragma CONST_SEG DEFAULT

The lines which are written in orange occurs the error. 

Error: L4101: Preprocessor failure because of not supported preprocessor directive. Only  #line supported directly by linker.

What should I do?

 

[PEBeginnerBeh]

Thanks for your help.

@ lundin:

Your first solution didn't solve the errors. So I used your second solution. This solution does work. Now i have only a couple of errors in the code, which I wrote by myself

But these errors I could solve by myself.

[ProcessorExpert]

Hello PEBegginer

Your project is set up to use C++. However, the Device Initialization tool is targeted to ASM and C projects.

To use the code generated by Device Initialization tool, please don't use  #include "MCUinit.c" in main.cpp. Instead, declare there the prototype of the MCU_init function:

extern "C" {
extern void MCU_init(void);
}

Please note: when declaring your own variables in the MCUinit.c file (zahler, impulse, dis_var) place them in the section "User declarations and definitions" in the top of the "MCUinit.c" file to preserve it after code generation.

Example:

/* User declarations and definitions */
/*   Code, declarations and definitions here will be preserved during code generation */
extern unsigned long zahler;
extern unsigned long impulse;
extern unsigned char dis_var;
/* End of user declarations and definitions */

best regards
Vojtech Filip
Processor Expert Support Team

[admin]

Here is the project which the error has.

Best Regrads

PEBeginner

Message Edited by PEBeginner on 2009-02-23 11:20 AM

[Lundin]

Indeed that code shouldn't compile. ISO C does not allow implicit typecasting from integers to pointers. If PE generated that code, you should demand that they fix it. This should solve the problem:

UNASSIGNED_ISR (void(* near const)())0xFFFF


However, that whole code is needlessly ugly and non-portable. And you shouldn't need to use the "near" keyword. Is there any use for "far" memory on the S08? Why not write the code fully ISO C compatible and portable instead?


In the .prm file:

SECTIONS
VECTOR_TABLE = READ_ONLY 0xFFCE TO 0xFFFF;
END


PLACEMENT
VECTORS INTO VECTOR_TABLE
END

ENTRIES
vector_table /* force linking */
END


/* vector_table.h */

#define DEFAULT_VECTOR _Startup

#pragma CONST_SEG VECTORS
extern void (*const vector_table[])(void);
#pragma CONST_SEG DEFAULT


/* vector_table.c */
#pragma CONST_SEG VECTORS
void (* const vector_table[])(void) = {
{
DEFAULT_VECTOR,
...
};
#pragma CONST_SEG DEFAULT

[CompilerGuru]

> However, that whole code is needlessly ugly and non-portable.

> And you shouldn't need to use the "near" keyword. Is there any use for "far" memory on the S08?

>Why not write the code fully ISO C compatible and portable instead?
 

The QE family did introduce a CALL instruction with 3 byte banked addresses. So

in the banked memory model (which is not applicable for all S08/HC08's) the __near is required.

As far as portability is concerned, I'm not sure I like this version better. Obviously vector initialization is for a particular architecture, even for a particular derivative only. So the portability gained can only be with another C compiler for this architecture. As the placement of the section is mandatory in this case, porting would still need to adapt the #pragma's. And now there is a part in the prm file which would not port automatically either (but granted, you have to port the memory layout somehow).

As I see it, using the @ is a bit less noise (less text), using the prm file has the advantage that all addresses are defined in one location.

Daniel

[Lundin]

Writing a vector table portable to another CPU architecture doesn't make sense, this isn't what I suggested.

The advantage is that the code will compile on any HC(S)08 compiler. It threats the vector table for what it is: an array of numbers. How it gets to the right place in the memory shouldn't be a concern for the compiler, but for the linker. If every compiler implemented this with #pragma, the code would be fully portable between HCS08 compilers. Sure, there would be a lot of pragmas all over the code, but it would still be portable. If a compiler doesn't understand them, it ignores them.

For the same reasons, #pragma TRAP PROC is a better way than messing around with the "interrupt" keyword.

The .prm lines are compiler (linker) specific. It is good to keep all such things in one file, so the code gets easier to port. If all compiler specific things are spread all over the code, porting is more of a mess.

Another advantage is that you can make the code conform to coding standards like MISRA-C. This isn't possible with non-standard code.

[ProcessorExpert]

Hello,

I have not reproduced such behaviour. Could you please provide us a project demonstrating the problem?

best regards
Vojtech Filip
Processor Expert Support Team
UNIS