Size matters - General Discussion - Netduino Forums
   
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

Size matters


  • Please log in to reply
16 replies to this topic

#1 Traveling Tech Guy

Traveling Tech Guy

    Advanced Member

  • Members
  • PipPipPip
  • 36 posts

Posted 25 May 2011 - 10:39 PM

Hi all,
I have a simple application that uses a light sensor, a temp sensor and MicroLiquidCrystal library to display the results and save them to an SD card. Everything works great.

I was hoping I could send the 2 sensor results to a Pachube feed. I downloaded the Gsiot PachubeClient and added it to my project. It compiles well. But when I try deploying, I get a generic error
An error has occurred: please check your hardware
and an error in
Microsoft.SPOT.Debugger.VsProjectFlavorCfg.Deploy()
.
No amount of restarting, re-connecting the USB, or even erasing the board helps.

After looking around, I found this thread, suggesting it might be a program-size problem. And indeed, if I remove any reference to the Gsiot DLL, the application can be deployed.

My questions are (in order of light to hard):
  • How much space do I have to deploy to? (Netduino Plus (v4.1.1.0 b1))
  • How/where in Visual Studio 2010 can I find out the total size my application compiles to?
  • While I did include the DLL for Gsiot, I just added the MicroLiquidCrystal project to my solution. Will compiling it and just adding the release version of the DLL mean a smaller sized application?
  • What other code-minimization techniques can I use?
  • Is what I'm trying to achieve (sensors + LCD + SD card + network) even possible?
This size limit takes me back 20 years to my Assembler days (and even then, I wasn't that great at it :blink: ). Any help is appreciated!

Thanks,
Guy

PS: for internet connection, I'm using the Asus WL-330gE as an adapter - so no additional components and or code are involved.

#2 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 25 May 2011 - 10:47 PM

Hi Guy, You have 64KB of flash available for deployment. When you run/deploy your program, Visual Studio should show the total size of your app in the build window (while it's copying it to the Netduino). It should appear for a few seconds. The System.Http.dll is the really big file. If you're using it in your application, it will take over half of your space. In sophisticated web apps, users sometimes switch from using the HttpWebResponse objects and just use simpler Socket wrappers instead. Chris P.S. What you're trying to accomplish should be totally possible on the Netduino Plus.

#3 Traveling Tech Guy

Traveling Tech Guy

    Advanced Member

  • Members
  • PipPipPip
  • 36 posts

Posted 25 May 2011 - 11:06 PM

Hi Guy,

You have 64KB of flash available for deployment. When you run/deploy your program, Visual Studio should show the total size of your app in the build window (while it's copying it to the Netduino). It should appear for a few seconds.

The System.Http.dll is the really big file. If you're using it in your application, it will take over half of your space. In sophisticated web apps, users sometimes switch from using the HttpWebResponse objects and just use simpler Socket wrappers instead.

Chris

P.S. What you're trying to accomplish should be totally possible on the Netduino Plus.


Hi Chris,
Thanks for the prompt reply and the great work you guys are doing on Netduino in general.
On my other laptop, using C# Express, I could see the size. However, I can't seem to get it in VS 2010 (Ultimate) output window.

I didn't check, but I assume the dll you've mentioned is used by the library I tried using. Any way around it? What are some other solutions you'd recommend?

Thanks,
Guy

#4 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 25 May 2011 - 11:12 PM

Hi Guy,

Thanks for the prompt reply and the great work you guys are doing on Netduino in general.
On my other laptop, using C# Express, I could see the size. However, I can't seem to get it in VS 2010 (Ultimate) output window.

I didn't check, but I assume the dll you've mentioned is used by the library I tried using. Any way around it? What are some other solutions you'd recommend?

It should always appear in the IDE when you deploy (just like with C# Express, unless you've changed a setting in Visual Studio to redirect the output). There are ways to tell the size of an app once it is deployed, but this is the best way when it isn't on the device yet.

In the GSIOT book, there's a chapter on using socket programming (vs. using the http object). Perhaps we need to pull the author into the conversation to help identify a good way to swap one for the other?

Chris

#5 Traveling Tech Guy

Traveling Tech Guy

    Advanced Member

  • Members
  • PipPipPip
  • 36 posts

Posted 25 May 2011 - 11:17 PM

In the GSIOT book, there's a chapter on using socket programming (vs. using the http object). Perhaps we need to pull the author into the conversation to help identify a good way to swap one for the other?

Chris

Chris,
Since I got to his book through your site, then by all means - if you have any way to get him to comment, I'd appreciate it :)

Guy

PS: btw, does the size of the executable itself matter, or is it non-relevant to the code deployed?

#6 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 25 May 2011 - 11:29 PM

Hi Guy,
What version of the GSIOT assemblies are you using? The latest ones from the book site?
http://www.gsiot.info/download/

I noticed that a new, smaller version of the server side is due to be posted next week. Which GSIOT components in particular are you using?

PS: btw, does the size of the executable itself matter, or is it non-relevant to the code deployed?

I'm sorry, but I don't understand the question. Can you please rephrase it for me? [The source code is compiled into object code...which is then deployed to the device. There is no limitation to the source code size specifically.]

Chris

#7 Traveling Tech Guy

Traveling Tech Guy

    Advanced Member

  • Members
  • PipPipPip
  • 36 posts

Posted 26 May 2011 - 01:05 AM

What version of the GSIOT assemblies are you using? The latest ones from the book site?
http://www.gsiot.info/download/

I noticed that a new, smaller version of the server side is due to be posted next week. Which GSIOT components in particular are you using?


I'm using the latest version from that site. I'm using the client library, as all I need is to post a value to a feed.

I'm sorry, but I don't understand the question. Can you please rephrase it for me? [The source code is compiled into object code...which is then deployed to the device. There is no limitation to the source code size specifically.]

Chris


What I meant was: what specifically gets deployed to the Netduino?
For example, if I just build the application, the bin/debug directory contains:
  • Sensors.exe - 8k in size
  • MicroLiquidCrystal.dll - 19K
  • Gsiot.PachubeClient.dll - 5k
  • Various PDB files - totaling well over 100k

So if just the EXE and DLLs get deployed, I don't see how go over the 64k limit. If there's a further list of DLLs and objects deployed in addition to the EXE and the DLLs I specified, how can I know what are they and how to calculate the total size of what will be deployed?

Thanks,
Guy

#8 Traveling Tech Guy

Traveling Tech Guy

    Advanced Member

  • Members
  • PipPipPip
  • 36 posts

Posted 26 May 2011 - 01:29 AM

BTW, just to make sure that I'm suffering from a size related error, here's what I see in the Output window when I click F5:
An error has occurred: please check your hardware.
Object reference not set to an instance of an object.
Source: Microsoft.SPOT.Debugger.CorDebug
Stack : 
   at Microsoft.SPOT.Debugger.VsProjectFlavorCfg.Deploy() in c:\depot\current\CLIENT_V4_1\Framework\CorDebug\VsProjectFlavorCfg.cs:line 893
   at Microsoft.SPOT.Debugger.VsProjectFlavorCfg.<Microsoft.VisualStudio.Shell.Interop.IVsDeployableProjectCfg.StartDeploy>b__0() in c:\depot\current\CLIENT_V4_1\Framework\CorDebug\VsProjectFlavorCfg.cs:line 634

Could it be something else? Just building succeeds.

#9 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 26 May 2011 - 06:39 AM

Hi Guy,

The assemblies you're adding aren't that big--but there may be some really large ones being pulled in as dependencies. That said, if they're not in your BIN folder...they probably aren't getting pulled in.

The .pdb file is not loaded onto your Netduino Plus.

The exception you're getting is an odd one. It could be size related, but it could be something else entirely. Is there any chance you can (a) zip up a copy of your project and post it online and/or (B) try to stub out the MicroLiquidCrystal features and assemblies to see if that fixes the issue?

Chris

P.S. Just to confirm...do you get any size info in the Output window before this error occurs? Such as...

Incrementally deploying assemblies to device
Deploying assemblies for a total size of 54152 bytes



#10 Cuno

Cuno

    Advanced Member

  • Members
  • PipPipPip
  • 144 posts
  • LocationZürich / Switzerland

Posted 26 May 2011 - 09:30 AM

Hi Guy,

thanks for buying my book!

The Gsiot.PachubeClient library is very simple and small, but it references System.Http. This is a large DLL, about 46 KB if I remember correctly. So together with the LCD library and the application, it may indeed be more than the available 64 KB.

You may want to take a look at example 9-1 (HelloPachubeSockets), which directly uses the Sockets API instead of the higher-level System.Http library. The price is that it doesn't interpret responses from Pachube, which may or may not be ok in your case.

Another possibility would be to create a reduced version of System.Http, a System.HttpClient assembly. It would have stripped away all server-related code, i.e., the classes HttpListener, HttpListenerContext, HttpListenerRequest, HttpListenerResponse, and auxiliary classes that are not used for the client-side classes. I did this once for the server-side, i.e., removed all client-side classes. I guess that (roughly) about 15 KB could be shaved off from the original 46 KB. Note that your program's source code would need no changes, not even to the source code of Gsiot.PachubeClient. The only change would be in Gsiot.PachubeClient in order to reference the System.HttpClient assembly, instead of System.Http. Unfortunately, stripping down System.Http is a bit of an iterative process until all unnecessary code is found and eliminated.

Cuno

PS
I just uploaded all the examples, and beta release 0.9 of Gsiot.PachubeClient and Gsiot.Server to www.gsiot.info.

#11 Chad

Chad

    Member

  • Members
  • PipPip
  • 16 posts

Posted 27 May 2011 - 08:21 PM

Guy, Just another idea. I’ve been using the MicroLiquidCrystal library for a project I’m working on. It has a provider model, which is great. A single API to talk with multiple LCD devices over different types of communication protocols. But what that means, is you are probably linking in providers for LCD screen types you aren’t using. For example, I am using the I2CBus to talk to a MCP23008 (using the Adafruit LCD Backpack). So I excluded from the MicroLiquidCrystal project both the GIPO and Shifter74Hc595 providers. This saved me about 3k. Not much, but if you go through this process with all of the libraryis you are including, it might save you enough without having to re-write your app. Also, you could build the release version of the libraries you are using. Because NetMF is interpreted, and I’m 99% sure there are no optimizations in the compile, I don’t think you get any performance improvements. But I have seen small decrease in size. Chris or others may know of a reason to not use the release version, but I haven't had any issues, including still having the ability to debug and use Debug.Print(). One thing I haven’t tried yet is to put everything into a single project. I wonder what overhead you get with each new dll. Chad

#12 Traveling Tech Guy

Traveling Tech Guy

    Advanced Member

  • Members
  • PipPipPip
  • 36 posts

Posted 27 May 2011 - 09:01 PM

Hi Guy,

The assemblies you're adding aren't that big--but there may be some really large ones being pulled in as dependencies. That said, if they're not in your BIN folder...they probably aren't getting pulled in.

The .pdb file is not loaded onto your Netduino Plus.

The exception you're getting is an odd one. It could be size related, but it could be something else entirely. Is there any chance you can (a) zip up a copy of your project and post it online and/or (B) try to stub out the MicroLiquidCrystal features and assemblies to see if that fixes the issue?

Chris

P.S. Just to confirm...do you get any size info in the Output window before this error occurs? Such as...


Chris,
Just posted my code to a Github repository - with the images I posted in some of my other questions, I got very close to the forum limit.
If Github is not accessible enough, let me know, and I'll zip and Dropbox the code.
Pay attention to the fact that you need to provide an API key and feed number in the Pachube.cs file to get a real result - although it's not relevant, since I'm just trying to deploy, not yet debug, the application.

To answer you second question - I never get the size line - I only get the error I posted, which got me to re-think the size issue.
I never get to deployment and I don't get a good reason. Any help is appreciated.

Thanks,
Guy

#13 Traveling Tech Guy

Traveling Tech Guy

    Advanced Member

  • Members
  • PipPipPip
  • 36 posts

Posted 27 May 2011 - 09:09 PM

Guy,

Just another idea. I’ve been using the MicroLiquidCrystal library for a project I’m working on. It has a provider model, which is great. A single API to talk with multiple LCD devices over different types of communication protocols. But what that means, is you are probably linking in providers for LCD screen types you aren’t using. For example, I am using the I2CBus to talk to a MCP23008 (using the Adafruit LCD Backpack). So I excluded from the MicroLiquidCrystal project both the GIPO and Shifter74Hc595 providers. This saved me about 3k. Not much, but if you go through this process with all of the libraryis you are including, it might save you enough without having to re-write your app.

Also, you could build the release version of the libraries you are using. Because NetMF is interpreted, and I’m 99% sure there are no optimizations in the compile, I don’t think you get any performance improvements. But I have seen small decrease in size. Chris or others may know of a reason to not use the release version, but I haven't had any issues, including still having the ability to debug and use Debug.Print().

One thing I haven’t tried yet is to put everything into a single project. I wonder what overhead you get with each new dll.

Chad


Chad,
Just tried building the project in release - it gets stuck deploying. I never see the size or any error issue. It builds, and then forever hangs on
------ Deploy started: Project: Sensors, Configuration: Release Any CPU ------
Maybe something is wrong with the combination of libraries, code, network...
My code itself is quite simple (Github repository link).
At this point, I'm not sure if it's a software, hardware or PICNIC issue :huh:

Thanks,
Guy

#14 Traveling Tech Guy

Traveling Tech Guy

    Advanced Member

  • Members
  • PipPipPip
  • 36 posts

Posted 27 May 2011 - 09:12 PM

Hi Guy,

thanks for buying my book!

The Gsiot.PachubeClient library is very simple and small, but it references System.Http. This is a large DLL, about 46 KB if I remember correctly. So together with the LCD library and the application, it may indeed be more than the available 64 KB.

You may want to take a look at example 9-1 (HelloPachubeSockets), which directly uses the Sockets API instead of the higher-level System.Http library. The price is that it doesn't interpret responses from Pachube, which may or may not be ok in your case.

Another possibility would be to create a reduced version of System.Http, a System.HttpClient assembly. It would have stripped away all server-related code, i.e., the classes HttpListener, HttpListenerContext, HttpListenerRequest, HttpListenerResponse, and auxiliary classes that are not used for the client-side classes. I did this once for the server-side, i.e., removed all client-side classes. I guess that (roughly) about 15 KB could be shaved off from the original 46 KB. Note that your program's source code would need no changes, not even to the source code of Gsiot.PachubeClient. The only change would be in Gsiot.PachubeClient in order to reference the System.HttpClient assembly, instead of System.Http. Unfortunately, stripping down System.Http is a bit of an iterative process until all unnecessary code is found and eliminated.

Cuno

PS
I just uploaded all the examples, and beta release 0.9 of Gsiot.PachubeClient and Gsiot.Server to www.gsiot.info.


Hi Cuno,
First, apology- I didn't buy your book (yet) - just read the online chapter.
How would I go about trimming the System.Http library? Is the code available? Can I just use the System.HttpClient somehow?

I realize I can (should?) always go down to sockets, but I'd like to avoid that for as long as possible :)

Thanks for the code and the support!!!

Guy

#15 Traveling Tech Guy

Traveling Tech Guy

    Advanced Member

  • Members
  • PipPipPip
  • 36 posts

Posted 27 May 2011 - 11:00 PM

UPDATE:

I managed to minimize the code and remove some stuff - got it down to 58K. Finally managed to deploy the code with System.Http.
However, after 2 loops, I got a memory exception in the code writing to the SD card. Clearly, 58K is pushing it.

So, I took Cuno's advice and switched to his sockets code - it dropped the total size to 14K!
The program can now successfully post both sensors' data to Pachube (feed link).
I'll trim it a bit further and update my Github, if anyone's interested.

One big negative side effect I've noticed: if you experience an error in deploying a version to the Netduino, or if your code suffers an exception,
you have to disconnect/reconnect the USB cable, or else you'll get strange behavior and hangs in VStudio.

Thanks all!
Guy

#16 Chad

Chad

    Member

  • Members
  • PipPip
  • 16 posts

Posted 27 May 2011 - 11:35 PM

Chad,
Just tried building the project in release - it gets stuck deploying. I never see the size or any error issue. It builds, and then forever hangs on

------ Deploy started: Project: Sensors, Configuration: Release Any CPU ------
Maybe something is wrong with the combination of libraries, code, network...
My code itself is quite simple (Github repository link).
At this point, I'm not sure if it's a software, hardware or PICNIC issue :huh:

Thanks,
Guy

I have run into the deployment issue where you have to unplug the Netduino and re-plug it in, both with debug and release builds. But I can run the release build just fine.

Glad you found a way to decrease your project size enough!

#17 mbinelo

mbinelo

    New Member

  • Members
  • Pip
  • 9 posts

Posted 11 January 2013 - 12:31 PM

I had the same problem, I could not find the progam size. The debug window does not apear during deploiment. To solve the problem, you have to open the window going to menu: debug->windows->output before "F5", and pin the window. Also try to open that window just after o compile an deploy "F5".






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.