Arduino: Cutting the SDA/SCL traces and rerouting them.

[gildasd]

I'm using an Adafruit datalogging shield and need all 6 analogue inputs.
there are multiple "expert" opinions on how to do this: http://forums.adafruit.com/viewtopic.php?f=31&p=277760
But none are really clear. For example, where does one cut the traces? On the Arduino or shield?
The SDA pins (28 and 27) are connected to A4 and A5 on both the Arduino and the shields. This is  very confusing.



Does anybody have guidance on this before I take the cutter to the traces?

[igendel]

What is the point of this "operation"? There must be a smarter way to achieve any goal than to permanently damage the Arduino board.

[gildasd]

What is the point of this "operation"? There must be a smarter way to achieve any goal than to permanently damage the Arduino board.

For a unclear reason (legacy probably), the V3 revision of the Arduino still runs the I2C signal (SDA/SCL) via the A4 and A5 analogue input pins.
This means that the write to the SD card, the RTC signal and my analogue sensor (1.5V average) are conflicting.

If I had know about this, I might have gone another route for this project (PI?) but I'm past due on this project and I need to hack a solution out...

[michaeliv]

Why not just cut the header pins that plug into the Arduino, you can re-solder them if you need them at any other time.
Anyway definitely don't cut the tracks on the Arduino otherwise you can't use them, which is exactly what you want to do.
Also do you need the RTC ?

[igendel]

Well, the connection between the I2C lines and the "analog" pins 4&5 goes all the way back to the micro-controller itself, so no matter what, you won't be able to talk to the RTC and use these pins as analog inputs at the same time.

In the forum discussion you linked to, someone suggested using a "software I2C". In theory that could work (after some delicate re-routing on the shield), but to my humble experience - maybe I'm wrong here - a software-based I2C will probably fail because it can be too demanding for this micro-controller.

I think a better approach will be to find some kind of analog-switch multiplexer IC, that will allow you to select from external analog inputs at will and read them using a single analog pin on the Arduino. Beware though that the IC itself may effect the signal - read the datasheet carefully!

[gildasd]

Why not just cut the header pins that plug into the Arduino, you can re-solder them if you need them at any other time.
Anyway definitely don't cut the tracks on the Arduino otherwise you can't use them, which is exactly what you want to do.
Also do you need the RTC ?

I've cut the traces on the shield (not the UNO) and bent the pins out. Nothing I can't fix with some solder...
With this mod and running my standard program, the shield does not hang on SD write any-more, the RTC time is correct on the Excel file.
However the readout of pin a4 and a5 is wrong (1023, that means +VCC).
I need the RTC... But it seems this can be achieved by re-routing the I2C signal with "SoftI2C" to digital pin 4 and 8.

Well, the connection between the I2C lines and the "analog" pins 4&5 goes all the way back to the micro-controller itself, so no matter what, you won't be able to talk to the RTC and use these pins as analog inputs at the same time.

In the forum discussion you linked to, someone suggested using a "software I2C". In theory that could work (after some delicate re-routing on the shield), but to my humble experience - maybe I'm wrong here - a software-based I2C will probably fail because it can be too demanding for this micro-controller.

I think a better approach will be to find some kind of analog-switch multiplexer IC, that will allow you to select from external analog inputs at will and read them using a single analog pin on the Arduino. Beware though that the IC itself may effect the signal - read the datasheet carefully!

I'm not sure about your 1st affirmation, jury is still out!

For the software based I2C, I think I need to be modest in my requests and leave "delay 10" in strategic places to give the ATMEL time to catch up.

If I was to redo this project, I would go the Raspberry Pi with the MCP3008 route. But 6 months ago I knew NOTHING about microcontrollers and chose using datasheets (missing the 6 analogue channels is really 4 marketing bullcrap).

Example of my readout:

millis   stamp         datetime                       temp    wind  cube2 cube3 cube4 cube5  vcc  999    1462238779    "2016/5/3 1:26:19"   22.19   351   237   473   1023   1023   5.03 1999   1462238780    "2016/5/3 1:26:20"   22.19   327   236   474   1023   1023   5.03 2999   1462238781    "2016/5/3 1:26:21"   22.19   321   243   473   1023   1023   5.03 3999   1462238782    "2016/5/3 1:26:22"   22.19   319   242   475   1023   1023   5.03 4999   1462238783    "2016/5/3 1:26:23"   22.19   317   242   475   1023   1023   5.03 5999   1462238784    "2016/5/3 1:26:24"   22.19   318   244   475   1023   1023   5.03 7000   1462238785    "2016/5/3 1:26:25"   22.19   318   250   475   1023   1023   5.03 8000   1462238786    "2016/5/3 1:26:26"   22.19   315   249   477   1023   1023   5.03 8998   1462238787    "2016/5/3 1:26:27"   22.19   318   251   480   1023   1023   5.03 9999   1462238788    "2016/5/3 1:26:28"   22.19   317   256   480   1023   1023   5.03

[sleemanj]

For a unclear reason

The reason is perfectly clear, it's right there on page 3 of the datasheet...

[gildasd]

For a unclear reason

The reason is perfectly clear, it's right there on page 3 of the datasheet...

That's pretty clear

[retrolefty]

I'm not sure about your 1st affirmation, jury is still out!

 Jury came in a long time ago. The pins are shared for those analog channels and the two I2C signals. A mega2560 board will solve that pin function conflict.

[sleemanj]

and chose using datasheets (missing the 6 analogue channels is really 4 marketing bullcrap).

If you use a more modern arduino variant which has the 32 pin package QFN/QFP/MLF instead of the 28 pin package DIP, then you get an extra 2 ADC channels, A6 and A7 in Arduino speak.  These are ONLY connected to the ADC, they can't do digitial I/O (nor PWM).  Arduino R3 boards, or at least some copies there of (I don't know about the official one), usually expose these as unpopulated pins somewhere in the middle of the board.

[gildasd]

I'm not sure about your 1st affirmation, jury is still out!

 Jury came in a long time ago. The pins are shared for those analog channels and the two I2C signals. A mega2560 board will solve that pin function conflict.

The MEGA route is obvious now, but I had insufficient knowledge when I started to choose it. It's too late to change.
Hence it's "bodging time"...

and chose using datasheets (missing the 6 analogue channels is really 4 marketing bullcrap).

If you use a more modern arduino variant which has the 32 pin package QFN/QFP/MLF instead of the 28 pin package DIP, then you get an extra 2 ADC channels, A6 and A7 in Arduino speak.  These are ONLY connected to the ADC, they can't do digitial I/O (nor PWM).  Arduino R3 boards, or copies there of, usually expose these as unpopulated pins somewhere in the middle of the board.

Darn, that seems to be the case on the MICRO, not on the full size UNO... Too late sadly!

[retrolefty]

I'm not sure about your 1st affirmation, jury is still out!

 Jury came in a long time ago. The pins are shared for those analog channels and the two I2C signals. A mega2560 board will solve that pin function conflict.

The MEGA route is obvious now, but I had insufficient knowledge when I started to choose. It's too late to change.
Hence it's "bodging time"...

 Roger that, you do what you have to do. 

With Asian mega2560 boards available for under $10 I would think the it a better 'starting board' then the Uno.

http://www.ebay.com/itm/Keyes-ATMega2560-16AU-CH340-Mega-2560-R3-Controller-board-for-Arduino-/131679238724?hash=item1ea8b1ba44:g:OKsAAOSwYaFWc3dF

[sleemanj]

Darn, that seems to be the case on the MICRO, not on the full size UNO... Too late sadly!

Wouldn't surprise me if the official arduino R3 doesn't have them broken out.  But various clones from the usual places do...



of course, no good if you are in a hurry to do your project.

[igendel]

If you use a more modern arduino variant which has the 32 pin package QFN/QFP/MLF instead of the 28 pin package DIP, then you get an extra 2 ADC channels, A6 and A7 in Arduino speak.  These are ONLY connected to the ADC, they can't do digitial I/O (nor PWM).  Arduino R3 boards, or at least some copies there of (I don't know about the official one), usually expose these as unpopulated pins somewhere in the middle of the board.

A6 and A7 pins exist on variants such as the Arduino Pro Mini, but are pretty rare on a shield-compatible boards (the yellow board in the picture is actually the first time I see them!)

[gildasd]

Darn, that seems to be the case on the MICRO, not on the full size UNO... Too late sadly!

Wouldn't surprise me if the official arduino R3 doesn't have them broken out.  But various clones from the usual places do...
of course, no good if you are in a hurry to do your project.

I'm wary about clones, this is for a Uni project, and some of professors can give you a hard time with non OEM stuff because of intellectual property brouhaha...
So an non Arduino made Arduino asking for trouble and would need 10 pages of explanation on open source hardware etc.
For example, my software list only includes open source (KIcad, Libreoffice etc) to avoid having to provide serial numbers.

[gildasd]

If you use a more modern arduino variant which has the 32 pin package QFN/QFP/MLF instead of the 28 pin package DIP, then you get an extra 2 ADC channels, A6 and A7 in Arduino speak.  These are ONLY connected to the ADC, they can't do digitial I/O (nor PWM).  Arduino R3 boards, or at least some copies there of (I don't know about the official one), usually expose these as unpopulated pins somewhere in the middle of the board.

A6 and A7 pins exist on variants such as the Arduino Pro Mini, but are pretty rare on a shield-compatible boards (the yellow board in the picture is actually the first time I see them!)

Found on http://www.arduino.cc/en/Reference/PortManipulation:

PORTC maps to Arduino analog pins 0 to 5. Pins 6 & 7 are only accessible on the Arduino Mini

    DDRC - The Port C Data Direction Register - read/write
    PORTC - The Port C Data Register - read/write
    PINC - The Port C Input Pins Register - read only

[gildasd]

Working on trying to reroute the SDA/SCL via SoftI2Cmaster.
THe shield traces are cut and, the pins bent, new two pin header on the SDA/SCL contacts on the shield.
Trying to use digital pin 2 (pcint18) and 8 (pcint0):

Code: [Select]

#include "RTClib.h"
#define SCL_PIN 2
#define SCL_PORT PORTD
#define SDA_PIN 7
#define SDA_PORT PORTB
#include <SoftI2CMaster.h>No errors so far!

[gildasd]

Giving up...
The vaunted 6 analogue inputs are pure marketing (a lie) and I can't do anything about it.
Luckily my sensors are "push pull" so I can interpolate from two in a cross.
But I lose the averaging out and some data quality of having 4.

Pissed off at having been "marketed" at by Arduino and Adafruit.
It's duckling stupid, I would have simple gone the MEGA or MINI route from the start had they not "marketed".

[SL4P]

I'm not a big fan of how Arduino has handled the explosion of 'vague' information, but you may find some ideas  on remapping the pins you're using in the pins.arduino.h (header) file - to remap the pin assignments of your 'standard' Arduino board...

C:\Program Files (x86)\Arduino\hardware\arduino\avr\variants\standard
There are \folders for all the other standard Arduino boards - one level up.

[gildasd]

I'm not a big fan of how Arduino has handled the explosion of 'vague' information, but you may find some ideas  on remapping the pins you're using in the pins.arduino.h (header) file - to remap the pin assignments of your 'standard' Arduino board...

C:\Program Files (x86)\Arduino\hardware\arduino\avr\variants\standard
There are \folders for all the other standard Arduino boards - one level up.

If I did that, would the header shield not be lost about what pin does what?

[SL4P]

No... the header specifies the pin assignments wrt the pin 'names', so you can move things around quite a bit.  Many pins are multi-purpose, and the Arduino default is to expose the most likely combination of functions for hobbyists.
I'm certainly no expert, but there are a couple of other files in the \hardware\avr branch that I've used some time ago, which manipulate the breakout of functions for the different chips and board layouts.

For more accurate info, it may be worth googling Arduino pin function mapping...

[gildasd]

No... the header specifies the pin assignments wrt the pin 'names', so you can move things around quite a bit.  Many pins are multi-purpose, and the Arduino default is to expose the most likely combination of functions for hobbyists.
I'm certainly no expert, but there are a couple of other files in the \hardware\avr branch that I've used some time ago, which manipulate the breakout of functions for the different chips and board layouts.

For more accurate info, it may be worth googling Arduino pin function mapping...

Mistyped, not the header, the datalogging shield that I slap on top, it's waiting for I2C via a4 and a5.

[SL4P]

If you're not keen on looking at function reassignment on the Arduino, then a soft implementation of I2C is fairly trivial (many references in C online), and will solve your conflict easily on any spare digital pins. 
Don't forget the 4K7 pull-ups for the second I2C buss !

[gildasd]

If you're not keen on looking at function reassignment on the Arduino, then a soft implementation of I2C is fairly trivial (many references in C online), and will solve your conflict easily on any spare digital pins. 
Don't forget the 4K7 pull-ups for the second I2C buss !

Can you recommend a thread/page? I've been sifting through a lot and most of what I've read seems to typed by code butchers that don't get around to finishing it...
And the butcher has 1000 cousins that all have variations that all are incomplete.
I'm not asking you do anything more than to indicate what cliff I should jump off 

[SL4P]

The library you mentioned earlier looks pretty good, and is designed for the Arduino...
http://playground.arduino.cc/Main/SoftwareI2CLibrary

The example down the bottom of that link tells you most you need to know to get started...
Once you get that inline with your code, change the I2C address to that for your shield, and rename the BMAxxx to whatever you like for your device.
Of course the specific read & write functions are specific to your device and functions required in your program.

[gildasd]

The library you mentioned earlier looks pretty good, and is designed for the Arduino...
http://playground.arduino.cc/Main/SoftwareI2CLibrary

The example down the bottom of that link tells you most you need to know to get started...
Once you get that inline with your code, change the I2C address to that for your device, and rename the BMAxxx to whatever you like for your device.
Of course the specific read & write functions are specific to your device and functions required in your program.

On a total tangent, probably end up you pointing a screen and laughing at my expense.
- The read out on pin a4 a5 is high, because the RTC is using it.

Code: [Select]

  // connect to RTC
  Wire.begin(); 
  if (!RTC.begin()) {
    logfile.println("RTC failed");
#if ECHO_TO_SERIAL
    Serial.println("RTC failed");
#endif  //ECHO_TO_SERIAL
  }used a bit later as:

Code: [Select]

// fetch the time
  now = RTC.now();
  // log time
  logfile.print(now.unixtime()); // seconds since 1/1/1970
  logfile.print(", ");
  logfile.print('"');
  logfile.print(now.year(), DEC);
  logfile.print("/");
  logfile.print(now.month(), DEC);
  logfile.print("/");
  logfile.print(now.day(), DEC);
  logfile.print(" ");
  logfile.print(now.hour(), DEC);
  logfile.print(":");
  logfile.print(now.minute(), DEC);
  logfile.print(":");
  logfile.print(now.second(), DEC);
  logfile.print('"');
#if ECHO_TO_SERIAL
  Serial.print(now.unixtime()); // seconds since 1/1/1970
  Serial.print(", ");
  Serial.print('"');
  Serial.print(now.year(), DEC);
  Serial.print("/");
  Serial.print(now.month(), DEC);
  Serial.print("/");
  Serial.print(now.day(), DEC);
  Serial.print(" ");
  Serial.print(now.hour(), DEC);
  Serial.print(":");
  Serial.print(now.minute(), DEC);
  Serial.print(":");
  Serial.print(now.second(), DEC);
  Serial.print('"');
#endif //ECHO_TO_SERIAL
But between this and writting to the SD

digitalWrite(greenLEDpin, LOW);

  // Now we write data to disk! Don't sync too often - requires 2048 bytes of I/O to SD card
  // which uses a bunch of power and takes time
  if ((millis() - syncTime) < SYNC_INTERVAL) return;
  syncTime = millis();
 
  // blink LED to show we are syncing data to the card & updating FAT!
  digitalWrite(redLEDpin, HIGH);
  logfile.flush();
  digitalWrite(redLEDpin, LOW);
 
}

The RTC, thusly the I2C does not NEED to be "on" the a4 a5  beween the RTC datafetch and the SD write!
Is there a "off" equivalent to:

Code: [Select]

// connect to RTC

[Ian.M]

You said you bent out pins on the header and cut some tracks.  Which pins? Which tracks?

The Adafruit data logger shield connects the I2C bus to the Arduino via two pairs of pins, A5,A6 on the analog in header, and SDA,SCL at the far end of the digital header on the other edge of the board.   To free up A5,A6 for analog and isolate the RTC so you can remap it, you need to isolate it from both sets of pins as they are wired in parallel on the Arduino UNO R3 board.

I would suggest *NOT* bending out pins but instead make the track cuts shown below.  You can then patch the RTC's SDA,SCL pads (bottom left next to A5,A6 on the topside photo) to whichever pins you prefer for soft I2C.  Check for continuity between the pads and all four header pins to make sure you have isolated it properly before reconnecting the shield to the Arduino.




The other option would be to fit an analog switch chip in the prototyping area and use one or more digital I/O line to control it to multiplex your sensors to the four available inputs. 

e.g. use a triple SPDT switch 74HC4053 and one digital output to control it to switch six sensors into three ADC channels.

[gildasd]

I bent pin a4 and a5 on the header.
My cuts are in green, I don't get the "oh" cut on the bottom...

But even doing that, the a4 a5 are connected directly to the 328, that is emiting the SDA/SCL signal.
I must be missing something here...

[Ian.M]

I'm working from fairly crappy photos so I didn't realise A6 had a bottom side connection that needed cutting.   Not isolating the R3 SDA,SCL pins at the end of the digital header would certainly account for your problems.

Its actually crappy design on Adafruit's part - there should have been clearly marked places to cut tracks, preferably all on the same side of the board, laid out for easy cutting.

[gildasd]

I'm working from fairly crappy photos so I didn't realise A6 had a bottom side connection that needed cutting.   Not isolating the R3 SDA,SCL pins at the end of the digital header would certainly account for your problems.

Its actually crappy design on Adafruit's part - there should have been clearly marked places to cut tracks, preferably all on the same side of the board, laid out for easy cutting.

The pins on the shield are isolated, continuity tested with multimeter.
If don't bend them they get the SDA/SCl via the UNO, and pin a4 a5 only have one trace that goes directly to the 328. If I cut there, a4 and a5 are not connected to anything.
Looking at the traces, it seems someone bothered to make it possible to use all 6 analogue pins but then no one documented how to...

[gildasd]

Oh...
I get the physical mods now...

1) Bottom: The RTC can ONLY talk via the extra SDA/SCL contacts. this is totally reversible.
2) Top: these extra contact are jumped to 2 free digital pins.
3) Magic in the code (work in progress..)

[SL4P]

The library you mentioned earlier looks pretty good, and is designed for the Arduino...
http://playground.arduino.cc/Main/SoftwareI2CLibrary

The example down the bottom of that link tells you most you need to know to get started...
Once you get that inline with your code, change the I2C address to that for your device, and rename the BMAxxx to whatever you like for your device.
Of course the specific read & write functions are specific to your device and functions required in your program.

On a total tangent, probably end up you pointing a screen and laughing at my expense.
- The read out on pin a4 a5 is high, because the RTC is using it.

Code: [Select]

  // connect to RTC
  Wire.begin(); 
  if (!RTC.begin()) {
    logfile.println("RTC failed");
#if ECHO_TO_SERIAL
    Serial.println("RTC failed");
#endif  //ECHO_TO_SERIAL
  }used a bit later as:

Code: [Select]

// fetch the time
  now = RTC.now();
  // log time
  logfile.print(now.unixtime()); // seconds since 1/1/1970
  logfile.print(", ");
  logfile.print('"');
  logfile.print(now.year(), DEC);
  logfile.print("/");
  logfile.print(now.month(), DEC);
  logfile.print("/");
  logfile.print(now.day(), DEC);
  logfile.print(" ");
  logfile.print(now.hour(), DEC);
  logfile.print(":");
  logfile.print(now.minute(), DEC);
  logfile.print(":");
  logfile.print(now.second(), DEC);
  logfile.print('"');
#if ECHO_TO_SERIAL
  Serial.print(now.unixtime()); // seconds since 1/1/1970
  Serial.print(", ");
  Serial.print('"');
  Serial.print(now.year(), DEC);
  Serial.print("/");
  Serial.print(now.month(), DEC);
  Serial.print("/");
  Serial.print(now.day(), DEC);
  Serial.print(" ");
  Serial.print(now.hour(), DEC);
  Serial.print(":");
  Serial.print(now.minute(), DEC);
  Serial.print(":");
  Serial.print(now.second(), DEC);
  Serial.print('"');
#endif //ECHO_TO_SERIAL
But between this and writting to the SD

digitalWrite(greenLEDpin, LOW);

  // Now we write data to disk! Don't sync too often - requires 2048 bytes of I/O to SD card
  // which uses a bunch of power and takes time
  if ((millis() - syncTime) < SYNC_INTERVAL) return;
  syncTime = millis();
 
  // blink LED to show we are syncing data to the card & updating FAT!
  digitalWrite(redLEDpin, HIGH);
  logfile.flush();
  digitalWrite(redLEDpin, LOW);
 
}

The RTC, thusly the I2C does not NEED to be "on" the a4 a5  beween the RTC datafetch and the SD write!
Is there a "off" equivalent to:

Code: [Select]

// connect to RTC

I didn't go through all your code (I'm on my phone), but when using the SoftI2C library, you don't use the 'Wire.' Functions...
Similarly, don't attach it to the Ax pins, but rather to the marching 'digital' pins.

[gildasd]

Oh...
I get the physical mods now...

1) Bottom: The RTC can ONLY talk via the extra SDA/SCL contacts. this is totally reversible.
2) Top: these extra contact are jumped to 2 free digital pins.
3) Magic in the code (work in progress..)

Progress, the RTC read out is  "2165/165/165 165:165:85" so VCC high.
The mod is reversible via jumpers. No worries.
But the VCC stays high... So there is still data there. I need to reroute that. In 30 minutes, I'm in a right mess!

[Ian.M]

The pins on the shield are isolated, continuity tested with multimeter.
If don't bend them they get the SDA/SCl via the UNO, and pin a4 a5 only have one trace that goes directly to the 328. If I cut there, a4 and a5 are not connected to anything.
Looking at the traces, it seems someone bothered to make it possible to use all 6 analogue pins but then no one documented how to...

Yes.  See: https://learn.adafruit.com/adafruit-data-logger-shield/using-the-real-time-clock#talking-to-the-rtc

On the Arduino, the pins are 'fixed' to be Analog 4 and 5 for the built in i2c capability. This is a bit annoying since of course we want to have up to 6 analog inputs to read data and now we've lost two. There is a way to use other pins...however, the hardware is by default set up for Analog 4 and 5 so lets start with that and then later we'll show how to modify the shield!

Unfortunately, they didn't document it.   Either the lower right corner of the shield (top photo) should have had pads for R3 digital header SDA and SCL, RTC SDA and SCL  and the A4,A5 breakout pads, with easy to cut tracks linking them in a straight line; Or there should have been breakout pads for R3 SDA,SCL next to the shield's reset switch, again with easy to cut topside tracks.  That would have meant moving the track to LED2.  Also they should have a clearly marked cut point for the power LED to support micro-power applications.

It looks like there will be quite a lot of work porting Adafruit's RTC library to use software I2C.  Look at all the wire library calls:
https://github.com/adafruit/RTClib/blob/master/RTClib.cpp
Personally I'd sh!tcan it and start looking for a DS1307 library that uses software I2C.

[gildasd]

The pins on the shield are isolated, continuity tested with multimeter.
If don't bend them they get the SDA/SCl via the UNO, and pin a4 a5 only have one trace that goes directly to the 328. If I cut there, a4 and a5 are not connected to anything.
Looking at the traces, it seems someone bothered to make it possible to use all 6 analogue pins but then no one documented how to...

Yes.  See: https://learn.adafruit.com/adafruit-data-logger-shield/using-the-real-time-clock#talking-to-the-rtc

On the Arduino, the pins are 'fixed' to be Analog 4 and 5 for the built in i2c capability. This is a bit annoying since of course we want to have up to 6 analog inputs to read data and now we've lost two. There is a way to use other pins...however, the hardware is by default set up for Analog 4 and 5 so lets start with that and then later we'll show how to modify the shield!

Reverting to the non SoftI2C code because my internal VCC is reading 7V and ruining the NULL of my sensors...
Unfortunately, they didn't document it.   Either the lower right corner of the shield (top photo) should have had pads for R3 digital header SDA and SCL, RTC SDA and SCL  and the A4,A5 breakout pads, with easy to cut tracks linking them in a straight line; Or there should have been breakout pads for R3 SDA,SCL next to the shield's reset switch, again with easy to cut topside tracks.  That would have meant moving the track to LED2.  Also they should have a clearly marked cut point for the power LED to support micro-power applications.

It looks like there will be quite a lot of work porting Adafruit's RTC library to use software I2C.  Look at all the wire library calls:
https://github.com/adafruit/RTClib/blob/master/RTClib.cpp
Personally I'd sh!tcan it and start looking for a DS1307 library that uses software I2C.

I'm going to go the 2 sensor approach as I need this up and running today.
I just find that it's dishonest from Adafruit's part to sell something on a claim that is plain wrong.
It's either RTC and 4 analogue or no RTC and 6 analogue if you are lucky. Maybe. Sometime. Have you seen our led googles?

[westfw]

>

I just find that it's dishonest from Adafruit's part to sell something on a claim that is plain wrong.It's either RTC and 4 analogue or no RTC and 6 analogue if you are lucky.

Huh?
1) I don't see any such claim for the "data logger shield."  In fact, the board has only an SD socket and an RTC - the A2D converter is part of the Arduino board itself.  Part of the AVR chip itself, actually.
2) It is the Atmega328 chip on the arduino Uno (and similar) that shares pins between the hardware I2C interface and the A2D interface, and there's nothing an external shield or any amount of trace cutting can do to fix that.  If you want to use the I2C interface on a m328, you lose 2 A2D pins.  Period.  Chip limitation.
3) If you need 6 A2D inputs AND I2C, you have a couple options:

• Use a different chip.  Not all AVR chips share the I2C pins and A2D pins, and some have more than 6 A2D to start with so it might not be a problem.  The reason that the R3 design has two new I2C pins is to accommodate  bigger chips; just because the Uno has the SCL/SDA pins connected to A4/A5 (because of the chip limitation) doesn't mean that that should be the case for an Arduino zero (in fact, I'm pretty sure it's not.)

• Use software I2C instead of the built-in I2C hardware.  This will requiring trace cuts and weird jumpers on the shield, since it is set up to interface specifically to an Uno.

• (It's a bit unfortunate that the Uno SMD didn't remap the analog signals.  It COULD have then used the I2C pins for I2C and STILL had 6 analog inputs.  But it would have made it a separate board type, eliminated the ability to use the analog pins for digital IO, and introduced other complications.)

• (an ATmega328pb is another option.  It adds a second I2C controller.  the Atmel Amega328pb Xplained Mini eval board is cheap and somewhat arduino compatible, though it would have the same problems as (3))

By the way, this sort of "pin sharing" is VERY COMMON on microcontroller chips.  If you read the long list of features a particular chip is supposed to be able to provide, you need to be aware that you can ALMOST NEVER implement all of those features at the same time!

[gildasd]

I just find that it's dishonest from Adafruit's part to sell something on a claim that is plain wrong.It's either RTC and 4 analogue or no RTC and 6 analogue if you are lucky.

Huh?
1) I don't see any such claim for the "data logger shield."  In fact, the board has only an SD socket and an RTC - the A2D converter is part of the Arduino board itself.  Part of the AVR chip itself, actually.
2) It is the Atmega328 chip on the arduino Uno (and similar) that shares pins between the hardware I2C interface and the A2D interface, and there's nothing an external shield or any amount of trace cutting can do to fix that.  If you want to use the I2C interface on a m328, you lose 2 A2D pins.  Period.  Chip limitation.
3) If you need 6 A2D inputs AND I2C, you have a couple options:

• Use a different chip.  Not all AVR chips share the I2C pins and A2D pins, and some have more than 6 A2D to start with so it might not be a problem.  The reason that the R3 design has two new I2C pins is to accommodate  bigger chips; just because the Uno has the SCL/SDA pins connected to A4/A5 (because of the chip limitation) doesn't mean that that should be the case for an Arduino zero (in fact, I'm pretty sure it's not.)

• Use software I2C instead of the built-in I2C hardware.  This will requiring trace cuts and weird jumpers on the shield, since it is set up to interface specifically to an Uno.

• (It's a bit unfortunate that the Uno SMD didn't remap the analog signals.  It COULD have then used the I2C pins for I2C and STILL had 6 analog inputs.  But it would have made it a separate board type, eliminated the ability to use the analog pins for digital IO, and introduced other complications.)

• (an ATmega328pb is another option.  It adds a second I2C controller.  the Atmel Amega328pb Xplained Mini eval board is cheap and somewhat arduino compatible, though it would have the same problems as (3))

By the way, this sort of "pin sharing" is VERY COMMON on microcontroller chips.  If you read the long list of features a particular chip is supposed to be able to provide, you need to be aware that you can ALMOST NEVER implement all of those features at the same time!

I'm just cranky because I made the error of "designing by datasheet" and what was meant to happen, happened.
But in all honesty, the UNO is marketed at newbs (like me a few months back) and they should be very clear of the "outathebox" limitations.
It's like having a 6 speed gear box in your car but you need to take it out and machine the gears to make it so. It's a 4 speed.

That being said, this has pissed me off and I will find a way to make this work AND document it.

1) It's sold as such on their web site.
2) Nothing wrong with sharing pins, just document the limitations on shifting them on your board.
If I could simply "pull down" or "interrupt" the I2C while I read a4 a5, I would be happy.
3) Arduino MICRO is the simplest route, I choose not to because the UNO with a shield mounted on a custom board seemed easier. Now I know it was not!
- The MEGA is the best in the ARDUINO range for my usage, and with hindsight a lot simpler - but as a first project I was scared of it.
- But I would probably PI with external ADC route if I had to start from fresh.

[westfw]

[size=0px] just document the limitations[/size]

The "main" teaser says "14 digital pins and 6 analog inputs."  I2C/TWI or SPI/SD isn't mentioned.
They are mentioned later, as is  this "explanation":

In addition, some pins have specialized functions:

• Serial: 0 (RX) and 1 (TX). Used to receive (RX) and transmit (TX) TTL serial data. These pins are connected to the corresponding pins of the ATmega8U2 USB-to-TTL Serial chip.
• External Interrupts: 2 and 3. These pins can be configured to trigger an interrupt on a low value, a rising or falling edge, or a change in value. See the attachInterrupt() function for details.
• PWM: 3, 5, 6, 9, 10, and 11. Provide 8-bit PWM output with the analogWrite() function.
• SPI: 10 (SS), 11 (MOSI), 12 (MISO), 13 (SCK). These pins support SPI communication using the SPI library.
• LED: 13. There is a built-in LED driven by digital pin 13. When the pin is HIGH value, the LED is on, when the pin is LOW, it's off.
• TWI: A4 or SDA pin and A5 or SCL pin. Support TWI communication using the Wire library.

I'm not sure what else you could ask for...
(Now, to be charitable, a beginner perhaps should not be expected to know that an RTC requires you to use the I2C, or that an SD card uses the SPI pins (plus one other.)  So it might be nice if every shield included a list of which pins it requires or could use, but ... it gets complicated (I2C and SPI shareable by multiple shields, sort-of, for example.))

[gildasd]

[size=0px] just document the limitations[/size]

The "main" teaser says "14 digital pins and 6 analog inputs."  I2C/TWI or SPI/SD isn't mentioned.
They are mentioned later, as is  this "explanation":

In addition, some pins have specialized functions:

• Serial: 0 (RX) and 1 (TX). Used to receive (RX) and transmit (TX) TTL serial data. These pins are connected to the corresponding pins of the ATmega8U2 USB-to-TTL Serial chip.
• External Interrupts: 2 and 3. These pins can be configured to trigger an interrupt on a low value, a rising or falling edge, or a change in value. See the attachInterrupt() function for details.
• PWM: 3, 5, 6, 9, 10, and 11. Provide 8-bit PWM output with the analogWrite() function.
• SPI: 10 (SS), 11 (MOSI), 12 (MISO), 13 (SCK). These pins support SPI communication using the SPI library.
• LED: 13. There is a built-in LED driven by digital pin 13. When the pin is HIGH value, the LED is on, when the pin is LOW, it's off.
• TWI: A4 or SDA pin and A5 or SCL pin. Support TWI communication using the Wire library.

I'm not sure what else you could ask for...
(Now, to be charitable, a beginner perhaps should not be expected to know that an RTC requires you to use the I2C, or that an SD card uses the SPI pins (plus one other.)  So it might be nice if every shield included a list of which pins it requires or could use, but ... it gets complicated (I2C and SPI shareable by multiple shields, sort-of, for example.))

I now can read that and sorta understand. A few months ago I would have not, made the mistake and I did

[Rick Law]

...The vaunted 6 analogue inputs are pure marketing (a lie) and I can't do anything about it...Pissed off at having been "marketed" at by Arduino and Adafruit...

I think it is not so much marketing but general practice.  What those board makers put down is what Amtel's datasheet said.  It is true, it has both (6 analog input and I2C support), just not concurrently.

To bring that idea to something more common: I am using a Radio Shack power brick - box saids "3V, 6V, 9V Power Supply."  It has only one outlet plug and a 3-position slider switch marked 3V, 6V, 9V.  Radio Shack didn't "lie", it can supply 3V or 6V or 9V - It cannot output 3V and 6V and 9V at the same time.  It just do the one you choose.

Going way back to even pre-Pentium dates, CPU makers would say in their specs something like "Four 16 bit registers" in one bullet point and "Eight 8 bit registers" in the next bullet point.  Of course, if you use one of those 16 bit registers you are also using up two eight bit registers.  Amtel (or Arduino, or AdaFruit) didn't lie, they just follow the common practice.

I have made my share of mistakes.  I learn to dig deep into the datasheet for the confirmation if my whole project depends on it.

[Pack34]

Why don't you just buy a pair 4-channel ADC chips and do everything over the I2C bus? Then just buy a breakout board to solder the chip on and wire it in.

It'll be easier than hacking together some Arduinos and shields.

[westfw]

Some of the Arduino "hacks" have come back to bite them.
I mean, one of the SMT ATmega chips could support 6 analog inputs AND I2C at the same time, but they went and admitted/allowed people to use the analog inputs as digital IO, which wouldn't be possible on the last two analog inputs.
The other one is "enable pullups by writing HIGH to a pin in Input mode."  Yep; that's how it works on AVRs.  And the post-avr platforms (ARM, etc) all end up having to include special case (ugly and slow) code in digitalWrite() to make sure that they behave the same way :-(

[gildasd]

Why don't you just buy a pair 4-channel ADC chips and do everything over the I2C bus? Then just buy a breakout board to solder the chip on and wire it in.

It'll be easier than hacking together some Arduinos and shields.

Yup.
That's the way I'll be doing it in the future, probably with Raspberry PI.
If I can design the circuit to power the load cells a few ms before the read then shut them down, via mofsets or relays, then I could even make this kind of thing work off some AA's.

[Pack34]

Why don't you just buy a pair 4-channel ADC chips and do everything over the I2C bus? Then just buy a breakout board to solder the chip on and wire it in.

It'll be easier than hacking together some Arduinos and shields.

Yup.
That's the way I'll be doing it in the future, probably with Raspberry PI.
If I can design the circuit to power the load cells a few ms before the read then shut them down, via mofsets or relays, then I could even make this kind of thing work off some AA's.

A PI will be more power hungry than a micro. If you intend to have it off of a couple AAs, and you want to stay with Arduino, they make some 3v3 uno style boards that you can wire in a couple ADCs and your SD card. Then put the thing into a sleep mode and check again periodically.

It all depends on what you're hoping to accomplish.

[gildasd]

Why don't you just buy a pair 4-channel ADC chips and do everything over the I2C bus? Then just buy a breakout board to solder the chip on and wire it in.

It'll be easier than hacking together some Arduinos and shields.

Yup.
That's the way I'll be doing it in the future, probably with Raspberry PI.
If I can design the circuit to power the load cells a few ms before the read then shut them down, via mofsets or relays, then I could even make this kind of thing work off some AA's.

A PI will be more power hungry than a micro. If you intend to have it off of a couple AAs, and you want to stay with Arduino, they make some 3v3 uno style boards that you can wire in a couple ADCs and your SD card. Then put the thing into a sleep mode and check again periodically.

It all depends on what you're hoping to accomplish.

For supper low power, I'd go Nano.
But the big power user are the load cells. They are only 2KOhm to ground... Around 50 to 70mA for 5.