Electronics > Beginners
Assembly code Help! PIC16F57
KL27x:
Just to go way back, here:
--- Quote ---Agree with others. To edit code, you need to understand it. There are a few obvious things of concern.
--- Quote ---carry equ 0
zer equ 2
ind equ 00
--- End quote ---
Default radix is hexadecimal with Microchip. (Choices are binary, octal (I think), decimal, hexadecimal, and ASCII. You can declare the radix during your initialization. RADIX DEC will make the default decimal. It is an Assembler directive and is not part of the chip's instructions per se.) Thus, you have given "carry" and "ind" the same value/identifier.
--- End quote ---
In this case, the writers of the code are designating bit location of "carry" and "zer." While "ind" is designating a register address.
This is redundant if you include the .inc file for the part. Because these are already defined in the device .inc.
The .inc file by default defines C bit as 0 and Z bit as 2.
Address of INDF is by default 0x00 (same as 0 or .0 or b'00000000'; we just write it this way because it looks more like an address)
So there is no conflict, other than you can misuse any designated register or bit designation.
For instance, you can write
Movlw PORTA
and instead of moving the contents at this address to W, it will load the value of that address.
And you can write
bsf PORTA,Z
this will set bit 2 of PORTA, even though the only reason Z bit was defined was to make using STATUS,Z easier to remember than STATUS,2 (and possibly more consistent between different devices).
or
movlw Z
would put 0x02 in W.
This is the reason the IDE can't throw an error when you define multiple things with the same number. That can be an address, it can be a value/constant, or it can be a bit designator 0-7, and it all depends on how the coder uses it. There are dozens of bit designators in the .inc header that will be the same value.
The assembler does not distinguish at all between address and literals/constants. We write them differently just to reinforce the difference, because it's up to the coder to know the difference.
This is why I always end constant names with ".c" for instance. Even though I like to define them thusly:
constant name.c = 0x01
This is absolutely no differnet in result than writing
name.c equ 1
Now, if you wanted to go down this road, you could make "zer" have more utility in a way.
#define zer STATUS,Z
and now you can write
btfss zer
instead of
btfss STATUS,Z
In this case, since STATUS is accessible from any bank, you don't need to worry about banking, so you don't have to remember what register zer is even associated with to do this.
Electrofinn:
your last asm was probably just meant as an exercise to go with what your teaching me but just thought I'd let you know just in case, it sometimes, but not all the time, fails to run "pattern" on a win. lights just stay off.
KL27x:
This is an example of how memory bugs happen. I didn't check the other subroutines that might be using counter_lo. So now we learn more, one tooth at a time.:)
So, let me guess, it also didn't change the speed of the sequence?
bsf counter_lo,7
I missed this line.
bsf counter_lo,7
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; incf counter_lo,f
; btfss status,zer
incfsz counter_lo,f
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
retlw .0
movlw .128 ;this is b;10000000; if bit 7 gets set, anyway, then this is the same value as zero!* But this register is evidently used elsewhere
movwf counter_lo
*As far as this subroutine in isolation is concerned. But elsewhere in another subroutine, there is apparently something else. I'm guess there's a Z check of counter_lo in another subroutine**, and 0x80 is not the same thing as zero, as far as other part of the code might be concerned. :)
**similarly to how the coin_counter gets a Z check at the end of this "sequence" subroutine.
When writing code, I will end up breaking it many many times. When altering my own code, I'll break it many more times. When altering someone else's code, I'll break it pretty much nonstop. This is why trying to fix it over the internet is pretty much impossible for myself. If it were here, I'd break it just as often, but the iterations would happen much much faster. :)
Electrofinn:
--- Quote ---So, let me guess, it also didn't change the speed of the sequence?
--- End quote ---
You guessed right. Will have to look at your posts again tomorrow, this is blowing my mind a little bit lol finding this really hard. I think with this it's going to be like most things I find hard, the more time I expose myself to it the better.
--- Quote ---This is why trying to fix it over the internet is pretty much impossible for myself. If it were here, I'd break it just as often, but the iterations would happen much much faster. :)
--- End quote ---
Yes absolutely understand that.
KL27x:
Hard is an understatement. The way these guys used counter_hi and counter_lo is very, very, intertwined and obfuscating. This is made to fail. These counters are manipulated in all kinds of different ways in different subroutines.
If they (or he.. I bet anything there was one guy coding and one guy sharing credit :)) were still coding today and wrote a similar program (on a baseline device, for some reason), they probably would have found a much better way to do this.
I imagine I would have a 2 byte counter, incremented only in the main Loop. And instead of Z checks in the individual subroutines, there ought to be compares, doing a subtraction of a literal and a C check. And they would have to submit a request for reset, which if the counter is in use by another routine, this should produce some obvious error code say on the output of the displays.
So, here's the rub. There's essentially zero chance you're gonna fix with google and intuition. Maybe in a matter of weeks, if you go through the Gooligum thing and don't lose interest.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version