Looking for macegr and info on his "Centipede shield"

Sorry if I spelt it wrong. Brain rebooting.

Why I am asking:

If this shield uses the I2C bus, I am wanting more I/O lines and am wondering if this would help.

The "Question":

As I said, I understand it uses the I2C bus to talk to the Arduino.

If I power it by "cheating" and connecting the power to the needed two pins, and connect the I2C bus to the Arduino; would it work like that?

I can't stack any more shields on my prjoect (I think).......

Awaiting reply.

You will also need to connect the Arduino GND to the centipede shield GND.
You can contact them here - Contact Us – Macetech

Thanks.

I thought connecting the + and - (supply) would be enough. "Common earth".

But thanks anyway. Live and learn.

Yes, you could use just four pins from the Arduino to the shield: 5V, GND, SDA, and SCL. Several customers have done off-board connections that way (or to non-Arduino controllers).

Alternately, you can solder up some boards using the DIP version of the MCP23017, and still use the Centipede Library to control them.

Macegr,

Thanks.

I have looked around and bought a DIP MCP.

I have downloaded your centiped library.

I hope it all works nicely.

I am asking other places but not getting any replies - which is annoying.

I am "using" this sketch called "multi day alarm clock" but have made it so much more/better.

That's why I am needing the MCP. I'm guessing - and that is literal - that the RTC and EEPROM are on the I2C bus as well. So now my concern is how to get both these types of devices working on the bus together.

Obviously it is possible, but as you are the guru of that - well: That shield is definitly a good idea and uses what I am going to use - I hope you may be able to allay any fears I have about getting it working easily.

Is it that when I connect the MCP, I assing it an address and the centiped library can just "find it"?

You assign addresses by pulling the A0, A1, and A2 lines high or low. If a chip has all three low, it is chip 000 and in the Centipede library is pins 0 through 15. If you set up the chip as address 001, then it will have pins 16 through 31.

There should be no conflict between the RTC and the MCP23017 on the same I2C bus.

Ok,

I shall show my stupidity here:

But obviously the MCP can't have the same address as either the RTC or EEPROM.

How/where in the code do I determin their addresses?

You'd probably do best to look in the respective datasheets for the parts.

But I can tell you now it's pretty unlikely you'll see a collision.

Well, I am "that much closer" to having it working.

Put in the IC socket and killed a couple of caps (alas) and 1 x 7805 (drats!)

But the voltage on the socket looks good.

Just to check:
I connect the SCL and SDA pins from the Arduino to the pins on the MCP and "voila!"

Do I need to do anything with the address lines on the chip? For now I haven't connected them to anything.

I shall make it address 0 and hope.

When I have the centipede library installed/included, how would I know I am "talking to it"?

I shall scurry off and look for example sketches.

Slight update:

Something doesn't work.

I got the example sketch and applied it to my sketch.

When I complied it and sent it to the arduino, it "crashed". The first line of the display was black, the second clear, the third back and the fourth clear.

I paniced (spelling?) and thought it was the I2C bus.

Luckily when I went back to an earlier version it worked. So then I realised that the Centipede library and stuff were happening.

I remarked out the lines and it works.

One thing:
I haven't got the 23017 connected yet.

I am (stupidly) worried about it. When building the veroboard part, I killed 1 voltage regulator and 2 caps. Well the caps were probably already dead. Can't be sure.

So I need to work out - somehow - what the RTC and EEPROM addresses are and make sure the 23017 is at another one.

Sketch here:

// Example code for Centipede Library
// Works with Centipede Shield or MCP23017 on Arduino I2C port
 
#include <Wire.h>
#include <Centipede.h>
 
 
/* Available commands
  .digitalWrite([0...127], [LOW...HIGH]) - Acts like normal digitalWrite
  .digitalRead([0...127]) - Acts like normal digitalRead
  .pinMode([0...127], [INPUT...OUTPUT]) - Acts like normal pinMode
  .portWrite([0...7], [0...65535]) - Writes 16-bit value to one port (chip)
  .portRead([0...7]) - Reads 16-bit value from one port (chip)
  .portMode([0...7], [0...65535]) - Write I/O mask to one port (chip)
  .pinPullup([0...127], [LOW...HIGH]) - Sets pullup on input pin
  .portPullup([0...7], [0...65535]) - Sets pullups on one port (chip)
  .init() - Sets all registers to initial values
 
  Examples
  CS.init();
  CS.pinMode(0,OUTPUT);
  CS.digitalWrite(0, HIGH);
  int recpin = CS.digitalRead(0);
  CS.portMode(0, 0b0111111001111110); // 0 = output, 1 = input
  CS.portWrite(0, 0b1000000110000001); // 0 = LOW, 1 = HIGH
  int recport = CS.portRead(0);
  CS.pinPullup(1,HIGH);
  CS.portPullup(0, 0b0111111001111110); // 0 = no pullup, 1 = pullup
*/
 
Centipede CS; // create Centipede object
 
 
void setup()
{
  Wire.begin(); // start I2C
 
  CS.initialize(); // set all registers to default
 
  CS.portMode(0, 0b0000000000000000); // set all pins on chip 0 to output
 
  //TWBR = 12; // uncomment for 400KHz I2C (on 16MHz Arduinos)
 
}
 
 
void loop()
{  
  for (int i = 0; i < 15; i++) {
    CS.digitalWrite(i, HIGH);
    delay(10);
  }
 
  for (int i = 0; i < 15; i++) {
    CS.digitalWrite(i, LOW);
    delay(10);
  } 
}

macegr,

I've pulled the code appart and can't resolve the RTC and EEPROM's addresses.

So I am still confused about "how" if I pick the same address as one of those, that these "collisions" won't happen.

The address I put on the MCP would determin the pin numbes it has when I want to set the pins high/low.

Is that right?

P.S.
I found this bit of reading:
Each device you use on the I2C bus must have a unique address. For some devices e.g. serial memory you can set the lower address bits using input pins on the device others have a fixed internal address setting e.g. a real time clock DS1307.

All my efforts to download a PDF falis.
I shall have to wait until I get home. But that is real interesting reading.

Macegr,

I'm confused..... Yeah, well, that's normal for me.

But until now we have been talking about an MCP and the I2C bus - right?

Looking at your example sketch (shiftbrite [macetech documentation]) that is on the SPI bus.
"The following Arduino code illustrates using the built-in SPI hardware for faster updates, "

In fact over on the left of the screen where the example scripts are listed I see this:

Simple Test
Rusty VU
ATTiny & AVR-GCC
AVR Assembler
Hardware SPI Example
Non-hardware SPI Example
OctoBrite on ATTiny84 with HW SPI

That's three SPI references and even the SIMPLE TEST is SPI.

Granted a bit further down on the original mentioned page, there is an I2C example.....

When I ran that I get alternate black and white lines on the LCD screen.

Black as in the (oh boy.... what is the CHR$() value? The inverted blank character.....)

So one line of those, one line of clear, one line of them again and the last line clear.

That is a simple cut/paste job and as a function in my sketch.

Shall maybe try as is, but .....