I had a program running on Netduino (Plus) and it was working for months. The device is turned on and off occasionally. After a while it stopped working. I guess the program got wiped out of memory or got corrupted somehow. I reloaded the program and the system is working now. I wonder if Netduino is not connected to power, doest the program over time get off the memory? 1) What kind of memory Netduino use to store memory? 2) Is it possible that this memory is wiped over time? 3) Is it possible that static electricity is the cause? 4) Is it possible that accidental tripping of reset make the memory go away? It's unlikely but I can imaging a static charge on reset ping of N+ (thought it's not connected to my main board) makes a reset. 5) I used to have out of memory as garbage collector couldn't keep up but that should not change the actual memory of program, right? This doesn't seem to be the cause since wiping/damage of the program is permanent. Thoughts?

Wow, then it's a lot of problem. Another option I had in mind becomes more relevant now: 1) Getting the new Fez Cerbuino Bee: http://www.ghielectr...log/product/351 for $40 then it works out of the box with $35 Ethernet: http://www.ghielectr...log/product/333 according to the former link also it's easy to do WiFi (using WiFi-Serial bridge solution of XBee Socket which is already there plus Roving Networks RN-XV Module for $35: http://www.sparkfun.com/products/10822) So for total $75 I get fast MCU + Ethernet (or the same price for WiFi) ! It has USB/SD Card/Power Barrel/USB Host etc...

So what's the best way to get Ethernet assuming direct socket to NGO is not available now and Shield is the way to go? I'm sure many have used a solution to make a Netduino Plus out of a Netdiuno and there is a rather standard answer for this now. Also correction: Looking close in MCU datasheet I see there are three SPIs: SPI1 can communicate at up to 37.5 Mbits/s, SPI2 and SPI3 can communicate at up to 21 Mbit/s. T Now I wonder if solution (1) above messes up with SPI1? If that's the case I lose the faster one

I wouldn't bet on it. The problem with most networking solutions is that they require specific firmware as well.
Even GHI is experiencing that. Thus the note: Currently, this module works only with FEZ Spider Main board.. It doesn't work with other gadgeteer mainboards.

Sounds like that.

Upside is that this is real WiFi not a Wifi-Serial bridge.

It's crazy, I bought an external WiFi-Ethernet Bridge with extra 4 ethernet ports and it has webpage for setup, antennas, WEP etc. for ~$50 so in practice it may be better to have an ethernet convertor and lose one SPI then use an external box like this. Only downside is that it takes more space...

What about: $15: http://www.ghielectr...log/product/314 It seems to be exact same thing as "Sytech Designs ZigBee Module". I see $ price instead of UK Pound

Here is another thing I found that works for Fez Spider: http://www.ghielectr...log/product/282 Is there a chance this works with Netuidino Go with small changes? http://www.ghielectr...log/product/282 It's pricy: $99

Hello, 1) What is the best Ethernet solution for Netduino Go? I could find this socket solution: http://www.ghielectr...log/product/333 Downside is that one SPI is used now. Go has two SPIs, correct? I heard from Chris that speed is different so I need to reserve the faster SPI for my own use (not this ethernet)! 2) I could think of adding Arduino Ethernet Shields on top of Netduino Go Shield Base. 2.A) Do these work out of the box? 2. How does this solution compare to above (1) without using the shield base? Seems like this way I still get two SPI but I needed extra Shield Base. A) http://www.sparkfun.com/products/9026 What about this ethernet shield + PoE? http://www.sparkfun.com/products/10864

Looking great. How does this compare to adding a WiFi shield to Shield Base? In general of course not using Shield Base should help preserve a socket, yes? First using your own solution: A) http://forums.netdui...-module-driver/ $34.95 http://forums.netdui...-module-driver/ $19.95 http://www.sparkfun.com/products/9976 " This module is in simple terms, a serial-to-tcp-bridge. It can handle one tcp socket at the same time, but for many applications this is exactly enough! " is fine with me it's just lower performance. Second: http://littlebirdele...uino-802-11-g-n $90 http://www.sparkfun.com/products/9954 $90 http://bit.ly/KNg4zt $51 Thanks

Also, does RN-VX WiFi let you have a WEP/... encryption (user/pass)?

Fantastic ! What's the board that you had "RN-VX WiFi" on top? What type Socket Type/Protocol does it use to talk to Go? Thanks

I find it a bit tedious too, if it really doesn't want to cooperate
I pull out the usb
Tell VS to Deploy app
Wait 5 seconds
plug in the usb

Exactly ! ) I found out that's the best path after doing it 200,300 times. Very interesting that you found the same thing.

However, sometimes I have to do fail, cancel, retry. Yet other times even this gets %100 stuck and doesn't go forward after a minute.

Perhaps timing should be kinda accurately 5 seconds...

Hello, I frequently run into cases where MS Visual C# gets stuck or delays deployment where the message is: "Preparing to deploy assemblies to the device." My solution is to disconnect USB and reconnect. Sometimes it fails and I redo, sometimes it simply works and reboots netduino and we are done. Overall this process is very slow and gets on people's nerves. I don't see this in forums being addressed. Is there a solution for this? My firmware and Visual C# are the latest stable versions. Thanks

Hi Chris,

I manually did that but time would tell if soldering new items on bottom side works or undoldering damage connections in the via/holes.

Another question. Is it possible to get PCB file of Netduino? (or similar)

I tried a dozen times printing a PCB and putting Netduino Plus on it to get distances correct to match the second board but in the end still I get 0.05 inch distance off.

I need to know power, ethernet distance from side connectors.

Thanks

Hi orange,

Have you tried using a desoldering gun? I've taken the headers off of a Netduino before.

I wish there was a good way to make you a special board with the parts missing

Chris

Hi, I'm integrating Netduino in a project by putting it on top of another board (larger board). I had a few solutions however none are as elegant as: - Receiving a Netduino Plus with everything installed except side connectors (hopefully also Ethernet and power barrel) then I solder similar connectors with longer pins which then is soldered to the second board. Right now I use another good solution however that's not ideal. I put longer connectors on the main board (connectors with longer pins) then push the Netduino Board from below. It works but Netduino is below the main board, I want to have it on top. Another solution I came up with is to reverse Netduino (bottom-up) and push it on headers with long pins on the main board. This is the solution I go next time if there is no Netduino Plus minus connectors are found. I tried having the connectors out (manual work with solder iron), it is messy and connectors may not be reliable for production. Thoughts?

I managed to make it work. Information on undocumented and strange behavior of API from this page was useful: http://wiki.netduino...-WriteRead.ashx

Thanks Charles, I ended up writing the code (with a lot of trial and error) from scratch. This page was quite helpful on explaining undocumented (and strange) behavior of API: http://wiki.netduino...-WriteRead.ashx

The link Stefan provided uses I2C (and works very well, I have implemented it), I understand Orange wants to use SPI instead for communication with the accelerometers. I searched a bit further, and found some references, but they are generally questions from people struggling with it. I did find libraries for the mbed, both an I2C and SPI version at http://mbed.org/cook...5-Accelerometer, maybe that helps.

When I read register zero two times in the beginning of the program:

- The second time read always gives correct Device ID now!

- The first time read returns a value which I wrote to DATA_FORMAT register last time in previous compilation (before reboot) !

While this helps passing this point, afterwards I get non-sense numbers. So issue still stands.

I'm doing exact same steps as Arduino. The only difference is that in Arduino code, we manually set Chip Select to HIGH and LOW: http://www.sparkfun.com/tutorials/240

I assumed that in Netduino case this is managed by the framework (SPI API) after each read/write. However, this may not be the case since Netduino has no idea if I'm doing two writes with the first write being register number and the second write being value unless it internally keeps a state and knows odd write are register number and even writes are values. Which kinda hints to above odd/even issue.

At this point the code is so simple that I suspect a bug in the firmware. There shouldn't be a bug in wiring as suggested before since double read always gives correct device ID.

This is Arduino code for reference:

//Parameters:
//  char registerAddress - The register to write a value to
//  char value - The value to be written to the specified register.
void writeRegister(char registerAddress, char value){
  //Set Chip Select pin low to signal the beginning of an SPI packet.
  digitalWrite(CS, LOW);
  //Transfer the register address over SPI.
  SPI.transfer(registerAddress);
  //Transfer the desired register value over SPI.
  SPI.transfer(value);
  //Set the Chip Select pin high to signal the end of an SPI packet.
  digitalWrite(CS, HIGH);
}

Is there a simple way to bypass .NET framework and simply use Arduino code on Netduino? I'm spending a long time on simply a few lines of code without a way to debug in more details or a way to isolate the problem more.

Hi Chris,

The only hint I have is that without changing anything (code or wiring), I compile once and it fails to give Device ID (gives zero) then next time I compile it give exact correct number 0xE5. It happens after 10+ times testing. There is no lose wire that can make it exactly odd/even times correct incorrect. This is when using a Digital output for Chip Select.

Unfortunately no logic analyzer. So issue is software. I double checked with the documentation and settings are correct for idle high and falling edge. Chip Select is clearly inverted so all boolean configuration parameters are correct.

SCLK should idle high during a period of no transmission. SDI and SDO are the serial data input and output, respectively. Data is updated on the falling edge of SCLK and should be sampled on the rising edge of SCLK.

Hi orange,

Do you have a logic analyzer by any chance? That's usually how I debug these things. It's almost always an issue of SPI configuration (or wiring up the signals or power wrong). I've done it wrong a few ways

Chris

Also changed configuration to use falling-edge (instead of rising edge) in case I have mistaken, the same with idle on high CLCK, lowering frequency to 400KHz, adding delays 0 -> 1 in config. I see sample code that people use SPI without using any GPIO to do Chip Select (with Shift Register not Sensors). Any suggestion is welcome...

Would it help to upgrade firmware? How can I find out what firmware I have and an update is needed?

I tried other things e.g. changing physical wires, changing sensor, closing and re-opening the IDE, etc but the issue of Device ID still stands.

Would it help to upgrade firmware? How can I find out what firmware I have and an update is needed? I tried other things e.g. changing physical wires, changing sensor, closing and re-opening the IDE, etc but the issue of Device ID still stands.

Correct. It compiles fine.

Actually it should be:

Pins.GPIO_PIN_D0

Thanks for looking into this. Below was a typo.

NO, the original wiring is correct and it matches all documents (two above) and what you say below.

When reading http://www.sparkfun....ter/ADXL345.pdf page 8 Figure 4. 4, I see:

/CS (pin 7 on the ADXL345, which must to a random GPIO for Netduino indeed)
SDI (also known as SDA/SDIO, pin 13 on the ADXL345, which must go to netduino MOSI; Netduino pin D11)
SDO (also known as ALT ADDRESS, pin 12 on the ADXL345, which must go to netduino MISO; Netduino pin D12)
SCLK (also known as SCL, pin 14 on the ADXL345, which must go to netduino SPCK; Netduino pin D13)

So you switched pins 11 and 12.

Thanks for the reply. Both seem to be acting the same. Both compile and both are available in auto complete. Both randomly fail Device ID between each compile.

I changed it to suggested

Pins.GPIO_Pin0

since it matches documentation to be on safe side.

but the same issues exist.

It's safer to use your suggestion due to my original reference to Wiki page: http://wiki.netduino...figuration.ashx and http://wiki.netduino...SPI.ashx?HL=spi

Orange, to solve one problem, just change:

Cpu.Pin.GPIO_Pin0

To:

Pins.GPIO_Pin0

Basically, the Pins enumeration is a Netduino remapping of the abstract Cpu.Pin set exposed by the Micro Frameowrk.

I know, it's confusing...
Cheers

Hi,

Connections are similar in Netduino and Arduino (as demonstrated in above article).

To be more specific:

ND 13 SCL, ND 12 SDA, ND 11 SD0, ND Digital 0 (GPIO 0, also tried 1,2 and 10 and matched the SPI.config) to CS, ND 3V3 to VS, ND 3V3 to VIO, ND Gnd to Gnd

It's probably not an issue with physical connections. It randomly changes on multiple compiles and also hack of connecting CS to VCC then Gnd works for passing the initial Device ID check. Not helpful for X/Y/Z reads.

Hi Orange,

When using SPI mode, can you tell us how you've got it connected? To which pins on the netduino?

I'm trying to use SPI and talk to ADXL345. I can do that with I2C with no problem so I know the sensor is working properly.

There is an article for Arduino and I'm trying to the the same with Netduino (Plus).

http://www.sparkfun.com/tutorials/240

Issue 1) Unfortunately, the SPI.Configuration doesn't work as intended.

The first issue I have is that when I read Device ID it's incorrect but if I manually VCC then GND the Chip Select (inverted) actually works to this point and I can read correct Device ID ! GPIO_Pin0 didn't work neither GPIO_Pin1..GPIO_Pin10 in below configuration as GPIO.

Here is a simple code:

            SPI.Configuration config = new SPI.Configuration(
                        Cpu.Pin.GPIO_Pin0, // I have Chip Select of Sensor connected but it didn't work. See below tests
                        false, // CS is inverted to it's active on low
                        0, // tried both 0 and 1 
                        0, // tried both 0 and 1
                        true, // High on Idle. See figure 37 and 38 in here: http://www.analog.com/static/imported-files/data_sheets/ADXL345.pdf, also see http://wiki.netduino.com/SPI-Configuration.ashx
                        true, // Seems to be stable on rising edge. See figure 37 and 38 in here: http://www.analog.com/static/imported-files/data_sheets/ADXL345.pdf, also see http://wiki.netduino.com/SPI-Configuration.ashx
                        500, // 500 KhZ, it can be upto 2MHz
                        SPI.SPI_module.SPI1
                        );

            SPI accel = new SPI(config);

            Byte[] wBuff = new Byte[1];
            Byte[] rBuff = new Byte[1];

            wBuff[0] = 0x00;
            accel.WriteRead(wBuff, rBuff);

            Debug.Print("Reading device id from register: " + wBuff[0]);
            Debug.Print("Received device id: " + rBuff[0]);

2) Second issue is after passing this point by VCC/Gnd hack is that data read for X/Y/Z Axis doesn't make sense (changes randomly, stays at zero or has specific numbers) so there is something I'm missing but several tries didn't help. Again, the sensor works well in I2C mode and change of sensor didn't help, wiring is simply so issue should be software, register settings etc.

Here is the code:

            //Put the ADXL345 into full resolution(+/- 2g) mode with the DATA_FORMAT register.
            wBuff[0] = DataFormat;
            accel.Write(wBuff);

            // 0x08 for full resolution (+/- 2g)
            wBuff[0] = 0x08;
            accel.Write(wBuff);

            //Put the ADXL345 into Measurement Mode by writing 0x08 to the POWER_CTL register.
            wBuff[0] = PowerControl;
            accel.Write(wBuff);

            wBuff[0] = 0x08;
            accel.Write(wBuff);

            // Setting FIFO to stream 0x80 also tried no FIFO 0x00 (commenting out following)
            wBuff[0] = FifoStatus;
            accel.Write(wBuff);
            wBuff[0] = 0x80;
            accel.Write(wBuff);


            


            double yAxisGs, xAxisGs, zAxisGs;
 
 
                    Thread.Sleep(100);

                    yAxisGs = 0.0; 
                    xAxisGs = 0.0; 
                    zAxisGs = 0.0; 

                    //
                    Byte[] rBuff6 = new Byte[6];
                    Byte[] wBuff6 = new Byte[6];

                    //wBuff6[0] = 0xFF;
                    //wBuff6[1] = 0xFF;
                    //wBuff6[2] = 0xFF;
                    //wBuff6[3] = 0xFF;
                    //wBuff6[4] = 0xFF;
                    //wBuff6[5] = 0xFF;

                    wBuff[0] = DataX_0 | 0x80 | 0x40; // Also tried without 0x80 (read mode) or (0x40) multiple-byte read mode
                    accel.WriteRead(wBuff6,0,6,rBuff6,0,6,0);

                    const double scale = 0.0039d; // Scale for 2G, full scale

                    xAxisGs = (rBuff6[0] | rBuff6[1] << 8) * scale; // I tried  (rBuff6[0] + rBuff6[1] *256) * scale to make sure it's not a logic, data type issue between byte, uint and double.
                    yAxisGs = (rBuff6[2] | rBuff6[3] << 8) * scale;
                    zAxisGs = (rBuff6[4] | rBuff6[5] << 8) * scale;


                    Debug.Print("x received data is " + xAxisGs);
                    Debug.Print("y received data is " + yAxisGs);
                    Debug.Print("z received data is " + zAxisGs);