Prev: CFP Applied Computing 2010: submissions until 28 May 2010
Next: LCP vs Stellaris micro
From: Mahesh_Shah on 13 Apr 2010 18:42
Can any one guide me how to develop pluggable fimrware architecture for
embedded system. I am developing a product using ARM Cortex-M3 core. I am
looking for an architecure where there will be a bare minimum functionality
involved in product. However additional functionalities or modules are
pluggable which can be added or removed from product any time based on
requirements.

For example, firmware will have basic 3 modules (M1, M2 and M3). Tomorrow,
i have to add module M4. So i can add code for that module M4 without
disturbing M1, M2 and M3 module. M4 code can be added using ethernet or USB
or simple RS232 or using wireless communication(RF). I dont want to
download entire new firmware having all 4 modules. Similarly if tomorrow, i
ahve to add another two modules M5 and M6 and now i want to remove M4, then
it should support it.

This makes sure that device will not bring back to factory from installed
location to load new firmware or modules.

Any thought.

Thanks in advance.



---------------------------------------
Posted through http://www.EmbeddedRelated.com
From: Stuart Longland on 13 Apr 2010 22:45
On Apr 14, 8:42 am, "Mahesh_Shah"
<maheshkumar.shah(a)n_o_s_p_a_m.gmail.com> wrote:
> Can any one guide me how to develop pluggable fimrware architecture for
> embedded system. I am developing a product using ARM Cortex-M3 core. I am
> looking for an architecure where there will be a bare minimum functionality
> involved in product. However additional functionalities or modules are
> pluggable which can be added or removed from product any time based on
> requirements.
>
> For example, firmware will have basic 3 modules (M1, M2 and M3). Tomorrow,
> i have to add module M4. So i can add code for that module M4 without
> disturbing M1, M2 and M3 module. M4 code can be added using ethernet or USB
> or simple RS232 or using wireless communication(RF). I dont want to
> download entire new firmware having all 4 modules. Similarly if tomorrow, i
> ahve to add another two modules M5 and M6 and now i want to remove M4, then
> it should support it.

One idea... not sure how well this will work... Implement the module
as you normally would, then define a struct with function pointers to
your routine's functions. Finally, use a linker script to place this
struct at the very start of a page in flash, followed by the .text
section. In your main code, always call the functions via the
struct's pointers.

When you want to leave the module out, you implement a dummy module to
take its place that implements none of the functions, but instead has
a struct containing NULL pointers for your functions that your code
checks for. Later when you come to add the module in, erase the page
where it is stored, then program the new module into that page. The
struct should get overwritten with a version that contains correct
pointers to your functions, and the rest of the page should contain
your code and other data for that module. The rest of the code should
see it then straight away.

Thoughts, anyone?
From: D Yuniskis on 14 Apr 2010 01:16
Stuart Longland wrote:
> On Apr 14, 8:42 am, "Mahesh_Shah"
> <maheshkumar.shah(a)n_o_s_p_a_m.gmail.com> wrote:
>> Can any one guide me how to develop pluggable fimrware architecture for
>> embedded system. I am developing a product using ARM Cortex-M3 core. I am
>> looking for an architecure where there will be a bare minimum functionality
>> involved in product. However additional functionalities or modules are
>> pluggable which can be added or removed from product any time based on
>> requirements.
>>
>> For example, firmware will have basic 3 modules (M1, M2 and M3). Tomorrow,
>> i have to add module M4. So i can add code for that module M4 without
>> disturbing M1, M2 and M3 module. M4 code can be added using ethernet or USB
>> or simple RS232 or using wireless communication(RF). I dont want to
>> download entire new firmware having all 4 modules. Similarly if tomorrow, i
>> ahve to add another two modules M5 and M6 and now i want to remove M4, then
>> it should support it.
>
> One idea... not sure how well this will work... Implement the module
> as you normally would, then define a struct with function pointers to
> your routine's functions. Finally, use a linker script to place this
> struct at the very start of a page in flash, followed by the .text
> section. In your main code, always call the functions via the
> struct's pointers.
>
> When you want to leave the module out, you implement a dummy module to
> take its place that implements none of the functions, but instead has
> a struct containing NULL pointers for your functions that your code
> checks for. Later when you come to add the module in, erase the page
> where it is stored, then program the new module into that page. The
> struct should get overwritten with a version that contains correct
> pointers to your functions, and the rest of the page should contain
> your code and other data for that module. The rest of the code should
> see it then straight away.
>
> Thoughts, anyone?

Build the struct in RAM. (either initializing it from a
similar struct defined in the initialized data area *or*
from a set of explicit assignments). Then, "examine" the
region of memory likely to contain your "extension(s)".
If found, set their struct member(s) accordingly.
Otherwise, leave them at NULL -- and know that you never
dereference *NULL.

You can layer this approach to allow each module to
have its own "init" function which can build other
structures (structs, arrays, etc.) as required.

How you inform other modules of the presence of particular
modules can either be ad-hoc (let each module explicitly *look*
for the modules that it needs) *or* you can implement a
little name service that maps symbolic names to legitimate
"objects" (I've used this technique quite successfully in
the past. The overhead isn't terribly expensive -- the
"register" and "lookup" functions are only done once so
you only have to incur the indirect function invocation
(jumping through a pointer) at run time (hard to get away from
this overhead)
From: Meindert Sprang on 14 Apr 2010 06:13
"Mahesh_Shah" <maheshkumar.shah(a)n_o_s_p_a_m.gmail.com> wrote in message
news:abidnXanysXbblnWnZ2dnUVZ_jOdnZ2d(a)giganews.com...
> Can any one guide me how to develop pluggable fimrware architecture for
> embedded system. I am developing a product using ARM Cortex-M3 core. I am
> looking for an architecure where there will be a bare minimum
functionality
> involved in product. However additional functionalities or modules are
> pluggable which can be added or removed from product any time based on
> requirements.

Such a system already exists. It's called a PC and the modules are generally
called applications ;-)
But seriously, what about a small ARM9 system running linux, where you can
add your modules as applications?

Meindert


From: Vladimir Vassilevsky on 14 Apr 2010 09:29


Mahesh_Shah wrote:

> Can any one guide me how to develop pluggable fimrware architecture for
> embedded system. I am developing a product using ARM Cortex-M3 core. I am
> looking for an architecure where there will be a bare minimum functionality
> involved in product. However additional functionalities or modules are
> pluggable which can be added or removed from product any time based on
> requirements.
>
> For example, firmware will have basic 3 modules (M1, M2 and M3). Tomorrow,
> i have to add module M4. So i can add code for that module M4 without
> disturbing M1, M2 and M3 module. M4 code can be added using ethernet or USB
> or simple RS232 or using wireless communication(RF). I dont want to
> download entire new firmware having all 4 modules. Similarly if tomorrow, i
> ahve to add another two modules M5 and M6 and now i want to remove M4, then
> it should support it.
>
> This makes sure that device will not bring back to factory from installed
> location to load new firmware or modules.
>
> Any thought.

Short answer: don't do that unless you really have to do that.

There will be a lot of unnecessary work on defining interfaces and
sharing system resources.

There will be a hell of compatibility issues between different versions
of different modules.

Modular approach actually makes sense in not too many cases.


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com


 |  Next  |  Last
Pages: 1 2
Prev: CFP Applied Computing 2010: submissions until 28 May 2010
Next: LCP vs Stellaris micro