I/O nomenclature

[tracecom]

In the code below, is there some logic to the apparent discrepancy between the nomenclature for I/Os in "if then" statements versus "irout" statements? I would like to understand the rationale rather than just remember which I/Os are handled each way. Thanks.

' IR Out Code Sample
' Infrared LED on pin C.0 
' Momentary N.O. switches on pins C.1,C.2,C.3,C.4
	
#picaxe 08m2
#no_data

main:	' Wait until switch is pressed
	if pinC.4 = 1 then tx_a
	if pinC.3 = 1 then tx_b
	if pinC.2 = 1 then tx_c
	if pinC.1 = 1 then tx_d
	
goto main

tx_a: 'Load desired SIRC code into b1.
	let b1 = 0		' Code 0
	goto tx_ir
tx_b:
	let b1 = 1		' Code 1
	goto tx_ir
tx_c:
	let b1 = 2		' Code 2
	goto tx_ir
tx_d:
	let b1 = 3		' Code 3
	goto tx_ir


tx_ir: 'Transmit SIRC code multiple times to increase reliability.
	
	for b2 = 1 to 2	' Send code 2 times.
	   irout C.0,1,b1 ' Send device code 1 followed by contents of b1.
	   pause 45
	next b2	
	
goto main

 

[lbenson]

Yes, there is a rationale for this discrepancy which often confuses.

A pin designation for output is a constant number--for instance, C.0 on the 08M2 has a value of 0 (on an 20M2, a value of 8). If you used it in an "IF" statement, "if c.0 = 1 then", it would never be true, since C.0 is equal to zero.

To get the value of a pin, you have to use the "pin" designation, for example, "if pinC.1 = 1 then". This returns either 0 or 1 depending on the voltage level present on the pin (relative to the operating voltage of the picaxe).

Having the output pin designation be a number allows some programming flexibility--"for b4 = 0 to 7 : high b4 : pause 1000 : next b4".

 

[Technical]

In 'irout' you are referencing a pin, which is a fixed number (constant).

In 'if...then' you are referencing (see how it colours) a variable called 'pinC.1' that contains a value 0 or 1.

 

[bryanl]

This is an area where I think some improvements could be made. Right now, pins on the chip are addressed directly in some commands, by the port register bit the mcu uses to control the pin in other commands, and by ADC channel number in other commands. There is no simple model for which is used where and the documentation is often not really clear about the distinctions between labels as the port bit nomenclature is often called a 'pin' when it really isn't.

IMHO, PICAXE needs to take care of this 'behind the curtain' with a command that defines the function for the pin. Input, output, ADC, serial in or out, interrupt or whatnot would be set as appropriate by this command and the user would then use a simple and consistent nomenclature in his program for mcu peripherals and attached devices.

 

[hippy]

This is an area where I think some improvements could be made.

The problem is four-fold; what this nomenclature would be, how it would be specified and used, how it would be implemented, and how it would be applied to existing chips.

The underlying problem is that native PICmicro pinouts are not always how PICAXE users would like their pinouts to be, and how analogue channels map to pins is not logical nor consistent to either and varies from device to device. We unfortunately have no control over that and can only deal with it as it arises.

The PICAXE digital pin designations of <number> or <port>.<number> is consistent and so is use of PIN<number> and PIN<port>.<number> etc but mapping to analogue channels can be difficult, both in READADC and ADCSETUP commands. The M2 devices lend themselves to more consistent mappings but other PICAXE devices do not.

It is true there is no single simple model because there really is no single simple model to be had. Even though the model is better for M2 and should be for future devices; existing devices will not have that model.

the documentation is often not really clear about the distinctions between labels as the port bit nomenclature is often called a 'pin' when it really isn't.

I am not sure how you mean by that and if you could clarify there may be an explanation which clears things up.

IMHO, PICAXE needs to take care of this 'behind the curtain' with a command that defines the function for the pin. Input, output, ADC, serial in or out, interrupt or whatnot would be set as appropriate by this command and the user would then use a simple and consistent nomenclature in his program for mcu peripherals and attached devices.

Again, it's not clear how this is envisioned, but we are always open to suggestions how things could be improved. If you could provide some example or further explanation that would help us in considering this.

 

[srnet]

IMHO, PICAXE needs to take care of this 'behind the curtain' with a command that defines the function for the pin. Input, output, ADC, serial in or out, interrupt or whatnot would be set as appropriate by this command and the user would then use a simple and consistent nomenclature in his program for mcu peripherals and attached devices.

That could easily add to the confusion, you somehow define the 'function' of the pin at the start of the program, and then do something different in the program itself.

And what about pins that can be used for several purposes, say as an Input, then an Output, then an interrupt and afterwards as an AD ?

When you do a 'high a.0' in PICAXE, you know that's all you need to worry about, no need for preceding commands to define the pin function.