• State Not Answered
  • Locked Locked
  • Replies 30 replies
  • Subscribers 21 subscribers
  • Views 5431 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Firmware and application cohabitation on the same device

Franquet Damien

Hello,

I would like to create a firmware and an application running on the same device.

The application needs to call some functions of the firmware. The application can be updated whereas the firmware is still the same.

Therefore, i want to have 2 projects: one for the firmware (C coded) and one for the application (C coded).

I have seen that it's possible to forbid idata, xdata and code area in order to prevent the application to overwrite the firmware and its variables, but I have no clues on how to give my firmware prototype to my application.
Of course parameters and functions' addresses must map with the firmware mapping.

Does anyone have an idea how I can do this?

Thanks for your help!
Damien.

Parents
  • 0 in reply to Franquet Damien

    I have no BIOS available into my chip.

    You're writing the BIOS for your chip. The question is what the interface into the "BIOS" should be.

    Usually, a small embedded application for an 8051 is so intimately tied to the hardware that it doesn't make a lot of sense for the application to be independent, in the sense that desktop application software tries to be independent of the hardware or even the OS. Sure, there's a layer of code to handle the hardware. But do you really need an application that ports from this 8051 to that 8051 to that 68HC11 to that ARM, all using a common BIOS-like interface so that the app doesn't change?

    If so, you have three choices already:
    - single well-known function entry (command + parameters)
    - vector table of function pointers
    - many well-known addresses, fixed by the linker

    One alternative to all of the above is simply to write a library that handles the hardware and deliver that to the application programmer. They don't have to mess with bits in registers (same as with a BIOS-ish design), they can build new code and upgrade it while still linking to the old library, and you can have a simple bootloader that does nothing but load the app, without providing this BIOS-like layer.

Reply
  • 0 in reply to Franquet Damien

    I have no BIOS available into my chip.

    You're writing the BIOS for your chip. The question is what the interface into the "BIOS" should be.

    Usually, a small embedded application for an 8051 is so intimately tied to the hardware that it doesn't make a lot of sense for the application to be independent, in the sense that desktop application software tries to be independent of the hardware or even the OS. Sure, there's a layer of code to handle the hardware. But do you really need an application that ports from this 8051 to that 8051 to that 68HC11 to that ARM, all using a common BIOS-like interface so that the app doesn't change?

    If so, you have three choices already:
    - single well-known function entry (command + parameters)
    - vector table of function pointers
    - many well-known addresses, fixed by the linker

    One alternative to all of the above is simply to write a library that handles the hardware and deliver that to the application programmer. They don't have to mess with bits in registers (same as with a BIOS-ish design), they can build new code and upgrade it while still linking to the old library, and you can have a simple bootloader that does nothing but load the app, without providing this BIOS-like layer.

Children
  • 0 in reply to Drew Davis

    Yes but this bootloader will use USB and Flash functions (USB to receive the appplication). Therefore, if my application needs to receive other kind of data via USB, USB functions will be duplicated, the same goes for Flash functions.

    In order to prevent function duplication, I want my application to be able to access those functions stored into the bootloader/firmware.

    My application will NOT run on other chip (ARM, ...) but I want to be able to update the application via USB. To do so, I need a bootloader. This bootloader have access to USB, Flash and other stuff, so I called it firmware.

    If I do not create a bootloader, it will be hard to update the application because if I'm erasing flash functions, while using them, it will crash.

    This is why I want a "firmware". (Maybe firmware is not the correct word...)

    Damien.