building own library with include-files?

[mischl]

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

[Darrel Taylor]

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.
But, I would love to hear more questions on this topic.
<br>

[mister_e]

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.

[Darrel Taylor]

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.

'****************************************************************
'*  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>

[mister_e]

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

[mischl]

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 ;-(

[mister_e]

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

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

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.

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

[Darrel Taylor]

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>

[mister_e]

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

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.

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

[timc]

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