PSoC Creator 3.0

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

cross mob
ScEn_283436
Level 5
Level 5
5 sign-ins First solution authored 100 replies posted

Hi,

   

Is anyone else having strange problems with PSoC Creator 3.0?

   

void main() is getting a warning that  "return type of 'main' is not int". I pretty knew that when I wrote the program.

   

Also, as I move down the module, the first subroutine after main() is being treated as a function call or a prototype, I can't tell. It's full error, not a warning. It's says it's looking for a semicolon. I already have a prototype at the top of the module.

   

It doesn't seem to me that an upgrade to the compiler should cause hard errors on a program that would previously build with no errors or warnings.

   

Nick

0 Likes
1 Solution
HeLi_263931
Level 8
Level 8
100 solutions authored 50 solutions authored 25 solutions authored

All the examples you brought up where actually cases of unsafe code before. With the compilers advancing, and needing to generate tighter and faster code, such code can actually lead to more bugs (because the compiler then assumes things which aren't true).

   

The ISR you mentioned which didn't work after you removed the warning: care to share the code?

   

Regarding the const char *- yes, the compiler is right. 'const char *' defined a pointer to a constant char array, meaning this array of characters is thought to be never changed. If you now hand over this pointer as a 'char *', it suddenly is now mutable, and any code getting this pointer is free to do so. Thats why the compiler warns you about that. (and thats the reason why the first argument of memcpy isn't const, but the second is - this function guarantees not to modify its source. If the second parameter wasn't const, memcpy would be perfectly allowed to screw around with the data there).

   

I once read a book about 'bug free C programming' (an oxymoron in itself, I know). It had a list of all the code which will get accepted by a C compiler (because the standard allows it), but which is unsafe or even undefined. The list was in 6pt font and about 15 pages long or so. And each item of this list, when in a program, can lead to a bug (and be it just because the compiler handles it differently after an update, or for some other reason).

View solution in original post

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

Yes on main( ) being declared as int, looks like it isnow consistent with other typing

   

and standard.

   

 

   

As far as f()'s following main( ), I have always placed protos and ISR f( ) before main( ),

   

then actual f( )'s after main( ). So I experience no change.

   

 

   

Regards, Dana.

0 Likes
Anonymous
Not applicable

Started usign PSoC3 this week.

   

Didn't notice the change about return type of main as it didn't give you warning while building the project. That warning only shown on the source file of main.c.

   

Have you tried archieve the whole project, clean up the folder of your project, unzip the files to the folder and start a clean build?

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

There are a handfull of issues with the Creator 3.0 IDE, go through the items you find here www.cypress.com/.

   

I think a new release is to come in february 2014, so stay tuned.

   

For me the code-completion and the code explorer are a big help, preventing me from mis-spelling my own (and foreign) routine names, really saves some time.

   

 

   

Bob

0 Likes
mattl_01
Employee
Employee
100 replies posted 50 replies posted 25 replies posted

 I believe there was a change to make main() more ANSI compliant.  The warning will have no effect on your design.

0 Likes
ScEn_283436
Level 5
Level 5
5 sign-ins First solution authored 100 replies posted

It looks like C99 requires an explicit 'int main' where it was once implied.

0 Likes
ScEn_283436
Level 5
Level 5
5 sign-ins First solution authored 100 replies posted

@ Daana

   

"As far as f()'s following main( ), I have always placed protos and ISR f( ) before main( ),

   

then actual f( )'s after main( ). So I experience no change."

   

Interesting, I had an error on my ISR  function. The prototype was before main and the function() after. I removed the prototype and placed routine before main and it cleared the error. Is this a Cypress only requirement or a coding standard issue?

   

Nick

0 Likes
ScEn_283436
Level 5
Level 5
5 sign-ins First solution authored 100 replies posted

The most annoying part is having to go through the entire project getting rid of warnings for trying to transmit const error messages. Warnings about const char8 and char8 discarding qualifiers seems unwarranted.

   

Nick

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

To help me out of the impacts of compiler ot target changes I use for my professional products always an own .h-file which I #include into every of my other .h files. Here I #define or typedef my own preferred constants, macros and datatypes, my beloved "forever", TRUE and FALSE and whatever I like. So when a target or compiler change is due most of the alterations needed are applied to that file. The newest version of GCC seems to be more restrict which I really welcome, since each restrictions prevents me from assuming a default behaveour which sometimes goes wrong and is later on hard to detect.

   

So try to get all your files warning-free and relax.

   

 

   

Bob

0 Likes
ScEn_283436
Level 5
Level 5
5 sign-ins First solution authored 100 replies posted

That's good advice and I actually do something like that. What I just don't understand is why there would be a warning for copying a const string of char8 to a transmit buffer of char8.  All these years of everyone from Fred Sanford to P.J. Plauger saying that const should be used on items that aren't likely to change and that const affects where the items are placed in memory. Now I have to ignore that and remove the const declarations in the .h files or recast everything as I'm writing the code. Doesn't that seem fundamentally wrong?

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

Kernighan and Ritchie didn't have computers with Harvard-architecture, so the "const" qualifier now has the meaning of putting the qualified variable into flash-memory. So when you want to copy something from flash to ram you'll have to type-cast it accordingly. Depending on your chip things can get (much) more complicated: On a PSoC3 a pointer's upper address-part containes a "descriptor" that specifies in which area of the memory-layout the target lies.

   

 

   

Bob

0 Likes
HeLi_263931
Level 8
Level 8
100 solutions authored 50 solutions authored 25 solutions authored

IMHO the compiler is right to warn about that. Const is there for a reason (or even two).

   

First, it allows to designate memory areas / variables whoich should not be changed (e.g. a string constant). This allows the compiler to place them into flash, saving you sRAM.

   

Second, its a guarantee by methods that they won't modify the memory areas handed over to them as parameters. If a method specifies a parameter as const, the compiler will ensure that it won't be modified.

   

So methods which don't specify their parameters as const are free to modify them. And if you then cheat the compiler by casting a const char into just char, code might want to try to wrote into flasdh memory, and just crash.

   

Casting a const char* pointer into char* should be a warning (but not the other way round).

   

I once read the suggestion to write a C compiler which, whenever it detects code which is defined by the C specification as 'undefined', just inserst to code to wipe out the complete hard drive. Would be perfectly legal and teach the developers to write proper code 🙂 (Unfortunately, the list of 'undefined' is rather huge in C...)

0 Likes
HeLi_263931
Level 8
Level 8
100 solutions authored 50 solutions authored 25 solutions authored

Really copying a memory area / string from flash to RAM (with memcpy) doesn't need a cast from const char to char* (see http://www.cplusplus.com/reference/cstring/memcpy/ - the src argument of memcpy is const).

   

Only when you want to hand over the flash-pointing pointer (being a const char*) onto a method which wants to get just a char*, you need that. But then the called method is free to do what it wants, including crashing your program.

   

(Maybe I should write a compiler which sends me one cent everytime it detects undefined behaviour 🙂

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

"I once read the suggestion to write a C compiler which, whenever it detects code which is defined by the C specification as 'undefined', just inserst to code to wipe out the complete hard drive."

   

 

   

I would have been Maxtors/Seagates largest customer  should that edict have

   

been in place. 🙂 Thats pretty funny.

   

 

   

Regards, Dana.

0 Likes
Anonymous
Not applicable

Well, you can re-use the HD after wiping the disk 

   

Howabout a "CRASH the head" command. Or changing the speed of the disk to play a song.

0 Likes
ScEn_283436
Level 5
Level 5
5 sign-ins First solution authored 100 replies posted

My program uses strcpy. I have an array of hard coded const char8 message strings which get copied to a serial transmit buffer of char8.

   

   

strcpy(OUTbuffer, msg);

       

   

So now copying const strings to RAM is a problem that warrants a warning? 

0 Likes
ScEn_283436
Level 5
Level 5
5 sign-ins First solution authored 100 replies posted

   

const char8 errMsg[9][24] =

   

   

   

{

   

   

   

  { "0,No errors" }, // NO_ERR     

   

...

...

};

   

   

void transmit(char8 *msg) ;

   

   

transmit(errMsg[PASS_NEEDED]);

   

 

------------------

The above code gets the warning: "passing 'const char8[24] to parameter of 'char *' discards qualifiers"

 

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

Yes Nick, that IS worth a warning! On the other hand this code will not even run on a PSoC1 (and an error is thown at compile-time).

   

There is a difference of const * char, * char and even * const char. What hinders you to write down a cast that supresses the warning and expresses what you want to do?

   

 

   

Bob

0 Likes
ScEn_283436
Level 5
Level 5
5 sign-ins First solution authored 100 replies posted

Well, I'm sorry I just happen to disagree based on the fact that code compiled without warnings in all  the previous versions. Please focus on that fact. It means that I have to spend days going through code recasting items inorder to use 3.0. People's time is worth something.

0 Likes
ScEn_283436
Level 5
Level 5
5 sign-ins First solution authored 100 replies posted

The question I would like one of you to address is WHY NOW AND NOT BEFORE???

   

I've implemented this code with 2 different compilers on Freescale controllers and PSoC Creator 1.0 through 2.2 on the PSoC 3.

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

I am not quite fit with the internals of the KEIL compiler, but for GCC (used for PSoC5) you may disable any warning by appending an appropiate parameter to the compile-step call.

   

Why now? You're right, could have been found earlier, but wasn't. I'm afraid you'll have to swallow that toad.

   

 

   

Bob

0 Likes
ScEn_283436
Level 5
Level 5
5 sign-ins First solution authored 100 replies posted

No, Bob. The company will swallow the toad in terms of my time.

   

I appreciate your help. I've subsequently opened a case because this seems fundamentally flawed. The const cast and the header file should be all you need. Recasting char8 is redundant.

0 Likes
ScEn_283436
Level 5
Level 5
5 sign-ins First solution authored 100 replies posted

I noticed in a post people can update their components but stick with a particular version of Creator.

   

In discussing this with the EE here, we thought that it was best to use the latest version of Creator.

   

Is it ok to update the components and leave creator as is? When I've had issues in the past, the support team always suggested that I upgrade Creator.

0 Likes
Anonymous
Not applicable

Yes, it is annoying to found those issues by upgrading the development tool which are from the same company that made the previous one. I have a project that works in creator 2 but not in creator 3, still waiting for Cypress to fix it for me.

   

However, I would rather have warning from the tool then not having it, as long as we have the option to disable that warning.
 

   

We are going to encounter those issues more often as more and more company started using the static annalise tool as part of the QA policy to scan for potential software bugs and weakness.
 

0 Likes
ScEn_283436
Level 5
Level 5
5 sign-ins First solution authored 100 replies posted

HL, I agree that it is probably better to have the warning, but C has been around for 40 years and it's a bit annoying that at some random point in time, the rules change, impacting tons of legacy code. If this were really necessary, why wasn't it done 30, 20, or 10 years ago. Why now?

   

Copying a const string from wherever it may be stored, to a buffer is not a potential problem any kind of way and doesn't warrant a warning. Const dictates where the information that doesn't change is stored. The warning should come when the program attempts to write from non-const to const, not the other way around.

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

Nick,

   

you always may lodge a complaint addressed to KEIL regarding that matter. Probably they can show you a way out or explain a bit more.

   

 

   

Bob

0 Likes
ScEn_283436
Level 5
Level 5
5 sign-ins First solution authored 100 replies posted

Bob,

   

I did go to Keil.com and started poking around the C51 Development Tools section. There are some pdfs that explain why some things were done because of the 8051 architecture, which someone mentioned earlier. This might turn out to be a good thing for me in that it made me dig into the C99 spec and review some things. I don't see the warning on const to non-const as being a C99 issue yet but I'm still going through it.

   

Thanks again for your help. Sorry to come off angry but typically upgrades come with a couple of gotchas where this one shotgun blasted my program.

   

Nick

0 Likes
lalec_300236
Level 1
Level 1
First like received

Yes, I can feel your frustration as I have a product switch to 5LP and would not build with the new creator 3.

0 Likes
ScEn_283436
Level 5
Level 5
5 sign-ins First solution authored 100 replies posted

I have contacted Keil about the shotgun blast of warnings for copying const strings to a serial output buffer. They don't agree that it warrants a warning and had me go into a directory and launch UV4.exe to make sure my license renewal had taken effect. I will now start from scratch with the program extracting it to a new directory and see what happens.

0 Likes
ScEn_283436
Level 5
Level 5
5 sign-ins First solution authored 100 replies posted

OK. so the licensing procedure didn't clear up the warnings. What I want to know is, do people who don't want to put their company's product line in jeopardy when upgrading PSoC Creator simply stay with a particular version and only upgrade the components?

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

Nick file a CASE on his and point to this thread. This is a situation

   

that Cypress end cutomer management ought to have cured in a

   

hurray to restore confidence in product release, etc..

   

 

   

    

   

          

   

To file a tech case -

   

 

   

www.cypress.com

   

“Support”

   

“Technical Support”

   

“Create a MyCase”

   

   

 

   

Regards, Dana

0 Likes
ScEn_283436
Level 5
Level 5
5 sign-ins First solution authored 100 replies posted

I did open a case and they said it was a Keil issue but also that it doesn't affect how the code behaves in the product. Keil said it was a license thing. This is like an episode of the Twilight Zone. I'm not going to lower the warning level. Warnings are there for a reason and as a matter of consistency I have to address them.

   

Here's another example. I took this code straight out of Cypress example code early in the project. This now gives the warning that the while loop has an empty body.

   

   

while(USBUART_1_CDCIsReady() == 0u);

   
0 Likes
markgsaunders
Employee
Employee
50 sign-ins 10 solutions authored 5 solutions authored

Sorry you are having a less-than-awesome experience with 3.0. Do you get errors/warnings from the compiler during a build, or are you getting the icons in the left margin? Or both? The compiler has not actually changed. We ship v9.51 of the Keil compiler, which is the same one we shipped in the 2.2 release. Are you updating from an older version?

The messages that pop up in the editor window (as opposed to the notice list) are generated from a tool called CLANG, which does a background (as you type) check for C99 violations. I strongly suspect it is these messages that are the problem here. There is a very close, but not 100%, correlation between the messages that CLANG reports and the things that the Keil compiler reports. I suspect you are seeing new warnings in the editor window but they are not present in the compiler output.

The CLANG diagnostics are intended to be a pre-build heads-up about potential issues. The goal is to save our users time. I am sorry that it appears to be having the opposite effect for you. But please be aware that CLANG is not intended to replace the actual compiler. I think of it in the same way as LINT. It is an optional syntax checker that is conveniently integrated into the tool. When viewed from that perspective an argument could be made that, since CLANG is not a part of the actual tool-chain, the messages should be considered aids to you making a design and not a code quality yard-stick.

That is, of course, not my decision to make. I am sorry that your laudable rigor is at odds with this intended-to-be-helpful feature of the 3.0 software.

-- mgs

0 Likes
ScEn_283436
Level 5
Level 5
5 sign-ins First solution authored 100 replies posted

According to Keil:

   

PSOC creator 3.0 uses C51 v 9.51.
PSOC Creator 2.2 used C51 v 9.03.
 

   

Yes, it's the warnings in the editor window. We have an electrical engineer who I try to stay synchronized with on PSoC Creator versions because of earlier situations where something would work in his little one subroutine hardware exercise program versus my full blown product application with several code modules. The reflex reaction was to blame my code but it turned out that I was using an earlier version.Wisely, I now do the upgrades on a separate desktop PC and do the product coding on a laptop.

   

CLANG might be helpful on a new design but legacy code it's insanity and some of the warnings just seem wrong.

   

Here is an example. I have a hard coded const list. If I create a pointer on the stack in a subroutine to parse through the list, I have to declare the stack variable as const to make the warning disappear. That can't be right.

   

   

typedef struct

   

   

{

   

const char8 keyword[16];

       

const int32 *calSpace;

   

} cal_pairs;

0 Likes
markgsaunders
Employee
Employee
50 sign-ins 10 solutions authored 5 solutions authored

I'm sorry - I did not double-check the compiler version from 2.2. But the issue is with CLANG.

   

I agree that CLANG is handy when you are working on new development and becomes less valuable with stable code because the complaints are less likely to be relevant. Did you know that you can turn the messages off (I do, by the way, because I kinda know C syntax and get distrated by it telling me about things I have simply not done yet but know I need to do).

   

In the Tools->Options dialog under Text Editor / General there is a checkbox for "Enable inline diagnostics". Uncheck that guy and the messages go away.

   

-- mgs

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

Hmmm, let me put my 2 cents to this: this is a >30 post threads and finally it turns out that the disturbing messages can be switched-off! That smells a bit (or byte) like a lack of documentation. I admitt that in the world of GCC I could have switched off the resulting warnings, but something like CLANG (sounds as if from Terry Pratchett) I've so for not heard of. Is there a deeper-going description?

   

 

   

Bob

0 Likes
ScEn_283436
Level 5
Level 5
5 sign-ins First solution authored 100 replies posted

So basically, some guys at Keil just randomly decided to drop a bomb because they felt like it is how I see it. This is craziness. There are other things that no longer work once I went through and cleared up all the warnings, such as the ISR I implemented to keep track of time. No big deal, it's just the basis of the whole functionality of the program.

   

Here is the feedback I got from Keil:

   

 From Me:

   

My question still holds. In the previous versions, this was not flagged with a warning. Does
this have to do with C99?

 

   

From Keil Support:

   


*** 2013-12-23  15:18 UTC *** /ARM:1025414 ***

I doubt it has anything to do with C99.  We made these changes somewhere between 2011 and 2013.

At some point, I believe the developers tightened up the rules over what the tools can
"silently" cast from one type to another.  Most of these changes were things the user
"shouldn't" have done before, but we assumed we knew what the program was supposed to do.  I
seem to remember we ran into some issues with certification, because of this.
 

0 Likes
HeLi_263931
Level 8
Level 8
100 solutions authored 50 solutions authored 25 solutions authored

All the examples you brought up where actually cases of unsafe code before. With the compilers advancing, and needing to generate tighter and faster code, such code can actually lead to more bugs (because the compiler then assumes things which aren't true).

   

The ISR you mentioned which didn't work after you removed the warning: care to share the code?

   

Regarding the const char *- yes, the compiler is right. 'const char *' defined a pointer to a constant char array, meaning this array of characters is thought to be never changed. If you now hand over this pointer as a 'char *', it suddenly is now mutable, and any code getting this pointer is free to do so. Thats why the compiler warns you about that. (and thats the reason why the first argument of memcpy isn't const, but the second is - this function guarantees not to modify its source. If the second parameter wasn't const, memcpy would be perfectly allowed to screw around with the data there).

   

I once read a book about 'bug free C programming' (an oxymoron in itself, I know). It had a list of all the code which will get accepted by a C compiler (because the standard allows it), but which is unsafe or even undefined. The list was in 6pt font and about 15 pages long or so. And each item of this list, when in a program, can lead to a bug (and be it just because the compiler handles it differently after an update, or for some other reason).

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

Hli, is there on online copy of that book ? Or Title/Author ?

   

 

   

Regards, Dana.

0 Likes
HeLi_263931
Level 8
Level 8
100 solutions authored 50 solutions authored 25 solutions authored

@dana: that was about 15 years ago - my memory is not good enough for that 😞

   

I thought it might be 'no bugs!' by David Thielen, of 'Writing Solid Code' by Steve McGuire, but the online versions I could find for them have no such list in them.

   

But I found some other references, which might be helpful:

   
0 Likes