if you look at the schem, most of the motor control pins are for the PWM channels. theres only 3 pins that are used for 'data' - and those are behind a latch - clk, data, enable and latch. turning into some i2c deal would thus save you a grand total of 2 pins. unless you wanted to, say, put -everything- onto another microcontroller. in which case you would try to do the PWM on the attiny2313 and have that controlled via i2c. and the attiny2313 only has 2 timers by the way, whereas the atmega168 has 3, so you'd have to do the PWM in software which means tons of fun debugging that and i2c communication at the same time. especially difficult when the user wants 8-bit PWM is at >20khz!

also, where are you getting an attiny2313 for $1.45 in qty 1? and a 8-pos DIP switch for $0.75 in qty 1?

unless you wanted to, say, put -everything- onto another microcontroller. in which case you would try to do the PWM on the attiny2313 and have that controlled via i2c.

Exactly. Makes the library controlling it far simpler and frees up timers.Was it you who hit a snag with the timers and delay()?

Quote

and the attiny2313 only has 2 timers by the way, whereas the atmega168 has 3, so you'd have to do the PWM in software which means tons of fun debugging that and i2c communication at the same time. especially difficult when the user wants 8-bit PWM is at >20khz!

Well the ATtiny2313 was a example. There are enough different chips to fill any need.

Quote

also, where are you getting an attiny2313 for $1.45 in qty 1? and a 8-pos DIP switch for $0.75 in qty 1?

Futurlec. Cheap shipping too.

In quantities of 100 the prices are $1.05 and $0.60 respectively.[/quote]

ok, so I wasn't totally off on the I2C thing. It sounds like a great idea, but it definitely introduces added costs(however large or small) and requires some software for the 2313.

Simple jumper wires don't seem to create any additional work other than in the PCB design, and add maybe a nickel to cost for the jumper wires.... kinda seems similar to my idea about jumpers, just easier to implement.

I'm gonna play with some stacky headers this weekend too.... but they are also a bit pricey...

for example it would only increase the price by about 3 dollars.~$1.45 for a ATtiny2313 for the I2C interface and ~$0.75 for a DIP switch to select the address.

It would increase the COST by about $3... (oops. The Lady already pointed this out!)Isn't implementing an I2C "slave" difficult, though? Or was that SPI? There are a couple protocols where the master has it easy, but the slave has to be able to toggle a signal on a clock edge (or similar), which is tough to do in SW.

ok, so I wasn't totally off on the I2C thing. It sounds like a great idea, but it definitely introduces added costs(however large or small) and requires some software for the 2313.

Simple jumper wires don't seem to create any additional work other than in the PCB design, and add maybe a nickel to cost for the jumper wires.... kinda seems similar to my idea about jumpers, just easier to implement.

I'm gonna play with some stacky headers this weekend too.... but they are also a bit pricey...

Any other ideas?

aballen, if you want to have many-to-many combinations, it is just impractical with jumpers. That is why buses were invented. I2C is the way to go. You can hide the complexity of i2c by writing an abstraction library that talks to a master I2C shield, which assigns device numbers to different shields and do the master coordination... every shield, when powered-up and connected to an i2c bus, tries to talk to the master shield... Arduino does the same... actually ladyada already put a price on this shield... $12... it is just a tiny AVR + PCB + software

Isn't implementing an I2C "slave" difficult, though? Or was that SPI? There are a couple protocols where the master has it easy, but the slave has to be able to toggle a signal on a clock edge (or similar), which is tough to do in SW.

I believe that Wire handles it out of the box. Its SPI with the tricky slave stuff.When creating the object there is a optional slave address parameter although I've never used it.