Assembly code Help! PIC16F57

[Electrofinn]

ok so its just that thing where it didn't play the pattern2 after running out of credits, but again just waiting for 30 seconds or so it begins to play, but mostly it does it after two seconds.   

[KL27x]

Well, I could throw more darts, but I'd probably just be wasting our time.   

Timeout, featuredel, and anywhere credit_count Z check is done are places to start breaking the code and seeing what gives. Mode_byte,7 might be involved. It looks like a lock bit to prevent subroutines from resetting certain registers when others are using them. But to begin putting any of that together would take active measures, breaking the code and seeing what happens.

So it's your call if this is good enough or if you want to get your hands dirty.
 

[Electrofinn]

well that bit seems good enough to me, however I just had an instance where it didn't do the full pattern2 on a win but something else has cropped up that I need to do further testing on because all this time I have been using a new servo but have noticed that on every servo actuation that the displays and leds very slighty light up and it doesn't do this with my other servo and I have a hunch that maybe the servo maybe interfering with the chips operation. I don't know if its a back emf issue or what but need to rule this out first I think.


also when you said it may behave differently, I have noticed that the win sequence seems quicker and the beeping seems a little higher in pitch lol I tried other programmed chip with v20 code on it and I swear its slower or am I going nuts. 
   

[Electrofinn]

no just confirmed! the servo isn't the cause its just done it again. I am beginning to think we wasting time on this, we could be at this forever and I bet your getting sick off this lol   

[Electrofinn]

I noticed certain things, even in the original source code, run faster than the original chip, like the servo actuations, the win sequence, the flashing of the hold leds ect. My question to is, Is it possible that problems could occur if the program is running to quickly? I'm just thinking clock cycles and timing. And if so how would we go about slowing it down?

[KL27x]

My question to is, Is it possible that problems could occur if the program is running to quickly?

No. If the servo is doing what it's supposed to, that is the only thing that has a speed limitation. The rest of the machine, AFAIK, has no speed limitation.

how would we go about slowing it down?

The clock speed is set by the external crystal. You could use a slower crystal.

You could also try changing the program constants. Programming constants are often there for tuning things like speed/delays. By virtue of existing, constants are something the coder wanted easy access to in order to tweak/tune/adjust, himself. So while doing so will almost certainly not fix the bug, messing around with these constants might give you some insight into how the program works.

[Ian.M]

If by servo you mean RC servo, the position they move to is set by the pulsewidth, so changing the MCU clock speed will change the position they move to (until the pulse repetition rate goes out of range) , not the actuation speed.   To control the speed of movement, the code would need to loop through intermediate positions rapidly enough and with a small enough position increment to cause the servo to move at a steady rate rather than driving to the new final position at its maximum motor speed.

At this point you have a much better understanding of what the code needs to do and how the hardware works than you did initially, and IMHO the optimum way forward, assuming the board has a socket for a DIP package PIC16x57, would be to design a pin compatible module with a modern PIC on it to let you rewrite the firmware without compromises  using a high level language e.g Microchip XC8.  With some thought given to choice of PIC and pinout allocation, you could probably have a dedicated ICSP/ICD header on the module allowing you to debug the new application in circuit, so you could pause execution at any time to examine/modify state variables etc.

[Electrofinn]

@Kl27x yeah I thought as much. oh well. The ones in the "constants" list seem to be for just the reels, messing with some of them had some strange results like the reels would stop half way between one fruit and another lol one effects the altogether speed but as far as being able to control flashing speeds, I'm guessing they exist in there respective headers? 

@Ian.m yep, I agree. I am happy with how far we have come and I learnt new things on the way. completely re-doing it maybe something for me to aim for in future. 

[KL27x]

To expand on what Ian said, there is perhaps the only way to make a servo move from position A to B faster is that it is a different brand of servo, it has less resistance to movement, or it is getting higher voltage. So what you are probably saying is that the servo pauses a shorter amount of time before moving to the next position.

If the crystal is the same frequency, the most likely reason for the "good" machine to run slightly slower is because  the code was changed and more instructions were added or are being executed per program loop. The average length of the program loop essentially determines the "program clock speed," due to how the code is structured. Many/most/all of the delays in this code are predicated off of main loop cycles.

So one might guess they had to add a significant amount of code to fix the bug.

[Electrofinn]

I see what your saying now, yes there is less of a pause between actuations as compared to the original chip as opposed to the actuations themselves being quicker, that is to say the actuation speed is constant throughout but the pause is shorter.

If I am understanding this correctly, things like the led blink rate is a product of how many instructions exist in a given loop and not a changeable variable?

So one might guess they had to add a significant amount of code to fix the bug.

maybe this might be what they were talking about when they said they did it with just 3 bytes to spare...perhaps.
 

[KL27x]

If I am understanding this correctly, things like the led blink rate is a product of how many instructions exist in a given loop and not a changeable variable?

Dependent on both. There will be a variable/counter, which can be adjusted by the coder, sometimes done through a constant. But what it's counting (in this particular code) is loops/executions of the main program loop.

So if pretty much EVERYTHING is slightly slower in the final version, vs one thing relatively slower compared to other things, it is probably a byproduct of there having been added a significant amount of instructions to the main program loop or to a subroutine which is active all or a large proportion of the time. Vs the programmer having slightly tweaked all these counters, proportionally.

[Electrofinn]

Ok I understand, is programming in a higher level language any better than this? I am beginning to hate this assembly language lol 

[Ian.M]

Ok I understand, is programming in a higher level language any better than this? I am beginning to hate this assembly language lol 

Much!

Assuming you stick to vanilla 'C' without a RTOS to keep it simple, typically for something like this, you'd write functions for each task, each implemented as a non-blocking state machine, with persistent    state,  + an initialisation function, then in the main() function, you'd call init(), then enter a loop to execute all the task functions in turn, with a sandwich delay using a hardware timer at the end of it so the loop execution time remains constant irrespective of the code executed, as long as the execution time of all the task functions is less than the total loop time.   Assuming a suitable PIC, you'd probably also have interrupt driven display multiplexing and hardware assisted servo pulse generation so their interface to the task functions would be via a memory mapped display buffer, and an array of servo positions, one for each servo.   Because each task function uses local variables except for a few globals like the servo positions, display buffer, current credit and overall state, there would be a much lower risk of unexpected interactions between them.   Also 'C' is *far* more human-readable than assembler, as stuff like generating and correctly accessing RETLW tables is handled invisibly by the compiler - you simply define an array of constants then use the array name with an index in square  brackets to access the Nth element of it.

[rstofer]

If your chosen chip is tight on memory, C isn't the way to go.

I have used cc5x

http://www.bknd.com/cc5x/

At the time, 10 years ago, it didn't implement the full C language and, realistically, some legal constructs probably don't translate well to the PIC.

[KL27x]

Much!

Agreed. But the explanation is a little lacking to me.

you'd write functions for each task, each implemented as a non-blocking state machine, with persistent    state,  + an initialisation function, then in the main() function, you'd call init(), then enter a loop to execute all the task functions in turn, with a sandwich delay using a hardware timer at the end of it so the loop execution time remains constant irrespective of the code executed, as long as the execution time of all the task functions is less than the total loop time.

 
With the exception of "the sandwich delay using a hardware timer," you could say that this assembly program pretty much follows this description to a T. And with a hardware timer, you could implement such a feature in assembly, as well.

Because each task function uses local variables

The reason this is a problem in this code is because there are no interrupts on this device. And because, very typically for a noob, he tried to squash all his variables into bank0 to avoid learning. This isn't an assembly vs C problem, IMO. And as rstofer said, you will need much more memory to use C, both data and program memory... particular with PIC baseline architecture which is not efficient with C.

IMO, the two most important difference are

1. that functions/subroutines in C are in many ways easier to read and modify. If you do not predict future needs or potential issues, it is easy to paint yourself into a corner in assembly to where your code is beyond practical repair. In C, making a paradigm shift might mean moving one parenthesis, and the compiler rips up the old framework and automatically rewrites 1000 lines of assembly.

2. C automatically handles when you writes code/routines that occur "simultaneously," to some extent. It hides that, to some extent. (And along with that, any C compiler would produce a metric crap ton of assembly in order to do what this code does... if it had to deal with the limitations of this exact device. This why Ian suggested a more modern device)

One of the biggest challenges with assembly really has nothing to do with coding or logic. It's simply the navigation of the code. Over 10 years of coding in assembly, the main improvements I have made are learning how to do that. No matter how you write it, it always ends up feeling like you can only looking at a single point of a strand of DNA that is 30 miles long. The most important tricks to learn are how to use the tools in the IDE in a way that makes this more manageable. In C, this entire code (minus the headers) might fit in one screen shot.

The other thing is learning to be more wasteful of the resources. Like a C compiler. When you start, it's easy to be stingy, but it is usually better to waste a ton of memory and programming space, here and there, to write code in a way that is more easy to maintain and modify and less easy to make inadvertent bugs.

[rstofer]

One of the problems with the mid-range PIC, using assembly language, is paging.  I have no idea how long the code is for this project but if you start to approach 2k, you need to figure out how to do paging.  It's truly a PITA.

http://www.piclist.com/techref/microchip/pages.htm

An example might be a lookup table that crosses a 2k boundary.  You can get to one end of the table but when you try to address the far end, in the next bank, what you really get is a wrap-around in the currently addressed bank.  And that is usually trash!

Hint:  If you are going to exceed 2k anyway, start your tables at the beginning of a new page.  You have to worry about PCLATH but you would anyway.  What you don't want is to have the tables cross a boundary.

Banking is a similar problem for variables.  You can only reach the currently addressed bank and if your variable is in another bank, you have to get involved with BANKSEL.

https://www.rs-online.com/designspark/the-curse-of-the-microchip-banksel--pagesel

The mid-range PICs are truly a PITA.  That's one reason why people like the AVR chips.  It has a nice, regular, architecture with no paging or banking required.  It also has a much larger instruction set and this can be either fantastic or a lot more work.  AVR chips work a lot better with C, hence the popularity of the Arduino and the ATmega328.

[KL27x]

16F57 isn't even a midrange PIC; it's baseline. Pages are only 2 address bytes long, lol. So it's not 2k per page, it's 0.5k.  Code is already spanning all 4 pages of program space. This device has no interrupts and a 2 deep stack!

start your tables at the beginning of a new page.  You have to worry about PCLATH but you would anyway.  What you don't want is to have the tables cross a boundary.

PIC is worse than that, even. For pointer manipulation, the table must not cross a single address byte or it wraps back to the beginning of that byte block. Tables in this code all start and finish between 200f and 299f 200h and 2FFh, so no problem, there.

*For larger tables you could potentially put them in data memory in an enhanced midrange PIC, where all banks are accessible in a continuous linear block with INDF.

[Electrofinn]

Just having a last ditch effort here, gone back to basics. trying original source code with some of your earlier steps with bitmasks on tables. I'll tell ya, if I had the money! I'd offer you a large sum. the stuff you guy's have mentioned is like a university course worth! you may say I shouldn't doubt myself but...too late! lol 

[KL27x]

I'll tell ya, if I had the money! I'd offer you a large sum.

Oh, the irony.

Some of the other PIC assembly coders on the forum laugh off my suggestions/practices and more or less think I'm a total idiot.   

[Electrofinn]

Lmao really! Well if they think they're that good they could sort this code out without suggesting I change the pic or some other drastic measure couldn't they lol after all a pair of novices managed it in the end on the same hardware.

I already know you could do it, it's just almost impossible to sort out over the Internet and without the hardware in front of you, Add to that it's just way too much work to ask of someone that I can't pay. Nah, you know your stuff, no argument here. 

[KL27x]

Oh, at least one of them has dropped by, already, to drop his 2 cents on the pile. But AFAIC, he completely missed the can. The other expert is still doing Edit>Find "  " to work out the code flow, after transferring it into a bare bones word editor program.

... but

without suggesting I change the pic

Ian.M is one of the most knowledgeable guys alive concerning PIC micros. He answered more than a few questions of mine when I first started learning PIC assembly over on the Microchip forums. Even though it took at least a day or two of reading to understand his 3 sentence answers. 

[Electrofinn]

I'll let them off lol, especially since all I can do is test things like a primitive being would i.e bang the thing against my head a couple times before grunting.

[jpanhalt]

16F57 isn't even a midrange PIC; it's baseline. Pages are only 2 address bytes long, lol. So it's not 2k per page, it's 0.5k.  Code is already spanning all 4 pages of program space. This device has no interrupts and a 2 deep stack!

And previously KL27x said:

Without even looking at the datasheet, I'm sure 12F509 has at least 2 timers which can generate an interrupt aside from the WDT and some GPIO digital input interrupt available on at least 2 of the pins. I've never seen a PIC without an interrupt. I can't imagine any microcontroller that does not have at least a timer interrupt.

Glad you finally looked at the datasheet. 

[Electrofinn]

Have tried my attempt and still no joy, still sometimes runs only part of the "pattern2" on a win. Sometimes it runs like one frame with one beep, or does something like half of it and half the amount of beeping.

Seems to be the only thing left that's wrong with this except... And to open up another can of worms lol..Occasionally when winning a jackpot, it stupidly gives you an option to gamble or collect, where it should be just going straight to payout mode when you get three bars! Now, this is not a new problem and is one forgot existed and looking over the conversation I had with creator way back when, it's a question I didn't get answer to because the conversation had digressed, which was my fault. But looking at the code in the  "gamble" section, if you match three reels in general play and it enters gamble mode and you manage to gamble your way upto "- - -", the machine knows to instantly pay out. I was wondering if this part of the code could be simply copied to the payout section or where ever it is in the code that it looks for matching reels such that if you spin the reels and it lands on "- - -" it just goes straight to payout rather going to gamble mode... Then again probably not since when is anything in this code or assembly in general ever that simple!

I meen the machine still gives the money if you press collect but it's silly the machine even offers a choice to gamble since pressing gamble would just scroll the reels down to the next prize down which is "A A A" = 50p

This "pattern2" issue is bummer though, at least it reads from the correct table, which is an improvement over the source code I guess. This code seems like it's in a right mucking fuddle! Lol

[Electrofinn]

It looks like a lock bit to prevent subroutines from resetting certain registers when others are using them. But to begin putting any of that together would take active measures, breaking the code and seeing what happens.

So it's your call if this is good enough or if you want to get your hands dirty.

Do you know what, I'm game if you are! but only if you are.

the 30 sec delay thing to return to the feature LEDs doesn't bother me, its this partial pattern2 on a win thing that i think really wrecks this. but if the both end up getting fixed as a result then whatever.