Go to page on main NoviceGuard site with list of all pages.

Go to main page of NoviceGuard site.

(NOTE TO SELF: At present, TransPgsIndex says NovGrdCore provides NO support for devices on the twelve way connector. Revise that when no longer true!)

This page named "TransNovGrdCoreTwelveWay" to say the following...

It is a page with a transitory existance. In due course, it will be subsumed into other pages.

It is about routines (to be created) as part of the NoviceGuard (hardware) support library NovGrdCore (software)

And it is about routines (to be created) to facilitate the use of the NoviceGuard's Twelve Way Connector.

In connection with the twelve way connector, two things need to be remembered:

a) The twelve way connector is the most advanced part of the NoviceGuard. It is not "hard" to use, but novices should have done quite a bit with the simpler elements first.

b) In due course, I intend to modify NovGrdCore to move us on to something which will be easier for the novices, and at the same time make it harder for inadvertant mistakes to do harm to the Arduino.

NovGrdCore / Twelve Way Connector plans

(Your thoughts on the following will be welcome! Better to change the "plan" before the work to program it into reality has been done, if it has flaws, or could be better!)

As written up "definitively" elsewhere, the signals on the twelve way connector, from left to right, leaving out the "no connection" "pin" positions where there is NO pin, to polarize the connector are...

   Vcc    D9    D8    D7    D6    A1    A0    D11    D10   Gnd

Just as the data lines assigned to the four "special" inputs and four "special" outputs serviced by the circuitry further up the face of the NoviceGuard have been given more logical, memorable names, I want to give these signals names.

The names for the signal lines, i.e. all of the lines apart from Vcc and Gnd, will, at the present time, probably be called....

  tw0  tw1  tw2  tw3.... including tw4 and tw5 for A0 and A1. (The last line, D10, would be called tw7.)

These names have the virtue of being SIMPLE. The fact that tw4 and tw5 are DIFFERENT is unfortunate, to say the least. The analog lines can, of course, be used as simple digital lines. (I'm going to have to look a bit at the details of that, in due course.)

I anticipate fuctions similar to those we already have....

boTwInHigh(0) would, for instance, return true if tw was set up as an input, and the input was high when the function was called. Maybe a different scheme would be better...

bTwIn(0) could return 0 if the input were low, 1 if it were high, and 2 if that line were not currently configured as an input?

A corresponding set of subroutines would be proviced for setting or clearing individual output bits.

For both, it might be an idea to offer a "read" (or write) the whole batch at once...

boMakeTwMany('0011xxx') might "say" "make the first three lines high, the next two low, and leave the rest untouched. It would return true if no problems arose, false otherwise. (The problem I have in mind is a request to change a line that is not set as an output.)

iTwInMany would return something like 0011222... one decimal digit for each signal. '0' if low, '1' if high, and '2' if the line were configured as an output. Maybe it would be better if the function returned a string?

Other routines would be needed to access the analog lines. It might be necessary to extend the "current use" codes to cover digital in, digital out, analog in, analog out.

And, lastly, which should probably have been first, a "configure lines" routine would be needed. It would call pinMode statements, yes... but the novices wouldn't see them.

"boSetTwPinModes" might be a suitable name. It could be followed by a string, one character to a signal....

x for "don't change this one

n for input (without pullup)

p for input with pullup

o for output

a for analog input

b for analog output?... (e.g. the pin used to create a PWM signal)

While some of these require no specific pinMode statement, I think it would be wise to provide for everything you might want to use a line for.

You might want a "report current pinModes" function. Not hard to provide, but of course the programmer should KNOW how the pins were programmed.

Again, the subroutine is set up as a boolean, so that false can be returned sometimes. For example, if a user said he/ she was going to use tw0 as an analog input, the boSetTwPinModes function could tell the user that it won't fly. Maybe the function should return a byte... 0 if there is no error detected, other numbers, for different errors.

====

Anything else needed in connection with the twelve way connector?

Go to page on main NoviceGuard site with list of all pages.

Go to main page of NoviceGuard site.