From: scytale413 on
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 http://www.EmbeddedRelated.com
From: Tim Wescott on
scytale413 wrote:
> 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?

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" --
http://www.powells.com/partner/30696/biblio/9780750686440. 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
From: D Yuniskis on
scytale413 wrote:
> 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?

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". :<
From: scytale413 on
[snip]
>
>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?

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

>
>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.

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.

>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.

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?

>If you're really as much a newbie as you sound, Get Jack Ganssle's "The
>Art of Designing Embedded Systems" --
>http://www.powells.com/partner/30696/biblio/9780750686440. 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.

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

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

---------------------------------------
Posted through http://www.EmbeddedRelated.com
From: scytale413 on
[snip]
>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?

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.

>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". :<

I tried to get some sort of version control software and server, but our
project didn't have anyone to maintain it, back it up, create an off-site
backup and so on. It's a joint research project with a university and
military contractor, so what's been easy with one side has to be hard with
the other. The contractor handles version control internally, but won't
let non-employees/half the project use it, and the university didn't
specify version control costs in the grants.

---------------------------------------
Posted through http://www.EmbeddedRelated.com