In SX Microcontrollers, SX/B Compiler and SX-Key Tool, peterverkaik wrote: Samuel, A response to your suggestions: Subroutines should be created and Macros should be defined as wrap-arounds. That is a subroutine should be developed and that way only the calls to it only would be repeated in the code. The Macro wrap around is the way into the routines. The macro is passed all the required parameters. The macro then does any setup required (flags,variables, etc.) and then the macro calls the subroutine. >Response: the main macros in my lib are selfcontained subroutines Of course if the user does not require the subroutines he should not include them in his code. The limitation on include files is if they are nested only, not if they are linear. >Response: there IS a limit if I try to include more than 9 files in my lib file, hence I use 1 file although I wrote seperate files for all main macros. So here is a structure I propose: -An Include file for All the EQUs and Definitions >Response: first part in my lib file (lib_constants.inc) -A seperate include file for all the Variable definitions for each Routine. It has to have the correct ORGs. Attention to Banking, but macros should help with this. IE all variables to be used by the user are Set or Got by a macro to get/put them. This way each Variables .inc file is included only if it's subroutines .inc files is included. (maybe with the correct ORG statements we can have the routines .inc file do both) >Response: This will not work. Each macro must consist of 3 code parts: isr part, init part and main part, and a data part. Each of these code parts may access the macro data variables and must therefore have knowledge of variable names and labels. Therefore a macro subroutine must have all its parts in a single file. Also keeps maintaining the code simpler. -One include file for all the macros for all the library to be included at the top. Since macros are definitions and are only expanded as code where they are called, there would be no additional code unless it is needed. Thus this is can be only one big file, not seperate files for each routine. >Response: I do that by including lib_total.inc in the main program file. Inside the library I would like to have other includes for the main macros, so there are only 2 include levels required. Unfortunately the number of includes is limited even with 2 include levels. -A sperate include file for each subroutine to be included under an ORG statement to position the subroutine were it is desired to have it in the code.....attention to Paging and Top of Page etc. (Macros would help with this) >Response: In my libfile I generate a jump table at any page start and place code itself towards the page ends. This resolves overlapping areas and allows code to be called from anywhere. You don't want to hassle with ORG's. -An include file for each section of the ISR to be included within the master ISR as desired and if the routine requires it. conditional directives might be needed to modify the RETIW value (again macros would help here) >Response: All sections of a main macro should be kept in one file. Don't split up related areas over multiple files. That will lead to errors and possibly unable to assemble. Also note that dependecies are to be considered. At the end of my main program I include the code for any used macro and this includes any additional code required by the used macro code. This way the Macro Call would look Something like this ShiftIN Pin,Mode,Value,Size >Response: Yes, and each main macro should have an extensive help text, just as the Sx/B commands. I started a new thread "Library development" here: [url=http://forums.parallax.com/forums/default.aspx?f=7&m=103848]http://forums.parallax.com/forums/default.aspx?f=7&m=103848[/url] Please post any questions/suggestions regarding my library there. regards peter ---------- End of Message ---------- You can view the post on-line at: http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=103788#m103923 Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2006 (http://www.dotNetBB.com)