Sharing data between cores

jcook

I understand that variables shared between cores must be declared volatile, but when I use the volatile qualifier on a two dimensional array of unsigned char I get the following warnings at compile time:
ReadTemp_multiple_cog.c: In function 'ReadTemp':
ReadTemp_multiple_cog.c:118:5: warning: passing argument 2 of 'FindDevices' from incompatible pointer type [enabled by default]
ownet.h:110:11: note: expected 'uchar (*)[8]' but argument is of type 'volatile uchar (*)[8]'
ReadTemp_multiple_cog.c:133:9: warning: passing argument 2 of 'owSerialNum' discards 'volatile' qualifier from pointer target type [enabled by default]
ownet.h:96:11: note: expected 'uchar *' but argument is of type 'volatile uchar *'

The code seems to function fine, but I don't like seeing warnings. Are these warnings something to be concerned about and, if so, how can I fix the code?

I have attached the source code in a .zip file.

Heater.

The problem you are facing goes like this:

Imagine you have a function that takes a pointer to an int as a parameter and it is declared something like:

int someFunc(int* x);

Now, someFunc has a pointer to x to play with but it has no idea if x is volatile, that is if x is subject to change by some other process.

That means that if you have optimizations turned on, which is very desirable, then someFunc() may be optimized in ways that you might not expect. It might for example only read x once, and do some long winded work with it, whereas the source code of someFunc() shows x being read many times as the function progresses. The optimizer feels free to do this because it is not aware that x may be volatile. Updates to x by other processes could be missed.

Then you call someFunc() passing it a volatile parameter. someFunc() takes int* not volatile int * so now the fact that x is volatile is lost and bad thing can happen as described above.

That is the story for an int* parameter but also applies to arrays being passed in.

You will probably be OK passing buffers to transmit routines and so forth. You will want to check if your code is actually allowing those buffers, strings, or whatever to be changed whilst the called function is doing it's work on them though.

The compiler is only alerting you to the possible problem.

jcook

Thanks for the explanation. The first warning is for the function that sets the variable value and after that the value is not changed, so I suppose the warnings can be ignored. I prefer to clean up warnings in my code, but in this case I guess I can ignore them.