METHOD AND SYSTEM FOR HANDLING DATA VALUES AND STRUCTURE IN A MEMORY

Abstract

A method and system allow to store and retrieve data values and data structure in a memory of an embedded system, the memory also storing executable code uploaded to the embedded system by a first external system through a first version of a firmware. A serializer is configured to receive from the executable code, sizes of data, corresponding to a number of chunks of the data, together with values of the chunks, to form a series of bytes therewith through concatenation, to calculate a total size of the series of bytes, and to write to the memory, successively the total size and the formed series of bytes. A deserializer is configured to read from the memory, successively a total size and a series of bytes, to deconcatenate the series of bytes into successively sizes of data, corresponding to a number of chunks of the data, together with values of the chunks, and to send the same to the executable code.

Claims

1. A method to store data values and data structure in a memory of an embedded system, the memory also storing executable code uploaded to the embedded system by a first external system through a first version of a firmware, the method comprising: receiving at a serializer, from the executable code, with i ranging from 1 to a maximum number of data: the size, S.sub.i, of a data, D.sub.i, the size S.sub.i corresponding to a number of chunks, D.sub.ij, forming the data D.sub.i, with j ranging from 1 to S.sub.i; and for each data D.sub.i, the value for each of the chunks D.sub.ij; forming by the serializer a series of bytes, obtained through concatenation of successively S.sub.i and D.sub.ij, with j ranging from 1 to S.sub.i, for i ranging from 1 to the maximum number of data; calculating a total size, S.sub.tot, as the sum of bytes in the formed series of bytes, plus a predetermined number of bytes, R; and writing by the serializer, to the memory, successively the total size S.sub.tot on R bytes, and the formed series of bytes.

2. The method of claim 1, further comprising: adding to the total size S.sub.tot a number of bytes, R, R being a predetermined number of bytes; calculating a CRC on the total size S.sub.tot on R bytes, and the formed series of bytes; and appending by the serializer the CRC on R bytes, to the total size S.sub.tot on R bytes, and the formed series of bytes written to the memory.

3. The method of claim 2, wherein the CRC is calculated by the serializer.

4. The method of claim 2, wherein the CRC is calculated by the executable code and transmitted to the serializer.

5. The method of claim 1, wherein the total size S.sub.tot is calculated by the serializer.

6. The method of claim 1, wherein the total size S.sub.tot is calculated by the executable code and transmitted to the serializer.

7. The method of claim 1, wherein a subsequent second version of the firmware uploads to the embedded system executable code whereby the maximum number of data is modified.

8. The method of claim 1, wherein a subsequent second version of the firmware uploads to the embedded system executable code whereby the sizes S.sub.i, the data D.sub.i, and the values of the chunks D.sub.ij are identical to those transmitted to the serializer by the executable code of the first version of the firmware, but the order in which they are transmitted to the serializer by the executable code of the second version of the firmware is different.

9. The method of claim 1, wherein a second external system transmits to the executable code a data, D.sub.i, of a size, S.sub.i, corresponding to a number of chunks, D.sub.ij, the method further comprising receiving at the serializer, from the executable code, with i ranging from 1 to the maximum number of data: the size S.sub.i of the data D.sub.i, and the value for each of the chunks D.sub.ij; wherein for one of the i, the size S.sub.i of the data, D.sub.i, and the value for each of the chunks D.sub.ij is replaced by the size S.sub.i of the data D.sub.i, and the value for each of the chunks D.sub.ij.

10. A method to retrieve data values and data structure from a memory of an embedded system, the memory also storing executable code uploaded to the embedded system by an external system through a firmware, the method comprising: reading at a deserializer, from the memory, successively a total size S.sub.tot on first R bytes, R being a predetermined number of bytes, and a series of bytes on next (S.sub.tot?R) bytes; deconcatenating by the deserializer the series of bytes into successively a size, S.sub.i, of a data, D.sub.i, the size S.sub.i corresponding to a number of chunks, D.sub.ij, forming the data D.sub.i, with j ranging from 1 to S.sub.i, and values of the chunks D.sub.ij for the data D.sub.i, with i ranging from 1 to a maximum number of data; and sending by the deserializer to the executable code, the size S.sub.i of each data D.sub.i, and for each data D.sub.i, the values for each of the chunks D.sub.ij forming the data D.sub.i, with j ranging from 1 to S.sub.i, for all i respectively.

11. The method of claim 10, further comprising: reading at the deserializer, from the memory, a CRC on a predetermined number of bytes, R, after the series of bytes; calculating a CRC on the total size S.sub.tot on R bytes, and the series of bytes; comparing the values of the read CRC and the calculated CRC, and if they are not identical, raising an alert.

12. The method of claim 11 wherein the calculating the CRC, the comparing the values of the read CRC and the calculated CRC, and the raising an alert, is performed at the deserializer.

13. The method of claim 11 wherein the read CRC is transmitted by the deserializer to the executable code, and the calculating the CRC, the comparing the values of the read CRC and the calculated CRC, and the raising an alert, is performed at the executable code.

14. A system to store and retrieve data values and data structure in a memory of an embedded system, the memory also storing executable code uploaded to the embedded system by an external system through a firmware, the system comprising: a serializer configured to: receive from the executable code, with i ranging from 1 to a first maximum number of data: the size, S.sub.i, of a data, D.sub.i, the size S.sub.i corresponding to a number of chunks, D.sub.ij, forming the data D.sub.i, with j ranging from 1 to S.sub.i; and for each data D.sub.i, the value for each of the chunks D.sub.ij; form a first series of bytes, obtained through concatenation of successively S.sub.i and D.sub.ij, with j ranging from 1 to S.sub.i, for i ranging from 1 to the first maximum number of data; and write to the memory, successively a total size S.sub.tot on R bytes, R being a predetermined number of bytes, and the formed first series of bytes; and a deserializer configured to: read from the memory, successively a total size S.sub.tot on first R bytes, and a second series of bytes on next (S.sub.tot?R) bytes; deconcatenate the second series of bytes into successively a size, S.sub.i, of a data, D.sub.i, the size S.sub.i corresponding to a number of chunks, D.sub.ij, forming the data D.sub.i, with j ranging from 1 to S.sub.i, and values of the chunks D.sub.ij for the data D.sub.i, with i ranging from 1 to a second maximum number of data; and send to the executable code, the size S.sub.i of each data D.sub.i, and for each data D.sub.i, the values for each of the chunks D.sub.ij forming the data D.sub.i, with j ranging from 1 to S.sub.i, for all i respectively; the system being further configured to calculate the total size, S.sub.tot, as the sum of bytes in the formed first series of bytes, plus R bytes.

15. The system of claim 14, wherein the serializer is further configured to: add to the total size S.sub.tot a number of bytes, R, R being a predetermined number of bytes; calculate a CRC on the total size S.sub.tot on R bytes, and the formed series of bytes; and append the CRC on R bytes, to the total size S.sub.tot on R bytes, and the formed series of bytes written to the memory.

16. The system of claim 14, wherein a subsequent second version of the firmware uploads to the embedded system executable code whereby the maximum number of data is modified.

17. The system of claim 14, wherein a subsequent second version of the firmware uploads to the embedded system executable code whereby the sizes S.sub.i, the data D.sub.i, and the values of the chunks D.sub.ij are identical to those transmitted to the serializer by the executable code of the first version of the firmware, but the order in which they are transmitted to the serializer by the executable code of the second version of the firmware is different.

18. The system of claim 14, wherein a second external system transmits to the executable code a data, D.sub.i, of a size, S.sub.i, corresponding to a number of chunks, D.sub.ij, the serializer being further configured to receive, from the executable code, with i ranging from 1 to the maximum number of data: the size S.sub.i of the data D.sub.i, and the value for each of the chunks D.sub.ij; wherein for one of the i, the size S.sub.i of the data, D.sub.i, and the value for each of the chunks D.sub.ij is replaced by the size S.sub.i of the data D.sub.i, and the value for each of the chunks D.sub.ij.

19. The system of claim 14, further configured to: read at the deserializer, from the memory, a CRC on a predetermined number of bytes, R, after the series of bytes; calculate a CRC on the total size S.sub.tot on R bytes, and the series of bytes; and compare the values of the read CRC and the calculated CRC, and if they are not identical, raise an alert.

20. The system of claim 19, wherein the calculating the CRC, the comparing the values of the read CRC and the calculated CRC, and the raising an alert, is performed at the deserializer.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0052] For a better understanding of the present technology, as well as other aspects and further features thereof, reference is made to the following description which is to be used in conjunction with the accompanying drawings, where:

[0053] FIG. 1 illustrates an environment where the present technology may be used;

[0054] FIG. 2 provides an example of a series of memory data, as part of firmware to be uploaded to an embedded system;

[0055] FIG. 3 illustrates an example of a modified series of data with added data, as part of a different version of the firmware;

[0056] FIG. 4 illustrates an example of a modified series of data with inverted data, as part of a different version of the firmware;

[0057] FIG. 5 illustrates an example of method steps that may be executed by a serializer according to the present technology; and

[0058] FIG. 6 illustrates an example of method steps that may be executed by a deserializer according to the present technology.

[0059] It should be noted that, unless otherwise explicitly specified herein, the drawings are not to scale. Finally, elements that are identical from one drawing to the other bear the same numeral reference across drawings.

DETAILED DESCRIPTION

[0060] The examples and conditional language recited herein are principally intended to aid the reader in understanding the principles of the present technology and not to limit its scope to such specifically recited examples and conditions. It will be appreciated that those skilled in the art may devise various arrangements which, although not explicitly described or shown herein, nonetheless embody the principles of the present technology and are included within its spirit and scope.

[0061] Furthermore, as an aid to understanding, the following description may describe relatively simplified implementations of the present technology. As persons skilled in the art would understand, various implementations of the present technology may be of a greater complexity.

[0062] In some cases, what are believed to be helpful examples of modifications to the present technology may also be set forth. This is done merely as an aid to understanding, and, again, not to define the scope or set forth the bounds of the present technology. These modifications are not an exhaustive list, and a person skilled in the art may make other modifications while nonetheless remaining within the scope of the present technology. Further, where no examples of modifications have been set forth, it should not be interpreted that no modifications are possible and/or that what is described is the sole manner of implementing that element of the present technology.

[0063] Moreover, all statements herein reciting principles, aspects, and implementations of the present technology, as well as specific examples thereof, are intended to encompass both structural and functional equivalents thereof, whether they are currently known or developed in the future. Thus, for example, it will be appreciated by those skilled in the art that any block diagrams herein represent conceptual views of illustrative circuitry embodying the principles of the present technology. Similarly, it will be appreciated that any flowcharts, flow diagrams, state transition diagrams, pseudo-code, and the like represent various processes which may be substantially represented in computer-readable media and so executed by a computer or processor, whether or not such computer or processor is explicitly shown.

[0064] The functions of the various elements shown in the figures, including any functional block, may be provided through the use of dedicated hardware as well as hardware capable of executing software in association with appropriate software. When provided by a processor, the functions may be provided by a single dedicated processor, by a single shared processor, or by a plurality of individual processors, some of which may be shared. In some aspects of the present technology, the processor may be a general purpose processor, such as a central processing unit (CPU) or a processor dedicated to a specific purpose, such as a digital signal processor (DSP). In the aforementioned, explicit use of the term a ?processor? should not be construed to refer exclusively to hardware capable of executing software, and may implicitly include, without limitation, application specific integrated circuit (ASIC), field programmable gate array (FPGA), read-only memory (ROM) for storing software, random access memory (RAM), and non-volatile storage. Other hardware, conventional and/or custom, may also be included.

[0065] Software modules, or simply modules which are implied to be software, may be represented herein as any combination of flowchart elements or other elements indicating performance of process or method steps and/or textual description. Such modules may be executed by hardware that is expressly or implicitly shown. Moreover, it should be understood that ?module? may include for example, but without being limitative, computer program logic, computer program instructions, software, stack, firmware, hardware circuitry or a combination thereof which provides the required capabilities.

[0066] With these fundamentals in place, we will now consider some non-limiting examples to illustrate various implementations of aspects of the present technology.

[0067] FIG. 1 illustrates an environment where the present technology may be used. An Embedded system 110 may for example comprise various hardware components including a Processor 101, a Memory 103 and an Input/output interface 104. In this context, the Processor 101 may or may not be included in a FPGA. The Processor 101 may be an off the shelf generic computing system. In some aspect, the Processor 101 may also be distributed amongst multiple computing systems. As a person skilled in the art may appreciate, multiple variations as to how the Processor 101 is implemented may be envisioned without departing from the scope of the present technology.

[0068] Communication between the various components of the Embedded system 110 may be enabled by one or more internal and/or external Buses 105 (e.g. a PCI bus, universal serial bus, IEEE 1394 Firewire bus, SCSI bus, Serial-ATA bus, ARINC bus, etc.), to which the various hardware components are electronically coupled.

[0069] The Input/output interface 104 may enable networking capabilities such as wire or wireless access. As an example, the Input/output interface 104 may comprise a networking interface such as, but not limited to, a network port, a network socket, a network interface controller and the like. The person skilled in the art will both be capable of devising multiple examples of how the networking interface may be implemented, and appreciate that any part of the Input/output interface 104 may also physically reside outside of the Embedded system 110, still within the scope of the present technology.

[0070] The Memory 103 may store Executable code 106, such as for example, a library, an application, etc. suitable for being uploaded into the Memory 103 and executed by the Processor 101, to enable Embedded system 110 to perform given functions. The Memory 103 may also store Data 107 consumed, and/or produced, by the Processor 101. As explained below, as part of the Executable code 106, a Serializer 108 may be used, to store at least certain of the Data 107 and/or their data structure onto the Memory 103, and a Deserializer 109 may be used, to retrieve at least certain of the Data 107 and/or their data structure from the Memory 103.

[0071] The person skilled in the art will appreciate that any part of the Memory 103 may also physically reside outside of the Embedded system 110, and that the Embedded system 110 may be implemented in any other suitable hardware, software, and/or firmware, or a combination thereof, and may be a single physical entity, or several separate physical entities with a distributed functionality, still within the scope of the present technology.

[0072] The Input/output interface 104 may allow Embedded system 110 to be communicably connected, through a Connection 102, to other processors, such as a Computing system 120, that may be used by a User 100. As will be appreciated by the person skilled in the art, the digital communication hardware and protocol used for Connection 102 may be of any type.

[0073] User 100 may for example use the Computing system 120 to prepare and upload successive versions of firmware to the Embedded system 110. Connection 102 may also be used, by Computing system 120 or any other computing system, to enter commands understood by the Executable code 106. For example, commands may be to set particular values to certain of Data 107.

[0074] As a first example, let us assume the firmware uploaded to the Embedded system 110 needs to store in the Memory 103 the following information relative to data: [0075] a data D.sub.1, with one field with a value D.sub.11 of 255, and [0076] a data D.sub.2, with eight fields D.sub.21 to D.sub.29 with a value each of respectively 1, 2, 3, 4, 5, 6, 7 and 8.
This information is therefore composed of information related to the data structure (data D.sub.i with one field, data D.sub.2 with eight fields), and the data values.

[0077] According to the present technology, the firmware uploaded to the Embedded system 110 may include a Serializer 108 as part of the Executable code 106, which function is to produce serialized information representing both the structure and the values of data to be stored in the Memory 103. This is shown FIG. 2, with a series translating the data and data structure of the first example above, according to the present technology. As seen FIG. 2, on line 201 are indicated, for the successive information fields, a descriptor for the field content, and on line 202, the actual content value of the corresponding field, according to the first example above. The series may be transmitted to the Memory 103 from left to right for example. It is to be noted that the method and system according to the present technology are endianness-agnostic, it being sufficient that the Serializer 108 and the Deserializer 109 support the same endianness.

[0078] Fields 203 represent the total size of the series of data. According to the present technology, one parameter needs to be predetermined, and fixed for all versions of a given firmware: a number R of bytes used for encoding the information of the total size of the series of data; let us assume here R=2 bytes. The person skilled in the art will appreciate that other R values may be adopted without departing from the present technology.

The values for fields 203 for the first example above, as shown on line 202, are binary 0x00 0x0E or 15, i.e. the total size of the series of data is 15 bytes.

[0079] Field 204 represents the size of the data D.sub.1. The number of bytes used for encoding the information of the size of the data D.sub.1 is 1 in the example. As will be appreciated by the person skilled in the art, this number may be higher than 1.

The value for field 204 for the first example above, as shown on line 202, is binary 0x01 or 1, i.e. the size of the data D.sub.1 is 1 byte.

[0080] Field 205, on 1 byte in this example as prescribed by the value for field 204, represents the value of the data D.sub.1.

The value for field 205 for the first example above, as shown on line 202, is binary 0xFF or 255, the value of D.sub.11 (i.e.: first and sole byte of D.sub.i).

[0081] Field 206 represents the size of the data D.sub.2. The number of bytes used for encoding the information of the size of the data D.sub.2 is 1 in the example.

The value for field 206 for the first example above, as shown on line 202, is binary 0x08 or 8, i.e. the size of the data D.sub.2 is 8 bytes.

[0082] Fields 207, on 8 bytes in this example as prescribed by the value for field 206, represent the values of the data D.sub.2.

The values for fields 207 for the first example above, as shown on line 202, are successively: [0083] binary 0x01 or 1, as the value of D.sub.21 (i.e.: the first byte of D.sub.2) [0084] binary 0x02 or 2, as the value of D.sub.22 (i.e.: the second byte of D.sub.2) [0085] binary 0x03 or 3, as the value of D.sub.23 (i.e.: the third byte of D.sub.2) [0086] binary 0x04 or 4, as the value of D.sub.24 (i.e.: the fourth byte of D.sub.2) [0087] binary 0x05 or 5, as the value of D.sub.25 (i.e.: the fifth byte of D.sub.2) [0088] binary 0x06 or 6, as the value of D.sub.26 (i.e.: the sixth byte of D.sub.2) [0089] binary 0x07 or 7, as the value of D.sub.27 (i.e.: the seventh byte of D.sub.2) [0090] binary 0x08 or 8, as the value of D.sub.29 (i.e.: the eighth byte of D.sub.2)

[0091] Fields 208 represent a Cyclic Redundancy Check (CRC) that may optionally be calculated by, for example, computing system 120, based on the contents of fields 203-207, when preparing and uploading firmware to the Embedded system 110, to ensure the series of data has not been corrupted, for example during transmission on Connection 102, or during write/read operations on/from Memory 103. As will be appreciated by the person skilled in the art: if the CRC and fields 208 are omitted, the total size value of the series of data in fields 203 will be adjusted accordingly, and the CRC, while shown on 2 bytes, may be encoded on any predetermined number of bytes R, fixed for all versions of a given firmware.

[0092] The person skilled in the art will appreciate that the number of bytes used for encoding the information of the size of the data D.sub.i (i.e.: size of fields 204 and 206 in the first example) may be 2 or above without departing from the present technology.

[0093] FIG. 3 illustrates an example of a modified series of data, with added data, as part of a different version of the firmware. As a second example, let us assume a different version of the firmware uploaded to the Embedded system 110 needs to store in the Memory 103 the following data: [0094] the same data D.sub.1 and D.sub.2 as in the first example, and [0095] an additional data D.sub.3, with two fields D.sub.31 and D.sub.32 with a value each of respectively 169 and 196.

[0096] According to the present technology, the corresponding series of data included in a different version of firmware uploaded to the Embedded system 110, may be as shown FIG. 3, where on line 301 are indicated, for the successive information fields, a descriptor for the field content, and on line 302, the actual content value of the corresponding field, according to the second example above.

[0097] Fields 303 represent the total size of the series of data, on R=2 bytes, the same as in the other version of the firmware corresponding to the first example.

The values for fields 303 for the second example above, as shown on line 302, are binary 0x00 0x2F or 18, i.e. the total size of the series of data is 18 bytes.

[0098] Fields 204 to 207 are the same as in the first example (same data D.sub.i and D.sub.2).

[0099] Field 304 represents the size of a data D.sub.3 added compared to the first example. The number of bytes used for encoding the information of the size of the data D.sub.3 is 1 as in the previous version of the firmware.

The value for field 304 for the second example above, as shown on line 302, is binary 0x02 or 2, i.e. the size of the data D.sub.3 is 2 bytes.

[0100] Fields 305, on 2 bytes in this example as prescribed by the value for field 304, represent the values of the data D.sub.3.

The values for fields 305 for the second example above, as shown on line 302, are successively: [0101] binary 0xCC or 169, as the value of D.sub.31 (i.e.: the first byte of D.sub.3) [0102] binary 0xDD or 196, as the value of D.sub.32 (i.e.: the second byte of D.sub.3)

[0103] Fields 306 represent a Cyclic Redundancy Check (CRC) that may optionally be calculated by for example, computing system 120, based on the contents of fields 303, 204-207, 304-305 when preparing and uploading firmware to the Embedded system 110, to ensure the series of data has not been corrupted, for example, example during transmission on Connection 102, or during write/read operations on/from Memory 103.

[0104] FIG. 4 illustrates an example of a modified series with inverted data, as part of a different version yet of the firmware. As a third example, let us assume a different version of the firmware uploaded to the Embedded system 110 needs to store in the Memory 103 the same data values of D.sub.1 and D.sub.2 as in the first example, but in an inverted order (i.e.: the values for D.sub.1 as those of D.sub.2 of the first example, and the values for D.sub.2 are those of D.sub.1 of the first example), i.e. with a different data structure.

[0105] According to the present technology, the series of data as part of a different version of firmware uploaded to the Embedded system 110, may be as shown FIG. 4, where on line 401 are indicated, for the successive information fields, a descriptor for the field content, and on line 402, the actual content value of the corresponding field, according to the second example above.

[0106] Fields 203 represent the total size of the series of data, on R=2 bytes, the same as in the other version of the firmware corresponding to the first example.

The values for fields 203 for the third example above, will be the same as on the first example above, i.e., as shown on line 402, binary 0x00 0x0E or 15, i.e. the total size of the series of data is also 15 bytes.

[0107] Field 403 represents the size of the data D.sub.i, and is equivalent to the field 206 in the first example. Conversely: [0108] fields 404 are equivalent to fields 207 in the first example [0109] field 405 is equivalent to field 204 in the first example [0110] field 406 is equivalent to field 205 in the first example

[0111] Fields 208 if present, will be the same as in the first example (identical CRC for merely inverted data).

[0112] As is known to the person skilled in the art, in all three examples, and in the general case, to produce serialized information representing both the structure and the values of data to be stored in the Memory 103, the Serializer 108 may be sequentially fed by the rest of the Executable code 106, the data values to be serialized, and their associated size, up to a maximum number of data. Based on that received information, the Serializer 108 may concatenate values and sizes into a series of bytes, which together with the information of total size, forms the series of data as exemplified above. The Serializer 108 may further calculate, and append to the series of bytes, a CRC representative of the content of the series of bytes. A CRC calculation and appending is optional but if implemented increases robustness of the data storing and retrieval process.

[0113] The Deserializer 109 may provide the inverse function of retrieving Data 107, deserializing them and providing them to the rest of the Executable code 106. In doing so, if a CRC is calculated and appended by the Serializer 108, then the Deserializer 109 may calculate a CRC for the retrieved series of data, and compare it with the CRC calculated and stored as part of the Data 107 by the Serializer 108. If the two CRC and CRC do not match, it means an error occurred in either or both of the processes of serialization or deserialization, or of storing Data 107 into, or retrieving Data 107 from, the Memory 103. An alert may then be raised by the Deserializer 109 to the rest of the Executable code 106. Mitigation and/or recovery techniques in relation to such corrupted data are known to the person skilled in the art.

[0114] Thus, according to the present technology as detailed below, a method and system are provided allowing to map data values and structure by an executable code onto an unstructured memory within an embedded system, in a manner that allows addition, deletion, or a different order, of data in the structure, and alteration of data values, while ensuring compatibility between successive versions of a firmware hosting the executable code and uploaded to the embedded system, and with external systems that may attempt to update data values.

[0115] FIG. 5 provides an example of a method that may be used by Serializer 108 to handle data input by the rest of Executable code 106, and transform them into a series of data that may be written onto Memory 103. As will be appreciated by the person skilled in the art, this is merely an example of how the serialization function may be performed.

[0116] At step 501, an indicium i for the data D.sub.i to be serialized, may be set to one.

[0117] At step 502, the Serializer 108 may receive from the rest of Executable code 106 the information of the size S.sub.1 of D.sub.1 (the first data to serialize). An indicia j for the data value D.sub.ij of the first data D.sub.1 to be serialized, may be set to one.

[0118] At step 503, the Serializer 108 may receive from the rest of Executable code 106 the information of the value of D.sub.11 (the first chunk of the data D.sub.1 to serialize).

[0119] At step 504, a check may be made whether the value of indicia j is equal to that of S.sub.1: [0120] if so: indicia i may be incremented by one at step 506, and at step 507, a check may be made whether another data D.sub.i is to be received from the rest of Executable code 106: if so, a loop back may be made to step 502 for data D.sub.2, if not branch may be made to step 508; [0121] if not: indicia j may be incremented by one at step 505, and a loop back may be made to step 503 for the information of the value of D.sub.2 (the second chunk of the data D.sub.1 to serialize).

[0122] At step 508, the Serializer 108 now has the information of the value of all chunks D.sub.ij for each of the data D.sub.i, as well as the value of the size S.sub.i for each of the data D.sub.i, and therefore may: [0123] calculate a total size S.sub.tot for the series of bytes representing successively for each data D.sub.i, a succession of respectively the value of the size S.sub.i of the data D.sub.i, and the values of the chunks D.sub.ij for all j from 1 to S.sub.i for the data D.sub.i, plus R bytes; [0124] write in Memory 103 successively: [0125] the total size S.sub.tot for the series of data, on the first R bytes; [0126] then for all values of j, the values of chunks D.sub.ij for respectively the data D.sub.i for each of all values of i.

[0127] Optionally (not shown on FIG. 5), the Serializer 108 may calculate a CRC value for the series of data to be written in Memory 103, and append that CRC value to the series of data written in Memory 103. It will be apparent to the person skilled in the art that, in such a case, S.sub.tot has to also account for the added data to the series, and the CRC value may be written on any predetermined number of bytes.

[0128] Optionally (not shown on FIG. 5), a CRC value for the series of data may be calculated by the rest of the Executable code 106, and provided to Serializer 108 to be appended to the series of data written in Memory 103.

[0129] Optionally (not shown on FIG. 5), the size of the series of data S.sub.tot may be provided by the rest of Executable code 106 to the Serializer 108, and not calculated by the Serializer 108 itself.

[0130] FIG. 6 provides an example of a method that may be used by Deserializer 109 to read data from Memory 103, and transform them into information of sizes of data, and data values, that may be handled by the rest of Executable code 106. As will be appreciated by the person skilled in the art, this is merely an example of how the deserialization function may be performed.

[0131] At step 601, an indicium i for the data D.sub.i to be deserialized, may be set to one, and an indicia k for the byte position in a series of data to be deserialized, may also be set to one. The total size S.sub.tot for the series of data, may be read from Memory 103 on the first R bytes of the series.

[0132] At step 602, the Deserializer 109 may read from Memory 103 on the first byte after the R bytes, the size S.sub.1 of D.sub.1 (the first data to deserialize). An indicia j for the data value D.sub.1j of the first data D.sub.1 to be deserialized, may be set to one.

[0133] At step 603, the Deserializer 109 may read from Memory 103 on the first byte after the R+1 bytes, the value of D.sub.11 (the first chunk of the data D.sub.1 to deserialize).

[0134] At step 604, a check may be made whether the value of indicia j is equal to that of S.sub.i: [0135] if so: branch may be made to step 606; [0136] if not: indicia j may be incremented by one at step 605, and a loop back may be made to step 603 for the value of D.sub.2 (the second chunk of the data D.sub.i to deserialize).

[0137] At step 606, a check may be made whether the number of bytes (R+i+j) already read from Memory 103, equals to that of the total number of bytes S.sub.tot of the series of data to be deserialized: [0138] if not: at step 607: [0139] indicia k may be set to (i+j+1), i.e. (R+i+j) bytes of the series of data have already been read and processed, and the next position in the series for the Deserializer 109 to process (at step 602, see below) will be (R+i+j+1); then [0140] indicia i may be incremented by one (deserialization of the next data D.sub.i); [0141] indicia j may be reset to one (deserialization of the first chunk of the next data D.sub.i), and [0142] a branch may be made to step 602.

[0143] At step 608, the Deserializer 109 has now read from Memory 103 for all values of j from 1 to S.sub.i, the values of chunks D.sub.ij for respectively the data D.sub.i for each of all values of i, and may provide the same to the rest of Executable code 106.

[0144] Optionally (not shown on FIG. 6), Deserializer 109 may further calculate a CRC for the series of data thus read from Memory 103, and if the Serializer 108 has included a CRC as part of the series of data written to Memory 103, read that CRC from Memory 103 and compare the calculated and read CRCs, and if the two CRCs do not match, raise an alert and provide information that data has been corrupted to the rest of Executable code 106.

[0145] Optionally (not shown on FIG. 6), a CRC value for the series of data may be calculated by the rest of the Executable code 106, and if the Serializer 108 has included a CRC as part of the series of data written to Memory 103, compare the calculated and included CRCs.

[0146] Optionally (not shown on FIG. 6), the size of the series of data S.sub.tot may be provided by the Derializer 109 to the rest of Executable code 106. This may for example allow the Executable code 106 to perform additional coherency checking on the data sent by the Derializer 109.

[0147] With the method and system described above, a system external to the Embedded system 110, may also update Data 107, even without being aware of the data structure. For example, Executable code 106 may receive a command (including for example through Input/output interface 104) from the external system to update a particular data, in which case the Executable may update accordingly data sent to Serializer 108, which may be handled according to the method of FIG. 5, for writing the updated Data 107 into Memory 103.

[0148] While the above-described implementations have been described and shown with reference to particular steps performed in a particular order, it will be understood that these steps may be combined, sub-divided, or re-ordered without departing from the teachings of the present disclosure. At least some of the steps may be executed in parallel or in series. Accordingly, the order and grouping of the steps is not a limitation of the present technology. It should further be expressly understood that not all technical effects mentioned herein need to be enjoyed in each and every aspect of the present technology.

[0149] Modifications and improvements to the above-described implementations of the present technology may become apparent to those skilled in the art. The foregoing description is intended to be exemplary rather than limiting. The scope of the present technology is therefore intended to be limited solely by the scope of the appended claims.