typedef void (* ble_cmd_handler) (const void *);

[katmani1]

Hello Frients


I use the module BLE112. I want to connect it to the PIC18F46J50. Through BGLIB API for RS232. By using the compiler CCS C PIC Compiler 5.049.

When you compile error is issued in the following line:

typedef void (* ble_cmd_handler) (const void *);

The compiler refuses to understand it.
"Expecting an identifier"
"Expecting a declaration"

What can be done to use BGLIB API and the CCS C PIC Compiler 5.049?

I did the test program, and it gives the compiler error:

newmain22.c:

[RF_Developer]

Its a function pointer definiton. The problem, in your test program, is that ble_cmd_handler has not already been defined. The parameter is a pointer, but a pointer to what? Or more to the point, its a function pointer, probably, but a fucntion with what return type?

[Ttelmah]

Also get rid of the const. Or select ANSI.

By default in CCS, a 'const', is a ROM type to which a pointer can't be constructed. In ANSI C, a const is a variable in RAM, that is protected (if the hardware has such protection), against being modified. If ANSI is selected CCS attempts to switch the definition (but personally it is safer just to get rid of const). So:

[katmani1]

Thank you!
this line is to remove all the errors:

#device ANSI // switch const meaning

[katmani1]

The problem did not end with the compiler.
New error: "Error#43 Expecting a declaration"
I minimize the program to select a piece with the error:

[temtronic]

OK, maybe I can't see it BUT where is' PLLEN' that the first error reports on in the program you've posted??

[katmani1]

[katmani1]

I use standart bluegiga bluetooth smart bglib-API for module BLE112.
This is a problem in CCS C PIC Compiler?

[RF_Developer]

The error is being thrown at the cast. The reference to PLLEN appears to be some kind of default thing in the compiler, "PLLEN" has nothing to do with it.

There's acually no reason to cast it. Instead of "(ble_cmd_handler) ble_default", "&ble_default" (my preference) or simply "ble_default" is perfectly acceptable syntax. Indeed with either of these your example compiles. The compiler warns that ble_default is not called (it isn't of course, merely pointed to) and that apis is not used, but that's okay.

[katmani1]

[katmani1]

I think more and more that this is a problem in the CCS C PIC Compiler.
It is interesting to developers CCS C PIC Compiler reading this forum?

[Ttelmah]

Not really.

The point is that you are trying to use code written for another compiler.

Now no two compilers are ever 'the same'. They can be very similar, and the core parts of a language can be the same, but they will all have individual differences. These need to be adjusted to by the programmer....

With the ANSI option, CCS attempts to pretty closely accept ANSI C99 code. However C99, not the later ANSI variants. Even at C99, it still has some small differences. However as an example, I recently ported about 10000 lines of Microchip code into CCS, and once I had done the defines, only had to tweak some data definitions, the initialisation, and the syntax of a few of the specific I/O functions. Probably less than 10% of the lines.
The point is that you do have to rewrite the code to suit the compiler. This is true even on mainstream compiler (try moving some Linux C to Microsoft sometime). You cannto just take code and plug it into any compiler without learning the specific features of the compiler.

CCS has some very specific differences, that actually allow it to optimise better to the chip than many of the other compilers, but the programmer has to adjust to these.

If you want to use CCS C, _you_ have to actually try to learn the language, rather than expecting to plug code straight in. What the code is doing, is what you should be looking at, and whether there is a different way that this should be done in CCS.

CCS, is CCS C, not any other C. It actually keeps remarkably closely to the original K&R definitions. Out of every code line in the original first edition K&R, I can't think of any that cannot be made to work pretty much 'as is' in CCS C.

[katmani1]

CCS C PIC Compiler I really like. Under it it has been written a lot of code.
I will try to further alter the code BGAPI under the CCS C PIC Compiler.
But I do not know how to do it :(

[RF_Developer]

Two problems with your example code: first, you haven't defined ble_msg_system_address_get_rsp_t, so you get an error at line 16. Second, the parameter type of ble_msg_system_address_get_rsp_t doesn't match const void* and so the compiler throws an error at line 26. Now, this is arguably wrong, as a void pointer should match any other type of pointer - in C terms void* is simply an address and can point to anything. However the CCS C compiler appears to be more picky about the types.

All this stems from the fact that most Cs run on processors with one address space, shared by code and data. The PICs are Harvard architechture, which has different memory spaces for code and for data. That means a function pointer, which is a pointer into code memory, has to be treated very differently to a data pointer, which points into data memory.

CCS C didn't even allow function pointers at all until fairly recently (late in version 4), and there are still restrictions on them. I beleive you can't assign them at run time, they must be resolveable at compile time. The problem in your example is not the function pointer itself, but the parameters to the function. There's another problem with that, and that it that most PICs don't have a data stack (i.e. no pushes or pops), and so the parameter passing mechanism used by most Cs, passing the parameters on the stack, is not possible. This, in turn, restricts the compiler as to how it deals with parameters for functions called via pointers. This may lie at the root of the compiler wanting the types of the parameters to match precisely, which is more associated with the behaviour of C++ or C# than C.

The reason for this may be that with a function pointer, the compiler can't know what routine will actually be called, and therefore where to put the parameters. That means it can deal with function pointers to functions with no parameters okay, but anything else is tricky.

How to solve the problem? I've managed to get it to compile, but I really don't know whether this will work at run time. I've declared ble_msg_system_address_get_rsp_t and changed ble_rsp_system_address_get to take a void pointer and in effect cast it inside the routine to what's required:

[Ttelmah]

Oh God. Another decade gone....