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

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

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

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

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

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

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 ?

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

Hello, What kind of hardware/software do we need to be able to debug firmware using VS like this: 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

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

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

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

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

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 !!

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.

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

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

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

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

Yes, each block is 8KB. There are 64 blocks total (8KB * 64KB = 512KB).

Does that help at all? It sounds like you had already figured that out though...

When making firmware modifications, we typically compile the image--and then measure the size of TinyBooter (using SAM-BA) and the size of TinyCLR (using MFDeploy). Then we re-adjust the block layout, recompile (with /t:rebuild), and reflash.

Chris

Thanks Chris,

And :
BLOCKTYPE_BOOTSTRAP = TinyBooter size
BLOCKTYPE_CODE = TinyCLR size
BLOCKTYPE_DEPLOYEMENT = Free memory for managed code size

But what's both *GCC_SPECIAL* blocks ? Do I need to change his size, and if yes, based on what ?

Many thanks,
Pascal

How can I detect the firmware version on my Netduino board ?

Thanks,
Paolo

Using MFDeploy.exe, select USB -> Netduino_Netduino, in Menu Target -> Device Capabalities,
The "SolutionReleaseInfo.solutionVersion" show the Netduino firmware version,

Pascal

Please have a look at the following post which contains updated blockrange for GCC 4.4. The *GCC_SPECIAL* symbols are used to differentiate the block range layout between GCC and the other compilers - when compiling with GCC, there is more blocks for bootstrap, because the generated code is twice as big.

Many thanks,

I'm finally successful with a firmware and TinyBooterDecompressor compiled with GCC 4.2.
And a simple blink led application works. For some of you, it's not a huge step, but for me, it was a long way.

But I have only 32k for C# project Without any new firmware feature.
And, I don't know why, the device capabilities function on MFDeploy reply Not Supported (any idea ?),
When I will have time, I will write a little document with my experience, because my feeling is that we don't have enought document about that, it's not realy trivial. Perhaps a little tools to manipulate both files needed to modify would be useful.

Thanks again,
/pascal

And, I don't know why, the device capabilities function on MFDeploy reply Not Supported (any idea ?),

Forget this remark, I have tested this function with TinyBooterDecompressor only , with no firmware,
It works know,
Pascal

Excellent video, Thanks for sharing, When I work with serial port and programming, I use this powerful free tools: http://www.der-hammer.info/terminal/ Pascal