Go Down

Topic: Arduino NG and SPI? (Read 5469 times) previous topic - next topic


Has anyone used the Arduino NG (newer rev USB) with SPI?  I'm becoming certain that there's a problem with my board, and I don't know if it's a bad board, something in the design, or just pilot error.

It isn't the code and I'm pretty sure it isn't pilot error because things work correctly when I use an Arduino-bootloader equipped ATmega8 on a breadboard.

Is the resistor on pin 13 attenuating too much of the signal to use it for an SPI clock?  The tutorials use it with the old USB boards.

It sure would be nice to have the schematic for the NG.....



Nov 17, 2006, 08:21 am Last Edit: Nov 17, 2006, 08:26 am by Daniel Reason: 1
see http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1158859542
seems the only electrical difference with the NG is a new LED.  


actually i forgot to mention the new USB chip

we used the new ft232r which doesn't require the external oscillator that was very prone to faults

there is also an hidden improvement... in the future by adding  small resistor to the board, arduino
IDE will be able to reset the board for you while programming... good if your board is buried deep inside a project

we also used the new lead free ROHS process which is good for you and the environment :) :)



Well, I've played around a fair amount, and there is in fact a problem with SPI on the Arduino NG.

My first problem was that I could not get an SPI device (specifically the DS1722 temperature sensor) to talk to the Arduino NG.  Soon after I tried to burn the bootloader to a bare ATmega8 using the NG board's ICSP connector.  This was also unsuccessful.

I moved over to a breadboard with minimal components and programming the bootloader worked fine (after some trials with building a programmer, but that's another story).  I then attached the DS1722 and it worked as expected.

At this point I was on hold for a while, until the recent posting of the NG schematic.  I have since replicated the arrangement of R7, R13, and the LED attached to pin 19 of the ATmega (digital pin 13 on the Arduino NG) on the breadboard, with the result that SPI communications is broken once the LED is added. If I remove the LED all is well.  Apparently the ~1k ohm worth of attenuation has no ill affect, at least on the circuits I've put together so far.

It seems to me that the addition of the LED on the NG design has broken ICSP and SPI.

I would like to hear if others have tried to use the ICSP header or tried to attach an SPI device to the standard pins, and have someone confirm (or refute:) my experiences.



I've been able to burn the bootloader onto chips in an Arduino NG with the ICSP header.  I'm using an AVR-ISP (original version) with a Keyspan USB-to-serial adapter.  Which programmer are you using?


I've been able to burn the bootloader onto chips in an Arduino NG with the ICSP header.

It's possible that I'm doing something wrong, but when I breadboarded it I had no trouble burning the bootloader on 5 or 6 ATmega8s - each one worked on the first try.

Which programmer are you using?

I don't have the schematic in electronic form, but it's this one


minus most of the resistors and caps.

Since I'm a Mac guy, I'd like to build (or even buy :| ) a serial port version, but I've been just using a windoze box at work for now.



I need to verify what I said about burning via ICSP not working.  Analyzing the circuit makes me think it should work OK; it's possible that I have not tried ICSP with a known good programmer.

The SPI issue is definitely there, though.  A bit of circuit analysis indicates that output pin 13 will never see more than about 2V, because the LED is like a zener diode and clamps the voltage.  R13 should be tied directly to the Atmel's pin 19 (i.e., on the other side of R7) to avoid this scenario.

I may mod the board (remove R13 and connect J3-6 to IC1-19 via a 470 ohm resistor) to see if it behaves as I expect.



I may mod the board (remove R13 and connect J3-6 to IC1-19 via a 470 ohm resistor) to see if it behaves as I expect.

Turns out to be a bit easier than this.

Simply remove R13 and reattach it to the right hand side (high side) of R7 and to the righ hand pad used originally.  The final orientation will be rotated 90 degrees.  Here's a (rather large) picture:

http:// http://www.eng.uah.edu/~jdw/avr/arduino_r13_mod.jpg

This mod fixed my problems with SPI devices attached to the Arduino pins 10-13.

Thanks to a buddy of mine for both figuring out the easy mod and for the picture.

I highly recommend this change for future revisions of the Arduino NG boards.



I should also note that this doesn't just affect SPI - any device that expects 5V TTL signals will not work correctly due to this problem.



I believe we're removing the LED on pin 13 from future boards to fix this problem.


I found this thread based on a thread I had posted on the Spark Fun Electronics forum here:


I was having trouble connecting an accelerometer break-out board for the LIS3LV02DQ over SPI. By itself, it worked fine. But, when I put a second device on the SPI in parallel, the LIS3LV02DQ started sending spurious, but consistent, data. (By that I mean that the data was wrong, probably off a bit or two or three, but consistently so. The "who am i" register is supposed to send 0x3A and would only send 0x30 or 0x38 when SPI for the device went wrong.)

If I connect the LIS3LV02DQ "closest" in parallel to the Arduino pin 13 (the SPI Clock), it works perfectly. With a second device (a DS1306 RTC) also in parallel, the LIS3LV02DQ only worked if I had a jumper from Arduino pin 13 to the LIS3LV02DQ clock in, _then_ to the DS1306 clock in. The DS1306 worked in either arrangement.

Based on this thread, I would normally suspect this issue with pin 13, but I have an older Arduino without the LED there. But, I'm still suspicious of an electrical design issue there, perhaps in combination with the LIS3LV02DQ being especially sensitive to a weak clock. (BTW the LIS3LV02DQ is a 2.6-3.6v device -- perhaps a weak clock, sunk even further with high impedence inputs nearby, tosses the device into the weeds.)



Does the Arduino Mini exhibit this problem?


Go Up

Please enter a valid email to subscribe

Confirm your email address

We need to confirm your email address.
To complete the subscription, please click the link in the email we just sent you.

Thank you for subscribing!

via Egeo 16
Torino, 10131