SharedArea

Think about data structures like a STRING, ARRAY or STRUCT

We can model this kind of data structures in a general way as a block of data with an start address pData and a size udiDataSize:

../../_images/SharedArea.png

In CODESYS this kind of structures may be declared as following:

sString : STRING(255) := 'The quick brown fox jumps over the lazy dog';
wsString : WSTRING(255) := "✞♄℮ ⓠʊї¢к ♭ґøωη ḟ◎✖ ʝυღ℘﹩ øṽℯґ ⊥ℌ℮ ʟ@ℨƴ ḓøℊ";
aiArray : ARRAY[0..9] OF INT := [2,3,5,7,11,13,17,19,23,29];

TYPE STRUCTURE :
STRUCT
    sString : STRING(255);
    wsString : WSTRING(255);
    aiArray : ARRAY[0..9] OF INT;
END_STRUCT
END_TYPE

myStructure : STRUCTURE := (sString:=sString, wsString:=wsString, aiArray:=aiArray);

In a single-core environment a simple function call to SysMemCpy will be enough to assign the content of this variables to a other variable.

SysMemCpy(pDest:=ADR(sOtherString), pSrc:=ADR(sString), udiCount:=DINT_TO___XWORD(MIN(LEN(sString), SIZEOF(STRING(255)))));

This approach will not result in a consistent content of the other variable if we execute this statement in a multi-core environment and there are multiple writers and/or multiple readers at the same point in time on the same memory area.

In a typical application we will have some writers for each area and multiples readers.

../../_images/application.png

The basic idea for an proper implementation approach is based on the possibility to assign the data types POINTER or INTERFACE consistently in a multi-core environment with a simple assignment statement.

pElement := ADR(element);
itfString := StringBuilder('The quick brown fox');

The problem which is left is: How can we implement a adequate SysMemCpy in a multi-core environment.

The function block SharedArea and its methods will solve this problem.