Home icon indicating copy to clipboard operation
Home copied to clipboard

Add/Modify configuration on flashed Device

Open LwServices opened this issue 2 years ago • 3 comments

Description

Currenty is difficult to seperate Data and Code. There are no way to copy files to internal drive on target.

Now you can use ResourceManager to do some of seperation. Example: var limits=Resource.GetString(Resource.StringResources.SensorLimits); When you modify limits you have to save it to other Place. FileHelper.WriteFile("I:\sensorLimits.json", limits);

Other Points are:

  • sensitive Data. Passwords, tokens, etc. this should'nt be commited to your repository.
  • commisioning: you have same codebase for all your devices. but the configuraion need to be different. like name, limits, ids, etc

How to solve the problem

To Solve this problem. need nanoff extended and add functionality to transfer files on flashed device.

nanoff --serialport COM31 --copy ~/source/configuration.json I:\config.json

Describe alternatives you've considered

Alternatives:

  • To handle the first issue would be helpful to make ResourceManager writeable.

This https://github.com/orgs/nanoframework/projects/39?pane=issue&itemId=18374816 solve the first two issues but not the last one.

Aditional context

No response

LwServices avatar Mar 04 '23 19:03 LwServices

Good points and reasoning here.

A couple of thoughts:

  1. Making ResourceManager to become writable is not doable. All the mechanism of resource mapping and composing the associate the corresponding metadata is done at compile time. Changing all this would deviate even further from C# Metadata specs, would break functionality with the full .NET and would be messy to implement, at best.
  2. The combination of being able to write files to storage from nanoff seems a great approach to be used in both production and development usage.
  3. The CopyToOutputDirectory implementation associated with .NET secrets would cover the remaining usage cases.

josesimoes avatar Mar 06 '23 09:03 josesimoes

It would be great to have the ability to write the configuration at any time, but the memory architecture of embedded devices have some limitations. Flash memory can only be updated after an erase in most cases that I have seen. For instance on the stm32H7 series, even though you can write a byte, the memory must have been erased before as the write can move a "1" to a "0" but not "0" to a "1" The smallest erase in the stm32H7 series is one sector or 128KBytes. One way to handle a smaller configuration than this would to read 128KBytes into RAM, update, erase and write, all doable, but you can see, its not an easy solution.

For comparison I investigated how the Arduino platform handles configuration between power up. The documentation states that microcontroller on the Arduino Boards have 512 bytes of EEPROM, and this seems to be the case of (all?) boards. EEPROM can be byte written, typically up to a million times in modern chips. A typical module (https://www.adafruit.com/product/5146) is a relative cheap device that could extend your project and possible give you the control you need.

Other Options

This first option uses the existing FLASH on the device and only addresses design time configuration
  • Use a C# class in your program as the configuration.
  • I am not sure about the Wireless/Bluetooth code, but it may need a change to be initialized later in boot as an option.
  • There had been an idea to support debugging over TCPIP over wireless, but I guess this could be addressed by having a fixed wireless configuration, not the best solution, but I have seen this done before, and there are ways to port forward if required.
  • The C# compiler has the facility to include source files names on the command line, so if you had 20 devices, all requiring different configurations, you could have 20 different config1.cs,config2.cs... names and 20 different compile lines.
Runtime option, saving user preferences etc.

This is more difficult with flash. At the moment there is some support by allocating a block of memory of the flash. This works in many cases, as some devices have a minimum erase size of 32Kbytes.

If you need something in short time frame for saving data, then I suggest an add-on EEPROM to get you moving quickly.

I guess, in the future, we could support an I2C EEPROM module as a standard way to save data.

TerryFogg avatar Mar 07 '23 01:03 TerryFogg

We use https://www.microchip.com/en-us/product/at24c08c EEPROM on our Evaluation Boards and it supports random write, no erase. With new https://github.com/nanoframework/System.Runtime.Serialization is is pretty straightforward to read/write data.

sky9mike avatar May 06 '23 16:05 sky9mike

nanoff now supports a file deployment which will copy file to internal drive.

Closing issue

AdrianSoundy avatar Jun 09 '24 09:06 AdrianSoundy

nanoff now supports a file deployment which will copy file to internal drive. I don't see any comit in https://github.com/nanoframework/nanoFirmwareFlasher/commits/main/ is it already meged?

LwServices avatar Jun 09 '24 18:06 LwServices

Yes merged in march

AdrianSoundy avatar Jun 09 '24 21:06 AdrianSoundy

yes I found. https://github.com/nanoframework/nanoFirmwareFlasher/blob/main/README.md#deploy-file-to-device-storage thank you

LwServices avatar Jun 10 '24 07:06 LwServices