In case somebody does not know, PSoC 3 is based on a C51 core that runs in single cycle execution up to 67 MHz. That is a CPU performance of 67x compared to the original 80C51 running at 12 MHz with 12 cycles / intruction.
Just for reference, PSoC 5 is based on a Cortex-M3
No device is good without supporting tools that create excellent code. Cypress has teamed up with Keil to provide the best 80C51 C-compiler with the most powerful chip with the 80C51 core on the market. Price for the tool? IT IS FREE!
You can download PSoC Creator including the Keil C51 compiler from the Cypress website.
You might wonder if there are any restrictions for the compiler and the answer is "Yes"
Yeah, now comes the catch. Well, you can only use this implementation with Cypress PSoC 3 devices and the version is 8.16. The IDE is Creator, not uVision because Creator is what you need to create your own chip.
Hope you like tha fact that you get development tools worth thousands of $$ for free!
If you have any questions about Cypress and Keil, feel free to ask right here in the forum.
Have fun exploring the incredible possibilities that PSoC 3 offers with Creator and the Keil C51 compiler
More information about Keil and PSoC
Keil compiler licensing if one is already installed
Limit of optimization in the free Keil compiler
The free C51 that comes with PSoC Creator does do some optimization, but it wasn't adequate enough for us so we went ahead and purchased the Keil CA51. Here is the version that we downloaded from the Keil web page: C51 V9.51a. It installs uVision 4. How do you get PSoC creator to use the C51 compiler in uVision?
You can select the compiler from the Project->Build Settings dialog. Pick "DP8051 Keil Generic" from the Toolchain pull-down. Note that you need to do this in every project (a feature to choose your default compiler is on the works).
Depending upon where you installed the compiler, you may also need to tell the tool where to find it. In the Tools->Options dialog. Under Project Management / Generic Toolchains add the full path to the compiler.
I just get Keil license and download and installed the latest version c51v952.exe.
In the PSoc Creator, Tools\Option\Generic Toolchains I put C:\Keil\C51\BIN in DP8051Keil Generic.
But I cannot find C:\Keil\ARM\ARMCC\BIN in my C:\Keil folder
What should I put in ARM MDK Generic ?
In my installation these paths all empty, looks like a default is in effect.
That being said I would think entry should be, based on my distribution, C:\Keil\ARM\BIN
Something about his post does not look right, given this is PSOC 3, which
is not ARM, you might contact author and ask for clarification.
You will get the C:\Keil\ARM\ARMCC\BIN in your C:\Keil folder when you install the MDK-ARM Microcontroller Development Kit. You could buy a licence or download the lite version.
In the mean time just leave it as it was by default.
Since my installed folder Keil do not have ARM sub-folder so that I leave this path not selected.
When I compile Creator sample project :Music_Creation, It generate 151 errors: something like:
L127: UNRESOLVED EXTERNAL SYMBOL SYMBOL: _iAP2_SendPacket
How can I resolve these errors?
If you do not (want to) file a technical case, ask your question, maybe I can help you. I am much older than the 8051 design, so I may know something about.
Thanks. I have a module that I place all my global variables in with little regard for data type and the order in which they are listed. Already quite a lot of values. I'm up around the 84% FLASH and 52% on RAM usage. I placed a new UINT16 and began having other UINT16 variable that are updated ADC readings began getting stomped on. I removed the variable but it didn't fix the problem. I had to drop back to a previously archived version to get the product to work again. I then tried renaming the variable and placing it next to the variables that were getting corrupted and it solved the problem.
I need to understand if there is some issue with byte boundaries or a preferred order for declaring variables. Do I lump all the 8 bits together, all the 16s together etc?
Usualy compiler-errors concerning variable allocation are VERY rare. There is no known issue with 8 and 16-bit wide variables or the order in which they should be declared.
Main source of issues are
You may set a breakpoint to find out from where a variable gets clobbered (access write)
Busted stack sounds interesting.If I'm writing C code, how would I have influence the stack operations? Would that be from being too many subroutines deep?
When we moved to Creator 3.0 with the Keil C99 update, my code had several hundred data type warnings which I cleared up completely through recasting.
I will try some break points and maybe I can trap it. and view the address in the XData memory window. I don't see any absolute listings for my code. There are list files for all the Cypress generated code but not my code. Am I missing something?
This is just very strange. I set a break point and started poking around in memory to see how the variables are structured. I see that const strings are randomly interspersed with integers used to store voltages. It doesn't surprise me that items could get stomped on. I haven't had to go this deep in a long time but I don't recall things being this random. Is there a compiler preference that might places memory in an order similar to earlier versions of the Keil? Something is fundamentally wrong and it's impeding our development.
Du to the (very) old design of the 8051 core the processor only has got 256 Bytes of stack. This is used only for the return-addresses of function calls and not for parameters as would have been done usually.
You name "const strings"
Afaik strings can reside in flash when declared with CYCONST and will not be intermixed with variables.
There is a final .map-file that shows all variables, functions etc with their associated addresses.
To ne honest: I abandoned designing for PSoC3 and I use PSoC5 instead. The reasons are: (much) more modern core, faster core and no restrictions.
Bob, thanks for the input. I will indeed try the CYCONST. I would love to abandon the PSoC3 but the hardware designer won't take the plunge while we still have 10K of code space left.
In further experiments I discovered that ONLY my ADC readings were getting corrupted and my preliminary conclusion is that I have to allow more time for the ADC to do whatever it must to present the last conversion for reading. In my code, I start a conversion and then poll the conversion complete flag before I read. The hardware designer's test program simply waits for a long fixed period of time and never has a problem, which I can't do because our product will go into a customer's machine and live on an RS485 network.
In my program, I removed a call to a routine just after my call the ADC routine and began having the problem.This suggests a time issue. I replaced the call with a CyDelayUs(5) and began doubling that parameter until the problem stopped. There are a number of ways for me to lengthen the time. The bad readings cause alarms to trip and I've noticed that if I clear the error in my code, I force a one second delay and the problem stops. I should take this back to the other thread now that I have a clue that it may be a timing issue with the ADC.