1 2 3 4 Previous Next 54 Replies Latest reply on Jan 30, 2014 6:30 PM by RobynW_26

    PSoC Creator 3.0




      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.



        • 1. Re: PSoC Creator 3.0

          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.

          • 2. Re: PSoC Creator 3.0

            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?

            • 3. Re: PSoC Creator 3.0

              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.





              • 4. Re: PSoC Creator 3.0

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

                • 5. Re: PSoC Creator 3.0

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

                  • 6. Re: PSoC Creator 3.0

                    @ 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?



                    • 7. Re: PSoC Creator 3.0

                      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.



                      • 8. Re: PSoC Creator 3.0

                        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.





                        • 9. Re: PSoC Creator 3.0

                          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?

                          • 10. Re: PSoC Creator 3.0

                            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.





                            • 11. Re: PSoC Creator 3.0

                              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...)

                              • 12. Re: PSoC Creator 3.0

                                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 :)

                                • 13. Re: PSoC Creator 3.0

                                  "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.

                                  • 14. Re: PSoC Creator 3.0

                                    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.

                                    1 2 3 4 Previous Next