Electronics > Beginners

Assembly code Help! PIC16F57

<< < (4/32) > >>

KL27x:
Electrofinn

I think I can help, but this code totally sucks. Fortunately, my own code mostly totally sucks, so I am pretty good at working backwards to fix things.

You have identified that the look up table named "pattern" is what produces the sequence of 16 frames that you wish to extend to 32. I'm assuming you are correct in identifying this.

Steps.
1. Look at "pattern." It is a table that adds the contents of W to the PCL to determine where to jump and exit from. The contents of W must be between 1 and 16 (or is it 0-15? I'm not sure. In modern PIC I use BRW, in this case it would be 0-15, not 1-16; but I digress) or else the PCL will jump to a point that is outside of the contents of pattern. Hence you must figure out what is loaded into the W register before pattern is called. If you simply add 16 more retlw instructions after the original 16, they will never be executed.

2. Figure out where "pattern" is called. To do this, first locate "pattern" by right clicking on the code and selecting "goto" from the dropdown menu in MPLAB. Then find header "pattern" in the dropdown list.

3. Now you have "pattern" in front of you. Type ".fuckall" after it. Then reassemble. You will get a list of errors where the code is trying to call or goto "pattern." In this case, you will get only one error. But before you click on it, be sure to change "pattern.fuckall" back to "pattern." Then click on the error and it will take you to
 where "pattern" is called from. It is called from "feature."

4. In "feature," you will find:
   movf   counter_hi,W
   call   pattern

   every single time "pattern" is called, the W register is first loaded with the value that is contained in register designated as "counter_hi."

  So unless the code is broken, the writer has assured that the value of  counter_hi is always something between 1 and 16 (or 0-15?). If it were not, this code would more than likely produce a stack error.

5. Find every instance of "counter_hi" in the code.
5A - locate where the coder defined counter_hi. In this case, it's a short code, and it is easily found at the top. But if it were more complex there are two ways.
    A trick I use is to scroll to the very top of the main .asm file and type "counter_hi equ 0" 
    Reassemble.
    You will get an error that says "counter_hi previously defined"
    delete the "counter_hi equ 0" you just typed, then click on the error to jump to where the coder has defined "counter_hi"
    The good part of this is it will find it no matter what file it was placed in, which it could be one of many .inc files and/or .asm files.

You will find it here:
unused2   equ   14
hold_counter   equ   15
counter_hi   equ   16
counter_lo   equ   17
delay_counter   equ   18

So this means that the coder has defined it to be register 0x16 in general memory. Do not change this to 32. This is a fortuitous coincidence, only. This is an address, not a value.

You might have forgotten by now, but the point of locating it was to find out every place it is used in the code. So change the name to produce an error.
write "ASS." in front of counter_hi. So it reads "ASS.counter_hi equ 16"
reassemble. You will find numerous errors of "counter_hi not defined."

Again, be sure to erase the "ASS." before you click on the errors.

Scrolling through the errors one at a time, I get to the eleventh error when I find this code

sequence1
      bsf      counter_lo,7
      incf   counter_lo,f
      btfss   status,zer
   retlw   00
      incf   counter_hi,f
      bcf      counter_hi,4
      movf   credit_count,f
      btfsc   status,zer
   retlw   00
      bcf      mode_byte,7
      bcf      mode_byte,5
      bsf      mode_byte,0
   retlw   00



     
If you notice, this code increments counter_hi, but it clears bit 4. Bits go from 0-7. So bits 0-3 are the only things used. Anything that rolls over into bit 4 gets clipped off. This is how the coder is assuring that the contents of counter_hi, and hence the addw PCL instruction in "pattern" do not overflow past 16. In fact, he clips the range to 0-15. 16 is not included, which is why maybe he has redundant value in the spot 15 and 16 in his pattern table. At 16, counter_hi just rolls back to zero.

If you change this 4 to a 5, you will double the range of counter_hi. And your 16 retlw valued you added to the original 16 in "pattern" should now be included in the mix
To be clear, change
bcf counter_hi, 4
to
bcf counter_hi, 5



There may be more things which you must take into account and change, but this will get you started.




Electrofinn:
wow yes This looks like something I can follow, excellent thank you. will work through your post and report back. yes the original writer had admitted that his code was ugly but hey it works so me personally couldn't argue with it. As I said I grew up playing with this fruit machine for hours and hours without a hitch.

would be marvellous if I had a fluent understanding of coding, because believe me if I did, the perfectionist in me would completely re-write this and make it the most efficient code it could possibly be. sadly, I have trouble with coding... and mathematics for that matter.   

KL27x:
You're welcome.

Just to add: if this were important, at all, you would want to carefully check all the errors past #11, too, to make sure that increasing the range of counter_hi is not going to cause some other stack error.

A perfectionist would have to completely rewrite this code. This code has very illogical/inefficient use of the stack.*  But this was a first attempt at coding in assembly. And even good, efficient assembly code is rarely readable. These "tricks" I have shown are pretty much necessary to do anything complex in assembly, IMO. Without manipulating error codes, it would be near impossible for me. This is why I avoid macros. Trying to make assembly readable is essentially a lost cause; but in some ways it breaks the chain of error codes.

*I take that back. This part probably only has 4 deep stack to begin with. This makes is very hard to write assembly!
edited to add

--- Quote --- Do a "disassembly" list and review it.
--- End quote ---
Why on god's earth would you disassemble assembly when you are looking at the source code?

Electrofinn:
OK well sort of a success, increasing the counter_hi does now display the 32 hex values with the pattern like the original so yay! to that one, but playing the machine for around 10 mins I noticed 2 things.

1. occasionally on a win it doesn't seem to be playing the correct light sequence, which for a win is the "pattern2" table. sometimes it plays the first 16 of the "pattern" table and other times it runs the correct one.

2. and I had one instance when I had ran out of credits and after 2 seconds the "pattern" is meant to be run but the lights stayed off. again this doesn't happen every time.   

Thank you so much for your help by the way, I really appreciate this.   


   

KL27x:
I still have this up on my computer, so error 10 shows

      movf   counter_hi,W
      call   pattern2

So pattern2 is analogous to pattern, but it only has the original 16 values, not 32. So when counter_hi is higher than 15, it is leaving pattern2 and producing a stack error. We call this "going off into the weeds."

What I would try is locate feature1 (right click on the code, goto, find feature1)
feature1   
      btfss   mode_byte,4
   goto      feature2
      movf   counter_hi,W
      call   pattern2

and change it to be:

feature1   
      btfss   mode_byte,4
   goto      feature2
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;   movf   counter_hi,W  ;the semicolon in front removes this from the code but leaves it there for posterity, for your own reference. In case this doesn't work.
;
movlw 0x0f
andwf counter_hi,w
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
      call   pattern2

and see what happens.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod