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

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
  • First of all - the chip isn't the worlds most powerful. Hence the question if you should take this fight.

    Second - if you really do make a "firmware" part, the firmware can set parameters in the struct before returning. Your inline function or define can then pick up this value.

    Third - you can't afford a switch that extracts all parameters and immediately calls the individual functions. You might save most code space by performing a copy of the struct to a fixed location in the firmware RAM space, and have the individual functions pick up their parameters directly from that global struct. Or, if you can have the caller know the address of the struct and setting the parameters in a shared struct.

Reply
  • First of all - the chip isn't the worlds most powerful. Hence the question if you should take this fight.

    Second - if you really do make a "firmware" part, the firmware can set parameters in the struct before returning. Your inline function or define can then pick up this value.

    Third - you can't afford a switch that extracts all parameters and immediately calls the individual functions. You might save most code space by performing a copy of the struct to a fixed location in the firmware RAM space, and have the individual functions pick up their parameters directly from that global struct. Or, if you can have the caller know the address of the struct and setting the parameters in a shared struct.

Children
No data