Jump to content

Recommended Posts

<_< Hi everyone,

 

so far I have been programming PICs exclusivley in assembler. For a bigger project that I want to take on I want to switch to C, so I am evaluating if SourceBoost is the way to go.

 

So far I have hit a few things that a normal C compiler would support but SourceBoost does not. They are mostly minor annoyances though with easy workarounds. However I hit on a non-supported feature that I am not quite sure how to work around. At least not in a clean way.

 

I need to work with an array of function pointers (this should be in ROM). It looks like SourceBoost does not support the definition of a function pointer as data type, nor does it support the direct creation of an array of function pointers. At least not with standard C syntax. I get either all sorts of errors regarding missing parens or about missing semicolons.

 

Does anyone know if there is a way of accomplishing this / a REASONABLE workaround?

 

Thanks

Link to post
Share on other sites

Enum and a big switch statement.

 

I tried something similar a few months ago and found it didnt do what I wanted.

SourceBoost function pointers are not what you expect, have a look at an assembler listing, the compilor assigns a number to each function pointed to (starting at 0) and when a function pointer is invoked it calls a hidden assembler function which is a big switch.

The compilor seems to detect what functions are pointed to by looking for them being assigned to function pointers. It doesnt recognise a table of function names.

 

If you dont like surprizes I suggest you also have a look at how call by reference is implimented, just so you know!

Link to post
Share on other sites

<_< Hi Picxie, thanks for your reply. I thought about that as well but thought it decidedly non-elegant. Part of the reason far what I want to do is that I want to implement a library that calls client functions based on index. It would be very simple for the client code to initialize the rom array. Having to force the client to write the switch statement is a bit clunky....

 

You are right about my expectations. I was hoping a ROM function pointer array would be implemented as a list of call statements and one could use a computed offset for the PC to select the right function. Oh well, those assembler programmers B)

 

I'll try that and see what the assembly listing looks like.

Link to post
Share on other sites

Array of function pointers is not supported yet. A workaround is to use a plain char array to hold function pointer values and a temporary function pointer variable as media to read and write this array:

 

//Data to store function pointer values
char fptr[2]; void (*ppp)(char);

//Initialize function pointer array
ppp = foo1, fptr[0] = ppp;
ppp = foo2, fptr[1] = ppp;

//Call function pointer stored in element 1
ppp = fptr[1]; ppp(x);

 

Regards,

Pavel

 

PS: Personally I don't use function pointers often and almost never used arrays of function pointers and this is one of the reasons why this area has been somewhat neglected in BoostC. My own position is that when code has too many of function pointers it's a good sign that it's time to move to C++ <_<

Link to post
Share on other sites

Pavel,

 

Funny you should mention that. Indeed I have written rather large amounts of code in Java. So I suspect that gives me a certain way of looking at solutions for programming problems. In fact these days it’s pretty much all I am using for desktop development.

 

However when I am programming an embedded device with all of 4k or perhaps 8k instructions total and just a few hundred bytes of RAM I feel that OO is not really called for. Try as you may, it just gets a bit more resource hungry than really needed. I like my embedded code tight, which is why I have been writing in assembler so far. Not that it is my best discipline though. However I have to admit it just isn’t as productive as a higher level language and that is a factor too.

 

Your code idea is interesting and I am sure to keep that idea in my arsenal. However I think it will not work for what I have in mind. This all happens in RAM and that is just too precious a resource to be squandered lightly. Plus it takes instruction space for the initialization.

 

I am currently working on a communications protocol for RS232, CAN, USB etc. that I want to implement as a library, because I need it in several projects and it’s likely to be of use in the future. There will be quite a number of commands that the protocol should automatically route to appropriate handlers in client code. Each of those might be only a very should routine but there could be many of them. A couple of dozen at the low end seems likely. I feel doing this with the RAM pointer approach will be too wasteful. A set of pointers in ROM appears like a more appropriate way to go.

 

So for this project I will probably go with the switch statement, even though that makes for a somewhat uglier interface to client code. For now I am the client myself, so it’s not that bad.

 

Thanks for the suggestion and keep up the good work. <_<

Link to post
Share on other sites

Pavel,

 

I just tried your suggestion and it does not compile. It allows me to define the pointer variable but then produces an error when I try to assign a function to it. Seems like the entire function pointer thing is a bit orphaned…

 

Regards, techie

Link to post
Share on other sites
I just tried your suggestion and it does not compile. It allows me to define the pointer variable but then produces an error when I try to assign a function to it. Seems like the entire function pointer thing is a bit orphaned…

 

We never had any problems with this particular bit of functionality. Are you sure you have all types matching? Like type of function pointer variable you use matches functions you try to assign to it?

 

Regard,

Pavel

Link to post
Share on other sites

Join the conversation

You are posting as a guest. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...