Two devices can use the SPI bus as long as they each have their own chip select pin, correct?
In this case I have a DeadOn RTC from Sparkfun on 11-13, CS is 8, and I'm running into issues incorporating an Ethernet shield.
Thanks.
Two devices can use the SPI bus as long as they each have their own chip select pin, correct?
Correct, as long as they conform to the standard and tri-state MISO when not selected.
What CS pin does the Enet shield use? I've never used one but there always seems to be problems with it sharing the SPI bus.
Rob
Graynomad:
Correct, as long as they conform to the standard and tri-state MISO when not selected.
Let's be careful. SPI is a quasi-standard.
SPI is a quasi-standard.
True and there are the different modes as well. I've used the W5100 (Ethernet shield chip) with an RTC (DS3234) and a microSD card holder before and they all played just fine together, but I did use proper level conversion for the SD and the Ethernet shield does not.
Rob
Enet shield uses pin 10 as CS, which is standard.
The problem I'm having is that the IP constantly refreshes gibberish. It shows the correct IP during setup(), but then after RTC_init() is called, it no longer works.
Heres my sketch, which will probably make this into a "programming questions" thread:
Any ideas why its not working?
Thanks.
vulture2600:
Enet shield uses pin 10 as CS, which is standard.
What standard?
vulture2600:
Any ideas why its not working?
480 bytes of memory are consumed by one array, plus all of the const arrays throughout.
Wrap your "prints" with the F() macro.
Dont they all use pin 10 as CS? I thought thats how it was.
I know they also use pin 4 for the SD card CS, which is why I have it set to HIGH, but it made no difference.
As far as running out of memory, the rest of the sketch works great without the ethernet code.
480 bytes? I calculate 60. 30 spots, 2 bytes each.
Which prints should I wrap F() with? All of them?
vulture2600:
As far as running out of memory, the rest of the sketch works great without the ethernet code.
Great clue you're running out of RAM.
vulture2600:
480 bytes? I calculate 60. 30 spots, 2 bytes each.uint16_t val[3][10] = {
16 * 3 * 10 = 480 bytes
vulture2600:
Which prints should I wrap F() with? All of them?
All of them.
Great clue you're running out of RAM.
I should rephrase: It works great as is, except for the ethernet code doesnt work. Its running right now.
uint16_t's use 16 BITS, not bytes. at least that's the impression I was under.
I will try F()'s around everything. Thanks.
I still thing RTC_init() has something to do with it. That code is towards the end of the sketch.
I tried wrapping F()'s around about half of the sketch. Its making memory usage climb steadily as I go. I've compiled about every 5 F()'s.
It also doesnt work when you just print a variable, ex: lcd.print(variable);
Your thoughts?
Scratch that. I read the link you posted again. It uses progmem, but keeps the following out of ram. Makes more sense now.
It also explicitly says it will not work with data you want to change, aka variables.
Moderators:
Can this be moved to the Networking category?
Thanks.
vulture2600:
I should rephrase: It works great as is, except for the ethernet code doesnt work. Its running right now.
When adding or removing seemingly unrelated code causes unexpected behavior changes, that is the strong clue that you've run out RAM.
vulture2600:
uint16_t's use 16 BITS, not bytes. at least that's the impression I was under.
Yeah, my bad. Should have been 2 * 3 * 10 = 60 bytes.
vulture2600:
I will try F()'s around everything. Thanks.
Its making memory usage climb steadily as I go.
One of the downsides of the F() macro is that there is no optimization. So the same string used through out the program will take up more PROGMEM. So for example in that really long section of Serial.print(" ") calls (which is just begging for a for() loop) each one of those calls will take up some PROGMEM even though it is the same string.
Unless you run out of PROGMEM, it isn't worth doing manual calls to save the space. There is no performance penalty for filling up PROGMEM.
vulture2600:
I still thing RTC_init() has something to do with it. That code is towards the end of the sketch.
If you've run out of RAM, then the call itself isn't the problem.
Thanks for the reply.
When adding or removing seemingly unrelated code causes unexpected behavior changes, that is the strong clue that you've run out RAM.
I would think the whole thing would act erratically if I've run out of ram, not just one function, so I'm not convinced I have.
I'm still leaning on the SPI code within RTC_init() changing modes or doing something that the ethernet shield doesnt like.
Ok so here's my latest sketch:
http://pastebin.com/K4DcUGiK
The issue is still that it shows a valid IP at startup (void setup() ) but then shows 0.0.0.0 when menu #7 is selected.
Other than that, the sketch is working perfectly.
In the past, I had issues with ethernet shields not seating on the ICSP headers correctly and they would always show 0.0.0.0 as an IP. I do not believe this is the case because it shows a valid IP in the beginning. Any thoughts?
vulture2600:
Two devices can use the SPI bus as long as they each have their own chip select pin, correct?In this case I have a DeadOn RTC from Sparkfun on 11-13, CS is 8, and I'm running into issues incorporating an Ethernet shield.
Thanks.
The SparkFun Dead-On RTC pins are:
1 - SS (slave select A.K.A. CS)
2 - MOSI
3 - MISO
4 - CLK (A.K.A SCLK)
5 - SQW (square wave output from RTC chip)
6 - VCC
7 - GND
Attached is my DS3234 driver package along with an Arduino demo. The demo isn't the greatest, but it does show how to access all the stuff in the RTC chip. The driver is very mature and works rock solid.
Nice thing about this driver is that you don't need hardware SPI to access it. You can set any pins to SCK, MOSI, MISO and SS. The amount of data transmitted or received by the RTC is so small that the "slowness" of a bit-bang SPI is irrelevant.
Hope this helps you.
DS3234.zip (6.38 KB)
Forgot to add the README in the ZIP file:
////////////////////////////////////////////////////////////////////
// Pinout of the Sparkfun DeadOn RTC Breakout Board
// Sparkfun item number: BOB-10160
//
// ______________________________
// | SS MOSI MISO CLK SQW VCC GND |
// ||
// | |
// | _____ |
// | / + \ |
// | [ backup ] |
// | [ battery ] |
// | _/ |
// | |
// |____|
//
// Note: See the supplied demo for an easy way to plug this
// breakout board into an Arduino UNO or MEGA2560 without
// the need for a breadboard.
////////////////////////////////////////////////////////////////////
// To setup this driver:
#include <DS3234.h> // include the header
static DS3234 rtc; // create the RTC object
// To use the driver:
// define the 4 pins used by the clock
const uint8_t _CLK = A0;
const uint8_t _MISO = A1;
const uint8_t _MOSI = A2;
const uint8_t _SS = A3;
// define the vars used for getting and setting the time
uint8_t hours;
uint8_t minutes;
uint8_t seconds;
uint8_t day_of_week; // 0=Sun,1=Mon...5=Fri,6=Sat
uint8_t month; // 1=Jan,2=Feb...11=Nov,12=Dec
uint8_t day; // 0 ... 31
uint16_t year; // 4 digit year (i.e. 2013)
// initialize the RTC:
rtc.init(_CLK, _MISO, _MOSI, _SS);
// READ rtc data
day_of_week = rtc.getTime(&hours, &minutes, &seconds, &month, &day, &year);
// WRITE rtc data (i.e. set the clock)
rtc.setTime(hours, minutes, seconds, month, day, year);
// READ an 8 bit byte battery backed SRAM (256 bytes available)
value = rtc.readByte(address); // address 0x00 ... 0xFF
// WRITE an 8 bit battery backed SRAM (256 bytes available)
writeByte(address, value); // address and value 0x00 ... 0xFF
// NOTE: The RTC chip alarms are not supported by this driver
-eof-
This looks awesome. Thanks.
So can I continue to use the RTC on pins 11-13 along with the ethernet shield on the same pins?
vulture2600:
This looks awesome. Thanks.So can I continue to use the RTC on pins 11-13 along with the ethernet shield on the same pins?
You can use the RTC on any pins you wish.