Using a number instead of a letter-number discripter.

[Gramps]

My 74 years of brain fade is showing more and more every day
I recall that on the larger chips it was necessary to label the chip pins with a number in stead of a letter-number designation.
For example:
Symbol LED1 = 13 'B.5
Symbol LED2 = 11 'B.4
Where is this information listed in the manual?
Thanks, Gramps

 

[1968neil]

I'm pretty sure that all of the chips can be used with the portPin format, the older system to my knowledge has been out of favour for some time.
I've used all of the chips in the current range at one time or another with the PortPin set up and have not had any problems.
I'm sure if this is not entirely correct someone will chime in.....
Regards
Neil

 

[lbenson]

Either designation should work for all current chips. For the 40X2, this lists the numbers:

sertxd(cr,lf)
for b1 = b.0 to b.7
  sertxd(#b1," ")
next
sertxd(cr,lf)
for b1 = c.0 to c.7
  sertxd(#b1," ")
next
sertxd(cr,lf)
for b1 = a.0 to a.7
  sertxd(#b1," ")
next
sertxd(cr,lf)
for b1 = d.0 to d.7
  sertxd(#b1," ")
next
sertxd(cr,lf)
do: loop

(So I think you're incorrect about the pin numbers for B.4 and B.5.)

 

[hippy]

I don't believe the numeric pin values were ever officially documented as it is recommended to only use the pin names - port.pin.

The only time it really makes sense to use numeric pin values is for the 8-pin PICAXE chips which only have one port. Otherwise it will just confuse people as to which pins are being referred to by a number. And that's also likely to include the author of the code when they come back to it sometime later.

The compilers will accept named pins for all PICAXE, including the older chips, and larger chips.

If one needs to programmatically set a pin in a port, such as when a program receives a number of a pin to set high, one can add the port.0 value, for example to set a pin in the B port -

SerRxd N4800, #pin
pin = pin & 7 + B.0
High pin

The only time there may be an issue is when a port.pin name is used to reference an ADC channel in a SYMBOL statement. The following will work because the compiler will auto-magically work out what A.0 means in terms of ADC channel, asuming it exists -

ReadAdc10 A.0, potValue

But the following may not work because that conversion doesn't happen for SYMBOL -

Symbol POT_ADC = A.0
ReadAdc10 POT_ADC, potValue

POT_ADC would likely end up having value 16, when the ADC channel should be some other number.

In that case you need to define POT_ADC in terms of the ADC channel number. I believe that only applies to non-M2 chips because M2 chip port.pin always match ADC channel.

 

[Gramps]

I've used all of the chips in the current range at one time or another with the PortPin set up and have not had any problems.

Ditto Neil. I don't remember why that number thing stuck in my mind.

So I think you're incorrect about the pin numbers for B.4 and B.5.

Correct Lance! Appreciate your detailed post!

will auto-magically work out

LOL! As always right on target!

 

[Buzby]

The only time I've used the 'number' method, instead of the usual 'port.pin' method, is in the orrery.

Because the orrery used 24 pins each with 3 states, there was a total of 552 combinations. To do all this with the 'port.pin' addressing would have meant having a huge amount of 'IF/THEN' statements. This would make the code very slow, not something than can be tolerated in a Charlieplexed display.

So although 'port.pin' is usually the best method, sometimes the 'number' method is the only sensible solution.

 

[Aries]

I have also very occasionally used the "number" variation for pins, usually when I want to do a READADC on a sequential set of pins (e.g. B.1 to B.4) within a FOR loop.

 

[hippy]

In most cases the port.pin naming can be used instead of numbers because they are simply numbers, albeit in not such an instantly recognisable form.

For example in, "For b0 = C.0 To C.7", "If b1 >= C.0 And b1 <= C.7 Then", the port.pin represents the pin number which would otherwise have been used.

That's not to say raw pin numbers can't be used, mustn't be used, and there may be cases where it makes sense to use those. It's just that there are very few cases where they have to be used.

 

[Aries]

For b0 = C.0 To C.7

As you said earlier, there is the catch with X2 chips that the ADC numbers do not match the pin numbers - and they are not necessarily even sequential - so READADC in a loop only works with M2 chips (fortunately mine was a 20M2, and I did use for b0 = B.1 to B.4

 

[Buzby]

I've only just realised, ten years later, that I could have used 'port.pin' numbering in my orrey !.

However, it would not have made any difference to the code, only the way the pins are defined in the EEPROM.

The main part of the code calculates what LEDs to light based on the count of LEDs in each orbit.
The display routine takes the LED numbers and converts each to a pair of pin numbers, which are retrieved from the EEPROM.

So my initialisation code that filled the EEPROM would have changed from :

' Write the values to the EEPROM
    hi2cout 0,(0,1)          ' LED 0
    hi2cout 2,(0,2)          ' LED 1
    hi2cout 4,(0,3)          ' LED 2

to

' Write the values to the EEPROM
    hi2cout 0,(B.0,B.1)          ' LED 0
    hi2cout 2,(B.0,B.2)          ' LED 1
    hi2cout 4,(B.0,B.3)          ' LED 2

As that code was auto-generated by some Excel VBA it would not have been much more difficult to make the VB write the numbers in 'port.pin' format. The actual numbers stored would have been just the same.

 

[hippy]

I've only just realised, ten years later, that I could have used 'port.pin' numbering in my orrey !.

It's never too late to score a D'Oh! moment

However, it would not have made any difference to the code, only the way the pins are defined in the EEPROM.

That's the key thing; port.pin is no different to any other number save for how it looks. It really is just a substitution - except in READADC commands for X2 where it triggers an additional conversion if it sees that form which it won't if pin numbers are used. For example for a 20X2 -

; 20X2 Pin C.2 has pin number value 10
; 20X2 Pin C.2 is also ADC Channel 8

ReadAdc C.2, b0        ; Works, C.2 is silently converted to ADC channel 8

ReadAdc 10, b0         ; Reads ADC Channel 10, reads from B.5

Symbol  ADC_PIN = C.2  ; Sets ADC_PIN to number value 10
ReadAdc ADC_PIN, b0    ; ADC_PIN has value 10, reads from B.5 as above

If "ADC_PIN" above had been called "ADC_CHAN" it would probably have been easier to avoid a mistake in doing the above. It would have been clearer that C.2 is a pin, not an ADC channel, that it should have been 'Symbol ADC_CHAN = 8".

That it doesn't usually make any difference is why it doesn't usually matter which one uses. So nothing wrong with what you had except it might have required slightly more working out at the time. It is mainly just to save effort and to make knowing what numbers represent which leads to port.pin recommendations.