Netduino home hardware projects downloads community

Jump to content


The Netduino forums have been replaced by new forums at community.wildernesslabs.co. This site has been preserved for archival purposes only and the ability to make new accounts or posts has been turned off.
Photo

Deploying from a file on the SD card


  • Please log in to reply
16 replies to this topic

#1 Arbiter

Arbiter

    Advanced Member

  • Members
  • PipPipPip
  • 132 posts
  • LocationBrisbane, Australia

Posted 31 January 2012 - 09:07 AM

I have file transfers happening just fine. I can send multi-megabyte files back and forth without a problem. Assuming I've transferred all the files of an application deployment to a folder on the SD card, how should I go about having the incumbent version of the application replace itself with the version on the SD card? In a sense I'm asking how deployment works, and rather than an epic answer I'm hoping someone will give me a reading list of URLs.Or an epic answer, if there isn't any doc.
One day, all this too shall parse.

#2 JerseyTechGuy

JerseyTechGuy

    Advanced Member

  • Members
  • PipPipPip
  • 870 posts

Posted 31 January 2012 - 03:45 PM

I am looking along those same lines now on my project after we found we cannot deploy and communicate with the app over the same COM port. Trying to make the upgrade of Netduino software a black box to the end user. Here was my thread.

My Thread on Deploying

If I come up with anything will share it.

#3 Arbiter

Arbiter

    Advanced Member

  • Members
  • PipPipPip
  • 132 posts
  • LocationBrisbane, Australia

Posted 01 February 2012 - 01:30 AM

Have a look at this. There's Microsoft documentation on customising MFDeploy. It seems we might use MFDeploy and MFTcpIpPort to get a connected MFDevice object (let's call it mfDevice) then call mfDevice.ConnectToTinyBooter() and then mfDevice.Deploy(binfilepath,sigfilepath,out entrypoint)

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.
One day, all this too shall parse.

#4 Arbiter

Arbiter

    Advanced Member

  • Members
  • PipPipPip
  • 132 posts
  • LocationBrisbane, Australia

Posted 02 February 2012 - 03:01 AM

Chris, does the Netduino Plus support deployment over ethernet? MFDeploy only sees it on USB.
One day, all this too shall parse.

#5 Magpie

Magpie

    Advanced Member

  • Members
  • PipPipPip
  • 279 posts
  • LocationAustralia (south island)

Posted 02 February 2012 - 10:58 AM

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.
STEFF Shield High Powered Led Driver shield.

#6 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 02 February 2012 - 01:42 PM

Hi Arbiter,

Chris, does the Netduino Plus support deployment over ethernet? MFDeploy only sees it on USB.

Not today (via MFDeployEngine). This may be possible in the future though.

Chris

#7 Arbiter

Arbiter

    Advanced Member

  • Members
  • PipPipPip
  • 132 posts
  • LocationBrisbane, Australia

Posted 07 February 2012 - 03:50 AM

Not today (via MFDeployEngine). This may be possible in the future though.

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.
One day, all this too shall parse.

#8 Robert L.

Robert L.

    Advanced Member

  • Members
  • PipPipPip
  • 100 posts

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 Arbiter

Arbiter

    Advanced Member

  • Members
  • PipPipPip
  • 132 posts
  • LocationBrisbane, Australia

Posted 07 February 2012 - 12:49 PM

I'd settle for application OTAU. The rest is just candy.
One day, all this too shall parse.

#10 Magpie

Magpie

    Advanced Member

  • Members
  • PipPipPip
  • 279 posts
  • LocationAustralia (south island)

Posted 07 February 2012 - 01:06 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
STEFF Shield High Powered Led Driver shield.

#11 Arbiter

Arbiter

    Advanced Member

  • Members
  • PipPipPip
  • 132 posts
  • LocationBrisbane, Australia

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.
One day, all this too shall parse.

#12 Arbiter

Arbiter

    Advanced Member

  • Members
  • PipPipPip
  • 132 posts
  • LocationBrisbane, Australia

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.
One day, all this too shall parse.

#13 Magpie

Magpie

    Advanced Member

  • Members
  • PipPipPip
  • 279 posts
  • LocationAustralia (south island)

Posted 07 February 2012 - 01:17 PM

Hi I upgraded to RC4 and at the same time ditched the StreamReader. And since then I have a stable webserver. My uploads are ok now too but I have only tried 30k max, but it doesn't look like failing. So thanks for the tip about StreamReader.
STEFF Shield High Powered Led Driver shield.

#14 Robert L.

Robert L.

    Advanced Member

  • Members
  • PipPipPip
  • 100 posts

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 Arbiter

Arbiter

    Advanced Member

  • Members
  • PipPipPip
  • 132 posts
  • LocationBrisbane, Australia

Posted 09 February 2012 - 12:27 PM

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.

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.

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.

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.

Oh Chriiiiiiiis! Let's talk about release schedules and virtual memory... ;)
One day, all this too shall parse.

#16 H07R0D

H07R0D

    Advanced Member

  • Members
  • PipPipPip
  • 95 posts

Posted 17 February 2012 - 03:47 PM

I've been using dynamic libraries for my Aquarium Controller app for a while now.
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 Arbiter

Arbiter

    Advanced Member

  • Members
  • PipPipPip
  • 132 posts
  • LocationBrisbane, Australia

Posted 03 July 2012 - 01:57 PM

Well, it took me long enough but finally I got around to it. I didn't end up using Fabien's code, although that was certainly crucial to understanding. I use a boot.config file on a fixed path to provide version, filename and an entry point class name. Version is something of mine; I like to leave different versions of the app in mass storage so I can go backwards to a last known good configuration. At any rate, I load the assembly the same way Fabien does, but instead of creating an object instance I call the static Program.Main() method that standard N+ applications all have. This means I can effectively chain into a standard program. While the class and method names are predictable, it is necessary to specify the entry point classname because the namespace could be anything, and need not match the app name. Being able to dynamically load a standard application has the tremendous advantage that you can deploy the same compiled codebase directly from the debugger, or dynamically via OTAU. I can have my cake and eat it too. I measured the memory overhead of the bootloader and it's about 3K. It is necessary for the bootloader to reference any assemblies your application code will want, but I have not found this to be onerous, since I always want network, filesystem etc. If this were a problem, there's nothing stopping the application from dynamically loading assemblies as well as statically referencing them.
One day, all this too shall parse.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

home    hardware    projects    downloads    community    where to buy    contact Copyright © 2016 Wilderness Labs Inc.  |  Legal   |   CC BY-SA
This webpage is licensed under a Creative Commons Attribution-ShareAlike License.