Importance of global variables

[Anonymous]

 I was working with a project for PSoC5. I had many functions which were callling in chain. One of the function was passing the address of an array to other function (this array was of 300 bytes length) and inturn the called function was passing the array adddresss to other function. oh...seems like messing......  The final function was writing value to the specified address.

   

Compiler which allocates the local memory for a function messed up a bit and the arrray was written with a different value ( i was working with many variables in this function). Compiler might have thought that such a huge memory space for each local variable was not required and tried optimising the data space. 

   

So it is important to have any huge array to be a "global" to prevent messing with the compiler.

[Anonymous]

Are you serious?

   

Does it mean we should stop using PSoC5?

   

How do we know our project doesn't have this problem?

   

Could Cypress support confirm this?

[kemic_264446]

 Something sounds a bit fishy here...

   

If you are only passing the address of the array, thats just a pointer being passed around. The compiler will only push 4 bytes to the stack, not the full size of the array. So sounds like something is not right here!

[Bob_Marlowe]

Well, you trust in your car that it works, you trust in the airplane you use and you ought to trust in the compiler you usually use.

   

When something goes amiss you can be sure that in more than 99.99 percent of the cases it is your mistake (normally it takes you some corrections and a re-build).

   

When searching for the reason of an issue you'll find it probably in your part of the system. If not, you can be darn sure that you exceed any limits within your code let it be stack, heap or parallel access of a variable from an interrupt procedure and from code.

   

There are some VERY surprising behaveours in PSoC3 caused by strange compiler needs for the strange core, but they have been documented although rarely red.

   

For PSoC5 there is a Gnu CC used about which you can say that in every cellphone in the whole wide world more or less code was compiled by that.

   

Having a bug like that one you mentioned would have been detected (and corrected) earlier or was it confirmed by ARM to be a compiler bug?

   

I am using constantly structures like linked lists, using memory from malloc() which all are including pointers in function parameters and since I am not a friend of global vars (when in need I try "static") but I've so far not come to any errorneous behaveour yet.

   

If you are willing to analyze a bug like that, I would try to cut-down the program to the smallest version that shows the error and post that project here, so that we all might have a look at, I am quite optimistic that we could find something...

       

Happy coding

   

Bob

[Anonymous]

Apologize for not clarifying things here earlier. You have nothing to worry about PSoC 5 compiler. Later figured out that I was doing something wrong in my code . I was doing some wrong arithmetic operations on the array pointer for accessing the array elements which ended up  in accessing memory locations beyond the array boundary.  Bottom line - Take special care while dealing with pointers in your code!!    

[ETRO_SSN583]

Working on code compression in a design I gained a lot in the

   

code size by passing pointers to longs, a little less to ints,

   

vs values. In a 32 K design ~ 1.2K gained. Of course speed

   

was enhanced as well.

       

Note passing pointers to native machine size, 8 bits (PSOC 1, 3) ,

   

sometimes bloated code.

       

Regards, Dana.

[ETRO_SSN583]

On the issue of Compiler reliability, I always think of them as a work

   

in progress. I have had fairly mature compilers choke on compound

   

typing of calls, and sometimes bloat a simple task with an api. I have

   

not yet had the opportunity to work with a compiler whose bug list is

   

empty.

       

And from one compiler to another, even for same architecture, code

   

density can be quite disparate.

       

Regards, Dana.

[Bob_Marlowe]

Wiping the sweat from our brows!!! Thanks for a feedback.

   

Pointers in PSoC3 can get weired, depending on their definition they are 4 or 3 bytes long and they may even as I remember be as short as 2 bytes. Yes, I admitt, I grew up in the age of 80xx micros but I never was a friend of the 8051 architecture..

       

Bob