Deploying from a file on the SD card
#1
Posted 31 January 2012 - 09:07 AM
#2
Posted 31 January 2012 - 03:45 PM
My Thread on Deploying
If I come up with anything will share it.
#3
Posted 01 February 2012 - 01:30 AM
I don't think we can do this from the Netduino, simply because the assemblies probably aren't present. But we can probably deploy from server to device OTA. The documentation specifically says that a failed update reverts to prior.
#4
Posted 02 February 2012 - 03:01 AM
#5
Posted 02 February 2012 - 10:58 AM
#6
Posted 02 February 2012 - 01:42 PM
Not today (via MFDeployEngine). This may be possible in the future though.Chris, does the Netduino Plus support deployment over ethernet? MFDeploy only sees it on USB.
Chris
#7
Posted 07 February 2012 - 03:50 AM
What is the possibility of this being implemented in the foreseeable future?Not today (via MFDeployEngine). This may be possible in the future though.
The lack of an OTAU facility severely limits the commercial application of Netduino.
It doesn't have to be TCPIP. Deploy from SD filesystem has a lot going for it.
#8
Posted 07 February 2012 - 04:09 AM
What is the possibility of this being implemented in the foreseeable future?
The lack of an OTAU facility severely limits the commercial application of Netduino.
It doesn't have to be TCPIP. Deploy from SD filesystem has a lot going for it.
Right, it would be easy to write managed code to transfer a file of replacement managed code from a distant server to the local SD card.
I would write that if there are was a way to use that image to flash the processor, then reboot.
It would be a bigger problem though if the TinyBooterDecompressor, ER_CONFIG, or ER_FLASH also needed updates. This seems likely since even the change from RC3 to RC4 required all of these to be updated.
#9
Posted 07 February 2012 - 12:49 PM
#10
Posted 07 February 2012 - 01:06 PM
I dont see why you couldn't deploy a small clr app that is basically only a 2nd stage bootloader to flash.
It never gets upgraded.
When the 2nd stage bootloader starts, it loads the latest version of your core app as a dll from SD.
Just make sure somewhere in your code you can upload a different version, you will also have to flag an upgrade somehow and reboot.
dynamic loading of assemblies
#11
Posted 07 February 2012 - 01:09 PM
Hi Arbiter
I was wondering how you do the multi-megabyte files? Is it wirelessly?
I have had a lot of trouble with the either/both the inbuilt TCPIP stack or the SD cards,
Particularly Out of memory, and network data rates and incompatible SD cards.
My solution to wireless comms is to connect to a wireless 3g router using an ethernet cable and use a relay to turn it on and off as required. This means that instead off a piss-ant 25mW transponder I have a 25W transponder juicing up a 9db whip. Signal fade? What signal fade? I've got a great signal
You need to ditch StreamReader in favour of direct use of FileStream and you need to use small buffers and be very aggressive about garbage collection.
#12
Posted 07 February 2012 - 01:11 PM
Just an idea, tell me if it's impractical.
I dont see why you couldn't deploy a small clr app that is basically only a 2nd stage bootloader to flash.
It never gets upgraded.
When the 2nd stage bootloader starts, it loads the latest version of your core app as a dll from SD.
Just make sure somewhere in your code you can upload a different version, you will also have to flag an upgrade somehow and reboot.
dynamic loading of assemblies
Aha! The long promised dynamic loading of assemblies! (we spoke of this on another thread)
I shall look into this at my earliest opportunity.
#13
Posted 07 February 2012 - 01:17 PM
#14
Posted 07 February 2012 - 05:29 PM
My solution to wireless comms is to connect to a wireless 3g router using an ethernet cable and use a relay to turn it on and off as required. This means that instead off a piss-ant 25mW transponder I have a 25W transponder juicing up a 9db whip. Signal fade? What signal fade? I've got a great signal
You need to ditch StreamReader in favour of direct use of FileStream and you need to use small buffers and be very aggressive about garbage collection.
A better solution is to send the upgrade as a series of smaller transactions, with each good one appended to the file on the SD card. Each one is checked for accuracy as it is received with a good hash. Missing records are retried as needed until the entire file has been received. Once you have a complete upgrade file, you can then proceed to invoke the routine that burns in the new code and reboots.
#15
Posted 09 February 2012 - 12:27 PM
You are quite right, of course. My logger has two parameters governing the reporting interval and the sampling interval. The size of the file is a function of the ration between these factors. I was merely having a happy gloat about how well my hardware solution works. I actually chose it for use in poor signal areas, and under the intended conditions it is an extremely good idea to keep the chunks small. But I remain gleeful about how fast and stable the unit is on my desk.A better solution is to send the upgrade as a series of smaller transactions, with each good one appended to the file on the SD card. Each one is checked for accuracy as it is received with a good hash. Missing records are retried as needed until the entire file has been received. Once you have a complete upgrade file, you can then proceed to invoke the routine that burns in the new code and reboots.
Now that I've solved all my immediate problems and had a squiz at your dynamic loader sample, I think that is a great idea. I'm completely certain it will work, and getting the code to the SD card is a trivial application of code that's already shaken down. I can't thank you enough; you've given me OTAU capability which is absolutely vital to commercial applications.Not to mention the possibility for crude VMM.I dont see why you couldn't deploy a small clr app that is basically only a 2nd stage bootloader to flash.
It never gets upgraded.
When the 2nd stage bootloader starts, it loads the latest version of your core app as a dll from SD.
Oh Chriiiiiiiis! Let's talk about release schedules and virtual memory...
#16
Posted 17 February 2012 - 03:47 PM
The config is a bit clunky, as it reads a config file to determine which libraries to load, but they all load via Reflection and callbacks are all running
through weak delegates.
It's working well so far; build a new .pe file, add an entry in the .ini file, copy to SD and reboot the N+. Bam, new plugin.
https://github.com/h...rium-Controller
#17
Posted 03 July 2012 - 01:57 PM
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users