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.
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);
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?
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.
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
/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)
/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)
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.
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.
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
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
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.