building own library with include-files?

hello all

i've read darrels lcd bargraph thread : http://www.picbasic.co.uk/forum/showthread.php?t=2359

and found it a very interesting method. is it right that i can build so my own routines each in an include file to take them in other projects also? like a library?
are there some disadvantages? and what are the restrictions :

- names of variables must be defined on both files with same name and type?
- where is an include "modedefs.bas" to made, on both or only in the include where it is needed at the end?

thanks for any feedback

Hi mischl,

At last, someone has seen the light. :)

The BARgraph program was written as an example of that very Idea.

In this thread Making PBP code more modular we've been talking about some of the Pro's and Con's of using Include files.  While others have expressed a different opinion, they did so before I had a chance to say my piece, and offer examples, So I'm not sure if they still feel the same way or not.

But to try to breifly answer your question.

Variables are only declared once. It can be in the main program, or in the include file, it depends on how they are going to be used.  It's best to define any variables required by the include file, In the include file. That way when you include it in a different program, everything is already there.

In effect, when the program gets compiled, it's just one big file. All of the Include files get combined into 1 big program. So, all the same rules apply. You can't duplicate variable names or labels. Constants and macro's must be declared before their use. And, most importantly, the execution of the program cannot accidently fall into a subroutine that isn't gosub'd to.

The last one just means that you have to jump over any code contained in the Include file with a GOTO and a label at the end of the include. Each include must jump over it's own code, but may also contain Initialization code that is not jumped over. This code will only be executed once on power-up. That's great for setting-up variables that need to be a certain way for the include to work.

---------

My mission now is to get everyone to use includes and macro's.
I'm done with the "Blinky lights" and "why doesn't my program work" stuff. :mad:
But, I would love to hear more questions on this topic. :)
<br>

I agree with macro. You give me this Macro disease ;) Really handy once you know how to play with.

But Includes.... still hard to me. But i understand and respect your point of view.

Then it looks like I'm only half done with you Steve. :)

Oh, and sorry about that disease. A little penicillin and you'll be fine.

So, let's see. More reasons to use Include files...

Hardware Definition:

How many proto-boards do you have on your bench? &nbsp;Or on a shelf somewhere? &nbsp;At the very least, just for trying out everyone elses programs you would need 2. &nbsp;&nbsp;1 for 14-bit programs, and 1 for 18F's. &nbsp;Maybe even a 12F proto in the mix. Personaly, I have 7.

Now, how many times have you Cut&Pasted the hardware definition section from some other program you wrote, just to have all the __configs, crystal, and pinout information so you could try out some little piece of code thats only 10 lines. And how long did it take to find the program that had the right definitions in the first place.

What I'm suggesting is to have a Hardware Definition file for each proto-board which defines everthing required to initialize that device, the LCD, USART, EEPROM's and give meaningfull names to the pins, SDA, SCL etc.

Now whenever you want to try the program on a different chip, simply INCLUDE the file for the proto-board you want to use, and spend your time on the program, instead of trying to get it to run on that hardware. &nbsp;Then if you change the hardware (it is a proto-board), you only need to change 1 file. &nbsp;And, you won't be copying the wrong header from an old file.

Here's 1 of my definition files, it's nothing special, just the basics for a LAB-X2. This way all I need to do is <p>INCLUDE "\PBP\hardware\LAB-X2.DEF"</p>and everthings ready to go, just add program.

Code:

---

'****************************************************************
'*  Name    : C:\LAB-X2.DEF                                    *
'*  Author  : Darrel Taylor                                    *
'*  Date    : 5/8/2003                                          *
'*  Version : 1.0                                              *
'*  Notes  : Target is 18F452                                  *
'*          :                                                  *
'****************************************************************
 @ __CONFIG _CONFIG1H, _OSCS_OFF_1H & _HS_OSC_1H        ' Set oscillator to High Speed (HS)
 @ __CONFIG _CONFIG2H, _WDT_OFF_2H                                        ' Turn off Watch Dog Timer (WDT)

Define OSC 10
CLEAR


 ' Define Hardware PWM channel 1
DEFINE  CCP1_REG                PORTC
DEFINE  CCP1_BIT                2

' Define Hardware PWM channel 2
DEFINE  CCP2_REG                PORTC
DEFINE  CCP2_BIT                1

AnalogPot    VAR  PORTA.0
AnalogPotAN  CON  0

ADCON1 = $8E      ' Right Justified, AN0 (RA0) Analog

INTCON2.7  = 0    ' Enable PORTB Pull-Ups

Button1  VAR PORTB.4
Button2  VAR PORTB.5
Button3  VAR PORTB.6

Servo    VAR PORTB.3

LED1    VAR PORTB.0
LED2    VAR PORTB.1
LED3    VAR PORTB.2

LOW LED1
LOW LED2
LOW LED3

---

That's just one more reason. I have more.
<br>

I still understand your point of view, make enough sense to me... the only thing... i never use pre-built proto-board or developpement board. I always build the according to fit to my project.

The only 'kind-of' include i'll use, and it's not an include, is the template file i use for each PIC i use. In each of these files, i found all config fuses, all register name and Bit alias definition. + my usual programming sequence/block definition (PIC config, Hardware connection, Serial comm definition, Alias definition..... ) well it's a template after all ;)

As i said, i prefer to see everything in my face. I feel safe that way. Maybe i'm too old for some changes now ;)

It could be interesting to have an IDE who could expand the INCLUDE in the project window. I mean also transfer Labels, Alias, Variable name in the current. That way, i'll probably think about include in a different way.

Sorry Darrel :(

hello darrel and steve

thanks for your explanations and opinions.

after the post of this thread i've found anther thread where you all discuss this art of programming.

there rests some questions for me :

- are includes and macros two different possibilites or just the same looked from two sites?
- it isn't also possible to programm a 12bit or 14bit pic from the mplab ide, like the 18bit family shared the code in several files.
- is free codespace and the circumstance that each call from the include is copied in the hexfile separately a disadvantage?

thanks a lot anyway... i'm not sure which way i should go for further projects ;-(

Quote:

---

are includes and macros two different possibilites or just the same looked from two sites?

---

That's two different things, two different possibilities. And you can mix them together

Quote:

---

it isn't also possible to programm a 12bit or 14bit pic from the mplab ide, like the 18bit family shared the code in several files

---

??? not sure of the question sorry

Quote:

---

is free codespace and the circumstance that each call from the include is copied in the hexfile separately a disadvantage?

---

Once you compile the code with 1 or more Include... it's nothing else than a single big file... Only 1 HEX file is generated. No problem with it.

Quote:

---

... i'm not sure which way i should go for further projects ;-(

---

There's no better way. Use the method you're confortable with. Try to always use the same method, same coding style and blah blah. That help when you return to a program done 1 month/year/decade/century ago.

There's no better way??

There's always a "Better Way". And, always using the same method / coding style, is a sure fire way to make sure you never find it.

Experiment! &nbsp; Try new approaches to problems that you've already solved before. Learn what advantages one method has over the other, so that you can avoid the disadvantages the next time.

Try using include files. If it doesn't work out for you, you can very easily just paste it back in your main code, no harm, no foul. &nbsp; If it does work out for you, you'll have found the basis for that Personal "Library" mentioned at the beginning of this thread.
<br>

C'est a peu pres ca que je voulais dire Darrel mais en Anglais! ;)

I should develop much more on every arguments next time... sorry

Quote:

---

And, always using the same method / coding style, is a sure fire way to make sure you never find it.

---

I wasn't unclear enough once again... I meant in the way you structure your program, not the way you code it. BTW how many different method can we use to blink a LED??? XOR the PIN, USE HIGH/LOW, TOGGLE, with PAUSE, Use internal Timer to produce delay and so on ;) wich is better?? the tight one, the readable one, the assembler one....... the one you're confortable with i guess. even if i'll more than often prefer the tight one. Probably the same thing for most who design stuff to be done in multiple copy.

Filling a PIC memory is easy. Everybody here can fill a 8K with a few different task/feature. Filling the same PIC with a maximum of task/option/feature by using all or a maximum of internal ressource and make things impossible to add extra feature is an art. Is this makes you a better programmer?? If the BOM is lower and the benefit are higher, your boss will probably agree.

Quote:

---

Try new approaches to problems that you've already solved before. Learn what advantages one method has over the other, so that you can avoid the disadvantages the next time

---

I agree. Some will say i'm a pure dumb and have no life but... one thing i do to relax myself, is to open an old code i did and try to shrink it as much as i can. OR trying different method as you said. Those i did on a rush request and those posted by user on different forum are my favourite. Yeah i can change the Coding style, the way to do one/multiple tasks but not the 'program template' or the order i place/declare things in a program.

Anyway, How to stucture, how to program and ALL 'How to' will be always an endless story.

Mmm... It's amazing to have as this few reply here...

Good to see this topic I thought I would add my 2cnts.

Start with the hardware layer use my (your) standard names: LABX1_20
Add chip layer ie DS1302, DS1620, one-wire: CLOCK1302
Add util layer ie save_word_to_eeprom, get_last_temp_change: UTIL

I also save these files in a include dir, so many projects can have access.
Include "..\include\LABx1_20.inc"

Since variables that need to be shared are shandard and internal variables are hidden like "__temp" then the actual project code is faster to code :)

I am trying to make object programming without the objects.

As you can see from my examples I break my own rules just to get the job done in time.

Regards
Tim

Excellent! Somebody else is on the "Same Page".

Are you interested in a few improvements?

While it's nice to have all the routines available by simply Including a file, with 100% PBP statements in them, even the routines that you don't use, still take up code space. It limits the amount of routines you can have available, because it uses up all the space you want for the actual program.

By using "Self-Optimizing" macro's, you could have hundreds of routines in place and ready to go. But, only the ones you use in your program will actually take up Code space.

It would mean a lot of editing, but I think you'd find it worthwhile. And, it's much closer to those "Objects" you're looking for.
<br>

Hello Darrell,

Darrell>My mission now is to get everyone to use includes and macro's.
I'm done with the "Blinky lights" and "why doesn't my program work" stuff. <<

In C/C++ we call this "OOP's" Object Oriented Programming. It is extremely nice, because once your "Include" is running (rountine or whatever you want to call it)... you can almost COUNT on that rountine to work nomatter what. You can forget about it. Call it up as a "Subroutine" to a degree, and know the response you received from your "routine" will be accurate and working.

One of the biggest disadvantages of Basic, (or PBP) is that the variables are "Global". Care must be taken to keep track of all variables within your program. C/C++ has what they call "Local" variables. These variables are ONLY recognized within their own subroutine or "object".

I, myself, prefer subroutine and/or (what you call Include files) to my preferred method of programming. I have not "played" with the Include statements yet, and my own Psuedo Libraries of code. But someday I will have time to sit down and start putting together my own...

Dwayne

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. :eek:

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>

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

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>

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

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.

mischl,

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

Quote:

---

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.

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

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.

For your inspection,

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

Darrel,

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

Dwayne

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.

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

Thanks Dwayne.

Quote:

---

Why don't you put a copy of this is in the FAQ section....

---

Well, from the number of "I can't get my PIC to blink an LED", and "How do I set the config Fuses" posts we still get here, apparently, nobody reads them.

But, as long as this thread remains active, almost everyone will see it.<hr>

Now then, to reiterate my post prior to the BOT bursting into flames.

For your Perusal,

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

Thanks Dwayne too! BTW it seems to be the usual comment or post of this user. Few here remind something called Heated Debate ;)

O.K i stop here...

Everybody go to the following link
http://www.picbasic.co.uk/forum/showthread.php?t=2444

Really awesome stuff from Darrel.