mayfly.ini reader #198
Comments
|
I'm puzzled; what functionality would this add? |
|
Well ... its all about scaleability. Defined parts of the per system configuration reside on the SD card in Mayfly.ini - not in the compiled software. Currently ModularSensors requires a trained programmer/scientist to be attached for each physical node deployment. Its going to be very inefficient in peoples time in the field. For a project that has a defined ModularSensors platform - ie the instrument configuration is defined, then one tested image can be deployed across a number of physical platforms, and all the customization happens in the .ini file. I currently have it tested and working, but I haven't decomposed it into Classes . |
|
I think there are more unique settings that need to be programmed than are practical to read from an ini file. When we've needed to update or change, we walk out with a new programmed board and exchange, which isn't really much more hassle than carrying an SD card. Or we've carried out a laptop. We often have a laptop in the field anyway at station visits to download other sensors. I think there are tutorials online on how to use one Arduino to program another, to avoid the laptop. I think the functionality you are really looking for is an ability to reprogram from an SD card or, better yet, over the air. That is simply not possible with the bootloader on the Mayfly or most other typical Arduinos. You need a different bootloader. I've looked into it. If you could write a working bootloader that would have that capability, that would be awesome. I know @aufdenkampe would really love it. But that's way beyond this library. |
|
https://github.com/zevero/avr_boot - to read the full program from the SD card |
|
@neilh10, thanks for experimenting with different options for scalability. These are really very important to explore and I really like your ideas. @SRGDamia1, it is true that the ideal solution to scalability would be over-the-air updates, similar to how Particle.IO boards (and others) function. This is something that I've discussed separately with colleagues at LimnoTech (@gcutrell) and also with @fisherba. If over-the-air updates are not possible, then updating from an SD card could be a great option! The idea of mailing a partner an SD card to swap in and then hit the resent button -- that could be very, very appealing. @SRGDamia1, do you think we might be able to do that using https://github.com/zevero/avr_boot? Then we could merge in the work that @neilh10 has prototyped in this issue. |
|
The bootloader I linked and Neil's reader do different things. Neil's work (I think) looks for the ini to tell it what the UUID's and logging interval should be, but it doesn't change anything else. So, the sensors attached, the order of the array, and the underlying functions all stay the same. It would be useful for moving a programmed mayfly to a new site with identical set up except for the site itself. So a user could yank their sensor station, write the new uuid's to the sd card and put it back out without the board itself touching a computer. The advantage of this is that the user has a plain text file to look at to see their settings which could (possibly) be less scary than seeing the Arduino code. The board also continues to act just like a regular Arduino any time you want to do something completely different with it. The disadvantage is that you wouldn't ever be updating any of the underlying programming, so you can't get any new functionality. And, although you might possibly make the ini seem less scary than the ino and editing the text in notepad and saving might feel a little less scary than editing and hitting the upload in an ide, almost every line in the logger program really is a setting for the user to change, so your ini file would end up being just like the ino pinned at a (possibly) out of date version. The avr_boot I linked would actually read a completely new pre-compiled program hex file from the SD card and then begin running that new program. The advantage would be that you'd get to change every setting, including adding sensors, and you'd could update everything under the surface as well. The disadvantage is that it's no longer a text file on the SD card, it's a binary file so you can't see what it is. And, probably more crucially, after you put on this bootloader, your board would, in some sense, no longer be an Arduino. You would have to re-burn the Arduino bootlader on it to be able to upload programs in the normal way again. Programming the bootloader is not the same as programming the firmware. You need the right cables and set up to do it. To upload over the air, you would again need a different bootloader that could look for a new firmware online and then use that, just like avr_boot does from the SD card. I have seen a few people mentioning bootloaders that might work that way over UDP or TCP when the board is connected over ethernet to a secured network, but I haven't seen anything "Arduino" style that's more over-the-air than that. |
|
Some great thoughts here - good find @SRGDamia1. I've hope this is OK to track it I've opened #219 The intent that I had for "Mayfly.ini" which I'm now calling "ms_cfg.ini" is what I've implemented with a release I just made - https://github.com/neilh10/ModularSensors/wiki/Feature-INI-file Its turned out to be quite interrelated to a number of classes - as the persistent customer configurations needed to be pushed down into those classes. https://github.com/neilh10/ModularSensors/wiki/Release-Notes The end objective is that I have one firmware.hex (taken .pioenvs\mayfly\firmware.hex) that is given a release name eg mayfly_v0.17.3.release1a.hex that I (or any person visiting the location) can load into any mayfly rev0.5B with avrdude and then customize with an ms_cfg.ini on the SD card. Customizations that are mandatory are the UUIDs, but its also nice to have the .log file that represents the core data be a unique file name for that geographical site. When/if new functionality is released, then the Mayfly firmware can be upgraded (.. avrdude, SD card, OTA), and the core site functions/identity are in the "ms_cfg.ini" |
|
I'll leave this open because I think it's reasonable to have this library look for some configuration information from an SD card. |
I've created an ini reader - it reads from the SD card, and can then be used to customize each specific cards environment.
Would this be of interest?
neilh10@e76b4ba
An example is on the sd card the following file is created (Windows10 in my case)
mayfly.ini
The result is a repeated call from an iniHandler_fn() with the following pairs, and comes out on debug as
The text was updated successfully, but these errors were encountered: