Looking for suggestions - how to handle multiple different user files with base code

Comments

5 comments

  • Avatar
    Darcy Williams

    Hi there, this sounds kind of similar to what we've done here, except different products using shared drivers/modules configured in different ways depending on the purpose? 

     

    I'll give a couple of examples of what we use it for and that should tell you if we're on the same page...

    ex1.  A common module that might provide a simple diagnostic interface through a usart, you need to select usart port, pins, baud rates etc

    ex2.  A generic module to provide a common interface to all external interrupt sources on that processor, selecting pins, priorities, trigger high/low, vector function

    ex3.  A generic module that provides simple tasking (e.g. calling a set of functions every, 1/10/50/100ms)

     

    Okay, so not sure if that's anything like what you're doing, and those are just some really simple examples of how we use this method.

     

    This is assuming that all your common modules are seperated off from your products in to folders like "drivers", "accessories", "shared" etc...  And that your products/projects each have their own folders.

     

    Each common module relies on either a config .h , or a config .c & .h.  These config files contain definitions, tables, enum's, and no functions what-so-ever.  Those config files reside in a "config" folder located within the source folder of each product.  Assuming your source folders are included in your project user paths, each of your common modules can include it's config file...  When that module initialises, it's using whatever tables/config you'd created for it specifically for that product application.

     

    e.g.

    A driver for managing 4-5 DMA handled USARTs might be called usart_dma.c/h and reside in your drivers folder.  You might then have two files called usart_dma_config.c/.h, each placed in the config folder of your product.  The driver then includes these by #include "config/usart_dma_config.h", and by the source files being included in the cross studio project.

     

    This means that so long as each product/project has it's own config folder, you can include "config/abc.h" from any of your modules that needs to be configured.  Because each prouduct sees only it's own config folder, when you build each product, the driver is customised for that product.  It's then just a matter of making sure that the variable/table/definition names in those config files are identical for every product that needs to configure that driver/module.

     

    Maybe that's something like what you're doing...  and maybe not.  But it makes for a brilliant way to reuse your code base

     

     

     

     

    0
    Comment actions Permalink
  • Avatar
    Matt

    Hi Darcy,

    Thanks for the description!  Your example 3 is a very close to what I'm doing, so you understood correctly.  I understand how you've done it and I think that is a good approach. 

     

    I believe that in your description, each separate project will have its own directory, config folder, and ALSO a Crossworks set of .hzp and .hzs files, correct?  I had originally posted thinking that there was one way to have a single common Crossworks project, but based on the build configuration it would go access the correct user directory / config.c/h type file.  If the whole project was presesnted to a customer, then they would be sent the core directory set of code plus their specific config folder contents.

    We provide an entire solution to some customers (i.e. do the development work then pass them a Crossworks project with source files).  The way I described it would make it just a shade easier for exporting the entire solution out of our SVN system when doing an update, but is probably non-standard and possibly confusing.  The other benefit however, would be that as updates to Crossworks come about, the one single "master" project would stay up to date with any changes that affect the hzp/hzs structure.

    Have I made the distinction between the methods clear?  In your description, there is a common  base directory, with separate project files and configuration files.  In mine, there is only one project file, located in the common base directory, that (based on build configuration somehow) accesses the configuration files in different directories.  In this case, if you change build configurations, the File System portion of the Crossworks GUI would now show a config.c/.h file for example, but it would be located in the correct user directory. 

    I'm probably just making it too difficult and I see problems with that approach as well.  I think what you have described is more common and makes more sense, and I should adopt it...

    Thanks for your comments Darcy!

    Matt

    0
    Comment actions Permalink
  • Avatar
    Paul Curtis

    You can use different build configurations to set the #defines to use.

    0
    Comment actions Permalink
  • Avatar
    Matt

    Thanks Paul, I was just looking at that.  I think I need to step back and figure out all the different combinations to see what will make the most sense.  Thanks again,
    Matt

    0
    Comment actions Permalink
  • Avatar
    Matt

    Hi Paul,

    I've been playing around with this, and was wondering if this made sense:

    1) Using only one core project file...

    2) Have a different #define for a user.c path definition in the different build configurations

    So if you are using the project and change the build configuration, it includes a different user.c file.  So I'd have a "common" directory, then a bunch of specific directories based on application.

    The remaining question is this though:  If I use this approach, the benefit is that the user sees the "user.c" file that applies to the build configuration in your GUI file explorer.  So if he switches from project A to project B, the file "user.c" is still in the explorer, but after a refresh if it is double clicked then the appropriate user.c file opens in the editor. 

    Does that make sense?  If so, how would I go about doing that (i.e. could I get CrossStudio to perform like that?)

     

    Thanks,
    Matt

     

    0
    Comment actions Permalink

Please sign in to leave a comment.