Note
This Bricklet is currently in the prototype stage and the software/hardware as well as the documentation is in an incomplete state.
This is the description of the Modbus protocol for the ARINC429 Bricklet. General information and technical specifications for the ARINC429 Bricklet are summarized in its hardware description.
A general description of the Modbus protocol structure can be found here.
BrickletARINC429.
get_capabilities
¶Function ID: |
|
---|---|
Request: |
|
Response: |
|
Gets the capabilities of the ARINC429 Bricklet as of the currently loaded firmware:
BrickletARINC429.
set_channel_configuration
¶Function ID: |
|
---|---|
Request: |
|
Response: |
|
Sets the data transmission properties of the selected channel:
When parity set to 'parity_auto', frames received with a parity error will be counted in the lost frames counter but discarded otherwise.
The following meanings are defined for the elements of this function:
For channel:
For parity:
For speed:
BrickletARINC429.
get_channel_configuration
¶Function ID: |
|
---|---|
Request: |
|
Response: |
|
Gets the data transmission properties of the selected channel. The channel parameter and the data returned use the same constants
as the set_channel_configuration
, despite that the all-channels constants CHANNEL_TX and CHANNEL_RX can not be used.
The following meanings are defined for the elements of this function:
For channel:
For parity:
For speed:
BrickletARINC429.
set_channel_mode
¶Function ID: |
|
---|---|
Request: |
|
Response: |
|
Sets the operating mode of the selected channel(s):
The following meanings are defined for the elements of this function:
For channel:
For mode:
BrickletARINC429.
get_channel_mode
¶Function ID: |
|
---|---|
Request: |
|
Response: |
|
Gets the operating mode of the selected channel. The channel parameter and the data returned use the same constants as the
set_channel_configuration
, despite that the all-channels constants CHANNEL_TX and CHANNEL_RX can not be used.
The following meanings are defined for the elements of this function:
For channel:
For mode:
BrickletARINC429.
clear_all_rx_filters
¶Function ID: |
|
---|---|
Request: |
|
Response: |
|
Clears all receive filters on the selected RX channel(s). The RX channels will only process those Arinc429 frames that pass the input filtering stage. With this command, all filters are cleared, thus all incoming Arinc429 frames will be blocked from further processing.
The following meanings are defined for the elements of this function:
For channel:
BrickletARINC429.
clear_rx_filter
¶Function ID: |
|
---|---|
Request: |
|
Response: |
|
Clears a specific receive filter on the selected RX channel(s). The RX channels will only process those Arinc429 frames that pass the input filtering stage. With this command, an Arinc429 frame matching the given parameters will be blocked by the filter.
The function either returns 'True' if the filter was cleared or 'False' if a respective filter was not set.
The following meanings are defined for the elements of this function:
For channel:
For sdi:
BrickletARINC429.
set_rx_standard_filters
¶Function ID: |
|
---|---|
Request: |
|
Response: |
|
Sets a receive filter for each label value (0-255 / 0o000-0o377) with the SDI bits set for data. Any previously existing filters will be overwritten.
The following meanings are defined for the elements of this function:
For channel:
BrickletARINC429.
set_rx_filter
¶Function ID: |
|
---|---|
Request: |
|
Response: |
|
Sets a specific receive filter on the selected channel(s):
The function either returns 'True' if the filter was set or 'False' if a respective filter could not be created e.g. because the given combination
of label and SDI collides with an already existing filter, or because all available filters are used up (see the get_capabilities
function).
The following meanings are defined for the elements of this function:
For channel:
For sdi:
BrickletARINC429.
get_rx_filter
¶Function ID: |
|
---|---|
Request: |
|
Response: |
|
Queries if a filter for the given combination of label and SDI is set up or not:
The function will return 'True' if the queried filter filter exists, else 'False'.
The following meanings are defined for the elements of this function:
For channel:
For sdi:
BrickletARINC429.
read_frame
¶Function ID: |
|
---|---|
Request: |
|
Response: |
|
Executes a direct read of an Arinc429 frame, i.e. without using the callback mechanism. In order to be able to do a direct read of a frame with a certain label and SDI combination, a respective receive filter needs to be set up beforehand.
The function return the following data:
set_rx_callback_configuration
will be returned.The following meanings are defined for the elements of this function:
For channel:
For sdi:
BrickletARINC429.
write_frame_direct
¶Function ID: |
|
---|---|
Request: |
|
Response: |
|
Immediately transmits an Arinc429 frame, given that the channel is in either ACTIVE or RUN mode. If the channel is in RUN mode and frames are sent as per programmed schedule, using this function will inject additional frames into the transmission, independent of the scheduler's activities.
The frame needs to be passed as a 32 bit integer. Opposite to the line transmission format, in the API functions the label code is mirrored such that the label code can be directly written 1:1 into the lower 8 bits. Beware that the label codes are usually given in octal notation, so make sure to use the correct notation (i.e. 0o377). If 'parity_auto' is set for the channel, the parity bit will be set (adjusted) automatically.
Between the API and the actual Arinc429 line output, there is a 32 entry deep FIFO. If frames are written via the API and/or in combination with a running TX scheduler, the FIFO may become overfilled and subsequently frames will get lost. Such frame losses will be indicated in the statistics data sent with the heartbeat callback.
The following meanings are defined for the elements of this function:
For channel:
BrickletARINC429.
write_frame_scheduled
¶Function ID: |
|
---|---|
Request: |
|
Response: |
|
Sets or updates an Arinc429 frame that is to be transmitted via the scheduler using the scheduler job types 'Single' or 'Cyclic'.
The frame needs to be passed as a 32 bit integer. Opposite to the line transmission format, in the API functions the label code is mirrored such that the label code can be directly written 1:1 into the lower 8 bits. Beware that the label codes are usually given in octal notation, so make sure to use the correct notation (i.e. 0o377). If 'parity_auto' is set for the channel, the parity bit will be set (adjusted) automatically.
If the frame is used by a 'single transmit' scheduler job entry, setting or updating the frame with this function arms the frame for its next transmission.
The following meanings are defined for the elements of this function:
For channel:
BrickletARINC429.
clear_schedule_entries
¶Function ID: |
|
---|---|
Request: |
|
Response: |
|
Clears a range of transmit scheduler job table entries:
To clear a single entry, set 'First' and 'Last' to the one index of the one entry to be cleared. Clearing scheduler entries actually means they are set to the job command 'Skip'.
The following meanings are defined for the elements of this function:
For channel:
BrickletARINC429.
set_schedule_entry
¶Function ID: |
|
---|---|
Request: |
|
Response: |
|
Sets an entry in the transmit scheduler job table:
get_capabilities
function for the total number of job indexes available. In firmware 2.4.0 it is 1000.write_frame_scheduled
.When the scheduler is set to 'run' mode via the set_channel_mode
, it continuously loops through the job table and executes
the assigned tasks. It starts with the job stored at job index 0.
The scheduler can execute the following activity types (jobs):
write_frame_scheduled
, then the process repeats.The value assigned to the 'Frame Index' parameter varies with the activity type (job):
write_frame_scheduled
of the frame to transmit. Valid range: 0-255The set_schedule_entry
can be called while the TX scheduler is running, i.e. the channel mode is set to 'RUN'.
Any change will take immediate effect once the scheduler passes along and executes the changed job entry.
Every time the scheduler is started, it will begin with the job stored at job index 0.
At the end of the programmed schedule there should be a 'Jump' command back to index 0 to avoid the scheduler wasting time in processing all the remaining 'Skip' commands.
Two or more TX schedules can be pre-programmed and then selected for execution by placing - and changing as desired - a 'Jump' at index 0 that then branches to the
sequence of commands destined to be executed. This can be arranged in arbitrary ways, e.g. to create schedules with fixed and variable parts, just by using the 'Jump'
command alike a track switch in railway.
When the dwell time of a transmit command is set to zero, the respective Arinc429 frames will be transmitted back-to-back on the physical link. Beware that there is a FIFO between the scheduler and the actual physical transmitter that is limited to 32 frames. So after latest 32 frames enqueued with zero dwell time, the scheduler needs to be commanded to do some dwelling. How much dwelling is required can be computed by the number of back-to-back frames and the speed setting: in high speed mode each frame takes 0.36 ms, in low speed mode 2.88 ms. If a certain sequence of frames is to be transmitted multiple times in a schedule, this sequence just needs to be put once into the scheduler table with a 'Return' command at its end. This way, this sequence can be called from multiple placed (job indexes) throughout the main schedule using the 'Jump' command. Please note that this kind of calling a subroutine can not be nested, i.e. there is no return index stack, the 'Return' command always branches to the job index following the index of the last 'Jump' command encountered. In case a dwell time > 0 is set with the 'Jump' command, this dwell time will actually be executed on encountering the 'Return' command, thus as a dwell time to be done after the execution of the subsequence that was jumped to before.
The 'Callback' command can be used to notify the application program via a callback when the scheduler passes at the respective job index. This can be used for pure reporting / surveillance purpose, or as a means to set up a self-clocked system in which the called application program's function in return does some modification of the programmed sequence or alike. The scheduler can also be programmed to stop itself via the 'Stop' command, e.g. to run a pre-programmed, accurately timed single-shot sequence of frame transmissions. Placing a' Callback' command right before the 'Stop' command will inform the application program via a callback when the sequence is done. When using several 'Callback' commands in a schedule, each of them can be uniquely identified in the receiving application program by assigning a different 'userdata' value to each callback command.
With the aid of the 'Retrans' commands, a frame transmission schedule can be set up whose frame timing is defined by the schedule, but whose frame's payload is taken from the frames received via the RX1 or RX2 channel. This opens possibilities to create an autonomously operating time base corrector or re-scheduling machinery, to zip the frames from two A429 buses onto one common bus, to create inline filers to remove certain frames (by their label & SDI code), to insert frames into a stream, to exchange the payload of certain frames on-the-fly, and much more.
The following meanings are defined for the elements of this function:
For channel:
For job:
BrickletARINC429.
get_schedule_entry
¶Function ID: |
|
---|---|
Request: |
|
Response: |
|
Gets the definition of a transmit scheduler job table entry, refer to the set_schedule_entry
.
The following meanings are defined for the elements of this function:
For channel:
For job:
BrickletARINC429.
restart
¶Function ID: |
|
---|---|
Request: |
|
Response: |
|
Reverts the whole bricklet into its power-up default state.
BrickletARINC429.
set_frame_mode
¶Function ID: |
|
---|---|
Request: |
|
Response: |
|
Stops / resumes the transmission of a specific frame or trigger another single-transmit. This function only works on frames that are sent via the TX scheduler jobs 'single' and 'cyclic'.
The following meanings are defined for the elements of this function:
For channel:
For mode:
BrickletARINC429.
get_spitfp_error_count
¶Function ID: |
|
---|---|
Request: |
|
Response: |
|
Returns the error count for the communication between Brick and Bricklet.
The errors are divided into
The errors counts are for errors that occur on the Bricklet side. All Bricks have a similar function that returns the errors on the Brick side.
BrickletARINC429.
set_status_led_config
¶Function ID: |
|
---|---|
Request: |
|
Response: |
|
Sets the status LED configuration. By default the LED shows communication traffic between Brick and Bricklet, it flickers once for every 10 received data packets.
You can also turn the LED permanently on/off or show a heartbeat.
If the Bricklet is in bootloader mode, the LED is will show heartbeat by default.
The following meanings are defined for the elements of this function:
For config:
BrickletARINC429.
get_status_led_config
¶Function ID: |
|
---|---|
Request: |
|
Response: |
|
Returns the configuration as set by set_status_led_config
The following meanings are defined for the elements of this function:
For config:
BrickletARINC429.
get_chip_temperature
¶Function ID: |
|
---|---|
Request: |
|
Response: |
|
Returns the temperature as measured inside the microcontroller. The value returned is not the ambient temperature!
The temperature is only proportional to the real temperature and it has bad accuracy. Practically it is only useful as an indicator for temperature changes.
BrickletARINC429.
reset
¶Function ID: |
|
---|---|
Request: |
|
Response: |
|
Calling this function will reset the Bricklet. All configurations will be lost.
After a reset you have to create new device objects, calling functions on the existing ones will result in undefined behavior!
BrickletARINC429.
get_identity
¶Function ID: |
|
---|---|
Request: |
|
Response: |
|
Returns the UID, the UID where the Bricklet is connected to, the position, the hardware and firmware version as well as the device identifier.
The position can be 'a', 'b', 'c', 'd', 'e', 'f', 'g' or 'h' (Bricklet Port). A Bricklet connected to an Isolator Bricklet is always at position 'z'.
The device identifier numbers can be found here.
BrickletARINC429.
set_heartbeat_callback_configuration
¶Function ID: |
|
---|---|
Request: |
|
Response: |
|
Sets the bricklet heartbeat callback function which reports the statistics counters for processed frames and lost frames.
The period is the period with which the CALLBACK_HEARTBEAT_MESSAGE
callback is triggered periodically. A value of 0 turns the callback off.
When 'Value Has To Change' is enabled, the heartbeat will only be sent if there is a change in the statistics numbers.
The following meanings are defined for the elements of this function:
For channel:
BrickletARINC429.
get_heartbeat_callback_configuration
¶Function ID: |
|
---|---|
Request: |
|
Response: |
|
Gets the current configuration of the bricklet heartbeat callback, see set_heartbeat_callback_configuration
.
The following meanings are defined for the elements of this function:
For channel:
BrickletARINC429.
set_rx_callback_configuration
¶Function ID: |
|
---|---|
Request: |
|
Response: |
|
Sets the configuration of the Arinc429 frame reception callback:
Despite on frame reception, a callback is also generated if a frame encounters a timeout, i.e. if it is not periodically received again before the set timeout period has expired. In order to have callbacks being generated at all, respective receive filters need to be set up.
The following meanings are defined for the elements of this function:
For channel:
BrickletARINC429.
get_rx_callback_configuration
¶Function ID: |
|
---|---|
Request: |
|
Response: |
|
Gets the configuration of the frame reception callback, see the set_rx_callback_configuration
.
The following meanings are defined for the elements of this function:
For channel:
BrickletARINC429.
CALLBACK_HEARTBEAT_MESSAGE
¶Function ID: |
|
---|---|
Response: |
|
This callback is triggered periodically according to the configuration set by
set_heartbeat_callback_configuration
. It reports the statistics counters
for processed frames and lost frames for all TX and RX channels.
The following meanings are defined for the elements of this function:
For channel:
For status:
BrickletARINC429.
CALLBACK_FRAME_MESSAGE
¶Function ID: |
|
---|---|
Response: |
|
This callback is triggered according to the configuration set by set_rx_callback_configuration
.
set_rx_callback_configuration
will be returned.The following meanings are defined for the elements of this function:
For channel:
For status:
BrickletARINC429.
CALLBACK_SCHEDULER_MESSAGE
¶Function ID: |
|
---|---|
Response: |
|
This callback is triggered by the 'Callback' job in the transmit schedule.
The following meanings are defined for the elements of this function:
For channel:
For status:
Internal functions are used for maintenance tasks such as flashing a new firmware of changing the UID of a Bricklet. These task should be performed using Brick Viewer instead of using the internal functions directly.
BrickletARINC429.
set_bootloader_mode
¶Function ID: |
|
---|---|
Request: |
|
Response: |
|
Sets the bootloader mode and returns the status after the requested mode change was instigated.
You can change from bootloader mode to firmware mode and vice versa. A change from bootloader mode to firmware mode will only take place if the entry function, device identifier and CRC are present and correct.
This function is used by Brick Viewer during flashing. It should not be necessary to call it in a normal user program.
The following meanings are defined for the elements of this function:
For mode:
For status:
BrickletARINC429.
get_bootloader_mode
¶Function ID: |
|
---|---|
Request: |
|
Response: |
|
Returns the current bootloader mode, see set_bootloader_mode
.
The following meanings are defined for the elements of this function:
For mode:
BrickletARINC429.
set_write_firmware_pointer
¶Function ID: |
|
---|---|
Request: |
|
Response: |
|
Sets the firmware pointer for write_firmware
. The pointer has
to be increased by chunks of size 64. The data is written to flash
every 4 chunks (which equals to one page of size 256).
This function is used by Brick Viewer during flashing. It should not be necessary to call it in a normal user program.
BrickletARINC429.
write_firmware
¶Function ID: |
|
---|---|
Request: |
|
Response: |
|
Writes 64 Bytes of firmware at the position as written by
set_write_firmware_pointer
before. The firmware is written
to flash every 4 chunks.
You can only write firmware in bootloader mode.
This function is used by Brick Viewer during flashing. It should not be necessary to call it in a normal user program.
BrickletARINC429.
write_uid
¶Function ID: |
|
---|---|
Request: |
|
Response: |
|
Writes a new UID into flash. If you want to set a new UID you have to decode the Base58 encoded UID string into an integer first.
We recommend that you use Brick Viewer to change the UID.
BrickletARINC429.
read_uid
¶Function ID: |
|
---|---|
Request: |
|
Response: |
|
Returns the current UID as an integer. Encode as Base58 to get the usual string version.