How can I install Netduino board driver on the host machine without install all the Netduino SDK ?

Thanks,
Paolo

By using this:
http://forums.netdui...tduino-drivers/

If I understand your question correctly,
Pascal

Hello,

I try to find a good procedure to compile firmware with GCC.
Each time we need to add some firmeware code, we need to modify memory layout.
After some reading on the web and the Porting Kit documentation, it's not very clear for me.

When I cannot build because my firmware doesn't fit the allocated memory, I need to change two files :
C:\MicroFrameworkPK_v4_1\Solutions\Netduino\TinyCLR>scatterfile_tinyclr_gcc.xml
and
C:\MicroFrameworkPK_v4_1\Solutions\Netduino\DeviceCode\Blockstorage\Sam7X_blockstorage

For the first, it's simple, if I understand correctly :

If I need x bytes (compiler give this value), I just need to add x to previous existing value in Deploy_BaseAddress properties.

<?xml version="1.0"?>
<ScatterFile xmlns="http://schemas.microsoft.com/netmf/ScatterfileSchema.xsd">

    <!-- SAM7X512 has 128KB of RAM at 0x00000000, 512KB FLASH at 0x00100000  -->

    <Set Name="Valid" Value="false"/>

    <!-- ################################################################################ -->
    <!-- 16KB Stack and 16KB Heap -->
    <Set Name="Heap_Begin"      Value="0x00010000"/>
    <Set Name="Heap_End"        Value="0x00017FF8"/>
    <Set Name="Stack_Bottom"    Value="0x00018000"/>
    <Set Name="Stack_Top"       Value="0x0001FFF8"/>

    <If Name="TARGETLOCATION" In="FLASH">
        <Set Name="Code_BaseAddress"    Value="0x0011e000"/>
        <Set Name="Deploy_BaseAddress"  Value="0x00172000"/> <!-- here -->
        <Set Name="Code_Size"           Value="%Deploy_BaseAddress - Code_BaseAddress%"/>
        <Set Name="Config_BaseAddress"  Value="0x0017E000"/>    
        <Set Name="Config_Size"         Value="0x00002000"/>
        <Set Name="Valid"               Value="true"/>
    </If>

With this modification, the compile phase should works. But, the deployement phase can be unsuccessful in case of not enought room in blockstorage.
So, we need to change values in this structure also.

const BlockRange g_SAM7X_BS_BlockRange[] =
{
    //
    { BlockRange::BLOCKTYPE_BOOTSTRAP       ,  0,  5 },
    { MEMORY_BLOCKTYPE_GCC_SPECIAL_BOOTSTRAP,  6, 14 },
    { BlockRange::BLOCKTYPE_CODE            , 15, 44 },
    { MEMORY_BLOCKTYPE_GCC_SPECIAL_CODE     , 45, 46 },
    { BlockRange::BLOCKTYPE_DEPLOYMENT      , 47, 60 },
    { BlockRange::BLOCKTYPE_STORAGE_A       , 61, 61 },
    { BlockRange::BLOCKTYPE_STORAGE_B       , 62, 62 },
    { BlockRange::BLOCKTYPE_CONFIG          , 63, 63 }
};

Anybody may explain how to modify this file with a easy to understand way. How to know the size of each block ?
Is it related to PortBooter.bin, TinyBooter.bin, TinyBooterDecompressor.bin files size (one block = 8k) ...

Any help appreciate,
/pascal

Hello Chris,

Next week, I will receive these components :
http://www.coolcompo...uksdbumahtmuqg5
http://www.coolcompo...?products_id=83

W5100 is very nice, but limited (only ipv4, only 4 concurrent connexions ...),
Enc28j60 is more low level, only MAC, but we can use lwIP.
But, lwip seems to be to big to run on Netduino. I will work on uIP instead of lwIP and see if it's possible to run on .net MF ...

My first issue is to be able to compile the firmware. I currently use a eval version of RVDS 4.1 with success, but it's a eval version. With GCC, we probably raise a out of flash memory very quickly

Pascal

I just receive an offer for MDK, Keil, 3900 euros without taxes !!! Is RVDS cheaper ?

Pascal

As requested, we have been working on a few Ethernet options for the Netduino here at Secret Labs.

One of these that's in development is support for the Wiznet W5100-based Ethernet shields. A few forums members indicated that they've also started writing code for it. I'd like to see if we can get everyone on the same track so we can leverage each other's efforts.

I don't have any data on the stability of the chip for networking. I can say that we have completed the first portion of the support--but are still fleshing out the TCP and UDP support.

Here's what user setup code looks like so far (I just tested it on my home network):

// configure our wiznet chip
SecretLabs.NETMF.Net.WiznetChip wiznet = new SecretLabs.NETMF.Net.WiznetChip(Pins.GPIO_PIN_D10);
// configure our IP settings
NetworkInterface networkInterface = NetworkInterface.GetAllNetworkInterfaces()[0];
networkInterface.PhysicalAddress = new byte[] { 0x01, 0x23, 0x45, 0x67, 0x89, 0x01 };
networkInterface.EnableStaticIP("10.0.1.12", "255.255.255.0", "10.0.1.1");

Pretty simple, and compatible with the .NET MF networking object model.

Please note that this is all beta, subject to change, subject to abandonment, etc. We only want to ship things that are stable--and we're not far enough along to make that call yet...

Chris

Hello Chris,

Next week, I will receive these components :
http://www.coolcompo...uksdbumahtmuqg5
http://www.coolcompo...?products_id=83

W5100 is very nice, but limited (only ipv4, only 4 concurrent connexions ...),
Enc28j60 is more low level, only MAC, but we can use lwIP.
But, lwip seems to be to big to run on Netduino. I will work on uIP instead of lwIP and see if it's possible to run on .net MF ...

My first issue is to be able to compile the firmware. I currently use a eval version of RVDS 4.1 with success, but it's a eval version. With GCC, we probably raise a out of flash memory very quickly

Pascal

Regarding more pins...we're working on something(s)

One of the other big unique advantages of the Netduino is that it's 100% open source--hardware and software. You can erase the Netduino and compile the actual source code from scratch. In fact, we contributed much of the source back and bug fixes back to Microsoft--so it's included in the core .NET Micro Framework codebase for the benefit of all .NET MF products.

We're all about building community and giving our users the freedom to unleash their creativity. Netduino is only five weeks old and you folks have already created some pretty fantastic drivers and projects.

Thanks for being members of the Netduino community,

Chris

P.S. Oh, and we have some more surprises in store.

This is a key point. It was the main feature when I decided to purchase a Netduino. Without firmware source, I can be limited in future. And what about using multiple type of board and sharing a maximum of code ... I also purchase a Tahoe II board for the same key point. But it's not the same market. For my point of view, selling a .NET micro framework board with a proprietary firmware can be a good way to create a captive market ... not good for us.

I had to change scatterfile to match the blockrange - for example, I changed Code_BaseAddress to 0x116000, where the first BLOCKTYPE_CODE started (adjusted to accomodate ~81KB bootloader).


I use an evaluation of RVDS 4.1 Pro (registration required for download link). I don't know how much is it, but the fact you must ask for a quote indicates it is not cheap.

Thanks CW2 !!

The problem is that code generated by GCC does not fit into flash segments, hardcoded as a table in bootloader, which must be changed - I have already written about this in different thread.

Thanks Chris & CW2 for your help,

CW2, may you confirm that I don't need to change scatterfiles in any case (even if I add some new assembly in firmware, but that's not my case at this time) ? Because, when I don't change this file, I always receive an error at compile time (LR_FLASH bla bla bla) ... Even if I change the blockrange value.

Before starting any native code, I need to be able to rebuild successfuly a firmware with GCC. I don't have RVDS.

Is RVDS expensive ? Difficult to find any price !!!

/pascal

Next time, I will read the thread more carefully ... The answer was in the thread.
Now I will start to try some native code,
Pascal

Next step, deploying failed,
Reflash with SAM-BA, first with my own TinyBooterDecompressor compiled with GCC, then failed,
Reflash with official TinyBooterDecompressor, success,

But now, I'm not able to start any native code

Here is what I have done :

- Install PK 4.1
- Install Network part
- Install Crypto part
- Install CodeSourcery 4.2 (lite)
- Open cmd
- setenv_gcc_cmd C:\PROGRA~1\CODESO~1\SOURCE~1 (using 8.3 name, long name doesn't work)
- msbuild Solutions\Netduino\dotnetmf.proj /p:flavor=Release
- No enough room on flash
- Open Solutions\Netduino\TinyCLR\Scatter_tinyclr_gcc.xml
- Change Deploy_BaseAddress from 0x00172000 to 0x00175D28 to leave more space (exactly the difference showed by msbuild)
- Compile again
- Error during signature make
- Apply jemery fix
- compile again, then success (with a erase of BuildOutput folder and msbuild with /t:CleanBuild)
- msdeploy, failed
- reflash my arduino

Any help appreciate,
Pascal

Hello,

I also try to rebuild firmware with GCC 4.2, and after multiple issues, I'm finaly near the success (I hope). I just have a issue regarding signature. But it's strange because I thought I do not need to sign firmware.

Here is my error message :

BuildSigFiles:
  Create Signature files for C:\MicroFrameworkPK_v4_1\BuildOutput\THUMB\GCC4.2\le\FLASH\release\Netduino\bin\tinyclr.bin\ER_CONFIG;C:\MicroFrameworkPK_v4_1\Bui
  ldOutput\THUMB\GCC4.2\le\FLASH\release\Netduino\bin\tinyclr.bin\ER_DAT;C:\MicroFrameworkPK_v4_1\BuildOutput\THUMB\GCC4.2\le\FLASH\release\Netduino\bin\tinycl
  r.bin\ER_FLASH
  C:\MicroFrameworkPK_v4_1\BuildOutput\public\Release\Server\dll\MetaDataProcessor.exe -sign_file C:\MicroFrameworkPK_v4_1\BuildOutput\THUMB\GCC4.2\le\FLASH\re
  lease\Netduino\bin\tinyclr.bin\ER_CONFIG C:\MicroFrameworkPK_v4_1\tools\bin\tinybooter_private_key.bin C:\MicroFrameworkPK_v4_1\BuildOutput\THUMB\GCC4.2\le\F
  LASH\release\Netduino\bin\tinyclr.hex\ER_CONFIG.sig
  C:\MicroFrameworkPK_v4_1\BuildOutput\public\Release\Server\dll\MetaDataProcessor.exe -sign_file C:\MicroFrameworkPK_v4_1\BuildOutput\THUMB\GCC4.2\le\FLASH\re
  lease\Netduino\bin\tinyclr.bin\ER_DAT C:\MicroFrameworkPK_v4_1\tools\bin\tinybooter_private_key.bin C:\MicroFrameworkPK_v4_1\BuildOutput\THUMB\GCC4.2\le\FLAS
  H\release\Netduino\bin\tinyclr.hex\ER_DAT.sig
MMP : error MMP0000: CLR_E_FAIL [C:\MicroFrameworkPK_v4_1\Solutions\Netduino\TinyCLR\TinyCLR.proj]
C:\MicroFrameworkPK_v4_1\tools\targets\Microsoft.SPOT.System.GCC.targets(391,5): error MSB3073: The command "C:\MicroFrameworkPK_v4_1\BuildOutput\public\Releas
e\Server\dll\MetaDataProcessor.exe -sign_file C:\MicroFrameworkPK_v4_1\BuildOutput\THUMB\GCC4.2\le\FLASH\release\Netduino\bin\tinyclr.bin\ER_DAT C:\MicroFramew
orkPK_v4_1\tools\bin\tinybooter_private_key.bin C:\MicroFrameworkPK_v4_1\BuildOutput\THUMB\GCC4.2\le\FLASH\release\Netduino\bin\tinyclr.hex\ER_DAT.sig" exited
with code 10. [C:\MicroFrameworkPK_v4_1\Solutions\Netduino\TinyCLR\TinyCLR.proj]
Done Building Project "C:\MicroFrameworkPK_v4_1\Solutions\Netduino\TinyCLR\TinyCLR.proj" (Build target(s)) -- FAILED.

Done Building Project "C:\MicroFrameworkPK_v4_1\Solutions\Netduino\dotnetmf.proj" (default targets) -- FAILED.


Build FAILED.

Thanks in advance,
/pascal

Next time, I will read the thread more carefully ... The answer was in the thread.
Now I will start to try some native code,
Pascal

CMD,

you need to spend some time reading and understanding the porting kit documentation. This will explain your issue. Look up scatterfiles.

The fact is that there is no compelling reason to build the firmware unless you want to make changes to it. If you want to make changes then there is no alternative but to spend a good few hours understanding what the porting kit docs have to say.

This assumes you have a background doing embedded development in assembler and/or C and understand how to lay out memory. The tinyCLR firmware is not place to start learning about embedded development in C.

Hello,

I also try to rebuild firmware with GCC 4.2, and after multiple issues, I'm finaly near the success (I hope). I just have a issue regarding signature. But it's strange because I thought I do not need to sign firmware.

Here is my error message :

BuildSigFiles:
  Create Signature files for C:\MicroFrameworkPK_v4_1\BuildOutput\THUMB\GCC4.2\le\FLASH\release\Netduino\bin\tinyclr.bin\ER_CONFIG;C:\MicroFrameworkPK_v4_1\Bui
  ldOutput\THUMB\GCC4.2\le\FLASH\release\Netduino\bin\tinyclr.bin\ER_DAT;C:\MicroFrameworkPK_v4_1\BuildOutput\THUMB\GCC4.2\le\FLASH\release\Netduino\bin\tinycl
  r.bin\ER_FLASH
  C:\MicroFrameworkPK_v4_1\BuildOutput\public\Release\Server\dll\MetaDataProcessor.exe -sign_file C:\MicroFrameworkPK_v4_1\BuildOutput\THUMB\GCC4.2\le\FLASH\re
  lease\Netduino\bin\tinyclr.bin\ER_CONFIG C:\MicroFrameworkPK_v4_1\tools\bin\tinybooter_private_key.bin C:\MicroFrameworkPK_v4_1\BuildOutput\THUMB\GCC4.2\le\F
  LASH\release\Netduino\bin\tinyclr.hex\ER_CONFIG.sig
  C:\MicroFrameworkPK_v4_1\BuildOutput\public\Release\Server\dll\MetaDataProcessor.exe -sign_file C:\MicroFrameworkPK_v4_1\BuildOutput\THUMB\GCC4.2\le\FLASH\re
  lease\Netduino\bin\tinyclr.bin\ER_DAT C:\MicroFrameworkPK_v4_1\tools\bin\tinybooter_private_key.bin C:\MicroFrameworkPK_v4_1\BuildOutput\THUMB\GCC4.2\le\FLAS
  H\release\Netduino\bin\tinyclr.hex\ER_DAT.sig
MMP : error MMP0000: CLR_E_FAIL [C:\MicroFrameworkPK_v4_1\Solutions\Netduino\TinyCLR\TinyCLR.proj]
C:\MicroFrameworkPK_v4_1\tools\targets\Microsoft.SPOT.System.GCC.targets(391,5): error MSB3073: The command "C:\MicroFrameworkPK_v4_1\BuildOutput\public\Releas
e\Server\dll\MetaDataProcessor.exe -sign_file C:\MicroFrameworkPK_v4_1\BuildOutput\THUMB\GCC4.2\le\FLASH\release\Netduino\bin\tinyclr.bin\ER_DAT C:\MicroFramew
orkPK_v4_1\tools\bin\tinybooter_private_key.bin C:\MicroFrameworkPK_v4_1\BuildOutput\THUMB\GCC4.2\le\FLASH\release\Netduino\bin\tinyclr.hex\ER_DAT.sig" exited
with code 10. [C:\MicroFrameworkPK_v4_1\Solutions\Netduino\TinyCLR\TinyCLR.proj]
Done Building Project "C:\MicroFrameworkPK_v4_1\Solutions\Netduino\TinyCLR\TinyCLR.proj" (Build target(s)) -- FAILED.

Done Building Project "C:\MicroFrameworkPK_v4_1\Solutions\Netduino\dotnetmf.proj" (default targets) -- FAILED.


Build FAILED.

Thanks in advance,
/pascal

A faster processor would be nice. After reading CW2's writeup about how it's currently not quite fast enough to really do all the one-wire stuff (among others) even in C++ native code. Come on, you guys can beat the FEZ can't you?

For my point of view, OneWire issue is not related to processor speed. It's more related to C# latency inducted. So, the solution, like other vendors, is to provide a OneWire feature in native code and a library in C# to use it.

I use onewire with a AVR 328p at 8 Mhz !!!

My 0.2cents,
Pascal

Hello, What kind of hardware/software do we need to be able to debug firmware using VS like this: Pascal

Hi, I have wired up a sparkfun Triple Axis Accelerometer Breakout ADXL335 to the netduino as follows:

x - PIN_A0
y - PIN_A1
z - PIN_A2
VCC - 3V3 && Aref
GND - Gnd

All works ok when I only try to read a single port, however if I try to read all 3 as detailed below the netduino drops out during the while statement and then I have to do a manual erase of the program via MFDeploy before I can successfully deploy to the device again.

My program is as follows:

using System;
using System.Threading;
using Microsoft.SPOT;
using Microsoft.SPOT.Hardware;
using SecretLabs.NETMF.Hardware;
using SecretLabs.NETMF.Hardware.Netduino;

namespace accelerometer
{
public class Program
{
// Define our accelerometer inputs
static AnalogInput accX;
static AnalogInput accY;
static AnalogInput accZ;

public static void Main()
{
// Create the Inputs
accX = new AnalogInput(Pins.GPIO_PIN_A0);
accY = new AnalogInput(Pins.GPIO_PIN_A1);
accZ = new AnalogInput(Pins.GPIO_PIN_A2);

// Output the values ???
while (true)
{
// When alone works fine
Debug.Print("accX: " + accX.Read().ToString());

// This (multiple) doesn't
// Debug.Print("accX: " + accX.Read().ToString());
// Debug.Print("accY: " + accY.Read().ToString());
// Debug.Print("accZ: " + accZ.Read().ToString());
}
}
}
}

I have tested the accelerometer via just running the single input code and swapping in the respective wire for x,y,z. The likelihood is that I am missing something obvious due to inexperience etc so with that in mind a few questions:

I have assumed that I can wire in multiple analog inputs which can be read concurrently. Is this correct?
Drawing upon peoples vaster pools of knowledge do I seem to have I wired up the system correctly?

Does the Aref only cater for a single input?

Cheers dyadica

Did you have update the firmware with patch 2, which include a fix regarding multiple analog use ?

Pascal

On the topic of EEPROM--are you wanting actual EEPROM (read/write tons of times) or just a few KB of on-board storage for ocassional use?

Chris

Chris, when you say that, do you plan to use other feature than ExtendedWeakReference ?

On the topic of EEPROM--are you wanting actual EEPROM (read/write tons of times) or just a few KB of on-board storage for ocassional use?

Chris

In my case, currently, it's just to have persistant information like IP address ... So just a few KB of on-board storage would be suffisant.

Pascal

I will admit I'd love to see a small EEPROM. The rest I don't think are really necessary (I mean the netduino already has a crapload of memory and flash compared to the arduino) not that I'd say "no" if there's more - more is (almost) always better! Onboard ethernet I think is unnecessary as long as its supported in the firmware - there are too many projects that won't use ethernet to warrant having it on the board. As long as its in firmware it can be "aftermarket".

However, if you are seriously considering an "ultra" style board I wouldn't say no to more GPIO pins.

Considering Ethernet feature is already avalaible on the ship ... Why not to have the possibily to use it ? Perhaps, to be open, just make the pins available to connect a magjack in case of you want to use it and the corresponding firmware.

Pascal

Perhaps we should build a Netduino "Ultra" with MBs of on-board RAM/FLASH and on-board Ethernet?

Chris

It would be perfect !!!! + EEPROM

Escpecialy if the Ethernet is compatible with lwIP,

Pascal

Thanks EdO!

I was under the impression that the analog pins were "general purpose", as far as them being able to act as digital? Was I mistaken?

The "brick shield" im using makes it pretty obvious that mapping the LCD pins to the analog ports pretty obvious. I'll check the "other" pins and try going all digital for the next round of testing.

I don't know with netduino, but on arduino you can use a analogue pin as a digital pin,
I often use it when no free digital pins,

Pascal

Hello Netduino community, I search for a more powered device needed for a new project (IPv6 network project), I would like to use multiple netduino (when it will be ethernet ready), and one of that device, Here is the needed features : - .NET micro framework ready - 1MB of flash or more, same for RAM - Firmware open source, because I need to write some native code for performance and low level network features. - Ethernet, enc28j60 prefered, because of lwIP compatibility I found a lot of devices, but I don't know if the firmware are open source or not Thanks in advance, Pascal

From the AT91SAM7X512 datasheet:
One Two-wire Interface (TWI)
– Master Mode Support Only, All Two-wire Atmel EEPROMs and I2C Compatible Devices Supported

A driver for SPI slave mode could be written, but I2C slave would require a "bit banged driver."

Chris

Thanks for that clarification ...

Pascal

The I2C on the ARM7X chip is master-only. We'll see what we can do on speeding up Ethernet support...

Chris

I2C master-only is a limitation of ARM7X or .NET micro framework ?
Perhaps I'm wrong, but when I read the datasheet, it's seems that the ATMEL used on netduino support both mode, no ?

Pascal

3 or more you've got a couple choices - you can use I2C to do it and give each a different address or you can use ethernet.

Personally, as a network engineer I'd say ethernet but there aren't any ethernet drivers for the netduino (yet!).

+1 for Ethernet.
It's seems that I2C .net MF implementation (like SPI) is always master. So, we cannot use I2C to cummunicate between 2 Netduino(s). Or we need to write another driver.
And I2C is very slow for that distance.

Pascal

Okay, just to make sure I understand this right... The SPI clock is working properly for you now, correct?

If not, I want to make sure I get a bug report files so we can investigate...

My SPI works because I use 1 Mhz clock. Because netduino is the master clock, I decided to use that freqency. If the slave doesn't support freqency above 150khz, we will probably have a issue.
But it's not my case.

Pascal

It seems that there is minimum SPI clock speed of about 200KHz.

Desired setting -> Frequency measured on oscilloscope
6000kHz -> 6.00MHz
1000kHz -> 1.00MHz
300kHz -> 300kHz
150kHz -> 743kHz
100kHz -> 215kHz
10kHz -> 251kHz

It's my mistake, I need to multiply by 2,
You're right for all results,
I have the same results now (approximatly),

Pascal

Hello,

I have tried to port Arduino library for this LCD with success. Only the LCD part works, not the joystick due to maximum 3.3v netduino use on Analogue pin.

Here is the library (Nokia3310.cs) :

using System;
using System.Threading;
using Microsoft.SPOT.Hardware;
using SecretLabs.NETMF.Hardware.Netduino;

namespace Shield
{
    class Nokia3310
    {
        public byte[][] font6_8 = new byte[][]            
        {
            new byte[] { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 },   // sp
            new byte[] { 0x00, 0x00, 0x00, 0x2f, 0x00, 0x00 },   // !
            new byte[] { 0x00, 0x00, 0x07, 0x00, 0x07, 0x00 },   // "
            new byte[] { 0x00, 0x14, 0x7f, 0x14, 0x7f, 0x14 },   // #
            new byte[] { 0x00, 0x24, 0x2a, 0x7f, 0x2a, 0x12 },   // $
            new byte[] { 0x00, 0x62, 0x64, 0x08, 0x13, 0x23 },   // %
            new byte[] { 0x00, 0x36, 0x49, 0x55, 0x22, 0x50 },   // &
            new byte[] { 0x00, 0x00, 0x05, 0x03, 0x00, 0x00 },   // '
            new byte[] { 0x00, 0x00, 0x1c, 0x22, 0x41, 0x00 },   // (
            new byte[] { 0x00, 0x00, 0x41, 0x22, 0x1c, 0x00 },   // )
            new byte[] { 0x00, 0x14, 0x08, 0x3E, 0x08, 0x14 },   // *
            new byte[] { 0x00, 0x08, 0x08, 0x3E, 0x08, 0x08 },   // +
            new byte[] { 0x00, 0x00, 0x00, 0xA0, 0x60, 0x00 },   // ,
            new byte[] { 0x00, 0x08, 0x08, 0x08, 0x08, 0x08 },   // -
            new byte[] { 0x00, 0x00, 0x60, 0x60, 0x00, 0x00 },   // .
            new byte[] { 0x00, 0x20, 0x10, 0x08, 0x04, 0x02 },   // /
            new byte[] { 0x00, 0x3E, 0x51, 0x49, 0x45, 0x3E },   // 0
            new byte[] { 0x00, 0x00, 0x42, 0x7F, 0x40, 0x00 },   // 1
            new byte[] { 0x00, 0x42, 0x61, 0x51, 0x49, 0x46 },   // 2
            new byte[] { 0x00, 0x21, 0x41, 0x45, 0x4B, 0x31 },   // 3
            new byte[] { 0x00, 0x18, 0x14, 0x12, 0x7F, 0x10 },   // 4
            new byte[] { 0x00, 0x27, 0x45, 0x45, 0x45, 0x39 },   // 5
            new byte[] { 0x00, 0x3C, 0x4A, 0x49, 0x49, 0x30 },   // 6
            new byte[] { 0x00, 0x01, 0x71, 0x09, 0x05, 0x03 },   // 7
            new byte[] { 0x00, 0x36, 0x49, 0x49, 0x49, 0x36 },   // 8
            new byte[] { 0x00, 0x06, 0x49, 0x49, 0x29, 0x1E },   // 9
            new byte[] { 0x00, 0x00, 0x36, 0x36, 0x00, 0x00 },   // :
            new byte[] { 0x00, 0x00, 0x56, 0x36, 0x00, 0x00 },   // ;
            new byte[] { 0x00, 0x08, 0x14, 0x22, 0x41, 0x00 },   // <
            new byte[] { 0x00, 0x14, 0x14, 0x14, 0x14, 0x14 },   // =
            new byte[] { 0x00, 0x00, 0x41, 0x22, 0x14, 0x08 },   // >
            new byte[] { 0x00, 0x02, 0x01, 0x51, 0x09, 0x06 },   // ?
            new byte[] { 0x00, 0x32, 0x49, 0x59, 0x51, 0x3E },   // @
            new byte[] { 0x00, 0x7C, 0x12, 0x11, 0x12, 0x7C },   // A
            new byte[] { 0x00, 0x7F, 0x49, 0x49, 0x49, 0x36 },   // B
            new byte[] { 0x00, 0x3E, 0x41, 0x41, 0x41, 0x22 },   // C
            new byte[] { 0x00, 0x7F, 0x41, 0x41, 0x22, 0x1C },   // D
            new byte[] { 0x00, 0x7F, 0x49, 0x49, 0x49, 0x41 },   // E
            new byte[] { 0x00, 0x7F, 0x09, 0x09, 0x09, 0x01 },   // F
            new byte[] { 0x00, 0x3E, 0x41, 0x49, 0x49, 0x7A },   // G
            new byte[] { 0x00, 0x7F, 0x08, 0x08, 0x08, 0x7F },   // H
            new byte[] { 0x00, 0x00, 0x41, 0x7F, 0x41, 0x00 },   // I
            new byte[] { 0x00, 0x20, 0x40, 0x41, 0x3F, 0x01 },   // J
            new byte[] { 0x00, 0x7F, 0x08, 0x14, 0x22, 0x41 },   // K
            new byte[] { 0x00, 0x7F, 0x40, 0x40, 0x40, 0x40 },   // L
            new byte[] { 0x00, 0x7F, 0x02, 0x0C, 0x02, 0x7F },   // M
            new byte[] { 0x00, 0x7F, 0x04, 0x08, 0x10, 0x7F },   // N
            new byte[] { 0x00, 0x3E, 0x41, 0x41, 0x41, 0x3E },   // O
            new byte[] { 0x00, 0x7F, 0x09, 0x09, 0x09, 0x06 },   // P
            new byte[] { 0x00, 0x3E, 0x41, 0x51, 0x21, 0x5E },   // Q
            new byte[] { 0x00, 0x7F, 0x09, 0x19, 0x29, 0x46 },   // R
            new byte[] { 0x00, 0x46, 0x49, 0x49, 0x49, 0x31 },   // S
            new byte[] { 0x00, 0x01, 0x01, 0x7F, 0x01, 0x01 },   // T
            new byte[] { 0x00, 0x3F, 0x40, 0x40, 0x40, 0x3F },   // U
            new byte[] { 0x00, 0x1F, 0x20, 0x40, 0x20, 0x1F },   // V
            new byte[] { 0x00, 0x3F, 0x40, 0x38, 0x40, 0x3F },   // W
            new byte[] { 0x00, 0x63, 0x14, 0x08, 0x14, 0x63 },   // X
            new byte[] { 0x00, 0x07, 0x08, 0x70, 0x08, 0x07 },   // Y
            new byte[] { 0x00, 0x61, 0x51, 0x49, 0x45, 0x43 },   // Z
            new byte[] { 0x00, 0x00, 0x7F, 0x41, 0x41, 0x00 },   // [
            new byte[] { 0x00, 0x55, 0x2A, 0x55, 0x2A, 0x55 },   // 55
            new byte[] { 0x00, 0x00, 0x41, 0x41, 0x7F, 0x00 },   // ]
            new byte[] { 0x00, 0x04, 0x02, 0x01, 0x02, 0x04 },   // ^
            new byte[] { 0x00, 0x40, 0x40, 0x40, 0x40, 0x40 },   // _
            new byte[] { 0x00, 0x00, 0x01, 0x02, 0x04, 0x00 },   // '
            new byte[] { 0x00, 0x20, 0x54, 0x54, 0x54, 0x78 },   // a
            new byte[] { 0x00, 0x7F, 0x48, 0x44, 0x44, 0x38 },   // b
            new byte[] { 0x00, 0x38, 0x44, 0x44, 0x44, 0x20 },   // c
            new byte[] { 0x00, 0x38, 0x44, 0x44, 0x48, 0x7F },   // d
            new byte[] { 0x00, 0x38, 0x54, 0x54, 0x54, 0x18 },   // e
            new byte[] { 0x00, 0x08, 0x7E, 0x09, 0x01, 0x02 },   // f
            new byte[] { 0x00, 0x18, 0xA4, 0xA4, 0xA4, 0x7C },   // g
            new byte[] { 0x00, 0x7F, 0x08, 0x04, 0x04, 0x78 },   // h
            new byte[] { 0x00, 0x00, 0x44, 0x7D, 0x40, 0x00 },   // i
            new byte[] { 0x00, 0x40, 0x80, 0x84, 0x7D, 0x00 },   // j
            new byte[] { 0x00, 0x7F, 0x10, 0x28, 0x44, 0x00 },   // k
            new byte[] { 0x00, 0x00, 0x41, 0x7F, 0x40, 0x00 },   // l
            new byte[] { 0x00, 0x7C, 0x04, 0x18, 0x04, 0x78 },   // m
            new byte[] { 0x00, 0x7C, 0x08, 0x04, 0x04, 0x78 },   // n
            new byte[] { 0x00, 0x38, 0x44, 0x44, 0x44, 0x38 },   // o
            new byte[] { 0x00, 0xFC, 0x24, 0x24, 0x24, 0x18 },   // p
            new byte[] { 0x00, 0x18, 0x24, 0x24, 0x18, 0xFC },   // q
            new byte[] { 0x00, 0x7C, 0x08, 0x04, 0x04, 0x08 },   // r
            new byte[] { 0x00, 0x48, 0x54, 0x54, 0x54, 0x20 },   // s
            new byte[] { 0x00, 0x04, 0x3F, 0x44, 0x40, 0x20 },   // t
            new byte[] { 0x00, 0x3C, 0x40, 0x40, 0x20, 0x7C },   // u
            new byte[] { 0x00, 0x1C, 0x20, 0x40, 0x20, 0x1C },   // v
            new byte[] { 0x00, 0x3C, 0x40, 0x30, 0x40, 0x3C },   // w
            new byte[] { 0x00, 0x44, 0x28, 0x10, 0x28, 0x44 },   // x
            new byte[] { 0x00, 0x1C, 0xA0, 0xA0, 0xA0, 0x7C },   // y
            new byte[] { 0x00, 0x44, 0x64, 0x54, 0x4C, 0x44 },   // z
            new byte[] { 0x00,0x00, 0x06, 0x09, 0x09, 0x06  }   // horiz lines
        };

        public SPI.Configuration conf; 
        public SPI SPI_port;
        public OutputPort RST = new OutputPort(Pins.GPIO_PIN_D9, false);
        public OutputPort DC = new OutputPort(Pins.GPIO_PIN_D8, false);
        public OutputPort BL = new OutputPort(Pins.GPIO_PIN_D7, false);

        public Nokia3310()
        {
            Init();
        }

        void Init()
        {
            conf = new SPI.Configuration(Pins.GPIO_PIN_D10, false, 0, 0, false, true, 1000, SPI.SPI_module.SPI1);
            SPI_port = new SPI(conf);

            Reset();

            Write_Cmd(new byte[1] { 0x21 });
            Write_Cmd(new byte[1] { 0xc0 });
            Write_Cmd(new byte[1] { 0x06 });
            Write_Cmd(new byte[1] { 0x13 });
            Write_Cmd(new byte[1] { 0x20 });

            Clear();

            Write_Cmd(new byte[1] { 0x0c });
        }

        public void Leds(bool On)
        {
            BL.Write(On);
        }

         void Write_Cmd(byte[] Cmd)
        {
            DC.Write(false);
            SPI_port.Write(Cmd);
        }

        void Write_Data(byte[] Data)
        {
            DC.Write(true);
            SPI_port.Write(Data);
        }

        void Reset()
        {
            RST.Write(false);
            Thread.Sleep(200);
            RST.Write(true);
            Thread.Sleep(200);
        }

        public void Clear()
        {
            ushort i;

            Set_XY(0, 0);

            for (i = 0; i < 504; i++)
                Write_Data(new byte[1] {0x00});

            Set_XY(0, 0);
        }

        public void Set_XY(byte X, byte Y)
        {
            Write_Cmd(new Byte[1] { (byte)(0x40 | Y) });  // column
            Write_Cmd(new Byte[1] { (byte)(0x80 | X) });  // row
        }

        public void Write_Char(char c, bool highlight)
        {
            byte line;
            byte ch;

            byte a = (byte)((byte)c - 32);

            for (line = 0; line < 6; line++)
            {
                ch = font6_8[a][line];
                ch = highlight ? ch : (byte)(ch ^ (byte)0xff);
                Write_Data(new byte[1] { ch });
            }
        }

        public void Draw_Bmp_Pixel(byte X, byte Y, byte[] map,
                                byte Pix_x, byte Pix_y)
        {
            ushort i, n;
            byte row;

            if (Pix_y % 8 == 0)
                row = (byte)(Pix_y / 8);
            else
                row = (byte)(Pix_y / 8 + 1);

            for (n = 0; n < row; n++)
            {
                Set_XY(X, Y);
                for (i = 0; i < Pix_x; i++)
                {
                    Write_Data(new byte[1] { map[i + n * Pix_x] });
                }
                Y++;
            }
        }

    }
}

Here a the sample of use (Program.cs) :

using System.Threading;

namespace NetduinoNokia3310
{
    public class Program
    {

        static byte[] AVR_bmp =
        {
            0x00,0x00,0x00,0x00,0x80,0xE0,0xFC,0xFF,0xFF,0xFF,0x7F,0xFF,0xFE,0xFC,0xF0,0xC1,
            0x0F,0x7F,0xFF,0xFF,0xFE,0xF0,0xC0,0x00,0x00,0x00,0xC0,0xF8,0xFE,0xFF,0xFF,0x3F,
            0x07,0xC1,0xF0,0xFE,0xFF,0xFF,0xFF,0x1F,0x07,0x8F,0xCF,0xFF,0xFF,0xFF,0xFE,0xFC,
            0x00,0x80,0xF0,0xFC,0xFF,0xFF,0xFF,0x7F,0x7F,0x78,0x78,0x79,0x7F,0x7F,0xFF,0xFF,
            0xFC,0xF0,0xC1,0x07,0x1F,0xFF,0xFF,0xFE,0xFC,0xFF,0xFF,0xFF,0x1F,0x07,0xC1,0xF0,
            0xFE,0xFF,0xFF,0x3F,0x0F,0x0F,0x7F,0xFF,0xFF,0xFF,0xFF,0xE7,0x07,0x03,0x01,0x00,
            0x02,0x03,0x03,0x03,0x03,0x03,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x03,
            0x03,0x03,0x03,0x03,0x00,0x00,0x03,0x1F,0x3F,0x1F,0x07,0x00,0x00,0x02,0x03,0x03,
            0x03,0x03,0x01,0x00,0x00,0x00,0x00,0x03,0x03,0x03,0x03,0x03,0x03,0x00,0x00,0x00
        };

        public static void Main()
        {

            Shield.Nokia3310 LCD = new Shield.Nokia3310();

            LCD.Leds(true);

            byte i, j;
            for (i = 0; i < 6; i++)
            {
                for (j = 0; j < 14; j++)
                {
                    LCD.Set_XY((byte)(j * 6), (byte)i);
                    LCD.Write_Char((char)((byte)(i * 14 + j + 32)), true);
                }
            }

            Thread.Sleep(5000);

            LCD.Clear();

            LCD.Draw_Bmp_Pixel(20, 1, AVR_bmp, 48, 24);

            Thread.Sleep(5000);

            LCD.Leds(false);

        }

    }
}

It would nice to have a Netduino bmp instead of AVR

Enjoy,
Pascal