Software integration of routines
in [Embedded]
|
From: scytale413 on 13 May 2010 11:02 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 13 May 2010 13:28 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 13 May 2010 13:59 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 13 May 2010 14:37 [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 13 May 2010 14:52
[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 |