pavel-kirienko/uavcan — pull request #6 by gtoonstra (2014-11-03 12:38:00+00:00)
Title: Libminimal integration

So, relocated all files and resolved the comments on the previous pull request.

Example generated code:
#pragma once

#include

/******************************* Source text **********************************
#
# Simple RPM setpoint.
# Negative values indicate reverse rotation.
#

int18[<=20] rpm
******************************************************************************/

/********************* DSDL signature source definition ***********************
uavcan.equipment.esc.RPMCommand
saturated int18[<=20] rpm
******************************************************************************/

#ifndef UAVCAN_PACK_STRUCTS
# error UAVCAN_PACK_STRUCTS
#endif

#if UAVCAN_PACK_STRUCTS
UAVCAN_PACKED_BEGIN
#endif

#define ID_TYPE_RPMCommand 261

typedef struct {
int32_t rpm:18;
} uavcan_equipment_esc_RPMCommand_rpm_t;

typedef struct UAVCAN_EXPORT
{
uavcan_equipment_esc_RPMCommand_rpm_t rpm[20];

} uavcan_equipment_esc_RPMCommand_t;

uint8_t unmarshal_uavcan_equipment_esc_RPMCommand( uint32_t can_id, uint32_t dh, uint32_t dl, uavcan_equipment_esc_RPMCommand_t *result )
{
return is_last_frame( can_id );
}

void marshal_uavcan_equipment_esc_RPMCommand( uint8_t *payload, uint8_t payload_len, uint32_t *dh, uint32_t *dl )
{

}

--------------------

Overall idea for reception:
1. The developer knows which CAN messages he wants to work with.
2. The developer includes the relevant C source headers
3. The developer creates an instance of the structure as in the header.
4. On receipt of a CAN msg, the developer uses the uint32_t mailbox identifier register (can_id) to extract the type of message.
5. The developer keeps calling "unmarshal" for the type of message indicated. The message may store the results in a buffer and keeps track of transfer_id probably (reset functions, etc).
6. When the last frame is received, the structure gets populated by the protocol and the structure can be used. If not last frame, the structure is not touched.

Overall idea for transmission: (incomplete and changing insight)
1. The developer knows which CAN messages he wants to produce and includes the relevant headers.
2. We want to make it easy to grab a new set of uint32_t bytes for transmission, so the protocol should grab the populated structure by the user and fill an internal buffer (payload), so that the developer can call "marshal" repeatedly when the tx mailbox is empty, until the last byte is returned in the two uint32_t bytes, then return "send complete".

TODO:
a. functions per message type that indicate whether a new message should be populated (no need to work with sensors until the previous message has been sent in its entirety).
b. reset functions to clear internal buffer and state.
c. I think "can_id" can be returned too in a single shot.
d. indicate a strategy for sending messages of different types at the same time.
- must send one type of message before another is sent (one global buffer for all messages).
- may send multiple messages at different times (one buffer per message).