"Variable already an alias" - is there a way to avoid this?

[CuriousOne]

I have 4 piece of 7 segment led displays connected directly to MCU pins, via 220 ohm resistor, common anode going to Vdd. I wrote a routine, which allows to display any number (X) on any digit (Y). But it is taking about 2.7k of memory, mostly because I can not redefine variables on the fly. So my main goal was to shorten this code somehow.

SMART:   'DECODER ROUTINE
FOR X=0 TO 9
IF X=0 AND Y=1 THEN GOSUB N10 'displays specific digit for specific segment
IF X=1 AND Y=1 THEN GOSUB N11
IF X=2 AND Y=1 THEN GOSUB N12
IF X=3 AND Y=1 THEN GOSUB N13
IF X=4 AND Y=1 THEN GOSUB N14
IF X=5 AND Y=1 THEN GOSUB N15
IF X=6 AND Y=1 THEN GOSUB N16
IF X=7 AND Y=1 THEN GOSUB N17
IF X=8 AND Y=1 THEN GOSUB N18
IF X=9 AND Y=1 THEN GOSUB N19

IF X=0 AND Y=2 THEN GOSUB N20
IF X=1 AND Y=2 THEN GOSUB N21
IF X=2 AND Y=2 THEN GOSUB N22
IF X=3 AND Y=2 THEN GOSUB N23
IF X=4 AND Y=2 THEN GOSUB N24
IF X=5 AND Y=2 THEN GOSUB N25
IF X=6 AND Y=2 THEN GOSUB N26
IF X=7 AND Y=2 THEN GOSUB N27
IF X=8 AND Y=2 THEN GOSUB N28
IF X=9 AND Y=2 THEN GOSUB N29

IF X=0 AND Y=3 THEN GOSUB N30
IF X=1 AND Y=3 THEN GOSUB N31
IF X=2 AND Y=3 THEN GOSUB N32
IF X=3 AND Y=3 THEN GOSUB N33
IF X=4 AND Y=3 THEN GOSUB N34
IF X=5 AND Y=3 THEN GOSUB N35
IF X=6 AND Y=3 THEN GOSUB N36
IF X=7 AND Y=3 THEN GOSUB N37
IF X=8 AND Y=3 THEN GOSUB N38
IF X=9 AND Y=3 THEN GOSUB N39

IF X=0 AND Y=4 THEN GOSUB N40
IF X=1 AND Y=4 THEN GOSUB N41
IF X=2 AND Y=4 THEN GOSUB N42
IF X=3 AND Y=4 THEN GOSUB N43
IF X=4 AND Y=4 THEN GOSUB N44
IF X=5 AND Y=4 THEN GOSUB N45
IF X=6 AND Y=4 THEN GOSUB N46
IF X=7 AND Y=4 THEN GOSUB N47
IF X=8 AND Y=4 THEN GOSUB N48
IF X=9 AND Y=4 THEN GOSUB N49

PAUSE 300
NEXT
Y=Y+1
IF Y>4 THEN Y=1
GOTO SMART 

N10: '0 at 1st digit
GOSUB CLAR1
LOW A1: LOW B1: LOW C1: LOW D1: LOW E1: LOW F1 '0
return

N11: '1 AT 1ST DIGIT
GOSUB CLAR1
low b1: low c1 '1
RETURN

N12: 
GOSUB CLAR1
low A1: low B1: low g1: low e1: low d1 '2
RETURN

N13:
GOSUB CLAR1
low A1: LOW B1: LOW C1: LOW D1: LOW G1 '3
RETURN

N14:
GOSUB CLAR1
LOW F1: LOW B1: LOW G1: LOW C1 '4
RETURN

N15:
GOSUB CLAR1
LOW A1: LOW F1: LOW G1: LOW C1: LOW D1 '5
RETURN

N16:
GOSUB CLAR1
LOW F1: LOW A1: LOW G1: LOW E1: LOW D1: LOW C1 'C6
RETURN

N17:
GOSUB CLAR1
low A1: low B1: low C1 '7
RETURN

N18:
gosub CLAR1
low A1: low B1: low C1: low f1: low e1: low g1: low d1 '8
RETURN

N19:
gosub CLAR1
low A1: low B1: low C1: low f1: low g1: low d1 '9
RETURN

CLAR1: 'clear 1ST DIGIT
high A1: high B1: high C1: high d1: high e1: high f1: high g1
return

N20: '0 at 1st digit
GOSUB CLAR2
LOW A2: LOW B2: LOW C2: LOW D2: LOW E2: LOW F2 '0
return

N21: '1 AT 1ST DIGIT
GOSUB CLAR2
low b2: low c2 '1
RETURN

N22: 
GOSUB CLAR2
low A2: low B2: low g2: low e2: low d2 '2
RETURN

N23:
GOSUB CLAR2
low A2: LOW B2: LOW C2: LOW D2: LOW G2 '3
RETURN

N24:
GOSUB CLAR2
LOW F2: LOW B2: LOW G2: LOW C2 '4
RETURN

N25:
GOSUB CLAR2
LOW A2: LOW F2: LOW G2: LOW C2: LOW D2 '5
RETURN

N26:
GOSUB CLAR2
LOW F2: LOW A2: LOW G2: LOW E2: LOW D2: LOW C2 'C6
RETURN

N27:
GOSUB CLAR2
low A2: low B2: low C2 '7
RETURN

N28:
gosub CLAR2
low A2: low B2: low C2: low f2: low e2: low g2: low d2 '8
RETURN

N29:
gosub CLAR2
low A2: low B2: low C2: low f2: low g2: low d2 '9
RETURN

CLAR2: 'clear 1ST DIGIT
high A2: high B2: high C2: high d2: high e2: high f2: high g2
return

N30: '0 at 1st digit
GOSUB CLAR3
LOW A3: LOW B3: LOW C3: LOW D3: LOW E3: LOW F3 '0
return

N31: '1 AT 1ST DIGIT
GOSUB CLAR3
low b3: low c3 '1
RETURN

N32: 
GOSUB CLAR3
low A3: low B3: low g3: low e3: low d3 '2
RETURN

N33:
GOSUB CLAR3
low A3: LOW B3: LOW C3: LOW D3: LOW G3 '3
RETURN

N34:
GOSUB CLAR3
LOW F3: LOW B3: LOW G3: LOW C3 '4
RETURN

N35:
GOSUB CLAR3
LOW A3: LOW F3: LOW G3: LOW C3: LOW D3 '5
RETURN

N36:
GOSUB CLAR3
LOW F3: LOW A3: LOW G3: LOW E3: LOW D3: LOW C3 'C6
RETURN

N37:
GOSUB CLAR3
low A3: low B3: low C3 '7
RETURN

N38:
gosub CLAR3
low A3: low B3: low C3: low f3: low e3: low g3: low d3 '8
RETURN

N39:
gosub CLAR3
low A3: low B3: low C3: low f3: low g3: low d3 '9
RETURN

CLAR3: 'clear 1ST DIGIT
high A3: high B3: high C3: high d3: high e3: high f3: high g3
return

N40: '0 at 1st digit
GOSUB CLAR4
LOW A4: LOW B4: LOW C4: LOW D4: LOW E4: LOW F4 '0
return

N41: '1 AT 1ST DIGIT
GOSUB CLAR4
low b4: low c4 '1
RETURN

N42: 
GOSUB CLAR4
low A4: low B4: low g4: low e4: low d4 '2
RETURN

N43:
GOSUB CLAR4
low A4: LOW B4: LOW C4: LOW D4: LOW G4 '3
RETURN

N44:
GOSUB CLAR4
LOW F4: LOW B4: LOW G4: LOW C4 '4
RETURN

N45:
GOSUB CLAR4
LOW A4: LOW F4: LOW G4: LOW C4: LOW D4 '5
RETURN

N46:
GOSUB CLAR4
LOW F4: LOW A4: LOW G4: LOW E4: LOW D4: LOW C4 'C6
RETURN

N47:
GOSUB CLAR4
low A4: low B4: low C4 '7
RETURN

N48:
gosub CLAR4
low A4: low B4: low C4: low F4: low E4: low G4: low D4 '8
RETURN

N49:
gosub CLAR4
low A4: low B4: low C4: low F4: low G4: low D4 '9
RETURN

CLAR4: 'clear 1ST DIGIT
high A4: high B4: high C4: high D4: high E4: high F4: high G4
return

[HenrikOlsson]

Yes I see.
Even this does not works:

 IF X=1 then
 Y var PORTA.0
 else
 Y var PORTA.1

You have to understand that the "code" Y VAR PORTA.0 isn't something that is actually being executed on the PIC itself. It's simply a way to inform the compiler that you, in your code, want bit 0 of PortA to be "named" Y. And since it IS something that the compiler handles when it converts your program from PBP into ASM (which is then assembled by the assembler) it can not later be changed by the running program.

So this is just compiler limitation, right?

You can call it a limitation if you like but it's just the way it works.

For the arrays, can be port name in it?

No. But you can do this:

idx VAR BYTE
idx = 9
PortA.0[idx] = 1

Here, idx acts as an offset from PortA.0
If you look at the datasheet for the PIC you'll find that the Port registers are consecutive in the memory map so by counting 9 bits from bit 0 of PortA.0 you'll end up PortB.1.

So with this method you can use an Array to hold your seven offsets and redifine those offsets at will, something like this (untested and uncompiled, treat it accordingly):

X VAR BYTE[7]     ' Array to hold the bit offset from PortA.0
idx VAR BYTE       ' Temporary variable needed to actually use the indexing

Main:

GOSUB DG1
  idx = X[2]            ' Since X[2] contains the value 17, so will idx
  PortA.0[idx] = 1    ' Write  to "PortA.17" which in real life will be PortC.1

GOSUB DG2
  idx = X[2]            ' Now that we've changed the values in the X-Array, X[2] contains the value 18 and so will idx
  PortA.0[idx] = 1   ' Write to PortC.2

END

DG1:
  X[0] = 27  ' AX VAR PORTD.3
  X[1] = 20  ' BX VAR PORTC.4
  X[2] = 17  'CX VAR PORTC.1
  X[3] = 18  'DX VAR PORTC.2
  X[4] = 24  'EX VAR PORTD.0
  X[5] = 26  'FX VAR PORTD.2
  X[6] = 21  'GX VAR PORTC.5
RETURN

DG2:
  X[0] = 28  ' AX VAR PORTD.4
  X[1] = 21  ' BX VAR PORTC.5
  X[2] = 18  'CX VAR PORTC.2
  X[3] = 19  'DX VAR PORTC.3
  X[4] = 25  'EX VAR PORTD.1
  X[5] = 27  'FX VAR PORTD.3
  X[6] = 22  'GX VAR PORTC.6
RETURN

[CuriousOne]

Well, we have been also told that PBP can't do string variables and this is chip limitation, but there are some other compilers, which can do variables on PICs. So I believe, this "on the fly" port redefine is exactly this particular compiler issue, not general hardware or software limitation.

Thanks for the array code, will read it later.

[richard]

So I believe, this "on the fly" port redefine is exactly this particular compiler issue, not general hardware or software limitation.

the ability to alter a defined constant at runtime would be make a total mockery of sound programming fundamentals .
changing a constants definition is not a thing .
runtime allocation of resources is not done that way in any programming language, pbp3 is not particularly adept at it but with a bit of imagination there are workarounds. the sort of output pin manipulation via port alias indexing can do what you desire (as henrik has stated ) .

while pbp3 has no str type vars it can deal with and create null terminated c-type strings easily, with a little practice and a little skills
strings can be manipulated in any way necessary with little fuss.


i would just say one more thing multiplexing ffs

[CuriousOne]

Why pin definition should be constant?

OK say compiler substitutes say code "LD, B(3)" which say means making PORTB.3 high each time I'm making HIGH BUZ because previously I had defined BUZ var PORTB.3

Now let's say, I want to do dynamic port re-mapping and at one moment BUZ is PORTB.3 and at another moment it is PORTB.4. What compiler should do? During the compile time, instead of replacing all references of BUZ with "LD,B(3)", it just places statement "LD,B(X)", where is X an address say in eeprom or ram, from which, during runtime, the number of port to be made high is being read. And when I need to force this statement to make say PORTB.4 high, I'll write 4 into that address, instead of 3.

I'm asking of something unusual and not previously done?

[Ioannis]

I really do not understand why you may need this.

At design time, you decide what you will connect on which ports. Then you proceed to writing the program.

At this stage you have lines that will be defining what your circuit will do, at compile time, and what decisions your code will do at run time. Your electric connection cannot change dynamically!

It just doesn't make sense, to me at least, why move around a LED or Buzzer, or Button from port to port at run time...

Ioannis

[CuriousOne]

Simple.

To make code shorter.

I've posted an example above. Yes it works but I have 40 subroutines and 40 IF THEN's in it. In case of redefinable port<>variable, it would be reduced 4 times.