Must-haves for EASY DIY controller?

[terahz]

If any of you prototypers out there have other changes, lemme know ASAP.

I've been thinking about the hardware configuration a bit and wanted to bring a few ideas out.

It mainly has to do with the fact that the communication part between modules is fixed. A common way to do hardware configuration are jumpers. How about we take out some of the hardware traces into 3pin jumpers so that we can "move" what talks to what. For example, the Ethernet chip will be hardwired by default to one of the CPUs but at some stage it might make more sense to move it to the other. Same goes for the RTC and PH. Also, it might be useful to be able to separate the two CPUs into their own I2C networks.

Just pointing a few things out that came to my mind while thinking about the communication part.

Also, might be worth putting out a dedicated 3pin header for IR sensor (signa, gnd, v+), same for a temp sensor or two.


Bottom line is, I think the hardware is a little too fixed on the board and if space allows it it would be nice to be able to move a jumper (or a few) and switch a certain circuit between the two CPUs.

Main reason for my thinking is that my firmware is almost 20Kb now and that is still missing a good amount of code and does not have any of the Ethernet portion which is in the 10K area by itself. So having the option to move hardware between the two CPUs might make it easier to code things.

Just thoughts. What do you guys think?

 

[der_wille_zur_macht]

Main reason for my thinking is that my firmware is almost 20Kb now and that is still missing a good amount of code and does not have any of the Ethernet portion which is in the 10K area by itself.

This was something I've been worried about lately, too.

I like the idea of making the hardware flexible via jumpers are you're suggesting, but then where do we draw the line? i.e. why not break things out onto separate boards? Just thinking out loud. There's a happy medium out there somewhere.

Another option, maybe worth bringing up again, would be to ditch the second AVR and "deal" with the SMT ATMega1280. This would mean tricky soldering and people building their own would need to burn a bootloader since you can't get the SMT chips pre-bootloaded.

Along the same lines, it's almost a waste to have the "main" AVR designed with shield-compatible headers. There really won't be any shields out there you'd be able to use with it, since we've pretty much used up all the useful pins and there won't be any program memory space left anyways.

So - do we go the route you're suggesting, or do a more wide-ranging redesign? Might be worthwhile to wait until a few of them have been up and running for a few months before we do anything too drastic.

 

[terahz]

I think the ATMega1280 will make things more complicated than having some jumpers out. I already got a programmer for myself so don't really mind the bootloader problem, but I don't think such a big change is required.

Jumper-wise I'm thinking of 4-5 jumpers really, not more. Ethernet, RTC, PH and I2C "breaker" between the two chips. That will probably give is a good amount of flexibility without doing a major change.

I agree, however, that a second round of boards should wait. Just bringing out a few points that have come up with after me working on the software side a bit.

 

[der_wille_zur_macht]

So in terms of busses/connections we have:

I2C:
-both AVRs
-RTC
-MCP for LCD

SPI:
-"main" AVR
-ENC chip for Ethernet

There's also the pH probe connected to A3 on the main AVR.

So which of these would we put on jumpers? And how exactly would we format the jumpers?

I guess I could see having one big I2C jumper block. The RTC, MCP, and both AVRs could all have their two respective I2C pins brought out to a 4 x 2 header. Then, you could put jumpers on the header to connect whichever of the devices together you wanted.

For SPI, we could do the same, but bring out the SPI pins from the two AVRs and the Ethernet chip. So we could do a 3 x whatever header and you could put jumpers on it to select which AVR the ENC was connected to.

All that said, I still feel like we should be able to do a "jumperless" hardware configuration that would work for our default set of functionality with some default set of code. I don't quite know if our current design reaches that goal or not though. . .

 

[DustinB]

Wow, I really do have a lot to catch up on.

Are you guys going with the standard 328 chip or the adafruit "2x upgrade" chip?

 

[der_wille_zur_macht]

The ATMega328p is the chip we're using. The Adafruit "speedy 2x upgrade chip" actually IS a 328p, but it has a different bootloader on it (one that responds differently to resets in order to appear to load faster). For our application, it won't really matter which bootloader you have, so get any pre-bootloaded 328p you want. I usually get them from moderndevice.com because they're cheap ($4.50) and moderndevice has other useful stuff so you can save on shipping - shield stacking headers, 20x4 LCD, etc.

In theory you could build this project with an ATMega8 or ATMega168 in a 28 pin DIP package with an Arduino-compatible bootloader, but doing so would be a little crippling because of the lack of memory on those two chips.

 

[DustinB]

Ah ok, the reason I was looking at that one is it claims to have twice the memory.

 

[der_wille_zur_macht]

That's a reference to the "old days" when the ATMega168 was the standard. The 328 does have twice the memory of the 168, but there really aren't many new Arduino compatibles still sold with the 168, so it's kind of a moot point for most people.

 

[terahz]

So in terms of busses/connections we have:

I2C:
-both AVRs
-RTC
-MCP for LCD

SPI:
-"main" AVR
-ENC chip for Ethernet

There's also the pH probe connected to A3 on the main AVR.

So which of these would we put on jumpers? And how exactly would we format the jumpers?

I guess I could see having one big I2C jumper block. The RTC, MCP, and both AVRs could all have their two respective I2C pins brought out to a 4 x 2 header. Then, you could put jumpers on the header to connect whichever of the devices together you wanted.

For SPI, we could do the same, but bring out the SPI pins from the two AVRs and the Ethernet chip. So we could do a 3 x whatever header and you could put jumpers on it to select which AVR the ENC was connected to.

Hmm, so:
2x2 for the avr's (connected or not)
two 2x3 for RTC and MCP (p1+p2 connect to AVR1, p2+p3 connect to AVR2)
4x3 for the Ethernet (SPI is 4 pins right?) using the same options as ^

One block of 6x3 and a 2x2 somewhere else seem like what will be required.

Then again, not all of them have to be configurable.

All that said, I still feel like we should be able to do a "jumperless" hardware configuration that would work for our default set of functionality with some default set of code. I don't quite know if our current design reaches that goal or not though. . .

I don't know of any way to disconnect traces. That is, I don't know if it possible on the hardware level to have a jumperless option and allow for configuration with jumpers without putting some extra logic components.

Or we can leave the hardware as it is, and just think about the implementation of the software. At the end of the day, I'd guess the majority of the people to use the same hardware configuration+firmware so maybe we can just permanently move some things like the ETH to the second cpu...



On a side note I've been playing with the Vishay TSOP34838 IC and it works great for IR receiver. That will be my choice of external IO with the controller.

 

[der_wille_zur_macht]

Or we can leave the hardware as it is, and just think about the implementation of the software. At the end of the day, I'd guess the majority of the people to use the same hardware configuration+firmware so maybe we can just permanently move some things like the ETH to the second cpu...

I guess that's what I meant - we should be able to design the hardware/software together such that our desired set of functionality is delivered without the need to think about switching stuff around via jumpers. Even if we let people switch stuff, I still feel like there's going to be a compromise somewhere, so we might as well pick the compromise ahead of time.

If we choose to continue with the current design that does not have an IR and One Wire header brought out, then at least we're leaving a little flexibility, since people can put those on pins they're not using for something else. I figure we pretty much NEED both AVRs to be on I2C, since that's used elsewhere on the board and will allow for communication - we don't have to designate one or the other as the master at the hardware level so there is some flexibility there. For instance, we could run the non-shield-format AVR as the I2C master, which would mean code to deal with the RTC and LCD would go there instead of the shield-format AVR. That pretty much means the only "compromise" we're making is which of the two AVRs is hardwired to Ethernet. And it seems like we should be able to juggle other code to allow for that choice to go either way.

I agree it's late in the game to think about switching to a different non-pin-compatible processor, but it makes for interesting brainstorming. If not the 1280, what about the 644 (as used in the Sanguino)? It's available in through-hole, and pre-bootloaded, and it has twice as much program memory (64k) and a few more I/O pins. I wonder if we could make the non-shield format AVR a 644, use it as the master for everything, and let the shield-format AVR do generic I/O and communicate with any shields the user wanted to add.

 

[der_wille_zur_macht]

Ok the 644 is a bad idea. It's huge!

 

[dafunkdawg]

I don't know if you guys read my other post but this piece here

http://www.guitarcenter.com/Chauvet-SR-8--Relay-Pack-803158-i1384700.gc

it the answer for the relay board with very minimal work. It has 8 12 vdc relays inside of it all connected to an external db9 port. You can send 12 v ground to one pin and then each of the 8 remaining will each control one relay / outlet with a 12 volt pulse. It eliminates the need for running 120 vac outside the enclosure to external relays . You can build a simple db9 control cable from whatever device you want and plug it in. They best part about it is the price .

 

[ludnix]

That thing looks great dafunkdawg.

 

[TheFishMan65]

Here imy $0.02.

I think I mentioned it early (and was over ruled) you really don't want two processors. The communications between them always turns out to be a problem. It sound easy, but something comes up. I will point too the IIC real time clock. Didn't someone already report problems when both processors tried to read the clock. This probably means that the main processor will halt while the secondary does any access on the IIC.

What if we design wth the Arduino mega board and design a shield with all our options around that? It add a little to the cost :sad1:, but I think we will al be happier in the end.

 

[terahz]

I see where a mega could be useful now that I've ran into SRAM limits ... yet, I believe the no-smd or very limited smd makes this accessible to more people. AFAIK the bigger chips are SMD only and are not the easiest to solder by hand.

We're doing good now, no need to dump the project because of a few small issues. We'll work them out.

Speaking of which the battery on my Hydra is dead! Don't know if I got a bad battery or something, but it didn't even last a few months. I'm still behind my original recommendation of a ds1302+supercap, but that's just me. Off to the store now for batteries...

 

[der_wille_zur_macht]

The 1302 is the SPI version of the chip, right? Why'd we want to switch to that instead of the I2C 1307 (which we could also use a supercap for)?

I shyed away from the supercap mainly because I couldn't get any solid info on an implementation using that concept, but if you think we can work it out, I'm all for it. The part that I don't get is this: If you simply wire the supercap from GND to VBAT, how does it ever get a charge?

That said, I just bought a 10-pack of those batteries so I should be good for a while.

 

[nauticac4]

Must-haves for EASY DIY controller?

--------------------------------------------------------------------------------

Many people are doing really cool things with DIY controllers and documenting the efforts in this forum. I've mentioned using an Arduino for LED control in several threads, and am hoping to start a thread on that subject soon.

On my own tank, the LED control will just be one feature. It'll be the main feature, but there are other features available without too much effort. I'll likely also be using it for the following, at a minimum:

1) pH monitoring
2) A small number of relays to turn pumps and other accessories on and off
3) A small number of digital inputs - i.e. float switches, etc.

I'm trying to keep the entire project small and realistic, and I'm sure it overlaps with what other people want. My overall goals are:

1) Reduce hardware complexity.
2) Allow for future expansion.



This was the first post in this thread and I jumped on board at day one. I have read through the thread a few times and it seems as if the main purpose of this controller design has been lost to time. Initially a simple controller to turn some stuff on and off, read temp and pH, and a few other things has ballooned into a monster.

I have a mechanical engineering degree and I am having a hard time following some of what is being discussed and other than buying the Arduino have yet to start on my Hydra because of the perceived complexity that has developed.

I am not trying to be negative and the work you guys have done has been great but I think that the scope of the project is getting away from EASY in which it was set out to be. Maybe a step by step simplification is in order such as what was done in the Led thread, maybe I'm just an idiot. Just my thoughts. Thanks again for the hard work in either case.

 

[der_wille_zur_macht]

nauticac4, you raise a good point - the project has expanded in scope at least a little. Though, I would argue that the only real expansion in scope beyond the initial target was the addition of Ethernet, since we can trace all the rest of the "extra" hardware back to the original requirements.

Either way, I suppose a clarifying statement is appropriate at this point. This thread has morphed into a discussion about the development of the controller. When I started the thread, I figured we'd go off and have a separate thread about development, but the discussion just evolved here. As a result, I don't expect that "typical users" would be able to follow every post in this thread. Once we have a stable version of both the hardware and software, the next direction we will take is documenting and presenting the "finished" project in a manner that DOES make it easy for the typical user to understand.

So don't sweat it if you're struggling to follow the thread at this point. Once things are a little more stable and finished up, we'll be very deliberate in how we present the finished product, to make sure we meet the original goals - developing a controller that someone with limited electronics/microcontroller experience can build and use on their own.

Thanks for the feedback! It helps keep the goals clear.

 

[nauticac4]

I look forward to seeing more of the end product. I am glad the the post was received positively.

Your doing some bang up work around here. Now I just wish there were more hours in the day and more money in the wallet to do it all with.

 

[terahz]

Hey nauticac4, thanks for bringing up the first post to remind us what the goal was . I'd agree with DWZM that apart from the ethernet and the second chip used to split the "load" we're still "only" PH, turning things on/off (relays) and time/date+lcd.

One can put together the hydra without the second AVR and ETH circuit and have a fully functional controller. As a matter of fact, I'm running it that way at the moment on my tank.

Stay tuned, we're close to having a fairly working controller soon. At least that's my feeling