Bug fix 5A6A1-INTR_LT_PANEL

[Arribe]

Description

Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context.

Bug fix for console and flood pots on 5A6A1-INTR_LT_PANEL. Updated defines to use A# values vs digital pin numbers.

Closes #110

Dependencies

• List any dependencies that are required for this change, including a full list of libraries required, especially if it is a new or otherwise unused library in the OpenHornet software.

Type of change

• [ ] New software module (new software module for slave)
• [x] Bug fix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
• [ ] This change requires a documentation update outside of the automatically-generated Doxygen documentation.

Checklist:

• [x] My code follows the style guidelines of this project
• [x] I have complied with the software manual for this project
• [x] I have performed a self-review of my own code
• [x] I have commented my code fully with Doxygen compatible comments, particularly in hard-to-understand areas
• [x] I have made corresponding changes to non-Doxygen generated documentation
• [x] I have ran Doxygen locally, and it builds the docs successfully
• [ ] My changes generate no errors on compile in Arduino IDE
• [ ] My changes generate no new warnings on compile in Arduino IDE
• [ ] Any dependent changes have been merged and published in downstream modules
• [ ] (For sketches only) This sketch complies with OH-INTERCONNECT v
• [ ] If this sketch requires additional libraries, I have added it as a sub-module per the Arduino Libraries section of the Software Manual.

How Has This Been Tested?

• [X] I have tested the sketch in-circuit in DCS with DCS-BIOS and outputs (displays, LEDs, etc.) function as expected.
• [X] I have tested the sketch in-circuit in DCS with DCS-BIOS and HID inputs (switches, pots, etc.) function as expected, with switches moving the correct direction.
• [X] I have tested the sketch in-circuit in DCS with DCS-BIOS and any logic in the sketch has been tested and functions as expected.
• [ ] This code has not yet been tested in-circuit.
• [ ] This code has not yet been tested in DCS-BIOS.

Description of Testing

Loaded the sketch and validated the dcsbios messages.

Test Configuration

• Firmware version:
• Hardware:
• Toolchain:
• SDK:

[kbastronomics]

Yes, these are POTS they must go to Analog inputs not digital ones. Interconnect calls out D6_A7 which is what the connection point is and is correct. do we need a note on the interconnect to point out that all POTS must be programmed as a Analog input maybe though I do not know that the interconnect is appropriate for a software note since its the hardware connection diagram?

[Arribe]

Seems to depend on the analog pin, but I haven't played with it much. The lower numbered ones (A0 - A3) on the sparkfun define match the digital numbers shown in the reference pic posted in the software channel today. The higher number ones are defined as much higher numbers. But regardless looks like the analog pins used for pots should use the A# to let the library sort it out.

[kbastronomics]

Yes. always use the Analog pins with a POT, digital pins will not work. they are on/off. so when the voltage on the pot is below the threshold voltage (usually around 2v) it returns a 0, above that it returns a 1.

only the analog pins can read a pot correctly.

[Arribe]

Tracking on the electrical hook up of pots vs digital pins for switches. This is a case of learning something new about programming differences between the A0 - A3 PINs vs the higher ones like A7. Too complicated for me to list out in these small comments. But I got it now.

[kbastronomics]

Do you think we need to point this out, I know your fix here was for your code itself and that's fine. i'm just wondering do we need to point this out and if so, where? i'm not sure the interconnect is the right place since it's physical hookup and we're only naming variables/defines using the same name to make lookup easier for coders.

[Arribe]

Good question, and I think this is where the complication comes in. For pins like A3 it’s defined as 21 in sparkfun’s pin_arduino.h file. Coding the pin as analog reads using 21 works fine. What I ran into is for A7 it’s defined as 25 on the header, not 6. But a digital read of the same physical pin coded using 6 works. So it’s probably a matter of saying analog pots should use A# where digital just the number. The ALE silkscreen only list A0, A1, A2, A3… but that is the range where the define is the same as the digital PIN number on the reference pic.

[Arribe]

To answer the question…perhaps best listed as a coding standard?