addressing individual pins: low/high vs let pin =

[bryanl]

When trying to set a gaggle of pins, different ways seem to require different nomenclature. Low/High appear to require pin names such as "C.3" while assignments require something like "Let outpinB.1 = 0" -- "let B.1=0" won't work and 'high outpinB.1' also seems to generate a syntax error.

It appears that if there is an assignment for the entire port, the in or out is inferred by which side of the assignment the port appears. (but maybe not for the 28x2?)

For example, the dx.com LCD thingy uses S.4 to S.7 for the data nibbles. These have to be set individually because they map to B.1, B.5, B.6, and B.7. That complicates the data mapping differently than having to just convert a byte to 2 nibbles. Assignment with the output character in b0 and using pin0 to pin8 is the easiest way to do this from what I can see so far.

As an example, inglewoodpete uses symbols for outpinB.* but then has to revert to S.* for the initialization "output" command to set them as outputs. The LCD output routine does assignment and can use the symbols. That leads to inconsistent names for the pins in the program. It appears that you do have to specificy the pins as output but that command won't accept the assignment type nomenclature easiest to use in assigning pin output values.

I'm trying to grok the nuance that must exist ...

Is that just the way it is? Or is there some reason for this issue? Or am I missing something?

 

[nick12ab]

C.0, C.1 etc. are constants and pinC.0, outpinC.0 etc. are pin variables.

 

[inglewoodpete]

If you have the Deal Extreme LCD module (I presume you mean the cheap LCD shield), then you can get it working with the code I posted here. The pin numbering is a pit strange, however, you only need to initialise the pins once at the start of your program and then fashion one subroutine to match the unusual pinout.

Once you have those two pieces of code, everything else should be fairly simple. I have use the dx.com modules in a couple of projects - they have a very high contrast ratio.

Edit: Having re-read the original post, I see now that the issue is about the way the PICAXE addresses its pins. In other languages, the difference could be described as direct and indirect addressing of the hardware. In the case of the PICAXE it probably has to do with the way the firmware evolved.

It would theoretically be possible to rewrite the compiler to accept pin assignments in two different contexts.

Example:

High B.0: Low C.1, C.2    ;Pin ID is interpreted as a constant, indication specific chip hardware.
C.1 = Bit6: C.2 = 0       ;[I]Pin condition is equated[/I] to a constant or variable.  (Hypothetical case)

 

[westaust55]

The HIGH and LOW commands and some others will automatically define an IO pin as an output when the command is used. This is explained in PIACXAE Manual 2 for the related commands where there is information in the form:

Information:
The high command switches an output on (high).
On microcontrollers with configurable input/output pins (e.g. PICAXE-08) this
command also automatically configures the pin as an output.

The other commands and assignments such as LET pinsC = (for entire port) and pinC.2 = (for a single IO pin) do not automatically set the pin as an output and the DIRSC (or DIRSB) command must be applied first.

With an assignment, an IO reference on the left side of the = sign is automatically taken to be an assignment to an output but will in effect do nothing if the pin has not been set as an output. This can be designated as pinC.2 or outpinC.2. The “Outpins is generally preferred to make it clear to readers – see also PICAXE Manual 2.

With an assignment, an IO reference on the right side of the = sign is automatically taken to be a reference to the state of an input – but the pin is not automatically changed to an input.


With the HIGH, LOW, PULSOUT command the pin parameter can be a constant or variable. As mentioned above, the parameters B.0, B.1, . . . C,.0 and C.1, etc are in fact pre defined constants, but you can also use a variable such as HIGH b0 where b0 could have a value from 0 to around 15 (less or more)depending upon the actual PICAXE chip involved.

When assigning a value/state to an IO pin with a program line such as pinsC = %01010101 or pinC.1 = 1,
pinsC and pinC.1 have to be able to accept a value and thus need to be a variable and not a constant (constants cannot change values as the data type name implies).

 

[bryanl]

I think this gets at what I was trying to understand in a nutshell:

C.0, C.1 etc. are constants and pinC.0, outpinC.0 etc. are pin variables.

it seems there must be some register or something (the pin variables, re: "but will in effect do nothing if the pin has not been set as an output.") that is handled differently down in the depths of the PIC from directly addressing the pins (the constants). That probably gets into how the PIC programs its pins (thanks westaus55 for some on this). I think I need to go muck around in the PIC datasheet to see if I can find what I am looking for (e.g. TB3009) -- one of the big benefits Revolution does with the PICAXE is to hid all that stuff (but some artifacts remain).

Once you have those two pieces of code, everything else should be fairly simple. I have use the dx.com modules in a couple of projects - they have a very high contrast ratio.

Thanks much for that code inglewoodpete. I have taken it apart, put it back together with a different naming scheme, and added comments that are really my notes for understanding what is going on. I have also 'borrowed' code ideas for the I2C RTC and EEPROM so my 'demo' that will make for one very expensive clock. - then I can add SWR calculations from the inline bridge, a CI-V monitor and a few other things (e.g. automatic logging?) until I max out a 28X2 or my attention goes elsewhere. Your PWM thingy for the LCD backlight and the keypad input are both good starts for playing around with some important concepts in the mucee world. (can't use button on a key ladder so debounce, key repeat, and other interactive factors need attention)

When I get the clock done some day, I'll add the PICAXE code to my online collection along with the re-engineering of the VK5JST Aerial Analyzer code at tcl.leipper.org. I haven't found much PICAXE code for clock display management (yet, like I want) so maybe it'd be something someone could use for ideas like I have been able to do with code snippits that folks have kindly posted in these forums.

The CTMU looks like another galaxy to explore - AN1375 "see what you can do with the CTMU" looks like fun - especially ideas 47 and 48 - solving hunger and bringing world peace - That charge time measurement capability has some interesting implications beyond capacitive touch buttons ... these things can at least bring peace of mind in a diversion from real world hassles and frustrations.

 

[westaust55]

For whichever PICAXE you are considering, look at the Rev Ed website pages starting here: http://www.picaxe.com/What-is-PICAXE/PICAXE-Chip-Labels/
Which provides links to the corresponding PIC datasheets.

The PIC has two primary registers for digital purposes for each port (A, B, C, D and E depending upon the size of the PIC chip).

Reading and writing data is via the Port<x> register (HIGH, LOW, pins<x>, etc act on bits in these register

Setting the direction for digital IO is via the corresponding port TRIS<x> register. (dirs<x> and some commands such as HIGH and LOW set the various bits in the TRIS register).

Some additional registers come into play when you consider analog data.

 

[Technical]

The PIC has two primary registers for digital purposes for each port (A, B, C, D and E depending upon the size of the PIC chip).
Reading and writing data is via the Port<x> register (HIGH, LOW, pins<x>, etc act on bits in these register
Setting the direction for digital IO is via the corresponding port TRIS<x> register. (dirs<x> and some commands such as HIGH and LOW set the various bits in the TRIS register).

The PIC has three primary registers for digital purposes for each port (A, B, C, D and E depending upon the size of the PIC chip).
Reading and writing data is via the Port<x> register (HIGH, LOW, pins<x>, etc act on bits in these register
Writing data is via the LAT<x> register (HIGH, LOW, pins<x>, etc act on bits in these register)
Setting the direction for digital IO is via the corresponding port TRIS<x> register. (dirs<x> and some commands such as HIGH and LOW set the various bits in the TRIS register).

 

[AllyCat]

Hi,

Also, if you're accessing the PIC SFRs directly, bear in mind that in PICaxe M2s, the "base" PIC port pins are mapped to different Port.Pins in the PICaxe. i.e. PICaxe ports B and C use some (different) bits from the PIC ports C, B and A.

Cheers, Alan.

 

[westaust55]

Also, if you're accessing the PIC SFRs directly, bear in mind that in PICaxe M2s, the "base" PIC port pins are mapped to different Port.Pins in the PICaxe. i.e. PICaxe ports B and C use some (different) bits from the PIC ports C, B and A.

My SFR memory map for M2 parts at post 13 here may be helpful:
http://www.picaxeforum.co.uk/showthread.php?11514-PICAXE-Memory-Map-and-SFR-Details-Chart/page2

The same thread on the next page has my more comprehensive PICAXE memory map which also shows the pre-defined variables, scratchpad and EEPROM memory which may help some to keep trace on what variable/lo action is used for specific function in their projects.

 

[westaust55]

The PIC has three primary registers for digital purposes for each port (A, B, C, D and E depending upon the size of the PIC chip).
Reading and writing data is via the Port<x> register (HIGH, LOW, pins<x>, etc act on bits in these register
Writing data is via the LAT<x> register (HIGH, LOW, pins<x>, etc act on bits in these register)
Setting the direction for digital IO is via the corresponding port TRIS<x> register. (dirs<x> and some commands such as HIGH and LOW set the various bits in the TRIS register).

@Technical,

Would I be correct in suggesting that the information I provided with respect to there being two registers is correct for the earlier (non M2 and X2 ) parts and that your amended version is correct for the newer M2 and X2 parts where the corresponding newer PIC chips do have LAT<x> registers (ie LATA, LATB, LATC, etc).

 

[inglewoodpete]

Perhaps the thread is drifting off-topic.

This all reminds me why I try to accept the product as it is offered. There can be enough challenges if you stay within the guidelines of Manual 2 - I know this because I tend to push the limits. You have to be really keen to fiddle with the SFRs when you have quite a comprehensive BASIC command set. (Before someone jumps in: Yes I realise that the SFR commands are part of the PICAXE BASIC command set.)

 

[westaust55]

Compared with some thread where the discussion can almost swing through 90/180 degrees and sometimes at post 2 instantly deviate with suggestions for alternatives without answering the OP&#8217;s original question, I didn&#8217;t think the discussion in this thread was deviating too far from the OP&#8217;s desire for information.

In post 1, I perceived that the request was for information about the nuances involved in addressing/controlling IO.

In post 5 the OP indicated an intent to read the PIC datasheet to understand the underlying registers involved with IO pins by the comment:
&#8220;I think I need to go muck around in the PIC datasheet to see if I can find what I am looking for&#8221;.

Notwithstanding that I had earlier neglected a difference between the older and newer PICAXE chips in terms of SRF&#8217;s (Special Function Registers) this was providing the OP with some of the basic information about the PIC registers into which he was considering to delve.

 

[bryanl]

I can very much understand the idea of accepting the product as offered - this is really the only way to use it to build things that work as designed. Where I see this mangled the most is in the 'which is better: PIC or Amtel?' wars. What Revolution has done for the PIC in creating a simplified model of a microcontroller often gets bypassed or ignored yet it is, IMHO, one of the critical factors in the debate.

I also like to go a step farther and try to understand why a product is offered the way it is. That helps me create a mental model of the device and better understand its limitations and its possibilities. Sometimes getting such an understanding is a clue to finding solutions or workarounds to problems I encounter and sometimes it highlights the evolution of a product and uncovers possible constructive feedback for the product designers. -- and I gain a better appreciation of just what those designers have done.

From my end, I really appreciate the comments offered. The westhaus55 memory map is a very nice visualization of the PICAXE representation of PIC memory. The nomenclature on this is, to me, a part and parcel of that for the pins. The map shows the link between the hardware and its internal representation. It also illustrates how the various types of memory in the PIC are used and named by the PICAXE firmware.

A namespace and how it is used is critical to problem solving, creativity, and communication. With a product as complex as a PIC microcontroller, enhanced by both a product line and product evolution, creating a translation layer between the hardware and a beginning user that is as effective as the PICAXE is something to admire. It makes it possible to take an incredibly complex chip and easily do something useful with it. As one starts to get to more complex constructions, issues like the pin naming differences with different commands come up and that can lead to investigations that provide insight into the technologies being used and the trade-offs taken for particular solutions. That is a learning experience without peer.

So, thanks guys: Good stuff and good ideas to pursue towards the next step.

 

[boriz]

Would something like this work?

pins = pins and %11111101     'clear bit 1
pins = pins or %00001100    'set bits 2 and 3