Relocatable code

[AGCB]

Since begining to learn PIC uCs in June of last year I have been using absolute code (MPLAB) 'assembly' and have done much and learned many things. In reading different forums, other than this one, I have been convinced to learn to write relocatable code for it's apparent ease of using previously written code blocks. It seems like a good idea. For instance, having used the Delay Code Generator I have run into the need to rename all of the variables, goto's and labels when using more than one delay in a program.

But in trying to figure out how to write it, I have so far found it to be more trouble than it's worth. I have searched for and read all the tutorials I could find and done the examples and read the users guides from Microchip but when I try to use it on my own, I get frustrated. Secondly, I have not found any indepth instrutions on the use or setup of a library (MPLIB).

SO!!!
My question is. Should I continue to pursue learning this mode of writing? I notice that the tutorials by Nigel are written in absolute code. I also searched this forum for "relocatable code" and did not find anything.

I trust the people on this forum and have learned much by your answers to my questions. The route of my future studies could depend on your answer.

Thanks Aaron

 

[be80be]

To use relocatable code is not that hard you just tell the compiler where to put it.

But it's a lot more work I would just use absolute code mainly because it easy.

And Mplab was designed for absolute, But it can generate relocatable code

The best guide i know of it in the Mpasm help file as quoted

MPASM assembler, used with MPLINK object linker, has the ability to generate and link precompiled object modules. Writing source code that will be assembled to an object module is slightly different from writing code used to generate an executable (hex) file directly. MPASM assembler routines designed for absolute address assembly will require minor modifications to compile correctly into relocatable object modules.

Header Files
Program Memory
Low, High and Upper Operators
RAM Allocation
Configuration Bits and ID Locations
Accessing Labels From Other Modules
Paging and Banking Issues
Generating the Object Module
Code Example

 

[AGCB]

Only one vote for absolute. Any others?

 

[Mr RB]

I would not bother with relocatable assembler. If doing small asm projects you can cut and paste asm source code from project to project.

And if/when you want to start doing large complex projects it will be well worth your time changing to C code and not using assembler.

I think that system you linked to is a poor way to generate delays. I would make a tiny function that makes a small standard delay (say 10mS) then if you need a 1 second or 2.3 second delay you can do something like this;

  movlw 230
delay_2point3
  call delay_10mS
  sublw 1
  btfss STATUS,C
  goto delay_2point3

Which gives you 230 loops of your standard 10mS delay function, so it is 2.3 seconds. With a few building blocks like this you can make all the different delays you need and with very little code, as the delays can call each other so it re-uses the delay code. I hope that makes sense.

 

[3v0]

I have to agree with Mr RB. They invented high level languages in part so the computer could take care of such things.

 

[AGCB]

OK. I'm convinced, I'll stick with absolute code. I like it anyway.

As a followup,
1. By using the cblock directive instead of equ and banksel instead of STATUS bit manipulation, I can make code that is easily portable from one device to another,YES? Anything else?

2. That delay code from MR RB looks good! How about a tiny code entered with WREG that allows for a longer delay, say up to 60 seconds or so?

3. I've started putting together a folder of routines for all the LCD use choices. I'm sure there is allready one written somewhere that is easy to use with assembly. If you have one would you please pass it along.

Thanks Aaron

 

[Mr RB]

If you need a 60 second delay, you can use some variation of the code I showed to make a 1 second delay.

Then "nest" it inside another loop that just calls it 60 times. Bingo, you have a 60 second delay.

Personally, in most code I do I like to use an interrupt to generate an exact 1 second "event", and/or sometimes a 10mS event. This updates a variable automatically in the interrupt. Then if it needs a 60 second delay I just reset the variable to 0 and wait until the variable >=60. Or if I need a 0.5 sec delay I reset the 10mS var to 0 and wait until it is >=50.

There a page of code systems for generating timed events here that might give you some ideas; Zero-error 1 second timing algorithm

And seriously, as 3v0 said if you are doing larger projects (and you said LCD) you might want to consider changing to C, and doing that change before you spend a lot of time building libraries of asm code examples. LCDs usually mean working with numbers, and converting large numbers between binary and text etc and C is so much better for these tasks than assembler.

 

[OlPhart]

Another for the chorus here. Been writing assembler >30 yrs, nearly all absolute. It seems I'm always running into link errors (relocatable) or functions behave Just Different than I need (C). A lack of experience in those areas, no doubt.

I agree with RB: data manipulation is easier in C. However, once you have your own set of assembler "chunks", you're in the same spot with the understanding of how each function gets there. Then again, I'm biased: given modern processors' speed, you're probably better off in C, a luxury unavailable when I started out. <<<)))

 

[be80be]

OlPhart It's all good from where I sit I love asm it's nice to talk to a chip in it's own language

But hill's are faster and way easier to use,But with a added headache of not really being easy to see how some chips are
being configured.

 

[AGCB]

Thanks for the replies and discusions. As always, I have gained much. I wrote (or copied)2 delay routines that do ms and seconds to 255. Aaron

 

[Brevor]

I have been using assembly language for 20 years with Intel 8048, 8051 and PICs. I always use absolute code. And believe me I have a large library of assembly routines. It saves lots of time.

 

[Mr RB]

I've worked in assembler for years. And I work in C on PICs, although I like to call it C-- as I write it very vertical and using simple constructs, then usually check the compilers asm output to see what it is doing with my C code.

People laugh at how bad my C is (or how bad it looks ) but the result is stuff that compiles small and runs very fast, and as an added bonus the "vertical style" C-- can easily be re-written to asm or other languages.

 

[AGCB]

... added bonus the "vertical style" C-- can easily be re-written to asm or other languages.

As i search for various codes on the web, I find many that do what I want to do but are written in C, so I have found them to be of no use to me. QUESTION Can C or some types of it be coverted somehow to asm?

For now I'm comfortable with asm but may find a need to learn C also.

 

[Nigel Goodwin]

As i search for various codes on the web, I find many that do what I want to do but are written in C, so I have found them to be of no use to me. QUESTION Can C or some types of it be coverted somehow to asm?

All C can be converted to assembler, it's what C compilers do - however, they generally produce absolutely horrible and hard to read assembler.

 

[AGCB]

Thanks Nigel. I'll just stick with assembler for now. Aaron

 

[OlPhart]

Complied C code vs its' handwritten asm equivalent is like a document pre & post lawyer :.) A Lot of a compilers' job it to save Everything in & out of calls, because it Can't know what's important. Library routine usage is another matter. It's centrally why it can't ever output code as efficient & fast as a well written asm version.

I've found it handy to "sidedoor" out of an interrupt (dump the bytes the INT put on the stack & jump to X) vs a normal return, based on a condition only seen in the INT. A compiler writer would Never allow it. In asm, I only have to preserve what I use in the call.

Unfortunately, I'm also known for terribly cryptic user interfaces. Asm makes writing a good one long & laborious. I try to write smooth running, well commented code and have had to work on too much of neither. Happy Coding... <<<)))

 

[Mr RB]

All C can be converted to assembler, it's what C compilers do - however, they generally produce absolutely horrible and hard to read assembler.

I don't know if I would go that far. With MikroC it generates an asm file, that shows each C line as a comment, then the assembler under it for that line.

So if you write very vertical C like this;

digit = 5;
digit = (digit * 10);
digit2 = (digit + 1);

The 3 C lines are converted into 3 simple comments and 3 nice neat little assembler chunks underneath each comment.

But if you code like a lot of C people like this;

digit2 = ((digit = 5)*=10)+1;

it will be converted into one cryptic comment and one large nasty chunk of assembler underneath it.

If someone is good with assembler they probably write good vertical code already, and you can continue doing that in C for PICs. The problem is people who learn "proper C" in a classroom and then expect the compiler to make perfect PIC code out of whatever C they happen to type in.

 

[misterT]

As i search for various codes on the web, I find many that do what I want to do but are written in C, so I have found them to be of no use to me.

Well written C is easy to read and understand. And one good thing about C is that there is a standard for the syntax. Of course you can find plenty of asm code examples for PIC, but they are practically useless if you are using some other microcontroller. But if you find an algorithm written in C, you can easily study how it works and probably use the code as it is.. or implement it in assembly after you understand how the algorithm works.

C is not very high level language. It only tries to hide things that make large (assembly) softwares difficult to manage. C is also far from perfect. It was designed by compiler writers who had little understanding about "what makes a high-level language great". They were only trying to make a "standard" programming language for easy code management and portability.