1. Home
  2. Embedded Programming
  3. Software integration of routines

Software integration of routines

In my work project, I was assigned as the firmware integrator for our digital power conversion board. We have different people working on different subsystems within the board. There aren't any problems with physically integrate each power conversion subsystem, but I would like some help with software integration.

Some of the routines are very time sensitive, others moderately, and a few are not sensitive at all. Does anyone have any recommendations on how to approach the integration of these routines, whether documentation formats or software?

Currently, I'm planning on gathering information on interrupts used, timing, and shared resources between the subsystems. Then gathering the designers and solving conflicts with their input. Then submit to them a common code organization structure for their subsystems with the conflict resolution solutions.

I don't know of any standardized/highly recommended ways to go about this.

Any thoughts?

--------------------------------------- Posted through

formatting link

Reply to
scytale413
Loading thread data ...

My first thought is that you seem to be going about this design backwards, unless everything is still in the block diagram stage.

You are designing real-time software, yet I don't see you use the term

-- are you familiar with it?

Your general design technique sounds good, but there's a huge difference between that scrap of theory and practice that actually works. Generally this is a job that goes to a senior engineer, often with a working title of "architect", and generally who has worked on a team doing similar work.

So, congratulations. You're being taught how to swim in the usual way. Just remember that the hard part is getting the bag untied.

In general your language sounds like you're thinking of yourself as a team member, possibly a new and lowly one who's taking a subordinate role. Unless your other team members are supernaturally cooperative, that won't work. You can't "submit" a common code organization "to" your team -- your team has to wholeheartedly accept a common code organization, and wholeheartedly agree to what is important and what is not. So you either have to _dictate_ the common code organization to a team that _has_ to do what you say, or you have to rally the troops to _agree_ to a common code organization -- and if the guy doing the decorative light display quietly decides that his work is more important than the ISR that keeps the FETs from blowing up, all your work will literally go up in smoke.

If you're really as much a newbie as you sound, Get Jack Ganssle's "The Art of Designing Embedded Systems" --

formatting link
If you're _really good_ it'll keep you from getting thrown under the bus, and if not at least you'll be able to understand what's happening to you.

--
Tim Wescott
Control system and signal processing consulting
www.wescottdesign.com
Reply to
Tim Wescott

Have you heard of "*SYSTEM* Engineering"? Is there an actual

*design* here? Or, is it just a bunch of folks with their own ideas as to what the project/product needs from them each pursuing their own individual agenda?

Trying to piece together a bunch of ad hoc designs ex post facto is fraught with perils... :< Plan on leaving *lots* of time at the end of the project to figure out why "nothing works". :<

Reply to
D Yuniskis
[snip]

I figured we weren't far from real-time software design. Managing multiple ISRs isn't exactly easy.

Our senior engineer is overseeing the entire board development, which has multiple microcontrollers on it. I'm supposed to off load the integration work of one of them, which I happen to be most familiar with.

It appears I have some indirect authority through our senior engineer. I suppose every set of standards will have to be approved by him, otherwise there is only an appearance of authority. Our project group does work well together and has a lot of friendly conversation. Even managed to convince two people to do some code cleanup on another chip without twisting their arms. Think I could use the second technique and keep the first in a back pocket?

Thanks for the book recommendation, just ordered it. Too many embedded systems books with few reviews.

--------------------------------------- Posted through

formatting link

Reply to
scytale413
[snip]

There is a distinct hardware design with specific requirements and functionality. Only adding things like snubbers, changing the inductors, caps, and resistors. It's the software that's been harder to organize since the development has been heavily distributed.

Reply to
scytale413

In addition to Jack Ganssle's book there are a number of others which I would suggest any engineer should have on their shelves.

?The Handbook of Walkthroughs, Inspections and Technical Reviews: Evaluating Programs, Projects and Products? by Freidman & Weinberg.

?Configuration Management: The Changing Image? by Marion Kelly

?Perfect Software and other illusions about testing? by Gerald M Weinberg

?Modelling control systems using IEC61499: Applying function blocks to distributed systems? by Robert Lewis.

"CMMI Distilled: A practical introduction to integrated process improvement? by Dennis Ahern, Aaron Clouse and Richard Turner.

"Applying Human Factors Methods" by Pietro Carlo Cacciabue

--
********************************************************************
Paul E. Bennett...............
Forth based HIDECS Consultancy
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-510979
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************
Reply to
Paul E. Bennett

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.