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.
Michal Sojka [Fri, 12 Dec 2014 14:17:41 +0000 (15:17 +0100)]
Update block masks by running rpp_update_doc.m
Changelog:
Processing rpp_lib/Analog Input
Processing rpp_lib/Analog Output
Processing rpp_lib/CAN Receive
--- sfunction_canreceive.MaskHelp.old 2014-12-12 15:17:32.064470220 +0100
+++ sfunction_canreceive.MaskHelp.new 2014-12-12 15:17:32.064470220 +0100
@@ -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 to 31. 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. 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 the messages are received and their priority depends on their mailbox numbers. The lower the mailbox number is, the higher is the priority. If you want to have the priority of the messages under control, you have to specify the numbers of the mailboxes manually.</p>
+<p>The mailbox number can be assigned automatically or manually. Automatic mailbox numbers are generated in ascending order from 1 to 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 number. The mailbox numbers are shared between CAN Transmit and CAN Receive blocks with the same CAN port (module) parameter.</p>
+<p>On message reception, the mailboxes and their acceptance filters are consulted in the order of increasing mailbox number. If a message can be accepted by more than one block you may want to assign the mailbox number manually to have better control over which block receives the 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>
Processing rpp_lib/CAN Setup
Processing rpp_lib/CAN Transmit
--- sfunction_cantransmit.MaskHelp.old 2014-12-12 15:17:32.716459327 +0100
+++ sfunction_cantransmit.MaskHelp.new 2014-12-12 15:17:32.716459327 +0100
@@ -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 to 31. 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. 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 the messages are transmitted depends on their mailbox numbers. The lower the mailbox number is, the higher is the priority of the message and the sooner will it be transmitted. If you want to have the priority of the messages under control, you have to specify the numbers of the mailboxes manually.</p>
+<p>The mailbox number can be assigned automatically or manually. Automatic mailbox numbers are generated in ascending order from 1 to 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 number. The mailbox numbers are shared between CAN Transmit and CAN Receive blocks with the same CAN port (module) parameter.</p>
+<p>If there is multiple messages waiting for transmission, the order in which thet are transmitted depends on their mailbox numbers and not on the message IDs. The lower the mailbox number is, the sooner the message will be transmitted. If you want to have this under control, you 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 Sojka [Fri, 12 Dec 2014 13:37:39 +0000 (14:37 +0100)]
Improve release target
Previously, the release target copied the library headers from the git
work tree. This could result in various garbage to be included in the
release zip. Release preparation is now reworked to copy the library
header files from the library release directory instead from the work
tree. This way, no unwanted file should leak into the release.
projects / jenkicar / rpp-simulink.git / log