building own library with include-files?

[mischl]

interesting all you write about this theme.

for me as a beginner there are still some questions ...

what is exactly the definition of a macro and an include? what are the advantages as well the disadvantages from each?

what are the restrictions and syntax definitions to build up them? i. e. global /local variables, underscore, ...

so when i can find this descriptions by myself anywhere, please tell me where.
otherwise i'm happy for a short explanation. thanks a lot

[Stump]

includes work very well when passing info to the pic from an external program.
I use a program written in GW basic to ask the factory questions as to
how the PIC is to be set up (alarm levels) and which options to enable.
The answers to these questions are then output to a text file.
The text file containing the setup data is then compiled as an include file.
..........Keeps the factory out of the program and provides a more user friendly
enviroment for the factory to enter setup info.

[Darrel Taylor]

mischl,

Well, since you said "what is exactly the definition of a macro...",   this is the way the MPASM.hlp file defines it.

Macros are user defined sets of instructions and directives that will be evaluated in-line with the assembler source code whenever the macro is invoked.

Macros consist of sequences of assembler instructions and directives. They can be written to accept arguments, making them quite flexible. Their advantages are:

Higher levels of abstraction, improving readability and reliability.

• Consistent solutions to frequently performed functions.
• Simplified changes.
• Improved testability.

Applications might include creating complex tables, frequently used code, and complex operations.

But that doesn't really do justice to what you can do with them.

Macro's are simply a way of grouping bits of code together, so that with a single command, you can place many lines of code in your program at the point where the command is used. And, since they can accept "Parameters", they can work a lot like "Functions" in other languages.

They are strictly assembly language directives, but since PBP converts your Basic code into assembly language before it is compiled, they work quite well with PBP too.   In fact, the entire PicBasic language is built around macro's.

The biggest thing to remember is that each time you reference a macro, the Entire code contained in the macro is copied into the program. So if you use a macro 10 times in your program, you will use up ten times as much code space. That's not quite as bad as it sound though, because you can create normal subroutines in PBP that are "Called" by the macro (like a GOSUB), and then all the macro needs to do is pass the parameters to it like a "Function".

If you look at the LCDbar_INC.bas file from the BARgraph example, you can see how that works. The BARgraph macro is only there to pass the parameters to the "ShowBAR:" subroutine.<hr>INCLUDE files are similar in only one respect. They also place a group of code at the location that the INCLUDE statement is placed in your program. But, the similarities end there. INCLUDE files do not have to be Assembly language, they can be 100% PBP statements, or they can be a mix of PBP and ASM. They can NOT accept parameters. Macro's inside of Include files seems to be the most usefull combination though.

A good place to start might be with the MPASM.HLP file. Assuming you have MPASM installed on you computer.
On my computer the help file can be found here...C:\WINDOWS\Help\MPASM.HLP but some installations are different.

After that, start reading the "Instruction Set" section of the datasheet for the PIC you are using. They all have that section.

It's a little tough to grasp in the beginning, but once you catch on, all those things you thought couldn't be done with PicBasic, are suddenly within reach again.

HTH,
&nbsp;&nbsp;&nbsp;Darrel

PS. Stump, that's a nice use of includes, hadn't thought of that one.

[Dwayne]

Hello Darrel,

Darrel>>I'm sure I can come up with something for an example.

But first, I'm preparing another program for the Code Examples forum that is somewhat similar. Except that it assigns variables to EEPROM instead of RAM.

It uses some of the same concepts, yet is very different from doing it in RAM.<<

I like the idea of using a label to access RAM or EEPROM... I guess I could write a Subroutine quite easily to accomplish this task to the EEPROM...Since all it is, is a Read/Write and a integer value placement of the EEPROM position. I am not good enough in PBP to know all the ins and outs of the language.

Something simple such as:

Pseudo Code:

Placement var byte
Value var byte

for s= 1 to 100
Placement = Random 5
GoSub ReadRoutine
LCDOUT Value
next s

ReadRoutine:
Read Placement, value
return


Thus this will give a Pseudo kind of Variable Passing, and you can put the ReadRoutine in a Include statement of somekind. But this is kinda Hokey <g>

Dwayne

[mister_e]

Dwayne,

Look te thread Embedded string in your codespace. It use MPASM DA directive to define labels. For the EEPROM we will use DE instead with few modification to the previous Macro... well per the book. I should have a look to this too.. one day

It's interesting to set Labels to EEPROM when you use many Constants or Array OR if you just want to store Text String directly to the EEPROM and keep your codespace for what it's suppose to be, OR, ... OR, ... once again possibility are endless.

I suggest to everyone to read and study the MPASM book. Really usefull stuff. i have a feeling about the popularity of this reading but...

YES it use some assembler line, YES ASSEMBLER. But as i know, nobody died after using Assembler.

[Darrel Taylor]

For your inspection,

EEPROM Variables (EE_Vars.pbp)
http://www.picbasic.co.uk/forum/showthread.php?t=2444
<br>

[Dwayne]

Darrel,

Why don't you put a copy of this is in the FAQ section....
Good stuff on these Macro's...

Dwayne

[bot402]

To quote

"I do not like Delphi, because it is not as powerful as C/C++."

This has to be one of the most idiotic statements I've read on this forum for a long time.

Delphi is one of the most powerful languages that is available on the PC and in some cases far outways what can be done in C++ (it certainly produces smaller, faster code). Did you realise that a lot of Borland Builder C++ VCLs are written using the "inferior" Delphi language?

It's C and C++ that is the sloppy language compared to Pascal (Delphi). Pascal was first written as a training aid, to show how a correctly formatted and structured program should be written. And to teach some discipline while writing, as opposed to C and C++ which has been created by comittee over the years and now has so many flavours and versions that the portability aspect has virtually dissapeared, unless it is a small set of functions or procedures.

You've just insulted every Delphi user out there! even the professional programmers who use it to create programs that are simply staggering in their complexity.