CANNY 7, System Registers
- General description
- Reset controller
- Built-in LED
- Hibernation
- WatchDog Timer
- Function diagram actual run time
- Device ID
- Interface activity monitoring
- Vendor ID
General description
System resources are divided into an address group of input registers and an address group of output registers. By accessing these registers from the function diagram you can receive useful information about the current status of the controller, and control its operating mode. The set of system registers is located in the “System Registers” folder of the CannyLab IDE registers list. The list is accessible via “Input Register” and “Output Register” context menu options in the editor.
Reset controller
Controller reset occurs when any of the three following events happen:
- the controller is powered up;
- soft reset is called from the function diagram;
- soft reset is initiated by the WatchDog Timer.
The controller is initialized after reset: all contents of the controller’s volatile memory are cleared, input-output channels are reset to a neutral state, system software drivers are transferred to their initial state, power consumption is set to normal mode, function diagram execution starts from the first block in the execution chain. The contents of non-volatile memory do not change at reset.
Information about the reset status is available by accessing the “Power On Detect Register”
| Register | Return values |
|---|---|
| Power On Detect Register | 1 = the current execution cycle is the first one after a soft reset or power restoration; 0 = the current execution cycle is not the first one after a soft reset or power restoration. |
Forced reset of the controller is performed by writing a non-zero value to the “Reset Register”. In this case, the controller will reset immediately after the end of the execution loop in which that register’s value was changed to a non-zero value.
| Register | Expected values |
|---|---|
| Reset Register | ≥ 1 = start a forced controller reset 0 = value is ignored |
Built-in LED
The controller has a built-in bi-color (green/red) LED. Each color may be switched on and off independently from the function diagram by writing specific values into the appropriate registers.
| Register | Expected values |
|---|---|
| Green LED On/Off Register | ≥ 1 = turn on built-in Green LED; 0 = turn off built-in Green LED. |
| Red LED On/Off Register | ≥ 1 = turn on built-in Red LED; 0 = turn off built-in Red LED. |
Note: Turning on both colors of the the LED simultaneously is not possible due to the design of the LED. If both green and red LEDs are turned on from the function diagram, the LED will turn green(priority is given to the green LED).
Hibernation
After the reset, the controller starts working in normal power consumption mode. The function diagram will be executed continuously. Transition to Hibernation Mode is done by writing a non-zero value to “Sleep Mode Enable Register” from the function diagram. The controller will transition into this mode immediately after the end of function diagram execution loop in which the value was changed, in the absence of conditions that impede this transition.
The duration of the “sleep” phase can be set from the function diagram by writing a value to the “Sleep Mode Time Scale Register”. By default, if this register’s value has not been changed, the “sleep” phase of hibernation mode lasts 1000ms. This means that while controller is in hibernation mode and in the absence of conditions for transition to the normal power mode, the controller pauses for 1 second after each execution loop of the function diagram.
| Register | Expected values |
|---|---|
| Sleep Mode Enable Register | ≥ 1 = go into hibernation mode; 0 = return to normal power mode. |
| Sleep Mode Time Scale Register | 0…65535 = duration of the “sleep” phase in milliseconds after each execution cycle of functional diagrams |
You can return the controller to normal power mode manually. Write “0” to the “Sleep Mode Enable Register”. The controller will transition into this mode immediately after the end of function diagram execution loop in which the value was changed.
The controller also returns to normal power mode automatically in the following scenarios:
- when electric potential is changed on any controller pin corresponding to a controller channel configured as an active input or pulse counter;
- when electric potential is changed on any controller pin corresponding to a channel controlled by one of the following drivers: CAN, LIN, UART/RS232, IR or Elita GSW.
Note: Information about changes in electric potential on controller pins corresponding to any of the above channels is available by accessing a special controller status register - Interfaces Activity Control Register.
Information about the current power mode is available by accessing the “Sleep Mode Control Register”.
| Register | Return Values |
|---|---|
| Sleep Mode Control Register | 1 = controller is in Sleep Mode 0 = controller is in Normal Mode |
Note: When creating a function diagram that uses hibernation mode, take into account the side effect caused by changes in the time scale. This effect affects function block timer incrementation: starting delays, stopping delays and PWM generator timers in hibernation mode increment intermittently each time the controller exits sleep mode. This means that by default these timers will increment in 1000 ms intervals per diagram loop.
Note: Take note of the inversion of the output of the function block №4.
WatchDog Timer
The WatchDog Timer (WDT) exists to eliminate the possibility of the controller entering an infinite loop unrelated to the main function diagram execution loop. The infinite loop could happen if the controller is connected incorrectly or when the controller system software encounters unknown errors.
In CannyLab IDE up to version 1.4, you could control watchdog timer operation: enable or disable it, set its period. The WDT was disabled by default.
From CannyLab version 1.4 onwards, you cannot disable WDT. It is enabled permanently and you can change its period, which is 1 second by default.
If the delay in diagram execution exceeds the set WDT period, the controller is immediately reset.
Function Diagram actual run time
The time the controller needs to execute a loop of the function diagram in actual conditions depends on the number and type of functional blocks present in the diagram, the number of drivers installed in the system software and the activity of said drivers. For reference, CANNY 7’s execution loop of a diagram, that contains about 400 function blocks and is actively interacting with the CAN driver, lasts approximately 9 ms.
Note: When creating a function diagram, consider the effect introduced by duration of the execution loop. This effect affects function block timer incrementation: starting delays, stopping delays and PWM generator timersincrement intermittently each loop by the value equivalent to the duration of the execution loop. This means that when the actual loop duration is 6 ms, the actual period of all PWM generators is a multiple of 6 ms.
Information about the length of the previous execution loop of the function diagram is available in the “Last Execution Loop Duration Register”.
| Register | Return Values |
|---|---|
| Last Execution Loop Duration Register, ms | 0…65535 = duration of the previous execution loop of the function diagram in milliseconds |
Note: The most accurate way to measure the total time of controller’s operation, for example when implementing a clock, is summation with accumulation of the values obtained in the “Last Execution Loop Duration Register” during each execution loop of function diagram.
Device ID
With CANNY 7’s updated bootloader release, version 001004, each device is assigned a unique identification number during manufacture that can be during function diagram development, in particular to protect function diagrams against unauthorized use.
Access the device identifier by reading the following system registers.
| Register | Return Values |
|---|---|
| Device ID Register D1:D0 | 0…0xFFFF = lower two bytes (D1 & D0) of the controller ID |
| Device ID Register D3:D2 | 0…0xFFFF = upper two bytes (D3 и D2) of the controller ID |
While developing a function diagram, you can get the device ID by accessing the device information window, available via the Device -> Information option in the menu bar or by pressing the “Information” button on the toolbar. The device ID will be shown as a 4 byte number, with the upper two bytes located on the left.
For example the identifier is shown as 0x563B8693 in the device menu. The D1:D0 Device ID Register is 0x8693, the D3:D2 Device ID Register is 0x563B.
Below is an example of a function diagram that illustrates working with device identifiers. The values read from the Device ID Registers are compared to constant pre-set values. If the values match, 1 is written to the “device ID is correct” named network.
Interface activity monitoring
Interfaces Activity Control Register is a synthetic register that monitors the current activity of the controller’s external interfaces used in the function diagram, as well as the channels used as active inputs or counters. When no data is being transmitted or received via any of the controller’s interfaces and no electric potential changes are detected on active IO channel pins, the Interfaces Activity Control Register is set to 0.
This register is useful when implementing controller power mode switching..
| Register | Return Values |
|---|---|
| Interfaces Activity Control Register | ≥ 1 = activity detected on one of the active channels or interfaces of the controller during the previous diagram execution loop 0 = no activity detected on any of the active channels or interfaces of the controller during the previous diagram execution loop |
Vendor ID
With CANNY 7’s updated boot loader release, version 001005, each CANNY 7 device is assigned a Vendor(supplier) ID during manufacture, which can be used during function diagram development for additional protection against unauthorized use.
Device Vendor ID assigned by the controller manufacturer is the same for all controllers designed for a single counterparty. It can also be assigned separately to a specific party of controllers. For the production of controllers with a specific vendor identifier please contact the manufacturer.
Access to work with the device identifier via the following special system register.
| Register | Return Values |
|---|---|
| Device Vendor ID register | 0…0xFFFF = value of the vendor identifier |
While developing a function diagram, you can get the vendor ID by accessing the device information window, available via the Device -> Information option in the menu bar or by pressing the “Information” button on the toolbar. The vendor ID is shown as a 2 byte number, with the upper byte being located on the left.
The value read from the Vendor ID Register is compared to a constant pre-set value. If the value matches, 1 is written to the “vendor ID is correct” named network.
SEE ALSO
