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).
I'm using Creator 3.0 SP1. The project is on a CY8C3666AXI-037.
structVar.MyFunction = PIN1_SetDriveMode;
structVar.SetDriveMode = PIN1_SetDriveMode;
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.
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.
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.
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.
Typo: ... than PSoC3. (of course)
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…….
Yes in units shipped, but not application specific breadth I would posit.
Problems solved, hence varied code solutions, I would bet >> ARM.
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.