doc for dhb, serializeIF and SerializeAdapter

devicehandlers/DeviceCommunicationIF.h

@@ -40,7 +40,7 @@ public:
 	virtual void close(Cookie *cookie) = 0;
 
 	//SHOULDDO can data be const?
-	virtual ReturnValue_t sendMessage(Cookie *cookie, uint8_t *data,
+	virtual ReturnValue_t sendMessage(Cookie *cookie,const uint8_t *data,
 			uint32_t len) = 0;
 
 	virtual ReturnValue_t getSendSuccess(Cookie *cookie) = 0;

devicehandlers/DeviceHandlerBase.cpp

@@ -11,6 +11,7 @@
 #include <framework/thermal/ThermalComponentIF.h>
 #include <framework/ipc/QueueFactory.h>
 #include <framework/serviceinterface/ServiceInterfaceStream.h>
+#include <mission/test/DummyCookie.h>
 
 object_id_t DeviceHandlerBase::powerSwitcherId = 0;
 object_id_t DeviceHandlerBase::rawDataReceiverId = 0;
@@ -452,7 +453,7 @@ void DeviceHandlerBase::doGetWrite() {
 		if (wiretappingMode == RAW) {
 			replyRawData(rawPacket, rawPacketLen, requestedRawTraffic, true);
 		}
-		//We need to distinguish here, because a raw command never expects a reply. (Could be done in eRIRM, but then child implementations need to be careful.
+		// We need to distinguish here, because a raw command never expects a reply. (Could be done in eRIRM, but then child implementations need to be careful.
 		result = enableReplyInReplyMap(cookieInfo.pendingCommand);
 	} else {
 		//always generate a failure event, so that FDIR knows what's up
@@ -473,9 +474,9 @@ void DeviceHandlerBase::doSendRead() {
 		cookieInfo.state = COOKIE_READ_SENT;
 	} else {
 		triggerEvent(DEVICE_REQUESTING_REPLY_FAILED, result);
-		//We can't inform anyone, because we don't know which command was sent last.
+		// We can't inform anyone, because we don't know which command was sent last.
-		//So, we need to wait for a timeout.
+		// So, we need to wait for a timeout.
-		//but I think we can allow to ignore one missedReply.
+		// but I think we can allow to ignore one missedReply.
 		ignoreMissedRepliesCount++;
 		cookieInfo.state = COOKIE_UNUSED;
 	}
@@ -1266,3 +1267,5 @@ void DeviceHandlerBase::changeHK(Mode_t mode, Submode_t submode, bool enable) {
 void DeviceHandlerBase::setTaskIF(PeriodicTaskIF* task_){
 			executingTask = task_;
 }
+
+

devicehandlers/DeviceHandlerBase.h

@@ -167,7 +167,7 @@ protected:
 	static const uint8_t INTERFACE_ID = CLASS_ID::DEVICE_HANDLER_BASE;
 
 	static const ReturnValue_t INVALID_CHANNEL = MAKE_RETURN_CODE(4);
-	static const ReturnValue_t APERIODIC_REPLY = MAKE_RETURN_CODE(5);
+	static const ReturnValue_t APERIODIC_REPLY = MAKE_RETURN_CODE(5); //!< This is used to specify for replies from a device which are not replies to requests
 	static const ReturnValue_t IGNORE_REPLY_DATA = MAKE_RETURN_CODE(6);
 //	static const ReturnValue_t ONE_SWITCH = MAKE_RETURN_CODE(8);
 //	static const ReturnValue_t TWO_SWITCHES = MAKE_RETURN_CODE(9);
@@ -626,9 +626,9 @@ protected:
 	 * @param[out] foundLen length of the packet found
 	 * @return
 	 *     - @c RETURN_OK a valid packet was found at @c start, @c foundLen is valid
-	 *     - @c NO_VALID_REPLY no reply could be found starting at @c start, implies @c foundLen is not valid, base class will call scanForReply() again with ++start
+	 *     - @c RETURN_FAILED no reply could be found starting at @c start, implies @c foundLen is not valid, base class will call scanForReply() again with ++start
-	 *     - @c INVALID_REPLY a packet was found but it is invalid, eg checksum error, implies @c foundLen is valid, can be used to skip some bytes
+	 *     - @c DeviceHandlerIF::INVALID_DATA a packet was found but it is invalid, eg checksum error, implies @c foundLen is valid, can be used to skip some bytes
-	 *     - @c TOO_SHORT @c len is too short for any valid packet
+	 *     - @c DeviceHandlerIF::LENGTH_MISSMATCH @c len is invalid
 	 *     - @c APERIODIC_REPLY if a valid reply is received that has not been requested by a command, but should be handled anyway (@see also fillCommandAndCookieMap() )
 	 */
 	virtual ReturnValue_t scanForReply(const uint8_t *start, uint32_t len,
@@ -954,6 +954,7 @@ private:
 	 *
 	 * This is called at the beginning of each cycle. It checks whether a reply has timed out (that means a reply was expected
 	 * but not received).
+	 * In case the reply is periodic, the counter is simply set back to a specified value.
 	 */
 	void decrementDeviceReplyMap(void);
 
@@ -1053,6 +1054,8 @@ private:
 	ReturnValue_t switchCookieChannel(object_id_t newChannelId);
 
 	ReturnValue_t handleDeviceHandlerMessage(CommandMessage *message);
+
+
 };
 
 #endif /* DEVICEHANDLERBASE_H_ */

serialize/SerializeAdapter.h

@@ -20,11 +20,31 @@
  *
  * The AutoSerializeAdapter functions can also be used as an alternative to memcpy
  * to retrieve data out of a buffer directly into a class variable with data type T while being able to specify endianness.
+ * The boolean bigEndian specifies the endiness of the data to serialize or deSerialize.
  *
- * In the SOURCE mission , the target architecture is little endian,
+ * If the target architecture is little endian (ARM), any data types created might
- * so any buffers must be deSerialized with bool bigEndian = false if
+ * have the wrong endiness if they are to be used for the FSFW.
- * the parameters are used in the FSFW.
+ * there are three ways to retrieve data out of a buffer to be used in the FSFW to use regular aligned (big endian) data.
- * When serializing for downlink, the packets are generally serialized into big endian for the network when using a TC/UDP client
+ * This can also be applied to uint32_t and uint64_t:
+ *
+ *   1. Use the AutoSerializeAdapter::deSerialize function with bool bigEndian = true:
+ *
+ *   	uint16_t data;
+ *   	int32_t dataLen = sizeof(data);
+ *   	ReturnValue_t result = AutoSerializeAdapter::deSerialize(&data,&buffer,&dataLen,true);
+ *
+ *   2. Perform a bitshift operation:
+ *
+ *   	uint16_t data;
+ *   	data = buffer[targetByte1] >> 8 | buffer[targetByte2];
+ *
+ *   3. Memcpy can be used when data is little-endian. Otherwise, endian-swapper has to be used.
+ *
+ *   	uint16_t data;
+ *   	memcpy(&data,buffer + positionOfTargetByte1,sizeof(data));
+ *   	data = EndianSwapper::swap(data);
+ *
+ * When serializing for downlink, the packets are generally serialized assuming big endian data format
  * like seen in TmPacketStored.cpp for example.
  *
  * \ingroup serialize

serialize/SerializeIF.h

@@ -11,10 +11,16 @@
 /**
  * An interface for alle classes which require translation of objects data into data streams and vice-versa.
  *
- * In the SOURCE mission , the target architecture is little endian,
+ * If the target architecture is little endian (ARM), any data types created might
- * so any buffers must be deSerialized with bool bigEndian = false if
+ * have the wrong endiness if they are to be used for the FSFW.
- * the parameters are used in the FSFW.
+ * there are three ways to retrieve data out of a buffer to be used in the FSFW to use regular aligned (big endian) data.
- * When serializing for downlink, the packets are generally serialized into big endian for the network when using a TC/UDP client
+ * This can also be applied to uint32_t and uint64_t:
+ *
+ *   1. Use the @c AutoSerializeAdapter::deSerialize function with @c bigEndian = true
+ *   2. Perform a bitshift operation
+ *   3. @c memcpy can be used when data is little-endian. Otherwise, @c EndianSwapper has to be used.
+ *
+ * When serializing for downlink, the packets are generally serialized assuming big endian data format
  * like seen in TmPacketStored.cpp for example.
  *
  * \ingroup serialize

tmtcservices/PusServiceBase.h

@@ -68,8 +68,8 @@ public:
 	 * It checks for new requests, and, if found, calls handleRequest, sends completion verification messages and deletes
 	 * the TC requests afterwards.
 	 * performService is always executed afterwards.
-	 * @return	- \c RETURN_OK if the periodic performService was successful.
+	 * @return	\c RETURN_OK if the periodic performService was successful.
-	 * 			- \c RETURN_FAILED else.
+	 * 			\c RETURN_FAILED else.
 	 */
 	ReturnValue_t performOperation(uint8_t opCode);
 	virtual uint16_t getIdentifier();