- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I'm using Creator 3.0 SP1. The project is on a CY8C3666AXI-037.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
structVar.MyFunction = PIN1_SetDriveMode;
should read
structVar.SetDriveMode = PIN1_SetDriveMode;
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Typo: ... than PSoC3. (of course)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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…….
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes in units shipped, but not application specific breadth I would posit.
Problems solved, hence varied code solutions, I would bet >> ARM.
Regards, Dana.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.