Must-haves for EASY DIY controller?

The simplest approach would be an ENC28J60 chip which isn't as sophisticated as the chips used by the "official" Arduino Ethernet shield, but are probably good enough for what we want.

I'm doing Ethernet either way, just wondering if others think it's worth baking in to the Hydra board itself. From a cost perspective it seems like a clear option. Even if you dig for a cheap unofficial Ethernet shield, they're usually at least $15 more than it would cost to just put it on the mainboard.
 
Just a quick summary, mostly for my own sanity. We're embedding an ATMega 328P as is used on the Duemilanove.

We're including the following additional circuits:

1) MCP23008 on I2C for driving an LCD
2) RTC on I2C for timekeeping
3) pH monitor on Analog 3
4) Breakout header for One Wire on Digital 2
5) Breakout header for an IR sensor on Digital 4
6) Onboard buzzer for alarms on Digital 7
7) FTDI-style programming header

This leaves us with:
-Analog In 0, 1, 2
-Digital 0 (Rx), 1 (Tx), 3 (PWM), 5 (PWM), 6 (PWM), 8, 9 (PWM), 10 (PWM), 11 (PWM), 12, 13

If we add an onboard Ethernet interface with the ENC chip, that would mean we use SPI, which means pins 10, 11, 12, and 13 are consumed. So we'd lose two of the PWM pins, leaving only 4. The other option for Ethernet is to go with a device that uses the Serial port, but then we lose the UART serial port (2 non-PWM pins) and serial ethernet interfaces are very expensive anyways.

If people want more PWM or GPIO they can use breakout boards with port expander chips. Or just slave a cheap Arduino clone on I2C I suppose. . .
 
Terahz or others, what's your level of attraction to ethernet functionality?
Sure, why not. If it doesn't add too much to the cost it would be nice to have an online monitor + alerts :)


If we add an onboard Ethernet interface with the ENC chip, that would mean we use SPI, which means pins 10, 11, 12, and 13 are consumed.
Ah it would be so nice if we can use the i2c bus for ethernet as well... I haven't done any reading on ethernet yet, but will take a look. Are we still in non-smd mode, I don't know what packages is this available in?


On a side note, I have a bunch of parts coming my way on the power module, so I'll soon start posting some progress on that.
 
The ENC chip is available in a DIP package. It needs level translation and a 3.3v supply, plus a crystal, but we can get those in through-hole form, too. This is the chip that's in all the "cheap" unofficial Ethernet shields (i.e. seeedstudio's cheaper shield, nuelectronics, etc.)

I've done a few searches for an I2C ethernet interface but haven't seen anything. I agree it would be really sweet. One crazy thought that enters my mind is to put another ATMega8/168/328 on the board, run it as an I2C slave, and use it as a dedicated SPI controller for the Ethernet chip plus we'd get additional PWM and GPIO pins if we needed them, eliminating the need for more port expanders, and the Ethernet and SPI code wouldn't be taking up memory on the main chip. That would be getting in the realm of silliness though. :lol:

FWIW I'm operating under the assumption that we'd be getting boards from seeedstudio's prototyping service, in the 10 cm * 10 cm price bracket. That means we can make the board bigger up to that limit, essentially for free - so PCB cost won't increase if we add these additional features, as long as we can keep under that size (which I think we could even with this additional stuff).
 
We are back to the lack of output pins. So, it appears the ATMEGA328 is about $4.30. The teensy is $18-24, but we get a lot of pins. I missed the reasoning why not to use one (or more) of these to get extra space between the boards so the teensy could be soldered in and not interfere with the shields.

Another option is to mirror the pin payout and attach the shields on the back (solder side) of the main board. This should allow for no interference. It would just have to be very clear on the build instructions.

I would avoid multi-processor communication it sound simple, but something always comes up. Usually a year after you started shipping. And you are trying to keep it simple for the masses. You would probably just be better of putting your lights (since they are fairly independent of everything else) on one. And all the water monitoring functionality on another.
 
We are back to the lack of output pins.

Welcome to my world. I'm one of those people who goes in circles when there isn't a clear choice. :D

So, it appears the ATMEGA328 is about $4.30. The teensy is $18-24, but we get a lot of pins. I missed the reasoning why not to use one (or more) of these to get extra space between the boards so the teensy could be soldered in and not interfere with the shields.

Those headers give you more height on the "male" side (UNDER the PCB) the female side is standard height, so you don't get any more clearance on the top of the PCB. We're already assuming the LCD is going on the bottom of the board, so nothing else can go there - unless we default to using a cable for the LCD.

I would avoid multi-processor communication it sound simple, but something always comes up.

I agree, it would likely be a huge nightmare. I've done VERY simple multi-Arduino I2C networks, but it was the sort of thing where one Arduino sent a string of text to another, and the second printed it on it's serial port. Not the sort of rocket science we'd need to implement my suggestion above.

I feel like we already have good solutions for more GPIO pins (just use port expanders, i.e. MCP chip we're using for the LCD). The one problem I don't think we have nailed is more PWM ports, since it doesn't seem like there's an easy to use I2C solution for that.

I'm going to do some more searching today. It sounds like the consensus is to put the Ethernet hardware onboard, so we'll go that direction, and try to find a simpler way to get more PWM if we need more than 4. I will definitely need more than 4, but I'll probably be going the route FishMan is suggesting - using a second cheap Arduino clone to run the LEDs, and just have it "check in" with the main controller for dirt simple communication, if needed (i.e. once a day it gets the time or something).
 
I missed the fact that the LCD would not have a cable.

I have a feeling I am not explaining myself well for the connectors. Solder one of the connectors to the Hydra. Plug/stack another connector into the soldered on. Then plug the shield into that. Rather than have 1 female connector worth of clearance there is not two. Not enough then plug a third one in before plugging in the shield. I will try and do a character picture (ignore the periods):

--------------- < shield
| <.............. connector
| <.............. connector
--------------- < hydra
 
Still trying to figure it out dwzm? You usualy respond much faster :)

If you are making the board larger you might consider a second (or more) bnc connector. American Marine make a variety of probes: calcium, salinity, nitrate, etc. That might be useful. I know more pins to use up.

I missed temperature on your last list of included options. Is that a separate option through IIC.
 
Sorry, I missed it. :)

I get the concept of stacking, but honestly at that point, why not just mount the shield next to the Hydra and use jumper wires to connect them? I know I'm playing devil's advocate here. ;) Plus, going with a Teensy or Teensy++ means a non-core-Arduino processor, so we'd be hooking our project to the Teensy vendor's support and development. Not saying that's the end of the world, just something to consider.

And I think we nearly have the pin problem solved anyways. Plain old port expanders give us more general purpose digital pins with minimal effort, and we're still going to have four PWM pins, which is probably enough for most folks (correct me if I'm wrong, people.)

Temperature - I'm assuming we'd do it through One Wire or I2C. The One Wire temp sensors are dirt cheap, easy to use, and common. The only real "problem" with them is that you need to pause after you've asked them to do something, which makes me wonder about I2C options. Either way, one of the two interfaces should be just fine. Absolute worst case, you could use a thermistor on an analog input pin to do temperature.

I've thought about adding BNC connectors and additional amp circuits for other probes, but I'm guessing you'd need to tailor the circuit to the specific purpose. Since the only real consensus seems to be that nearly everyone wants pH, I put that one on. If people want others, they can do a breakout and either use a One Wire or I2C chip, or plug directly into one of the open Analog In lines - we've got plenty of those.
 
I am just throwing out ideas. That is what you wanted - wasn't it.

PWM - I think for most people 4 are enough. I think I am using two for moonlight control of one bank each blue and white. The rest of the banks would be hooked up to the other two PWMs. BUT we would get much more realisitic sunrise if we could control each bank individually. Imagine the sun getting brighter east to west over our tanks :). Don't forget lightning. We need a whole other group we can flash on and off. These are not something I intend, but I am sure someone might. Sump control may also push for a PWM although mine will be on/off.
 
I'm actually FOR the multi-headed hydra :D. Why not use an Atmega chip as extender on the i2c bus? It is not really that expensive and we can just program it as a dumb switch and nothing else. That way we can have all onboard hardware use the dumb switch and report to the main cpu via i2c and all other pins on the main cpu will still be available. I'm up for the coding challenge. Just a thought.
 
It WOULD add a certain sense of "correctness" given the name we've chosen, since a Hydra is supposed to be a multi-headed beast. :D

Time to do some digging on the web. I know there have been a few really good forum and blog posts on multi-processor implementations but I never paid attention to them.
 
I don't think you will like this because I doubt it could be done at home. It does have a lot of advantages so I will mention. Several FPGAs (field programmable gate arrays) are coming with source for a on board microprocessor. What this means is that each pin can be configured for what you want (and there are a lot of pins). And you don't have to buy a processor it can be programmed in. Altera makes the cyclone which is where my company is headed.

If you want more info I will help you find it. I don't think you will want to go this way, but I figured I should al least mention is an option.
 
I don't think you will like this because I doubt it could be done at home. It does have a lot of advantages so I will mention. Several FPGAs (field programmable gate arrays) are coming with source for a on board microprocessor. What this means is that each pin can be configured for what you want (and there are a lot of pins). And you don't have to buy a processor it can be programmed in. Altera makes the cyclone which is where my company is headed.

If you want more info I will help you find it. I don't think you will want to go this way, but I figured I should al least mention is an option.

I've done a fair bit with FPGA's, and it's a world away from the current level of project you're considering, IMHO. Yes, you can get FPGAs with embedded systems, but (a) they're expensive, (b) they're unfamiliar, (c) they're hideously complex by comparison, (d) they're not available in home-friendly soldering packages, (e) interfacing them is more awkward, and (f) you have to start worrying about parasitic capacitance, trace load and impedance, matching traces on the PCB that run at high frequency, spread spectrum clocks etc. etc.

I tend to use BGA chips, which solder reasonably well in an SMD oven at home, but not everyone has an oven, and the PQFP devices are normally very fine pitch - 0.5mm is typical.

If you're into coding C, a verilog module is superficially similar - indeed I used that argument when I was pitching an internal project. The problem is one of "coding" - you have to wrap your head around the fact that almost *everything* happens in parallel due to the 'always @ (sensitivity-list)' statements. It's a different mind-set, and it takes software programmers a while to adapt, at least in my experience.

You *can* do FPGA's at home (I do), but it takes a reasonably sophisticated setup - I use the PCB machine to engrave the circuits, a solder-paste dispenser to put the solder-paste on the circuit, and an SMD oven to actually solder the parts. It's do-able, but it needs a level of investment that I don't think is typical. Bottom line: I would stay away for something like this, but hey, don't let me stop you if you're keen :)

Simon
 
found this today Hydra buck puck shield
http://batchpcb.com/index.php/Products/27303

Awesome, someone else is using our name. :lol:

You *can* do FPGA's at home (I do), but it takes a reasonably sophisticated setup - I use the PCB machine to engrave the circuits, a solder-paste dispenser to put the solder-paste on the circuit, and an SMD oven to actually solder the parts.

And I'm pretty sure you're the only person in this thread (except maybe kcress?) who has those capabilities at home. :lol:

Regarding the Hydra design, I still haven't finished putting the Ethernet interface onboard. Been too busy playing with the LED drivers, and I got a 20x4 LCD from Moden Device last week (real nice blue/white) so I've been distracted. :D
 
Back
Top