| Electronics > Beginners |
| Assembly code Help! PIC16F57 |
| << < (23/32) > >> |
| KL27x:
--- Quote ---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? --- End quote --- 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:
--- Quote from: Electrofinn on October 06, 2018, 09:16:00 pm ---Ok I understand, is programming in a higher level language any better than this? I am beginning to hate this assembly language lol --- End quote --- 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:
--- Quote ---Much! --- End quote --- Agreed. But the explanation is a little lacking to me. --- Quote ---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. --- End quote --- 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. --- Quote ---Because each task function uses local variables --- End quote --- 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. |
| Navigation |
| Message Index |
| Next page |
| Previous page |