Stand-alone test program

[Neil Higgins]

Oscar is right in claiming elsewhere that a test program for the PiDP-11/70 lights and switches is not really needed. If you follow his instructions for building the PiDP-11, you will get an early indication of success or failure.

Not withstanding, I have attached a stand-alone test program written in Python, written mostly because I wanted to build my Python skills a little. This program is slow and pedantic (like its author) - it does not take shortcuts, or do anything clever, or invoke high-flying Python syntax. As such, it should be fairly easy to follow.

At this stage, the program only performs positive tests, i.e. it invokes what should be correct behaviour with correct stimuli.

Everything works as expected, EXCEPT for testing of the rotary encoders. This is because they do not work as I expected. I expected that the switches would put out a steady sequence of I/Q (in-phase/quadrature) indications, e.g. AA, AB, BB, BA in one direction, and AA, BA, BB, AB in the other direction. It appears that instead they put out an I or Q -pulse- for each change of position. Meaning that I have to look for momentary indications, not steady ones. This screws up my simplistic approach to testing.

Operating instructions can be found in the accompanying PDF document or by using the -h or --help command line option.

Observe carefully the Licence provisions.

Comments and suggestions are welcome.

[Neil Higgins]

Rotary encoder testing now works.

[Oscar Vermeulen]

Neil,

Great! Can I add this to the web site with proper attribution? I think it's a rather useful reference for people who want to hack about or have a soldering problem.

Regarding the encoder - It's sampled in a somewhat unorthodox manner in the code. In case anyone ever looks at it and wonders or feels disgust: it looks primitive (you'd think the lack of debouncing would cause trouble) but has the advantage of not eating up more CPU cycles than the other switches.

Kind regards,

Oscar.

On Wed, 8 Aug 2018 at 08:47, Neil Higgins <1955...@gmail.com> wrote:

Rotary encoder testing now works.

--
You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/ab1e3456-2a6d-4251-88d4-e9307b36940b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Neil Higgins]

On Wednesday, 8 August 2018 20:02:10 UTC+10, oscarv wrote:

Neil,

Great! Can I add this to the web site with proper attribution?

Yes, Oscar. Of course. I have uploaded new files because I fixed an error in a comment.

Your success with the encoders, despite the lack of debouncing, would be due in part to the fact that the transitions make a Gray code - only one bit changes at a time - so if it changes to-and-fro a few times, the net effect is the same.

Cheers,

Neil

[Neil Higgins]

“Regarding the encoder - It's sampled in a somewhat unorthodox manner in the code. In case anyone ever looks at it and wonders or feels disgust: it looks primitive (you'd think the lack of debouncing would cause trouble) but has the advantage of not eating up more CPU cycles than the other switches.”

Now that you mention it, I don’t do any debouncing either. Looking at my code, I can certainly see that this might result in multiple counts for a single (micro-) step into a detent position. So the apparent success of the code is due as much to the grace of God, and maybe the quality of the encoders, as to my expertise.

[Neil Higgins]

This version should be robust with respect to single-bit bounces.

[Garry Lockyer]

Neil, thanks for this very useful test program! I was testing my PiDP (after soldering switches, all LEDs tested OK before moving on to the switches) using scanswitch - all was good for bits 0 - 11 but scanswitch returned 0 for bits 12 and up. So I decided to try your program and it showed that all switches were functional! So it looks like scanswitch might have a problem or be limited to bits 0 - 11. But...

The sense of the reported switch data seems inverted to me. When switches are in their normal or non-active position, you report a value of 1. I would prefer that switches in their normal or non-active position be reported as a 0 and be reported as a 1 when they are up or active. I think this would more closely mimic the operation of the switches, at least for the address/data switches.

But, all that being said, your program is very useful and I recommend it for final testing.

Regards,

Garry

[Neil Higgins]

Hi Garry. Thanks for the feedback. At present the program just reports values “as read” - switch open -> high = 1 = True. It wouldn’t be difficult to map these to “user” values, but the main point is to ensure that the value changes when the switch if flipped.

[Neil Higgins]

This version (V0.5) adds selective inversion of the switch inputs, so that the displayed values are "logical" rather than "physical". Enjoy.

[Neil Higgins]

Documentation updates - see revision history.

[Neil Higgins]

Program and documentation updated pursuant to feedback form Oscar.

[Julian Calaby]

For those who are wondering why this fails immediately on Lite Rasbian images, you need to install python3-rpi.gpio first, i.e. run:

sudo aptitude install python3-rpi.gpio

[Neil Higgins]

Hi Julian. Thanks for that information. I’ll include it in the next documentation update. Neil.