[Juaquin]

I've been doing some work with my little rotary encoder and I think I'm ready to order a couple prototypes. The main idea is the encoder input (with optional push-switch) and then outputting a count over the 1-wire protocol through the HEADER (which also carries 5V and GND) to an Arduino / LCDuino. There's also a breakout that contains most of the other pins, if people want to add more or modify the design, and of course the ISP header for programming. There's a resistor/cap combo to stabilize the reset, a cap on the power pin to stabilize that, and a small electrolytic to stabilize the rails since this may be a ways from the power source.

Here's the schematic and the board is below. It's not very polished - mostly just a working prototype to get it off the breadboard. If anyone feels so inclined, please look it over and let me know of any mistakes or problems. If there's nothing bad I'll order a couple to play with.

[EDIT] The encoder will be mounted on the other side, so it can be panel mounted. Also, the top plane polygon is 5V and the bottom is GND - sorry for the confusion, the capacitors/power pins ARE connected!

 

[Pars]

C1 and C2 aren't connected (looks like C2 isn't connected in the schematic either, as there are no airwires). Not sure what pins are power/ground on the tiny2313, but I would beef the traces up. Possibly move R1 over by ISP6 (whatever that is), flipping it clockwise 90 degrees.

EDIT: I see, missed the bottom plane.

 

[Juaquin]

Yeah, sorry - the top plane is 5V, bottom plane is GND - I left them as polygons for this screenshot so you could see the other traces. I could see how that could cause some confusion - even I was scared for a moment there when I saw nothing connected to the capacitors!

ISP 6 is the 6-pin header for ISP programming of the chip. I wanted the resistor over by Pin1 (reset) since that resistor is what is holding the pin high along with the cap C3, but I suppose it can go anywhere.

 

[error401]

Looks fine to me. My only concern is how you're going to address it on the bus, adding some jumpers/DIP switches is probably prudent since you don't have a hardware 64-bit unique ID and programming it manually for each device is a pain if you ever plan to build more than one.

I'm curious about the encoder, it doesn't look like a typical quadrature encoder, what is the encoding? Probably easier to get a quad one, and more varied as well, but whatever you've chosen is probably fine. If you wanted to I think you could also switch to the 8 pin tiny25 and shrink the board considerably.

Also wondering why you chose 1-wire when LCDuino already has an I2C bus you can use and you haven't tried to use parasitic power, but there's nothing really wrong with the choice, it just seems odd.

 

[Juaquin]

I2C is two pins. It could be done with the existing board (breakout pins) but I wanted to simplify. Honestly I haven't done a lot of research on the communication aspect yet (I had to have something to do during the 3 week wait for boards) and I'm definitely open to suggestions on that. I'll look into it - if anyone has good sources on I2C using AVRs that would be much appreciated.

I thought about using a Tiny13 / Tiny25 but it limits expandability and would put me short on pins. The 2313 is only about a dollar more anyways, plus the slightly larger board cost for the larger area, and a lot of people are already familiar with it.

It's a typical encoder, using incremental/quadrature coding. There are two pins, one for each switch - they are the ones on the sides of the bottom of the encoder. The pin in the middle at the bottom is connected to ground (so when the switches complete the connection they are pulled from their normal internally pulled-up 5V to ground). The two pins at the top are for an optional pushbutton (some encoders have built-in pushbutton switches). I'm planning on using the Alps EC11E series which I've been testing with. I've also tested using this one Sparkfun sells that I had lying around.

 

[error401]

Quote:

Originally Posted by Juaquin /img/forum/go_quote.gif I2C is two pins. It could be done with the existing board (breakout pins) but I wanted to simplify. Honestly I haven't done a lot of research on the communication aspect yet (I had to have something to do during the 3 week wait for boards) and I'm definitely open to suggestions on that. I'll look into it - if anyone has good sources on I2C using AVRs that would be much appreciated.

The main reason I would suggest using is that it should be much easier to integrate into the LCDuino (which you mentioned), as that board already uses I2C, so most of the code (and obviously the physical interface) would already be there. I2C is pretty much everywhere though, so it should be possible to wedge it into pretty much anything.

A good start on I2C would be Atmel app note AVR312, though I haven't tried this implementation myself, it claims to implement a software slave.

Most information you're going to find on any inter-IC type bus is probably going to have the AVR being the master, finding good information on being a slave is a bit more difficult. I believe doing 1-wire slave in software is probably considerably more difficult than doing I2C slave in software, but if you have found good documentation it could be a good route. To make matters worse, for any of these protocols the master is typically easier to implement in software. In your situation you need to be very careful in order to not miss any I2C interrupts/data periods and also not miss any encoder events, all while keeping the timing tight enough for the master clocking you.

 

[cobaltmute]

C1 is your screen cap is showing the symbol of a trace being needed.

On breakout, you could re-order the last two pins on the right to make the traces straight as opposed to having one go around the other.

To me, the fact that almost every trace to breakout crosses the board implies that it is in the wrong place. It causes too many cuts in the plane. Rotate the AVR 180 degrees and start from there. Unless I'm visualizing it wrong, you can make all the traces a lot cleaner and shorter. You can re-order your pins to make your traces clean and then adjust your code to fit.

 

[Juaquin]

Quote:

Originally Posted by cobaltmute /img/forum/go_quote.gif C1 is your screen cap is showing the symbol of a trace being needed.

Good eye! Definitely need to fix that.

Quote:

Originally Posted by cobaltmute /img/forum/go_quote.gif To me, the fact that almost every trace to breakout crosses the board implies that it is in the wrong place.

You're probably right - I need to make some changes anyway so I'll play around with the layout.

Thanks for the insights guys!