Function Pointer in Referenced Struct

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

 I certainly may be missing something obvious, but there seems to be an issue with implementing a function pointer in a struct referenced by a pointer:

   

struct MyStruct {

   

void (*SetDriveMode)(uint8);

   

};

   

 

   

void Function1(const struct MyStruct * structPntr) {

   

void (*foo)(uint8);

   

foo = PIN1_SetDriveMode;

   

structPntr->SetDriveMode(PIN_DM_STRONG);

   

}

   

 

   

struct MyStruct structVar;

   

main {

   

structVar.MyFunction = PIN1_SetDriveMode;

   

Function1(&structVar)

   

}

   

 

   

Notice that foo is not actually used at all.  If I compile my program written like above, it appears to work properly.  I can place a breakpoint at the "structPntr->SetDriveMode(PIN_DM_STRONG);" line and it shows me the correct function address both in foo and in the SetDriveMode function pointer.  However, if I just comment out the "foo = PIN1_SetDriveMode;" line and recompile, it will not work properly and when the debugger halts at the breakpoint, the member values of *structPntr are blank.  I would greatly appreciate any thoughts y'all might have.  Thanks.

0 Likes
13 Replies
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

This is obviously not the complete story: Designer or Creator? PSoC3?? Which compiler??? Can you post your complete project, so that we all can have a look at all of your settings? To do so, use
Creator->File->Create Workspace Bundle (minimal)
and attach the resulting file (do NOT use chrome, that still may not work).

   

 

   

Bob
 

0 Likes
lock attach
Attachments are accessible only for community members.
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

I just programmed and tested your code and I cannot reproduce your issue.

   

 

   

Bob

0 Likes
Anonymous
Not applicable

 I'm using Creator 3.0 SP1.  The project is on a CY8C3666AXI-037.

0 Likes
Anonymous
Not applicable

 structVar.MyFunction = PIN1_SetDriveMode;

   

should read

   

structVar.SetDriveMode = PIN1_SetDriveMode;

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

Yes, I thought so already. Creator 3.0 SP1 is the actual version (so far). For PSoC3 a function which is used via pointer call must be declared as reentrant, I fell into the same pit some time ago.

   

See this www.keil.com/appnotes/files/apnt_129.pdf Keil document describing how2 solve that situation.

   

 

   

Bob

0 Likes
Anonymous
Not applicable

 I remember there are issues with stacks with function pointers as well. Something to do with call tree. It would be better to use PSoC5.

0 Likes
Anonymous
Not applicable

 Thanks, Bob.  I think that is exactly the information I was missing.  What a headache.  In this case I will probably just use a bunch of if statements instead of a function pointer, but this is certainly another argument to use a PSoC 5 instead.

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

Peter, the design of the 8051 is old and the license probably cheap.

   

I had a customer whom I showed PSoCs and he said: "8051? I know that chip, let's use that". Full stop.

   

Even a PSoC4's core (ARM Cortex M0) is faster and quite more modern than the core of the PSoC4.

   

 

   

Bob

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

Typo: ... than PSoC3. (of course)

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

Wait, not all characteristics of 8051 bad -

   

 

   

1) It has, without doubt, the largest code base in the Galaxy, compared to ARM,

   

to draw upon.

   

2) Its silicon is totally bug free or all bugs totally identified. ARM, can we say that,

   

re M0 core  especially ?

   

3. ARM is based on load store architecture i.e data processing instruction can not

   

access memory directly , data has to be stored in a register before processing . 8051

   

can access memory directly.

   

4) Also, the 8051 was designed using a strict Harvard architecture, so it can only execute

   

code fetched from program memory.

   

5) No license fees, unlike ARM, guess who pays for that.

   

6) Tools, 2000+ vendors vs 4 – 5 for ARM ?

   

7) So many more…….

   

 

   

Food for thought, we should still all be on IMSI computers, Dana…….

0 Likes
Anonymous
Not applicable

8051 type of MPU would be here for a while. 

   

However, I think code base of ARM may have already exceeded 8051, most smartphone and tablet are ARM based.

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

Yes in units shipped, but not application specific breadth I would posit.

   

Problems solved, hence varied code solutions, I would bet >> ARM.

   

 

   

Regards, Dana.

0 Likes
Anonymous
Not applicable

We develope projects for low volume production, the management is more concern about time to market. And as most (not all) program are now in C. The CPU is becoming a non-issue to them. Of course, as an eneginner, we still like to discuss the difference of using this chip and that chip. But for the management, they don't really care, as long as the project is finished on time so they can sell the product.

   

Well, that's live.

0 Likes