pepperdash/Essentials
1
0
Fork 0
mirror of https://github.com/PepperDash/Essentials.git synced 2026-02-03 23:05:00 +00:00
Code Issues Packages Projects Releases Wiki Activity

grammar edits

Andrew Welker
2020-02-13 11:29:35 -07:00
parent e53139df26
commit 16a63d7a79
1 changed files with 67 additions and 51 deletions
Download Patch File Download Diff File Expand all files Collapse all files

118
Debugging.md

@@ -1,39 +1,41 @@
## Methods of Debugging
1. You can use Visual Studio step debugging
* Pros:
- Detailed real time debugging into with breakpoints and object inspection
* Cons:
- Doesn't really work remotely
- On processors with Control Subnet, you must be connected to the CS interface to use step debugging. Often not practical or possible.
- No logging
- Using breakpoints stops the program and can interrupt system usage
- Requires the running application to be built in debug mode, not release mode
- Pros:
- Detailed real time debugging into with breakpoints and object inspection
- Cons:
- Doesn't really work remotely
- On processors with Control Subnet, you must be connected to the CS interface to use step debugging. Often not practical or possible.
- No logging
- Using breakpoints stops the program and can interrupt system usage
- Requires the running application to be built in debug mode, not release mode
2. You can use the Debug class features build into the PepperDash.Core library.
* Pros:
- Can be easily enabled from console
- Allows for setting the level of verbosity
- Works when troubleshooting remotely and doesn't require a connection to the CS interface of the processor.
- Allows for logging to the Crestron error log or a custom log stored on removable media
- Works regardless of build type setting (debug/release)
- Can easily identify which class instance console messages are being generated by
- Can use console commands to view the state of public properties on devices
- Can use console commands to call methods on devices
- Doesn't stop the program
* Cons:
- No detailed object inspection in real time
- Only prints console statements already in code
- When enabled at the highest level of verbosity, it can produce a significant amount of data in console. Can be hard to find messages easily.
- No current mechanism to filter messages by device. (can be filtered by 3rd party tools easily, though)
- Not very effective in debugging applications running on the VC-4 platform as only log messages get printed to the Syslog
- Pros:
- Can be easily enabled from console
- Allows for setting the level of verbosity
- Works when troubleshooting remotely and doesn't require a connection to the CS interface of the processor.
- Allows for logging to the Crestron error log or a custom log stored on removable media
- Works regardless of build type setting (debug/release)
- Can easily identify which class instance is generating console messages
- Can use console commands to view the state of public properties on devices
- Can use console commands to call methods on devices
- Doesn't stop the program
- Cons:
- No detailed object inspection in real time
- Only prints console statements already in code
- When enabled at the highest level of verbosity, it can produce a significant amount of data in console. Can be hard to find messages easily.
- No current mechanism to filter messages by device. (can be filtered by 3rd party tools easily, though)
- Not very effective in debugging applications running on the VC-4 platform as only log messages get printed to the Syslog
## How to use the PepperDash.Core Debug Class
The majority of interaction is done via console, preferably via an SSH session through Crestron Toolbox, PuTTy or any other suitable application.
In code, the most useful method is `Debug.Console()` which has several overloads. All variations take an integer value for the level (0-2) as the first argument. Level 0 will ALWAYS print. Level 1 is for typical debug messages and level 2 is for verbose debugging. In cases where the overloads that accept a `Debug.ErrorLogLevel` parameter are used, the message will ALWAYS be logged, but will only print to console if the current debug level is the same or higher than the level set in the `Debug.Console()` statement.
In code, the most useful method is `Debug.Console()` which has several overloads. All variations take an integer value for the level (0-2) as the first argument. Level 0 will ALWAYS print. Level 1 is for typical debug messages and level 2 is for verbose debugging. In cases where the overloads that accept a `Debug.ErrorLogLevel` parameter are used, the message will ALWAYS be logged, but will only print to console if the current debug level is the same or higher than the level set in the `Debug.Console()` statement.
All statements printed to console are prefixed by a timestamp which can be greatly helpful in debugging order of operations.
``` csharp
```csharp
// The most basic use, sets the level (0) and the message to print.
Debug.Console(0, "Hello World");
// prints: [timestamp]App 1:Hello World
@@ -56,66 +58,74 @@ Debug.Console(0, Debug.ErrorLogLevel.Notice, "Hello World");
```
## Console Commands
The following console commands all perform actions on devices that have been registered with the `PepperDash.Essentials.Core.DeviceManager` static class
### Appdebug:[slot] [0-2]
### Appdebug:[slot][0-2]
Gets or sets the current debug level where 0 is the lowest setting and 2 is the most verbose
Example:
```
RMC3>appdebug:1 // Gets current level
RMC3>AppDebug level = 0
RMC3>AppDebug level = 0
RMC3>appdebug:1 1 // Sets level to 1 (all messages level 1 or lower will print)
RMC3>[Application 1], Debug level set to 1
```
### Devlist:[slot]
Gets the current list of devices from `DeviceManager`
Prints in the form [deviceKey] deviceName
Example:
```
// Get the list of devices for program 1
// Get the list of devices for program 1
RMC3>devlist:1
RMC3>[16:34:05.819]App 1:28 Devices registered with Device Mangager:
[16:34:05.834]App 1: [cec-1] Tx 5 cec 1
[16:34:05.835]App 1: [cec-1-cec]
[16:34:05.835]App 1: [cec-1-cec]
[16:34:05.835]App 1: [cec-5] Rmc 1 cec 1
[16:34:05.836]App 1: [cec-5-cec]
[16:34:05.836]App 1: [cec-5-cec]
[16:34:05.836]App 1: [cec-6] Dm Chassis In 1 cec 1
[16:34:05.837]App 1: [cec-6-cec]
[16:34:05.837]App 1: [cec-6-cec]
[16:34:05.837]App 1: [cec-7] Dm Chassis Out 1 cec 1
[16:34:05.838]App 1: [cec-7-cec]
[16:34:05.838]App 1: [cec-7-cec]
[16:34:05.838]App 1: [comm-1] Generic comm 1
[16:34:05.838]App 1: [comm-1-com]
[16:34:05.838]App 1: [comm-1-com]
[16:34:05.839]App 1: [comm-2] Rmc comm 1
[16:34:05.839]App 1: [comm-2-com]
[16:34:05.839]App 1: [comm-2-com]
[16:34:05.840]App 1: [comm-3] Rmc comm 2
[16:34:05.840]App 1: [comm-3-com]
[16:34:05.840]App 1: [comm-3-com]
[16:34:05.841]App 1: [dmMd8x8-1] DM-MD8x8 Chassis 1
[16:34:05.842]App 1: [dmRmc100C-1] DM-RMC-100-C Out 3
[16:34:05.843]App 1: [dmRmc200C-1] DM-RMC-200-C Out 2
[16:34:05.843]App 1: [dmRmc4kScalerC-1] DM-RMC-4K-SCALER-C Out 1
[16:34:05.844]App 1: [dmTx201C-1] DM-TX-201C 1
[16:34:05.845]App 1: [eisc-1A]
[16:34:05.845]App 1: [eisc-1A]
[16:34:05.845]App 1: [gls-odt-1] GLS-ODT-CN 1
[16:34:05.846]App 1: [gls-oir-1] GLS-OIR-CN 1
[16:34:05.846]App 1: [processor]
[16:34:05.846]App 1: [processor]
[16:34:05.847]App 1: [ssh-1] Generic SSH 1
[16:34:05.847]App 1: [ssh-1-ssh]
[16:34:05.848]App 1: [systemMonitor]
[16:34:05.847]App 1: [ssh-1-ssh]
[16:34:05.848]App 1: [systemMonitor]
[16:34:05.848]App 1: [tcp-1] Generic TCP 1
[16:34:05.849]App 1: [tcp-1-tcp]
[16:34:05.849]App 1: [tcp-1-tcp]
```
### Devprops:[slot] [deviceKey]
### Devprops:[slot][devicekey]
Gets the list of public properties on the device with the corresponding `deviceKey`
Example:
```
// Get the properties on the device with Key 'cec-1-cec'
// Get the properties on the device with Key 'cec-1-cec'
// This device happens to be a CEC port on a DM-TX-201-C's HDMI input
RMC3>devprops:1 cec-1-cec
[
@@ -152,12 +162,15 @@ RMC3>devprops:1 cec-1-cec
RMC3>
```
### Devmethods:[slot] [deviceKey]
### Devmethods:[slot][devicekey]
Gets the list of public methods available on the device
Example:
```
// Get the methods on the device with Key 'cec-1-cec'
// Get the methods on the device with Key 'cec-1-cec'
RMC3>devmethods:1 cec-1-cec
[
{
@@ -192,22 +205,25 @@ RMC3>devmethods:1 cec-1-cec
RMC3>
```
### Devjson:[slot] [JSON formatted object {"deviceKey", "methodName", "params"}]
### Devjson:[slot][json formatted object {"devicekey", "methodname", "params"}]
Used in conjunction with devmethods, this command allows any of the public methods to be called from console and the appropriate arguments can be passed in to the method via a JSON object.
This command is most useful for testing without access to hardware as it allows both simulated input and output for a device.
Example:
```
// This command will call the SendText(string text) method on the
// device with the Key 'cec-1-cec' and pass in "hello world" as the
// This command will call the SendText(string text) method on the
// device with the Key 'cec-1-cec' and pass in "hello world" as the
// argument parameter. On this particular device, it would cause
// the string to be sent via the CEC Transmit
// the string to be sent via the CEC Transmit
RMC3>devjson:1 {"deviceKey":"cec-1-cec", "methodName":"SendText", "params": ["hello world\r"]}
// This command will call SimulateReceive(string text) on the device with Key 'cec-1-cec'
// This command will call SimulateReceive(string text) on the device with Key 'cec-1-cec'
// This would simulate receiving data on the CEC port of the DM-TX-201-C's HDMI input
RMC3>devjson:1 {"deviceKey":"cec-1-cec", "methodName":"SimulateReceive", "params": ["hello citizen of Earth\r"]}
```
For additional examples, see this [file](https://github.com/PepperDash/Essentials/blob/master/devjson%20commands.json).
For additional examples, see this [file](https://github.com/PepperDash/Essentials/blob/master/devjson%20commands.json).