Michal Sojka [Thu, 30 Apr 2015 11:05:15 +0000 (13:05 +0200)]
Remove old Matlab paths when calling rpp_setup again
This allows to switch between multiple versions of RPP target. Without
this, the path would contain both old and new version, which would lead
to problems.
Michal Sojka [Wed, 29 Apr 2015 17:46:36 +0000 (19:46 +0200)]
Update block masks by running rpp_update_doc.m
Changelog:
Processing rpp_can_rx/CAN Receive
diff --git a/sfunction_canreceive.MaskHelp.old b/sfunction_canreceive.MaskHelp.new
index 4d75fe6..370c258 100644
--- a/sfunction_canreceive.MaskHelp.old
+++ b/sfunction_canreceive.MaskHelp.new
@@ -1,7 +1,7 @@
<p>This block allows receiving messages from the CAN bus. It can be configured for any of the CAN ports (modules) CAN1, CAN2 or CAN3.</p>
<p>The acceptance rules for message reception can be specified by a <em>Message ID</em> parameter and optionally by a <em>Message ID mask</em>. Specifying the mask allows to receive messages with multiple IDs. The block supports both, the Standard (11b ID) and the Extended (29b ID) frame formats. Note that if Mixed message ID type is selected, the blocks will receive both frame types, but the Standard Message ID and optionally the Message ID mask has to be shifted by 18 bits to the left to correspond with the extended IDs and masks. For example, if Message ID parameter is set to 0x80000 and mask to 0x1ffbfff, the block will receive SFF messages with IDs 0x002 and 0x003 and EFF IDs 0x00080000 and 0x000c0000.</p>
<p>The mailbox number can be assigned automatically or manually. Automatic mailbox numbers are generated in ascending order from [-0-]{+1+} to [-31.-]{+64.+} Every mailbox must have a unique number. It is possible to mix blocks with automatically and manually assigned mailboxes. If the manually assigned mailbox number would collide with the automatic one then the automatically generated block will get assigned a next higher non-colliding [-ID.-]{+number.+} The mailbox numbers are shared between CAN Transmit and CAN Receive blocks with the same CAN port (module) parameter.</p>
[-<p>The order in which-]{+<p>On message reception,+} the [-messages are received-]{+mailboxes+} and their [-priority depends on their mailbox numbers. The lower-]{+acceptance filters are consulted in+} the {+order of increasing+} mailbox [-number is, the higher is the priority.-]{+number.+} If {+a message can be accepted by more than one block+} you {+may+} want to [-have the priority of-]{+assign+} the [-messages under control, you have-]{+mailbox number manually+} to [-specify the numbers of-]{+have better control over which block receives+} the [-mailboxes manually.</p>-]{+message.</p>+}
<p>The output of this block is a message data in selected format: uint8, uint16, uint32 or CAN_MESSAGE. The CAN_MESSAGE object can be unpacked by <code>CAN Unpack</code> block.</p>
<p>Every time a message is received, the function call on <code>f()</code> output signal is triggered and the received message data is appears on the <code>Msg</code> output port. See <code>cantransmit.slx</code> demo for examples of different configurations and the usage of the CAN blocks.</p>
<p>In order to use this block, there must be a <code>CAN Configure</code> block in the model.</p>
[\bWarning: an error occurred while parsing class fxptui.explorer:
Invalid data type.
]\b
Processing rpp_can_setup/CAN Setup
Processing rpp_can_tx/CAN Transmit
diff --git a/sfunction_cantransmit.MaskHelp.old b/sfunction_cantransmit.MaskHelp.new
index b098f95..d94aa9b 100644
--- a/sfunction_cantransmit.MaskHelp.old
+++ b/sfunction_cantransmit.MaskHelp.new
@@ -1,6 +1,6 @@
<p>This block allows to send a message to the CAN bus. It can be configured for any of the CAN ports (modules) CAN1, CAN2 or CAN3.</p>
<p>The message data are read from <code>Msg</code> input port. The data type is decided automatically from the input, but it is restricted to uint8, uint16, uint32 and CAN_MESSAGE. The CAN_MESSAGE object can be created by the <code>CAN Pack</code> block.</p>
<p>The message sent by the block will have an ID assigned according to the number in the <em>Message ID</em> parameter. The block supports both types of message IDs: Standard (11b) and Extended (29b). If CAN_MESSAGE is used as input type, the message ID stored in CAN_MESSAGE object is ignored and the ID from the parameter of this block is used instead.</p>
<p>The mailbox number can be assigned automatically or manually. Automatic mailbox numbers are generated in ascending order from [-0-]{+1+} to [-31.-]{+64.+} Every mailbox must have a unique number. It is possible to mix blocks with automatically and manually assigned mailboxes. If the manually assigned mailbox number would collide with the automatic one then the automatically generated block will get assigned a next higher non-colliding [-ID.-]{+number.+} The mailbox numbers are shared between CAN Transmit and CAN Receive blocks with the same CAN port (module) parameter.</p>
[-<p>The-]{+<p>If there is multiple messages waiting for transmission, the+} order in which [-the messages-]{+they+} are transmitted depends on their mailbox [-numbers.-]{+numbers and not on the message IDs.+} The lower the mailbox number is, the [-higher is the priority of-]{+sooner+} the message[-and the sooner-] will[-it-] be transmitted. If you want to have [-the priority of the messages-]{+this+} under control, you [-have to-]{+should+} specify the numbers of the mailboxes manually.</p>
<p>In order to use this block, there must be a <code>CAN Configure</code> block in the model.</p>
Michal Horn [Tue, 7 Apr 2015 11:03:05 +0000 (13:03 +0200)]
Rework multi rate handling system
In commits 6ca7b9c and bff19d9 have been developed a mechanism for
tasks timing, which is working properly when Auto or Multi threading (MT)
is selected. Unfortunatelly we have missed the option Single tasking (ST),
which should be checked instead of Auto or MT, because this mode is not yet
implemented.
When ST is selected in the model configuration, the timing becomes
completely wrong (besides a compilation warning reported in Issue #1150),
because the manually generated timers are colliding with the automatically
generated timers.
As a result, the code written in the mentioned commits has been moved from
rpp_srmain.tlc into rpp_mrmain.tlc, because some ideas will be used later
for implementing Multi tasking multirate system.
rpp_srmain.tlc content has been restored to the previous state, which was
working correctly with right model configuration.
Exit macro with error message has been added to the rpp_file_process.tlc
for wrong model configuration detection.
projects / jenkicar / rpp-simulink.git / log