I'm not sure how many Keil MDK users there are here. . . Is anybody rolling their own Keil software packs  for in-house use?  If so - I'd like to hear about your experience with it, thoughts, suggestions, etc.  

We have various in-house libraries that are used by a few developers and I'm trying to figure out if it's worth the trouble of creating packs, or to just leave it as raw source in version control.  I'd be nice to be able to bring in a feature quickly and I feel like they'd also give us an extra bump to "button up" development on a module more often than final product release.

Since you have enough of a clue with version control, I would not worry about the SW packs. You can always re-use the code (and that is a Good Thing!).

Have you gone to the trouble of building any packs? If so, any impressions?  I went through some examples in the arm site and they weren't as bad as I was expecting.  I didn't get into real world examples of dependencies and configuration files (which are going to be more involved), but its starting to look like it *might* be worth the time if it's supported with some script code to fill out the xml pdsc files for the packs.  This would also give us a decent excuse to finally implement scripted tagging in svn, which would be a huge nudge in the right direction for something like continuous integration (a pipe dream at the moment).

I'm thinking they'd be great for a team attempting to leverage one another's code, as well as less experienced firmware engineers (both beginners and those new to the code base)

The trouble of course is making the time to devote to creating enough scripts to make it useful and realatively pain free and getting other Devs to use it

Never built any. While I am an embedded guy, I have been doing non-arm/keil stuff. Last time I used ARMs was 2012, and we went with IAR.

(BTW - I love ARMs. I have one hand, so when I use an ARM - I have *two* arms. i was on a project with 5 ARMs in the box. I tried to get the manager to cghange the internal name to Shiva, because the project allows me to have 6 arms :^)

But - it sounds like the goal is to create reusable blocks - a Good Thing. So it seems like it would be worth your time to try it. I would suggest starting small - 2..3 files with 1..2 functions per file - kind of a hello.c version. 

My daddy was a computer consultant. He had 4 rules (which were made into the book "Secrets of Consulting" by Gerald Weinberg). #1: no matter what they tell you, there is a problem. #2: no matter what they tell you, it's a people problem. I find #2 is spot on in almost all cases. Wonder of wonders, my daddy gets wiser the older I get. Considering he went braindamaged when I was 13 but started to recover when I hit 20..... Same thing happened to me when my son was 13..20 :^) I know Jerry - he doesn't need me to shill his books. However, they are very useful to read. Check them out of the library.

So - you are in a problem #2 situation. Talk to your manager. First, figure out (and practice) a compelling story to get him/her on-board on what you want to do (I'm assuming you are not a manager). Lay out what you want to do as proof-of-concept, and the advantages for *your manager*. You *must* get your manager on-board.

When you have it working, create a presentation for the group, and practice it with your manager. Also, create a "migration" plan on what things/functional areas/modules to start migrating to this method. Again, it is crucial to have your manager backing you up.

The short version: it sounds like you want to do Good Things, and your manager already has a clue (because you use - gosh - version control - you would be surprised on the number of groups that do no.). start small - proof-of-concept - and work with your manager on a plan. You will need to do most of the work (I suspect you know that) but it is the manager who has the power to implement it in the group.

Success to you!