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

[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.