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.=20
You wonder why there is no software blocks "ready to use" on Internet. I th=
ing it's not so easy to design reusable blocks. The problem is the interfac=
e 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 ne=
ver 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 s=
tandart for instance. Then the other developers will use this standart to c=
ode 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 whi=
ch define how is working an OS (and other layers) on a small uC like the PI=
C18.=20
PICos18 (www.picos18.com), a free real time kernel for PIC18 uC, has be des=
igned 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 app=
lication.
You cannot do that without a preemptive kernel (I don't talk about a cooper=
ative 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 automoti=
ve industry.. moreover the Integrated Development Environment (MPLAB) is fr=
ee and C18 is available for free as a trial version.
In conclusion you can work as a professionnal at home with free tools avail=
able on Internet, and if you want to development safier and faster you can =
buy additionnal products from the Pragmatec company (www.pragmatec.net).
Of course it's just my opinion...
Xavier MONTAGNE





> Message du 17/03/04 04:54
> De : Ken Pergola=20
> A : PICLIST@MITVMA.MIT.EDU
> Copie =E0 :=20
> Objet : [PIC:] Creating PICmicro libraries with MPLIB
> Hello all,
>=20
> 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 (ev=
en
> 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.
>=20
> 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).
>=20
> 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).
>=20
> 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 th=
e
> interface or implementation of any library member functions in the origin=
al
> library.
>=20
>=20
> My plan to avoid this nasty situation is to do the following (I'll use a =
few
> I2C routines as an example):
>=20
> A) Always append a version suffix to the ASM name of all code that will b=
e
> converted to object file library member functions:
>=20
> i.e. I2C_StartCondition_v10.asm
> I2C_RepeatedStartCondition_v10.asm
> etc
>=20
> (the 'v10' suffix in the name would be interpreted as version 1.0)
>=20
>=20
> The assembler will create the object files since I will be using the
> linker:
> I2C_StartCondition_v10.o
> I2C_RepeatedStartCondition_v10.o
> etc
>=20
>=20
> Then I would build a library (I2C.lib) using MPLIB by adding the I2C
> member function object files.
>=20
>=20
>=20
> 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 wou=
ld
> 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 na=
me
> suffix (version):
>=20
> i.e. I2C_StartCondition_v11.asm
> I2C_RepeatedStartCondition_v11.asm
> etc
>=20
> (the 'v11' suffix in the name would be interpreted as version 1.1)
>=20
>=20
> Re-assemble, re-link, add new member functions to I2C.lib.
>=20
>=20
> 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 t=
he
> library would most likely use the latest version of a particular member
> function.
>=20
>=20
> I would greatly appreciate it if anyone could take a stab at the followin=
g
> questions I have:
>=20
> 1) Does this sound like a reasonable approach?
>=20
> 2) If not, does anyone use a different method to avoid breaking client co=
de
> when modifying a library member function (interface or implementation) is
> necessary in the future?
>=20
> 3) What should be the maximum length of my library member function names?
>=20
> 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...
>=20
>=20
> Thanks for everyone's time, help/advice, and consideration -- I appreciat=
e
> it!
>=20
>=20
> Best regards,
>=20
> Ken Pergola
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> 32 size?
>=20
> --
> http://www.piclist.com hint: To leave the PICList
> mailto:piclist-unsubscribe-request@mitvma.mit.edu
>

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