Subroutine problem with PIC18F452

(instructions, reset, WDT, specifications...) PIC17Cxx, PIC18Fxxx

Re: Subroutine problem with PIC18F452

Postby Tom Maier » Mon Jun 30, 2014 7:28 pm

Dimebag wrote: I did look at program flow being a major problem at the moment as well.


You need to work those types of things out before starting the coding. The algorithm used should be described in plain lanuage and look workable before attempting to write code, then the plain language description becomes the template for writing the code.

Have you written any high level language before? The XC8 compiler is free and pretty good. Any high level language is easier then assembly.

What you are trying to do is a simple switch statement. Look up "switch statement in C" on google and you will find many examples.
User avatar
Tom Maier
Verified identity
 
Posts: 179
Joined: Mon May 26, 2014 2:37 pm
PIC experience: Professional 5+ years with MCHP products

Re: Subroutine problem with PIC18F452

Postby Dimebag » Tue Jul 01, 2014 12:42 pm

I have decided to try and finish this program or, at least fix some of the problems. I will be re-working the program flow and place more comments in the code. After reading all the comments I have decided that not dealing with code issues now is just avoiding the problem to start with. If I don't fix it now I will be stuck at the same stage of any other code problems I encounter.
Dimebag
 
Posts: 109
Joined: Sun Jun 29, 2014 7:51 am
Location: Sydney, Australia

Re: Subroutine problem with PIC18F452

Postby Tom Maier » Tue Jul 01, 2014 1:36 pm

A common beginner's mistake is to write code and THEN try to comment it. That's backwards. You should start out with high level comments, and then try to code what you described.

A bird's-eye view description of the whole program then becomes the main program header. It describes the overall algorithm and flow. The next level detail descriptions then become the headers for subroutine calls. The line comments are the lowest level of nitty-gritty detail and can be filled in as the code is written.

Writing good assembly language is to mimic what is normally done in high level programming. Think about the high level structure first. There is the temptation to start coding right away and hope that by doing enough writing you will find your way through the rabbit warrens, but that just causes you to get lost and in frustration you end up with stringy spagetti code that goes in loops, like a rabbit warren.

I worked with an engineer many years ago who pounded on some code for 8 months and it was getting worse as he continued. Our boss told me to straighten him out. The code was enormous and repetive, with a lot of "gotos" that tied the monster code into knots. There was no structure or high level plan. The engineer was literally in tears. I had to struggle with him for a week to convince him to start over and create a high level plan, but when he did, everything fell into pace quickly.

He had only taken a assembly language class in college and the instructor seems to have skipped any mention of modularity and structuring of code. Once he got the right idea he was running full speed with it, but he had never seen that before. I won't mention the college he graduated from. ;)
User avatar
Tom Maier
Verified identity
 
Posts: 179
Joined: Mon May 26, 2014 2:37 pm
PIC experience: Professional 5+ years with MCHP products

Re: Subroutine problem with PIC18F452

Postby Ian.M » Tue Jul 01, 2014 2:18 pm

O.T.O.H. Before even considering a large pure assembler program, it is always worth looking at the possibility of throwing faster, more capable hardware at the problem if performance is critical and using a high level language. Unless you are manufacturing in volume, never need to upgrade already sold products and need to squeeze every last cent, or need bleeding edge performance, coding non-trivial tasks in assembler is rarely cost effective

High level languages exist to protect you from the brain-bending details of the instruction set and core architecture. If you are going to succeed with the level of detail required for success in assembler, the intermediate planning step before you get down to line by line coding and commenting looks much like a program in a high level language.

As you've got to do it anyway, you might as well write that planning step as a usable program with only a little more effort, then you only have to continue on into assembler for the parts of it that need a performance boost.

If you don't know C, I *strongly* recommend you start learning it. Its is the most popular language for embedded systems on the planet (as you cant really count different manufacturers totally incompatible assembly languages as being the same).
Ian.M
Verified identity
 
Posts: 95
Joined: Wed May 28, 2014 12:47 am
PIC experience: Professional 1+ years with MCHP products

Re: Subroutine problem with PIC18F452

Postby Tom Maier » Tue Jul 01, 2014 2:55 pm

Ian.M wrote:
... the intermediate planning step before you get down to line by line coding and commenting looks much like a program in a high level language.


+5

That's why asm is so difficult. If you are using proper programming technique you are first writing the pseudo code that is high level, and then having to render it down to the funky asm language. The pseudo code becomes the function header. Rendering to asm is an extra step, and one command of high level can mean writing 6 lines of assembly.

Well written, modular assembly can be "portable" to other architectures and languages because the high level code is in the headers, and details are in the line comments.

But otherwise, when a job requires menu structures then right away I start looking for a compiler. Since they are being given away for free, there is no justification for mucking around in asm now-a-days, unless it is a critical code section.

And I just noticed that ME Labs is giving away their student edition of PICBASIC Pro compiler (it used to be $50). I don't suggest basic for professional development because it is so divergent and unique from implimentation to implimentation, but there is a race for the bottom in price among compiler companies and high level compilers are approaching the pocket change to free zone. We often used to use asm because comilers were expensive and really sucked with bugs in the old days, but those days are over.

The only reason I can see to pursue this project in pure asm would be for the learning experience, but I see frustration ahead because I think the OP is not properly prepared with understanding structured programming.
User avatar
Tom Maier
Verified identity
 
Posts: 179
Joined: Mon May 26, 2014 2:37 pm
PIC experience: Professional 5+ years with MCHP products

Re: Subroutine problem with PIC18F452

Postby Dimebag » Tue Jul 01, 2014 3:09 pm

C language tools might be easier to read. I however never had the chance to learn programming at school or, higher level university degrees. Please excuse my total lack of meaningful examples to identify any problems I am experiencing.
Dimebag
 
Posts: 109
Joined: Sun Jun 29, 2014 7:51 am
Location: Sydney, Australia

Re: Subroutine problem with PIC18F452

Postby Tom Maier » Tue Jul 01, 2014 3:31 pm

Ahhh... now we are getting somewhere.

You don't need to excuse yourself for anything. You are welcome here no matter what your background. Most of us here are professional developers and I also taught college, but "We all began... as something else.". (I stole that line from the movie "Chronicles of Riddick". Great movie.) But listen to the people giving advice, because they have a lot of experience. You might not like what is suggested, but realize the advice comes from decades of experience.

You would do yourself a favor by starting out with learning a high level language, learning modularity and structured programming, and THEN trying to hack it out in assembly. You can learn the high level language by doodling around with a command prompt window programming. What you are doing is trying to dive into the deep end of the pool, but you haven't learned to swim yet. Don't use compilers that generate the desktop GUI, just stick with talking through the command prompt (or "terminal window"). That is most like embedded programming. There is mingnu C and others.

Look at other people's C code and see how they have structured it. If they don't have comments and modualrity and proper headers, then move on to other examples. Search google for "C tutorial", "modular programming in C", "structured programming in C" and look for CLI programming. That means "command line interface", which is the use of the comand prompt I was mentioning.

If you don't learn those things, you will head down the terrible path that I described of the engineer in tears.
User avatar
Tom Maier
Verified identity
 
Posts: 179
Joined: Mon May 26, 2014 2:37 pm
PIC experience: Professional 5+ years with MCHP products

Re: Subroutine problem with PIC18F452

Postby Ian.M » Tue Jul 01, 2014 7:14 pm

Back in the day, I was a reasonably competent self-taught BASIC and assembler programmer. I then taught myself C from K&R ("The C Programming Language" by Brian W Kernighan & Dennis M Ritchie) on a 8 bit system that loaded the compiler from cassette tape. Later on, this considerably reduced my stress levels when introduced to C in an academic environment as I did most of the assignments on my home 68000 system rather than struggling with the uni's glitchy cross-compiler on their timesharing mainframe. The skills I learnt back then are still applicable when programming PICs today, and having started out on a slow resource limited system is no disadvantage when getting into the mindset required for success on the 8 bit PICs.

If you want to get into embedded C or even 'plain vanilla' hosted C, I strongly recommend a copy of K&R second edition. That's the one that covers ANSI C89 (ISO C90) which most cross-compilers for embedded systems support. C99 and later standards just add a few extras that are easy enough to adapt to if you can code clean C89 C. If you know 'vanilla' ANSI C89 C, then adapting to any non-object oriented C-like language is fairly trivial and you can be programming productively within a week.

Its not quite as good as K&R but I like: http://publications.gbdirect.co.uk/c_book/
Its free, online and does a good job of covering C89. My only real gripe is you cant mark it up with postit notes!
Ian.M
Verified identity
 
Posts: 95
Joined: Wed May 28, 2014 12:47 am
PIC experience: Professional 1+ years with MCHP products

Re: Subroutine problem with PIC18F452

Postby user2009 » Wed Jul 02, 2014 9:00 am

Pretty much offtopic but I want to thank Tom, Ian and all other for sharing your experiences and insights which are really interesting and good advices :)
user2009
 
Posts: 13
Joined: Tue Jul 01, 2014 11:48 am
PIC experience: Professional 2-5 years with MCHP products

Re: Subroutine problem with PIC18F452

Postby Dimebag » Wed Jul 02, 2014 1:36 pm

Thanks Tom,
I found some code examples in high level language. Very interesting subject that requires more reading. I got a Arduino package from Freetronics. The reason I got the board is to learn more about C type programming. I am trying to investigate these included things called ***.h. I haven't been able to open one let. I look forward to chatting with you all soon.
Dimebag
 
Posts: 109
Joined: Sun Jun 29, 2014 7:51 am
Location: Sydney, Australia

PreviousNext

Return to 16-Bit Core

Who is online

Users browsing this forum: No registered users and 8 guests

cron