Must-haves for EASY DIY controller?

[nauticac4]

Forgive my lack of knowledge again as I am just getting immersed in the whole Arduino thing.

Could the memory problem be solved by using one of the SD card expansion boards. They are fairly cheap at $12-15 bucks and most folks have a few SD cards laying around and if not they are cheap...Plus this might allow for some data loggining in Revision II.

 

[TheFishMan65]

I am. I have read the threads, but with out hands on design I have trouble keeping them all straight. I agree the boot loader should not have to be programmed. Do you know the difference between the 1280 and 1284? There appear to be 3 sets XXX0, XXX4, XXX8. The 8 series appears to be what was used in the Arduino environment. The 1284 has a 40 pin PDIP (13x52mm) so a little bigger then two of the 328s. Is the 4 series available with the boot loader? Sorry to add to the confusion -$0.02 back to $0.04.

There is also the option of adopting an existing board and only making a shield. Yes, that is more expensive, but would solve the board space and memory problems.

[EDIT]
The memory problem is so much in logging data as having room to store the code. Think of it as harddisk versus RAM. When you run out of hard disk space you can not add any more programs adding RAM won't help.

 

[der_wille_zur_macht]

FishMan,

The only "official" chips with bootloaders are the ATMega8, ATMega168, ATMega328p, and ATMega1280. The ATMega644 can be used with the open-source Sanguino bootloader which is a modification of the official bootloader. Otherwise, you're pretty much on your own. I dunno about differences between other chips, I don't know if there is any standard meaning to the model number other than that bigger numbers usually seems to mean "more powerful."

nauticac4, as FishMan mentioned, there are different types of memory used for different purposes, just like in a PC. Generally, the AVRs have:

Program memory (aka flash): More or less like the hard drive in a PC, it's used to store the program you want to execute. Program memory is persistent - it stays put when the chip is power cycled.

RAM: Like the RAM in your PC, it's used to store variables that your program uses to run. RAM is wiped clean when the chip power cycles.

EEPROM: Sorta like a hybrid between a PC's RAM and hard disk. It's used like RAM (to store variables, not code) but it is persistent.

The chips have the following specs, in kb (using a code tag to preserve spacing in the table):

      ATMega168    ATMega328    ATMega644    ATMega1280
Flash    16            32          64            128
RAM       1             2           4              8
EEPROM   .5             1           2              4

With the current 328, we are running in to two problems:

1) Our code will likely come close to filling up the program memory (flash).
2) Our code needs so many variables that we are filling up the RAM, too. This can be solved by shuffling larger variables (i.e. text arrays to provide a UI on an LCD) into program memory space.

An SD card cannot really solve either of these problems. There's just no way to store program code or variables on an SD card. You can buy external EEPROM chips, but it doesn't totally solve the problem for "static" things because you'd still need to write those things to the AVR and have it write them to the EEPROM. EEPROMs are really best for variables you need persistent (i.e. settings configured through a UI on the device) and SD cards are really best for when your device will be generating historical data you want to look at later, i.e. datalogging over long periods of time.

 

[TheFishMan65]

Ok, I think that if this was just for me at this point I would design using the arduino mega. Make a shield for that that has everything the hydra has (minus the arduinos). Add to the hydra the connection for a Arduino shield if possible. This solves the memory and board space issues at the cost of price ($65 for the Arduino mega).

The mega also add more PWMs for those that want sunrise east to west across the tank. I admit it would look cool (if you are there), but I can't imagine that 8 feet is enough to tell the difference in light level of a real sun rise/set.

So what is the disadvantage of doing this (other than cost)?

 

[terahz]

Right now it seems like we're facing two problems:

1) We're worried about memory on the main AVR and haven't even implemented Ethernet yet
2) The Ethernet hardware doesn't seem to be working in the current design anyways. Even with the two fixes I mentioned earlier, I still get zero response. I watched the various SPI lines as the device booted and it does look like the Arduino is trying to talk to the ENC chip, but it never does anything. Could be a hardware or software problem, but I don't know where to troubleshoot either way.

For 1, we might be able to fit in one AVR. I'm 90% done with the code for everything except Ethernet and I'm at 22K sketch. I'm hoping I'll be under 25K when done and when I do a pass to optimize for space, there might be enough space to fit everything on a single chip. It will, however, be tight!

For 2, if it s a big pita, then let's just put a breakout for this (with the supporting circuitry):
http://www.criticalvelocity.com/item.php?itemid=wiz1

That should make it straight forward and modular so that ppl who don't want to can skip the Ethernet

Or, we could troubleshoot the hardware, and continue on the current path.

I still want to give it a try to troubleshoot this. I'm sorry that I haven't been able to do it yet, but I'm trying to make sure the rest is working because I'm going away for a week and something must be taking care of the tank

I understand that there are people who want to see this in a more complete status already so that they can start making their own, but lets not rush it.

Regarding switching to an SMT AVR... if we go that route we can make it all SMT (I'd love that) and probably reduce the size of the controller in half. However, even only the AVR in SMT will be a problem for the average reefer who wants to try a DIY controller with his 15W radioshack soldering iron.

I'd suggest we finish everything else, and leave the ETH part for last. I don't think we should be making any big changes until all of us with the first batch of boards haven't tried to debug/test/run it.

 

[TheFishMan65]

I can't find it right now, but I thought DWZM said the ethernet code was huge 10k. If so you need to keep it under 22k and that leave no room. I was hoping to add ATO code and maybe water change code. It might be worth thinking about what else might be added. that may help us decide how much code space might be needed. To me ATO is more important than PH, but reading a couple relays doesn't require any changes on the board, so in that sense it is designed in.

terahz, Do you just turn your LEDs on and off. Or are you simulating sun rise/set?

I really don't think we want to turn this loose with no/little memory left for expansion. The masses will want to add something. However, I like inexpensive . I also worry about processor to processor (I know you have examples), but I have done it for simple projects several times and it always comes back to bite us.

 

[terahz]

yes, the ETH code is in the 7-10K range. And we really have 30K (not 32s) available on the chip so it is very tight for one chip to do it all. That's the main reason I suggested a second one. I think a second chip dedicated for ETH is the best way to go. That way we have enough space to program a nice web interface. All we have to do is make the main AVR send updates to the ETH one (or something like that).

for LEDs, I have the sunrise and sunset done as well.

here is the latest code that's running atm.
http://svn.geodar.com/hydra/branches/prod/

The IR rcvr(TSOP34838) is on pin 8 and the BKL+ on the LCD is on pwm pin 6 for dimming.

To enter learning mode for the remote for the first time, uncomment:
//enter_setup_mode();
(after that it can be called from the menu)

 

[OTCHU]

My proc have 64K of memory .... like I said, I still need to put ethernet and the Ph control in it and right now I am at about 31K of firmware. So I do have 31K left.

I heard (for the PIC processor) you need about 10K, so I should be OK but if I want to do an advance website, I think I will need a lot of more ....

der_wille_zur_macht, I did a prototype last night for the PH and it's not stable in ambient temperature. Just to be curious, I did put that in my temperature chamber and IT'S NOT GOOD !!!!! Not stable on temperature (40F to 100F). For sure it's not the amp op. I need to figure out what is wrong on this schematic .... Do u guys have an idea ?

 

[der_wille_zur_macht]

I can't find it right now, but I thought DWZM said the ethernet code was huge 10k. If so you need to keep it under 22k and that leave no room. I was hoping to add ATO code and maybe water change code. It might be worth thinking about what else might be added. that may help us decide how much code space might be needed. To me ATO is more important than PH, but reading a couple relays doesn't require any changes on the board, so in that sense it is designed in.

terahz, Do you just turn your LEDs on and off. Or are you simulating sun rise/set?

I really don't think we want to turn this loose with no/little memory left for expansion. The masses will want to add something. However, I like inexpensive . I also worry about processor to processor (I know you have examples), but I have done it for simple projects several times and it always comes back to bite us.

We have pretty much the full flash on the "slave" AVR at this point, which is where I'd implement stuff like ATO, water changes, etc - which should really only add a k or two to the code, worst case.

For reference, here are some Ethernet sketches I have and their size. These are by no means complete but to give an idea:

Ethernet ping: 3k
Ethernet, super simple webserver (show values of a few I/O pins): 5k
Ethernet, fully functional twitter client: just under: 10k

If we switch to the Wiznet Ethernet interface instead of ENC, the code will probably shrink a bit, since the Wiznet module implements some functions onboard that the ENC requires you to implement on the AVR.

At this point, I agree with terahz - let's not make any sudden changes until more of the prototypes are complete, and people besides me take a stab at the current Ethernet design.

 

[TheFishMan65]

Oh, I am willing to wait. I just thought it was back under discussion. Please keep us posted.

 

[nauticac4]

Has anyone sent the board to be prototyped?. I was thinking of burning a few bucks and ordering boards for the Cat4101 Driver and I figured while I'm at it I'd take a crack at this one as well. Didn't know if the Eagle files on the Code site had any known problems. Haven't been able to look at them because I am at work.

 

[terahz]

By prototyped do you mean PCB only or PCB + components?

We have a few PCBs that we're using to test:

 

[theatrus]

Looks good so far. Nice to see hardware built up

Do you have an off the shelf enclosure in mind? It would be nice to mount it in something available like a Polycase box to protect it.

What is the drift on your pH probe? What temp probes are you trying to use?

 

[Foosinho]

This is offtopic, but I'm currently helping a grad student improve his code, and we started with 6MB (over 160k lines) of Fortran code that compiled to a 9MB executable. So this talk of 22k is amusing to me (what I wouldn't give to be dealing with something that small!). In fact, he has single functions that are bigger than that.

If you are careful, I'd be surprised if you couldn't make it. Really, 32k is a decent amount of space. You might just have to spend some time optimizing.

I wonder if you could write code that could page program code out of EEPROM memory? That'd be a trick. Probably publishable, too, if it hasn't already been done.

 

[theatrus]

You're not counting all of BLAS are you? :-O

Paging out of EEPROM is possible, however you're going to hit the 10k erase endurance of flash in very short order. AVRs cannot execute code from RAM.

If you're looking for more power, and lots of connectivity, I'd honestly use a BeagleBoard. There are a lot of Linux-accessible GPIOs and buses, plus you have 10/100 ethernet (xM) and high speed USB, HDMI (or raw LCD), plus you're running from a SD card, all at around 5W of power. I've made a handful of expansion cards for various purposes, but ironically never for aquarium control (I'm still using an ACjr ))

The cost is of course an issue - the Beagle alone ($150) would be more expensive than the Hydra

 

[OTCHU]

Terahz ... good job .... I am impressed. For my projects I still making the boards by myself at work lol We have a little room with all the equipments to make them ... It's very basic and don't look good like yours but it's working n it's free lol
I have all the stuffs available too to make labels so if your guys need that one day, just ask me, ok?
Still don't have solution for the PH ?

 

[terahz]

OTCHU, DWZM is the one who made the PCBs.

Regarding the PH, which circuit are you using again and how are you taking the reading? If it is the same circuit as the hydra, did you keep the analog parts away from the digital? Also when you take a measurement you should take a few samples and average them. That's what I do on mine and seems to stay quite stable.

 

[Foosinho]

You're not counting all of BLAS are you? :-O

Nope.

 

[terahz]

Does anyone know how long is the battery supposed to last on the hydra without any power for a long time? I unplugged mine Thursday night at 3.3V, today I get 0V. I have no idea how long when the battery died, but if it lasts only a couple of days, that doesn't seem right.

 

[theatrus]

From the schematic, the only thing being powered by the battery is the RTC, which should go for years. Double check the current consumption with a multimeter.