Adds support for HiTechnic SuperPro breakout

[jrddunbr]

This commit adds support for the HiTechnic SuperPro breadboardable breakout. It's no longer sold and the documentation is hard to find, but I have one of them and tested most of the functionality.

The only functionality that doesn't make sense to me is the "Strobe" functionality; it appears to be simply digital outputs, but there is not much documentation about what it does. Nothing interesting shows up on the o-scope while using this part of the device.

Also includes a demo of a bar graph doing a binary count from 0 to

255. Looked at examples provided in PDF but some depend on board giving fast response time so decided against it. Should be relatively performant.

[jrddunbr]

If you have time, could you add a unit test?

Do you have examples of unit tests in this codebase that set a good example of what you want to see? I was considering an integration test by making all of the examples in the manual for the device, but decided against it for this PR. Ended up doing a few of them.

[schodet]

Do you have examples of unit tests in this codebase that set a good example of what you want to see? I was considering an integration test by making all of the examples in the manual for the device, but decided against it for this PR.

Yes, look at tests/test_sensors.py, there is a test for all sensors.

You can run them with python3 -m pytest

[jrddunbr]

This is still on my radar, I just haven't had the time this month to work this.

[jrddunbr]

Rebased PR on current tip. Might work on this today.

[jrddunbr]

So something must be broken with my implementation for the analog write functionality because it is getting the first command right (might be a fluke) and then subsequent ones cause the frequency to go into the kHz when I'm sending values under 500Hz.

Bytes were swapped. Fixed.

[jrddunbr]

Items left on this:

• [x] Python 3.7 compatibility checking (seems to pass 3.9 in Debian tests?)
• [ ] Unit tests that actually test underlying functionality instead of just making function calls (which is still better than nothing, since it'll check that the functions at least take the correct inputs as well as not have glaring syntax issues in the hot path)
  • Could just give this a pass since I've written 6-7 different demos that work as integration tests for half the hardware.
• [ ] Sensor auto-detect syntax instead of the current way I'm doing it (optional)
  • I don't see this as a merge-blocking issue since auto-detect won't work anyhow
• [ ] Refactor ADC read to read all 4 at once (optional).
  • I'm thinking it's got both pros and cons since one might want more control over when they are calling each ADC for settlement and such.

I accidentally refactored a bunch of the HiTechnic file thinking that Sphinx was not loading it properly and causing build failures, turns out it was an unrelated issue. It cleans up the comments and fixes most of the syntax errors except where it would likely break existing API functionality (this could be broken in the future if desired to make it PEP-compliant, but I didn't see a need to break it now).

[schodet]

This seems to work with all supported python versions: https://builds.sr.ht/~ni/job/832337