aboutsummaryrefslogtreecommitdiffstats
path: root/CAN-binder/libs/nanopb/examples/using_union_messages/README.txt
diff options
context:
space:
mode:
authorRomain Forlot <romain.forlot@iot.bzh>2017-05-02 18:29:37 +0200
committerRomain Forlot <romain.forlot@iot.bzh>2017-05-02 18:29:37 +0200
commitb9e1b4435a406a8a27c078ea05dee1240e51704a (patch)
tree3bd5e75d001d0c1d57710c47375af5c8ba84c26c /CAN-binder/libs/nanopb/examples/using_union_messages/README.txt
parent0242c26c2f5dc96387bca7efb118364c800f4ee7 (diff)
Added external libraries from openXC CMake files.
Now libraries are cleanly included and built. Change-Id: Iaa85639578b55b2da8357bc438426403e2cca8de Signed-off-by: Romain Forlot <romain.forlot@iot.bzh>
Diffstat (limited to 'CAN-binder/libs/nanopb/examples/using_union_messages/README.txt')
-rw-r--r--CAN-binder/libs/nanopb/examples/using_union_messages/README.txt52
1 files changed, 0 insertions, 52 deletions
diff --git a/CAN-binder/libs/nanopb/examples/using_union_messages/README.txt b/CAN-binder/libs/nanopb/examples/using_union_messages/README.txt
deleted file mode 100644
index 7a1e75d4..00000000
--- a/CAN-binder/libs/nanopb/examples/using_union_messages/README.txt
+++ /dev/null
@@ -1,52 +0,0 @@
-Nanopb example "using_union_messages"
-=====================================
-
-Union messages is a common technique in Google Protocol Buffers used to
-represent a group of messages, only one of which is passed at a time.
-It is described in Google's documentation:
-https://developers.google.com/protocol-buffers/docs/techniques#union
-
-This directory contains an example on how to encode and decode union messages
-with minimal memory usage. Usually, nanopb would allocate space to store
-all of the possible messages at the same time, even though at most one of
-them will be used at a time.
-
-By using some of the lower level nanopb APIs, we can manually generate the
-top level message, so that we only need to allocate the one submessage that
-we actually want. Similarly when decoding, we can manually read the tag of
-the top level message, and only then allocate the memory for the submessage
-after we already know its type.
-
-
-Example usage
--------------
-
-Type `make` to run the example. It will build it and run commands like
-following:
-
-./encode 1 | ./decode
-Got MsgType1: 42
-./encode 2 | ./decode
-Got MsgType2: true
-./encode 3 | ./decode
-Got MsgType3: 3 1415
-
-This simply demonstrates that the "decode" program has correctly identified
-the type of the received message, and managed to decode it.
-
-
-Details of implementation
--------------------------
-
-unionproto.proto contains the protocol used in the example. It consists of
-three messages: MsgType1, MsgType2 and MsgType3, which are collected together
-into UnionMessage.
-
-encode.c takes one command line argument, which should be a number 1-3. It
-then fills in and encodes the corresponding message, and writes it to stdout.
-
-decode.c reads a UnionMessage from stdin. Then it calls the function
-decode_unionmessage_type() to determine the type of the message. After that,
-the corresponding message is decoded and the contents of it printed to the
-screen.
-