Searching \ for '[PIC:] Creating PICmicro libraries with MPLIB' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'Creating PICmicro libraries with MPLIB'.

Exact match. Not showing close matches.
PICList Thread
'[PIC:] Creating PICmicro libraries with MPLIB'
2004\03\16@225425 by Ken Pergola

flavicon
face
Hello all,

I rarely see dialogue exchanged on this PICLIST with regard to creating
libraries with MPLIB and I was hoping that someone would be able to offer me
some guidance and/or advice if you have the time. I'm hoping this could
generate some discussion since the benefits of libraries are enormous (even
for individual developers). I have been re-using code the 'copy and paste'
method for too long and it's time I start using MPLIB for organizing code
and real re-usability.

To keep things simple for starters, I've decided that I want to create an
ASM library specifically targeted for the PIC18F452 right now. I've been
using MPLINK, but I've never used MPLIB and created libraries before and
there's some questions that I have that I have not seen covered in the
'bible': MPASM USER'S GUIDE with MPLINK and MPLIB (DS33014G).

First off, at a higher level, I'm wondering what are some good techniques
for eliminating the situation in which future modifications of library
member functions can 'break' the original interface (similar to avoiding DLL
hell of the Microsoft world).

For example if I have already released a library and have client code
already using it, I do not want to break the client code when I change the
interface or implementation of any library member functions in the original
library.


My plan to avoid this nasty situation is to do the following (I'll use a few
I2C routines as an example):

A) Always append a version suffix to the ASM name of all code that will be
converted to object file library member functions:

  i.e.  I2C_StartCondition_v10.asm
        I2C_RepeatedStartCondition_v10.asm
          etc

  (the 'v10' suffix in the name would be interpreted as version 1.0)


  The assembler will create the object files since I will be using the
linker:
        I2C_StartCondition_v10.o
        I2C_RepeatedStartCondition_v10.o
          etc


  Then I would build a library (I2C.lib) using MPLIB by adding the I2C
member function object files.



B) Then in the future, if I even needed to change the interface or the
implementation of the library member function (for whatever reason) I would
have a rule that you would NEVER modify any existing member functions in the
library -- you must create a new one and increment the member function name
suffix (version):

  i.e.  I2C_StartCondition_v11.asm
        I2C_RepeatedStartCondition_v11.asm
          etc

 (the 'v11' suffix in the name would be interpreted as version 1.1)


       Re-assemble, re-link, add new member functions to I2C.lib.


If these rules are followed, existing client code that uses the library
would not be broken. And, when using the library it would be very easy to
see which member functions are the newest due to the versioning method
employed in the member function name itself. Any new code written using the
library would most likely use the latest version of a particular member
function.


I would greatly appreciate it if anyone could take a stab at the following
questions I have:

1) Does this sound like a reasonable approach?

2) If not, does anyone use a different method to avoid breaking client code
when modifying a library member function (interface or implementation) is
necessary in the future?

3) What should be the maximum length of my library member function names?

  I can't seem to find out from reading MPASM USER'S GUIDE with MPLINK and
MPLIB (DS33014G) what this should be.
  It mentions that labels should be 32 characters or less -- maybe this is
the answer. I guess I'll go and experiment...


Thanks for everyone's time, help/advice, and consideration -- I appreciate
it!


Best regards,

Ken Pergola
























32 size?

--
http://www.piclist.com hint: To leave the PICList
spam_OUTpiclist-unsubscribe-requestTakeThisOuTspammitvma.mit.edu

2004\03\17@040703 by Alan B. Pearce

face picon face
Have a look at Olin's development environment. As each file is assembled the
.o file is added to a library for the linker to use. I haven't checked the
MPLINK documentation to see if this is necessary, I just use it :))

Your scheme looks sensible to me, except you may also want to add a
processor ident to the library name.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\03\17@042405 by Jan-Erik Soderholm

face picon face
Alan B. Pearce wrote :

> Have a look at Olin's development environment. As each file
> is assembled the .o file is added to a library for the linker to use.

Maybe if used out-of-the-box. I made a few minor changes
to the build scripts (BAT-files), so I link the EXE directly from
the .o files. I added a "make" tool instead, so just the needed
modules are re-assembled each time.

> I  haven't checked the
> MPLINK documentation to see if this is necessary,...

Well, it isn't  :-)

And MPLINK can mix .o and .lib files in the same run,
if you want. This is normal, IMHO, since you often have a
"main" module that is linked from the .o file, and (if you
use that) some LIB files.

And as a final note, using LIB's is just an administrative
thing, it's no difference to the linker AFAIK, between linking
from the plain .o files and building from a LIB.

Jan-Erik.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\03\17@042406 by Xavier MONTAGNE

flavicon
face
Hi Ken,
Your question is very interesting in fact, and I would like to give you my opinion. First of all sorry for my "bad" english... but I'll try to make me understood pretty well !
I'm using libraries in my PIC18 projects so I use sometimes MPLIB. You wonder why there is no software blocks "ready to use" on Internet. I thing it's not so easy to design reusable blocks. The problem is the interface as you told in your last mail.
If the interface changes so the previous client won't be very happy to know you've changed the interface. If you decide to freeze the interface and never modify it, how could you be sure the interface is the right one ?
The problem must be solved by specifying a dedicated interface based on a standart for instance. Then the other developers will use this standart to code their application, even if the different blocks available change (with the respect of the standart interface).
In the automotive world for instance you can find the OSEK-VDX standart which define how is working an OS (and other layers) on a small uC like the PIC18. PICos18 (http://www.picos18.com), a free real time kernel for PIC18 uC, has be designed in order to be compliant with a unique interface (the OSEK standart) and because the kernel is multi-tasks you can add "software blocks" (tasks) or remove them to/from your project without disturbing the rest of the application.
You cannot do that without a preemptive kernel (I don't talk about a cooperative kernel like Salvo).
The Pragmatec company in charge of the PICos18 kernel improvements proposes a set of software solutions (commercial products) to help people to design their own blocks, to reuse them, to promote them...
PICos18 is distributed under GPL licence and is totaly free. Then you have the same development platform than professionnal people working in automotive industry.. moreover the Integrated Development Environment (MPLAB) is free and C18 is available for free as a trial version.
In conclusion you can work as a professionnal at home with free tools available on Internet, and if you want to development safier and faster you can buy additionnal products from the Pragmatec company (http://www.pragmatec.net).
Of course it's just my opinion...
Xavier MONTAGNE





{Quote hidden}

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\03\17@091242 by Dave Tweed

face
flavicon
face
Alan B. Pearce <.....A.B.PearceKILLspamspam.....RL.AC.UK> wrote:
> Have a look at Olin's development environment. As each file is assembled
> the .o file is added to a library for the linker to use. I haven't
> checked the MPLINK documentation to see if this is necessary, I just use
> it :))

I have never figured out why Olin does this. The linker is perfectly happy
to process the .o files directly.

-- Dave Tweed

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\03\17@114449 by Ken Pergola

flavicon
face
Alan B. Pearce wrote:

> Have a look at Olin's development environment. As each file is
> assembled the .o file is added to a library for the linker to use. I
haven't checked the
> MPLINK documentation to see if this is necessary, I just use it :))
>
> Your scheme looks sensible to me, except you may also want to add a
> processor ident to the library name.


Hi Alan,

Thanks for your response Alan.

I guess the main reason I have not used and invested my time in Olin's
environment is because it is not in my total control. In other words, I'm a
little hesitant investing a lot of time and energy in it when I don't know
for certain if he will continue to offer and maintain it. Maybe that's a
lame excuse on my part or my ignorance of his environment. But sometimes the
only way for me to learn is to trip over your own feet and that's why I
wanted to invest some time in my own library. Creating a library is easy.
It's the library planning and foresight needed that comes with experience
that I don't have right now. That's what prompted my original question.

I'm only focusing on a library for the PIC18F452 right now and I realize
that not everything can be thrown in a library, but with careful thought, a
sensible library can be created in my opinion.

But my main post was more of a planning strategy in terms of configuration
management with regard to a library. Configuration management issues will
surface regardless of whether you are using a "source code library" or a
"binary library" (DLL analogy).

I'm most interested on hearing people's strategies on tacking these
configuration management issues I raised in my original post (having the
freedom to make future interface/implementation changes but at the same time
ensuring backward-compatibility with existing client code).

Thanks again Alan for your time.

Best regards,

Ken Pergola

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\03\17@114450 by Ken Pergola

flavicon
face
Xavier MONTAGNE wrote:

> First of all sorry for my "bad" english...
> but I'll try to make me understood pretty well !

I find your English to be awesome. I'm always in awe of people who speak in
'several tongues'. And who write in different languages too of course.
(I can only speak in my native tongue.)

> You wonder why there is no software blocks "ready to use" on
> Internet.

Actually Xavier, I'm not wondering that. I was just wondering why there does
not seem to be much discussion on the PICLIST with regard to MPLIB. I
realize that libraries can be very open-ended and general, or rather
specific, and combinations thereof.

As I mentioned to Alan, I guess I'm more interested right now in how people
tackle configuration management issues in their 'source' or 'binary'
libraries. And I don't mean using version control software.

I'll check out OSEK-VDX -- thanks for mentioning that Xavier.


Thanks again for your time and response Xavier .

Best regards,

Ken Pergola

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\03\17@115525 by Wouter van Ooijen

face picon face
> method for too long and it's time I start using MPLIB for
> organizing code and real re-usability.

Long long time ago I started writing re-useable stuff in MPASM, but I
could not find a way past its limitations, for instance I found no way
to share RAM space among different routines. So I wrote a compiler
instead :)

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\03\17@120359 by Ken Pergola

flavicon
face
Wouter van Ooijen wrote:

> Long long time ago I started writing re-useable stuff in MPASM, but I
> could not find a way past its limitations, for instance I found no way
> to share RAM space among different routines. So I wrote a compiler
> instead :)


Hi Wouter,

That might be one of several reasons why Olin developed his own environment
as well. I posted my original question on the Microchip forums, and Olin
answered why he does not think creating a binary library is a particularly
good idea.

But in my case, a binary library appears to make sense (at least right now)
and I think I will give it a shot. If I fall on my face in the mud with
arrows in my back that's ok. :)

Thanks for your comment Wouter.

Best regards,

Ken Pergola

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\03\17@124731 by Alan B. Pearce

face picon face
>But in my case, a binary library appears to make sense (at least right now)
>and I think I will give it a shot. If I fall on my face in the mud with
>arrows in my back that's ok. :)

I suspect that one of the reasons it has not happened is that everything
needs to be highly configurable, but use minimal resources. For instance,
lets say you have a module to handle a UART.

How do you configure the baud rate?

Do you have a callable subroutine that is passed a parameter? If so then
this is going to consume a number of words of ROM to handle parameter
checking that would otherwise be done by macros at assembly time. This is
for code that will be run once, but could be (relatively) sizable for what
it does. If you don't do it this way, then you have to write external code
that loads the baud rate generator, which is exactly what one is trying to
get away from.

I think that Olin's environment gives the best of both worlds, where a
source module can be effectively a library item, but is assembled for each
project. This allows details to be modified to suit the project, and
unwanted/unused pieces of code to be cut out if need be. It also allows the
code to be tweaked to get the required performance for the project, e.g. A/D
channel handling. One would not want that in code that needs only one A/D
channel, but be writing external code to handle multi-channel A/D switching
when the library module is single channel.

The overheads involved with otherwise unused code in a very limited ROM
resource environment makes the library handling a bit of a pain I think you
will find. Each module will be so exactly targeted that when you want one
there will never be a "drop in" module, and you will start from the
beginning modifying the source of an existing one.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\03\17@125353 by Jan-Erik Soderholm

face picon face
Ken Pergola wrote :

> I posted my original question on the Microchip
> forums, and Olin answered why he does not think
> creating a binary library is a particularly good idea.

Yes, a big deal of the "features" in Olin's code, is managed
by the assembler. All that is lost with object libraries.

If one could have a kind of "ASM-LIB", where you had both
the benefit of "packaged" code in a single file, and at the
same time also had access to such things as conditionaly
incl/excl ASM code, or modifing code (literals) based on assembler
symbols setup from your main code, that would make "libraries"
more usefull.

Much like Olins env but where the different modules (such as
the UART_xxx.aspic module) could be truly shared and not
(as now) copied into each project (and often modified/tweaked).

Say you would like a library routine to handle an IR-diod. Then
the actual pin used for the diod will be fixed in the LIB routine.
Or is there any easy way to dynamicaly select a specific pin
and/or port (in ready built code, not in MPASM) ?

Anyway, with great dicipline and planning of your subroutine
interfaces, object libs could still be usuable...

>
> But in my case, a binary library appears to make sense (at
> least right now) and I think I will give it a shot. If I fall on
> my face in the mud witharrows in my back that's ok. :)

Absolutly, as long as you let *us* learn from it :-) :-)

Jan-Erik.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\03\17@163407 by Ken Pergola

flavicon
face
Alan B. Pearce wrote:

> I suspect that one of the reasons it has not happened is that everything
> needs to be highly configurable, but use minimal resources. For instance,
> lets say you have a module to handle a UART.
>
> How do you configure the baud rate?
>
> Do you have a callable subroutine that is passed a parameter? If so then
> this is going to consume a number of words of ROM to handle parameter
> checking that would otherwise be done by macros at assembly time. This is
> for code that will be run once, but could be (relatively) sizable for what
> it does. If you don't do it this way, then you have to write external code
> that loads the baud rate generator, which is exactly what one is trying to
> get away from.

Hi Alan,

Thanks for your sharing your thoughts in this thread. Your points are
well-taken and I'm definitely aware of some of the trade-offs involved. I
was thinking along the lines (as you have already suggested) in that you
would use property 'Gets' and 'Sets' that go along with the library member
functions that need set/get attributes or properties. Even if you don't use
libraries, some people use routines in which they might pass the desired I2C
frequency in the W register to a function that configures, for example, the
I2C frequency (master mode) to allow configurability. If you're strapped for
space, this could be the straw that breaks the camel's back, but it is
definitely a nice way to program in my opinion if you have the resources
available (which I do in this case).

But even if one is a strong proponent of 'source' libraries versus 'binary'
libraries, there are still the issues of configuration management specific
to the original source code library that I alluded to in earlier posts. If
someone names their routines in their source library 'UART_Initialize' or
'UART_Get' or 'UART_Put' I'm just curious how they handle the situation in
which they need to make a revision on these routines (for whatever reason),
especially in the case where existing code is already using these routines.
In could be something as simple as an errata patch or something like that.
So the concern is that, in my opinion, you never want to destroy any
original code in the library. You would have to create a brand new routine
to host the fix/patch/revision and re-name it with a new name. Maybe the
change is so trivial that existing client code does not need to be updated,
or maybe it does. Changing a sub/function and naming it the same thing could
be disastrous. That's why I will go with the versioning strategy for the
sub/function names I mentioned before. Perhaps I should look at Embed Inc's
methods to see how this is handled in this regard.

> The overheads involved with otherwise unused code in a very limited ROM
> resource environment makes the library handling a bit of a pain I
> think you will find. Each module will be so exactly targeted that when you
want one
> there will never be a "drop in" module, and you will start from the
> beginning modifying the source of an existing one.

To some extent the above is true in some cases, but even in your example of
a UART library module or my I2C example, I don't feel that these routines
would be so targeted or closely coupled to a specific project to render them
not re-useable, but maybe I'm misinterpreting what you are saying. I do
agree that some routines would probably be best served by not placing them
in a library because they would be so specific to a particular application
that it would not be worth the trouble. It would come down to a judgment
call.


Thanks for the dialog Alan -- I appreciate your thoughts.

Best regards,

Ken Pergola

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\03\17@164443 by Ken Pergola

flavicon
face
Jan-Erik Soderholm wrote:


> Yes, a big deal of the "features" in Olin's code, is managed
> by the assembler. All that is lost with object libraries.

Hi Jan-Erik,

Thanks for your comments as well.

Yes, definitely Jan-Erik. This is one of the reasons Olin told me as well.
One thing I'm attracted to with a binary library is the same reason I like
DLLs in the PC programming world.

I guess it might be best to start with a source code library first and
manage things from that perspective for a while.


> Anyway, with great discipline and planning of your subroutine
> interfaces, object libs could still be usuable...

It's nice that MPASM will simultaneously accommodate source files, object
files, and libraries. That's a good thing!

> Absolutely, as long as you let *us* learn from it :-) :-)

Well, this is all for the benefit of trying to work smarter instead of
harder.


Thanks for your time,

Ken Pergola

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\03\17@171728 by Jan-Erik Soderholm

face picon face
Ken Pergola wrote :

> It's nice that MPASM will simultaneously accommodate source
> files, object files, and libraries. That's a good thing!

Just a minor tidbit... :-) :-)

I don't think MPASM even knows what a LIB is.

MPLIB and MPLINK does...

:-)

Regards,
Jan-Erik.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\03\17@181905 by Ken Pergola

flavicon
face
Jan-Erik Soderholm wrote:


> Just a minor tidbit... :-) :-)
>
> I don't think MPASM even knows what a LIB is.
>
> MPLIB and MPLINK does...
>
> :-)

Hi Jan-Erik,

Yes, Freudian slip on my part -- thanks for pointing that out.

This is what I meant to say in my original post:

It's nice that *MPLAB IDE* will simultaneously accommodate source files,
object
files, and libraries. That's a good thing!

Best regards,

Ken Pergola

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\03\18@090730 by al smith

picon face
Isn't Olin a few feet from you? Ask HIM!!


{Quote hidden}

_________________________________________________________________
Get tax tips, tools and access to IRS forms   all in one place at MSN Money!
http://moneycentral.msn.com/tax/home.asp

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\03\18@091145 by Spehro Pefhany

picon face
At 06:05 AM 3/18/2004 -0800, you wrote:
>Isn't Olin a few feet from you? Ask HIM!!

He's probably a bit snippy first thing in the morning. ;-)

Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
RemoveMEspeffTakeThisOuTspaminterlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

More... (looser matching)
- Last day of these posts
- In 2004 , 2005 only
- Today
- New search...