Pluggable Firmware Architecture for Embedded System

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

formatting link

Reply to
Mahesh_Shah
Loading thread data ...

ty

,

SB

i

en

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?

Reply to
Stuart Longland

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)

Reply to
D Yuniskis

functionality

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

Reply to
Meindert Sprang

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

formatting link

Reply to
Vladimir Vassilevsky

I agree with Vladimir. Make M1 a bootloader and send the user whatever combination of M2,M3,M4....they need. You compiler and linker will keep the application smaller and more maintainable. I don't see many attractive waypoints between a single well-crafted application and a Linux install.

The time saved in only downloading a portion of the firmware will be exceeded by the engineerng time and tech support time. It may even be independent of product volume. For large volume, the engineering time gets amortized over many units, but the tech support is proportional to the number of units.

Mark Borgerson

Reply to
Mark Borgerson

Why not? I guess the size of the firmware is not a problem, so compile support for all modules in the firmware and if you develop a new module, add this to the main program, which should be able to detect all modules at runtime. Then the customer needs only one firmware and can always update to the latest version and all his modules are working.

If the size is a problem, the solution depens a lot on your system. Are you using an operating system? With Linux it is easy to use a plugin concept with shared libraries, but as Vladimir wrote, the interface, versions and integration in the rest of your program can be difficult.

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Reply to
Frank Buss

ity

,

SB

i

en

What you're trying to invent has been around for a long time.

Intel used something similar with their 80130 (OS in a chip) in the early '80s.

I built something like that for an 8051 at about the same time.

If you think of 'tasks' instead of 'modules' you'll be able to find more of the existing art.

RK

Reply to
d_s_klein

Take a look at the AmigaOS.

Antoon

Reply to
Jaded Hobo

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.