building own library with include-files?

[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.

[Dwayne]

Hello Bot402,

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

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

This is not a forum for fighting matches ;-}

Bot>>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? <<

I have programmed for 25 years... I have programmed in Delphi, C/C++, Pascal, Assembly, ADA, Basic, RPG, and a few others. I know what Delphi does, and I know what C/C++ does.

Bot>>It's C and C++ that is the sloppy language compared to Pascal (Delphi).<<

It is what some people call a sloppy language. Yes, I agree, but it is only sloppy, because it is up to the programmer and the programmers knowledge to control what the program is doing. As I said before, you can overwrite Memory space quite easily in C/C++... This can be a advantage on security issues as well as a disadvantage to those who are not able to write good code.


Bot>> Pascal was first written as a training aid, to show how a correctly formatted and structured program should be written.<<

Nothing new to me. I even have a few older versions of Pascal. I believe it is called Turbo Pascal 3 (the version I have), and maybe Turbopascal 5 before I stopped purchasing it. I liked Turbo C/C++ from Borland better, to each their own.

Bot>>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.<<

No, I Have not insulted every Delphi user out there. I have only stated facts... Dephi is great for its field, it is a much easier and MUCH more forgivng language than C/C++ is. Unless a person knows how to keep control of their memory, stacks, variables, and initializations, C/C++ is not going to be easy for them.


This issue has been a long time running issue between the C/C++ and Delphi folks for years. <g>. The only thing I say ... To each their own. You like Delphi, (which I like also, and own 2 versions of it, and if I want to use it, I can click on the yellow 3 piller delphi32 icon and use it). I like C/C++ with or without the Builder, and own 5 versions of it. Thus it is my more preferred language to work with.

I do like the way they integerated Delphi into the Builder though!...Thus Borlands Builder will accept Delphi's object code too, and compile it. (quite nice IMO). There are *more* Delphi Programmers than Bolands Builders C/C++ too. I think in time, they will be meshing Delphi and C/C++ Builder into one huge IDE/Progamming platform.

Dwayne