You are here

Keil C51 compiler and PSoC 3 | Cypress

Keil C51 compiler and PSoC 3

Summary: 19 Replies, Latest post by Nick_Danger on 13 Aug 2014 11:14 AM PDT
Verified Answers: 0
Last post
Log in to post new comments.
rtcy's picture
Cypress Employee
112 posts

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

Cheers, Robert

More information about Keil and PSoC

Keil compiler registration

Keil compiler licensing if one is already installed

Limit of optimization in the free Keil compiler

Azlan's picture
User
12 posts

 uVision allows setting the code editor font and size where creator does not.

marshg1's picture
User
5 posts

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?

yfs
yfs's picture
Cypress Employee
101 posts

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.

 

Happy compiling!

Mark.

 

yfs
yfs's picture
Cypress Employee
101 posts

Here is the image I managed to fail to add to the last post!

 

Learn's picture
User
2 posts

 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 ?

user_14586677's picture
User
7293 posts

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

 

Regards, Dana.

user_14586677's picture
User
7293 posts

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.

 

Regards, Dana.

user_14586677's picture
User
7293 posts

Or contact Robert, thread originator, rtcy@cypress.com, and ask he pass

onto yfs, Mark, include the thread link and ask Mark why he was parametizing

ARM build settings on a PSOC 3.

 

Regards, Dana.

user_39759791's picture
User
357 posts

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.

Learn's picture
User
2 posts

 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? 

user_1377889's picture
User
5983 posts

Robert left Cypress one year ago, better try to find someone else or file a technical case.

 

Bob

Nick_Danger's picture
User
90 posts

Hi,

I suspect I am having a problem with how the Keil is managing memory on a PSoC 3 using Creator 3.0.

Who should I contact?

Thank you,

Nick

user_1377889's picture
User
5983 posts

@Nick

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.

 

Bob

Nick_Danger's picture
User
90 posts

Bob,

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?

user_1377889's picture
User
5983 posts

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

-Bad pointers

-Busted stack

-Ignored warnings

You may set a breakpoint to find out from where a variable gets clobbered (access write)

 

Bob

Nick_Danger's picture
User
90 posts

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?

 

Nick_Danger's picture
User
90 posts

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.

user_1377889's picture
User
5983 posts

Stack:

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

Nick_Danger's picture
User
90 posts

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.

Log in to post new comments.