building own library with include-files?

[Darrel Taylor]

Hiya Dwayne,

Many years ago, I chose Pascal. I now wish I had chosen C instead. Would have been making much better money by now. But, pascal or Delphi, is also an OOP environment. All that Inheritance and Polymorphism stuff was so confusing, for so long. Didn't think I'd ever get a handle on it. But eventually it did make sense.

Fortunately, OOP will never be a part of PBP. I can just image the posts on here if it was.

As for the PBP variables, yes, they are all global. But, it's not mandatory that they are all assigned their locations by PBP. It's possible to create "Placeholders" for PBP variables. That way PBP can go ahead and compile the program, even though it doesn't know where the variables will be, and then the actual locations can be determined at the assembly level, by your code. Any variables that aren't used in the program, don't need to be assigned a location since there's no code that will be trying to use them.

It's not quite "Local Variables", but it does help when making code that may, or may not be used in any given program. So, much like the "Self-Optimizing" macro's, the variables are optimized by the routine that might be using them.
<br>

[Dwayne]

Hello Darrel,

D>>Many years ago, I chose Pascal. I now wish I had chosen C instead. Would have been making much better money by now. But, pascal or Delphi, is also an OOP environment. All that Inheritance and Polymorphism stuff was so confusing, for so long. Didn't think I'd ever get a handle on it. But eventually it did make sense.<<

Yes, Delphi and Pascal both have OOP environment...Borland compilers (The Builder Series) allow Delphi coding to be integrated. I do not like Delphi, because it is not as powerful as C/C++. But delphi has LOTS of PROTECTION from programming errors. This makes it so that messy and weaker programmers can make a mistake, and have their errors caught. In C/C++, you can overwrite your own program if you are not careful. You can overstep your variable bounds, overwrite memory, or any number of different things. This CAN be a advantage if used properly...<g>.

Darrel>>As for the PBP variables, yes, they are all global. But, it's not mandatory that they are all assigned their locations by PBP. It's possible to create "Placeholders" for PBP variables.<<

My knowledge on PBP is not this great. I use it to get a job done...and let the compiler take care of it for me. Off the top of my head, I can only think of something like "Orging" to a position of the program on startup. And those variables would be the first few locations of the program.

could you give a example please Darrel? I think folks could benefit from this...Or should I say *I* (at least!) could benefit from this.


Dwayne

[Darrel Taylor]

Dwayne,

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 should have it posted in a day or two.
<br>

[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...", &nbsp; 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. &nbsp; 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.