SEEMINGLY bad practice?

Thread Starter

MaxHeadRoom

Joined Jul 18, 2013
25,183
Subject Pic 16c84 program.
btfsc 5, 4
decfsz 13, 1

Do these commands simply refer to the 5th & 13th word in data memory?
Seems lazy and-or leads to confusion??
What say you?
 

MrSalts

Joined Apr 2, 2020
1,762
I think it's just fine and using numerical addresses can make it easier to look at address blocks easier (e.g. handling a 32-bit number using four consecutive registers).
The example code for ADDLW (the first instruction alphabetically) in the datasheet for most Microchip parts gets the detail description of all the ways you can address registers. You can address registers the same way for all other instructions like DECFSZ
63358E67-86F2-4DCA-9434-835650211D42.jpeg
 

Thread Starter

MaxHeadRoom

Joined Jul 18, 2013
25,183
I never run across something like that nor wrote so with PICs.
I came across a series of PIC assembly instructional manuals by one instructor who insisted on listing all the pertinent definition equates at the head of the Pgm, instead of just including the ready available '*.INC file. :confused:
 

JohnInTX

Joined Jun 26, 2012
4,667
Bad IMO.

What would make the program easier to read, debug and port to another chip?
This?
btfsc 5,4 ; got a databook handy?

or this

#define ButtonIn PORTA,4 ; defines like this go into an IOdefs.inc file. Change the definitions for other chips/PCB revs etc.

then code like this:
btfsc ButtonIn ; skip if button == 0 (pressed)

I don't know if pic-as allows defines like that but it's invaluable in MPASM, IMO.

RAM should be defined the same way:
Count equ .10
WordValue equ .3456 ; some 16 bit constant, decimal

cblock 0x0ch ; start of 16F84A RAM
Abyte : 1 ; define one byte
Aword: 2 ; define 2 byte word
endc

movlw Count ; count to Abyte (location 0ch)
movwf Abyte

movlw high WordValue ; upper byte to Aword MSbyte
movwf Aword
movlw low WordValue ; lower byte to Aword LSbyte
movwf Aword+1

to move the whole shebang to another PIC just change the cblock starting address - the code stays the same.

Rule of thumb is to always use defined values in the code flow. The reasons include easier and SAFER to read, modify, adjust values without the risk of fouling up the code flow.

My .03
 

JohnInTX

Joined Jun 26, 2012
4,667
So you agree it is a bad premise!
As I thought. :)
LOL! But a good technique to manage porting to another chip is to have all of the ports, memory, PCB rev., etc. for each chip in one (or a few) include file(s). Then use an build time switch to select the target. That way once you confirm the old code is building/running on the F84A you can switch over to the new target chip. If something needs checking, or you want to trace some flow in the simulator, just switch back and test.

TARGET_F84 equ 1
TARGET_18F4520 equ 0

if TARGET_F84
INCLUDE ChipDefs84.inc ; F84 ports, RAM etc
endif

if TARGET_4520
INCLUDE ChipDefs4520.inc ; same named stuff but located for another chip
endif

If all of the references in the actual code are symbolic instead of literal numbers, the build will fix up everything without danger to the code flow AND give you an error if you whiff on some location spec.
 

Thread Starter

MaxHeadRoom

Joined Jul 18, 2013
25,183
Re: 16C84.
The whole program appears to posses poor design.
There is no memory block assigned , just the EQUate constants listed.
No processor _config set.?
Evidentially it must have worked as the project was distributed. PCB and all.?
 

BobTPH

Joined Jun 5, 2013
4,888
Microchip XC16 defines athe hardware registers as external in the headers then resolves them with a linker file automatically included based in the target processor.

Bob
 

JohnInTX

Joined Jun 26, 2012
4,667
Re: 16C84.
The whole program appears to posses poor design.
There is no memory block assigned , just the EQUate constants listed.
No processor _config set.?
Evidentially it must have worked as the project was distributed. PCB and all.?
Early Microchip PIC programmers (PIC Pro, PIC Pro II) did not have the ability to specify the configuration bits in the .HEX - you had to set them manually when connected to the programmer via PC and terminal emulator. Frequently a master chip without code protection was copied to the programmer's memory then it would ask you if you wanted the target chips to be code protected. The later programmers are much better in that regard.
EQU is common for smaller PICs/early code. Symbolic debugging wasn't all that it is today so it was nice to be able to inspect registers/RAM knowing their fixed address. CBLOCK was a later improvement to define RAM (really just associating a name with an address that incremented according to the byte count) while giving some flexibility when it came time to define a new byte or two somewhere in the middle of the RAM space without having to re-do all of the following EQUates. Having known, fixed addresses at build time also allows more compact code - you only set banks when you know you need them.
I don't do relocatable assembler on 8 bit PICs with the banked RAM and ROM on all but the 18F.
 
Last edited:
Top