Must-haves for EASY DIY controller?

No, the slave AVR does not need to run the ENC. I only did that as a test with a shield I bought. Run the ping sketch on the main AVR.

If you do the following it should, hopefully, work.
CS (p9) -> d10
reset (p10) -> reset
p22 -> gnd
p24 -> +3.3V

On pins 22 & 24 I pulled the ENC out of the socket and bent them out sideways, then soldered some patch wires onto the pins to make sure there was no further interference. Was easier than cutting traces as well. Also when attaching some patch lines to CS and RESET, be sure not to get on the outside of the resistors. I soldered directly to the socket pins.
 
That sucks, I have an extra I can send you. PM me your address if you want.

Did you test it? What happened? Any LED activity on the magjack?
 
Oh, and by p24 above I mean p25 (Vddosc) :)

Anyway, nothing happens, unfortunately. No power is sent to pins 27 and 26 (LED pins).

Also not only does the slave AVR not need to, but it can't run the Ethernet because the rest of the signal pins are wired to the main AVR.
 
Yeah that's why I was thinking more about the jumpers for the ENC that you guys were talking about. I figured it would be easier to have the ENC on the slave to only have to poll the main AVR for current status.

Then again, I haven't even looked into the difficulty or limits of AVR communication. Jumpers should be fairly easy without running the risk or another problem. Hopefully we can stop at Rev2.0.
 
I have a spare HR911105A and a spare ENC if you guys want parts to test with, just shoot me a PM.

I'm still really torn on jumpers. I guess it would give people the choice, but I feel like we should be able to make a choice like that ahead of time, based on the functions we want each chip to handle and the resources available on each. My original thought was that the main AVR would handle driving onboard hardware (pH, Ethernet, RTC, LCD), and the slave AVR would basically exist for I/O capacity. But maybe we won't be able to swing such a "pure" division of duties.

terahz, I feel like the code you're currently running is the closest thing we have to firmware that does what we want. Remind us again where you are as far as space? Do you think it's realistic to squeeze the Ethernet code in with your current sketch?
 
Me and TeraHz traded. :cool: Thanks for the offer!

I would personally like the ethernet to be on the second chip, but I have no looked at the difficulty of communicating between the two AVRs. I just figured it would be easier to poll the main AVR for temp, pH, etc... variables. Then have the main AVR cover everything else, temp, pH, relay control, display,etc... In theory it would make for simpler code and avoid issue of trying to access certain hardware at the same time.

IIRC TeraHz stated he was at @ 25kB. A basic ethernet sketch to display a status page will likely run @ 3-5kB. If this is the same sketch he posted, he currently has LED control, relay control(routines, not implemented control), IR remote, pH. I don't think he had temp yet or any timer code to control the relays.

Maybe it's easier than I'm thinking. For example, I'm just figuring say pH, display, ethernet on the main AVR. Then having temp, relay control, etc... on the second AVR. You have the ethernet polling both chips for status variables, then you have the relay control trying to poll the main AVR for time and the display polling the second AVR for temp, etc...
 
Last edited:
No kidding, I would finally be able to get back to making my breakout boards for relay control, power, etc... I can't believe I didn't have enough sense to look at the giant sticker on the jack. Haha, I think TeraHz is the only one with a functional setup right now. The IR remote is going to be awesome BTW.

I edited my last post, I hit the quick reply button instead of advanced.
 
Does someone want to suggest a through-hole replacement for L1? That's the last "small SMT" device on the board (not counting the two voltage regs). I'd like to get a through-hole part for it so people don't complain about having to solder something tiny. I don't know enough about inductors/filters to pick a part. . .

Also, assuming we've solved the Ethernet function, let's take a vote:

1) Connection to ENC from main AVR
2) Connection to ENC from slave AVR
3) 3x4 jumper block (MISO, MOSI, SCK, INT) to allow either option

I vote #1, unless we really absolutely are out of code space. . .
 
I am afraid I need some reminders. What does the second AVR do now. IRC it does not do anything yet. But I think the plan was for it to handle and additional functions such ATO, water changes, dosing pumps etc. If so how much polling will be going back and forth (I know I keep bring up the comms issue, but I have had trouble with poorly thought out multiprocessor systems)?

Another thought. I don't have a server or any other computer on 24/7 or even close. So I will not be logging events. In fact I may never need to network connection since programming is by USB. So I would like to know what you want to use it for.

The code will be split and the division should be such the the cross communication is a minimum, IMO.

And please remind me are both AVR easy to reprogram (plug in a usb cable). If not this will greatly affect things.

Right now I agree with DWZM, but I am not sure I see the BIG picture.
 
My take:

TheFishMan65 said:
I am afraid I need some reminders. What does the second AVR do now. IRC it does not do anything yet. But I think the plan was for it to handle and additional functions such ATO, water changes, dosing pumps etc. If so how much polling will be going back and forth (I know I keep bring up the comms issue, but I have had trouble with poorly thought out multiprocessor systems)?
Click to expand...

The second AVR doesn't "do" anything via hardware (it's not wired to any of the other hardware on the board, except the main AVR via I2C) and none of us with working prototypes have done anything with it in software yet. Original intention was for extra I/O and program memory space.

Another thought. I don't have a server or any other computer on 24/7 or even close. So I will not be logging events. In fact I may never need to network connection since programming is by USB. So I would like to know what you want to use it for.
Click to expand...

I don't intend to use it for logging, but rather for remote monitoring - i.e. I'd like to be able to check a webpage, or twitter, or something else online to see my tank's current stats, and/or receive an alarm communication if something goes wrong. You COULD use the Ethernet connection for datalogging, via a local PC or via online service.

And please remind me are both AVR easy to reprogram (plug in a usb cable). If not this will greatly affect things.
Click to expand...

Yep, there's an FTDI-style header for both, so you can quickly and easily plug a cable or breakout into either to reprogram.

That raises another design question I have. Currently, the RESET lines for the two AVRs are NOT tied together. Not sure if anyone has thoughts on the implications of leaving it this way or linking them.
 
The "prod" version currently compiles at 19290 (out of 30720) bytes.

That includes IR, relays, LEDs, clock, LCD, menu via IR, IR learning, Clock/date setup.

After implementing the various limits/levels setup via menu + ATO, I'm guessing it will be up to at least 25K. The basic "ping" Ethernet example which does basically nothing, compiles at ~7K so we are out of space. There might be some optimization that will let us fit in 30K, but we'll also need some space for IO with the other AVR and I have no idea how big that will be.

That being said, I think we can treat the Ethernet as additional function thus falling under the second AVR. ATO, dosing and water changes are very small relative to Ethernet, LCD and IR for example.

My vote is for #2, if not, at least #3.
 
Can the AVR support 2 I2C buses? If not this may be a problem. I'll pick on ATO since that will be my first addition. If slave AVR is constantly (1/sec) checking switches. Are there going to be a lot of I2C collision because both chips want it. If it can support two I2C that it is not as big a deal.

However, the more I think about it. I think the ECN should be on the slave. Here is my thinking. Once every second (5 sec, 1 min) the master sends the current state of everything it monitors to the slave. The slave is then responsible for updating the web page or logging the data. It should never need to start the communication process - I think this will make the programming much easier. I am picturing the slave AVR as never bing a master in the I2C bus.

Advantages (at least in my opinion)
The end user may never touch the second AVR (or even need it) if they don't want networking. Not sure one pricing, but this could save significant money.
One routine to modify in the master if you want to add another data point. Not sure what it would take in the slave.

Disadvantages
perhaps a little more awkward if you want to be able to turn pump/etc. on and off from the network connection.

[EDIT]
Just to clarify I am picturing the second AVR only for networking. All other function in the main AVR. I know this is not what was planned, but may be easier for the novice user to understand.
 
TheFishMan65 said:
Can the AVR support 2 I2C buses?
Click to expand...

No, but it doesn't need to. We'll have one master, everyone else will be a slave. Though, technically, the I2C implementation on the AVRs should support a multi master bus, so if we DID really have a need, we could go that route.

If slave AVR is constantly (1/sec) checking switches. Are there going to be a lot of I2C collision because both chips want it. If it can support two I2C that it is not as big a deal.
Click to expand...

ATO will likely be via plain old GPIO, not I2C. Since all you're doing is checking/setting switches/relays.

However, the more I think about it. I think the ECN should be on the slave. Here is my thinking. Once every second (5 sec, 1 min) the master sends the current state of everything it monitors to the slave. The slave is then responsible for updating the web page or logging the data. It should never need to start the communication process - I think this will make the programming much easier. I am picturing the slave AVR as never bing a master in the I2C bus.

Advantages (at least in my opinion)
The end user may never touch the second AVR (or even need it) if they don't want networking. Not sure one pricing, but this could save significant money.
One routine to modify in the master if you want to add another data point. Not sure what it would take in the slave.

Disadvantages
perhaps a little more awkward if you want to be able to turn pump/etc. on and off from the network connection.

[EDIT]
Just to clarify I am picturing the second AVR only for networking. All other function in the main AVR. I know this is not what was planned, but may be easier for the novice user to understand.
Click to expand...

That makes sense. I think you guys are convincing me to lean towards #2.
 
If I am reading it right 6 Analog I/O and 14 Digital. Seems the common number is 8 for relays, 2 or 3 for ATO (water level in sump, water level in reserve, safety in sump), 1 for water chagnes (salt water reserve), 1 for skimmer level to prevent over flow. That is 13 out of 20. I am sure I am missing someone's plan and their implementation will be different. But my question is do/will we have enough GPIO?
 
I vote for #3, jumper block. Even if the user doesn't end up needing a complex web based side of things, there is still the option should you choose. Seems to be the simplest(codewise) way to go. I would love for #1, but I can see issues for those who want complex logging servers or remote control. Option #2 would work, but then there could be unnecessary communication between AVRs when all would fit on one chip for a good number of users, plus I believe the jumper option would probably be the easiest change to the board without risking another problem. That's my opinion on it anyway, but again, I have not fully explored AVR communication other than communication in general could get tricky for some people.

The way I see it now the likely functions of the board are going to be: Time, Display, pH, Timed Relays, Temperature, Ethernet, and probably either IR Remote or Keypad

Time, Display, pH, and Remote/Keypad are probably best on the main AVR.
Temperature, Ethernet and Remote/Keypad are the options. Remote/Keypad are probably best on the main AVR. Then you have Temperature and Ethernet, which Temp could easily be on either. Like you said though, I think the big limiting factor is going to be sketch size, which ethernet could easily cause a problem.

Also, on the port expanders. Can more than one MCP23008 be on the same SCL/SDA pins of one AVR?

FishMan: As it stands the second AVR is doing nothing. For the average user I think it would be best to avoid as much cross-communication as possible.

You would use the ethernet in the simplest way to display information such as pH, temp, etc... while you are away from the house. You wouldn't need a server or computer on this way. The Hydra will be connected to a port directly on your router.

As for programming the AVR's, there is no FT232 chip onboard. You would need either a USB cable with the FT232 chip built in and configure your own pin header plug, or buy a USB-BUB(or similar) from modern devices. You can plug it into either FTDI row for each chip via a standard USB->USB-Mini Cable.


If we were to add the jumpers for the ENC, for my requirements I would set it up as follows:
Main AVR: Time, Temperature, pH, Timed Relays, IR Remote
Secondary AVR: Get variables from main AVR and send to my remote server for display/recording(or just display the page from the ENC). In my case of sending variables to a dedicated server, this could drop the ethernet code size allowing a single AVR as well.
 
terahz said:
Relays don't take pins. They are on the I2C bus.
Click to expand...

I was thinking of the model where the second AVR does all the extra functions (ATO, saltwater change, wavemaker). In which case it would probably control the relays. And I did not think it could be a master so the I2C was out.

You have more of what I was thinking main AVR doing all the work so the I2C bus is available.
 
You must log in or register to reply here.

Similar threads

A
Aquarium Temperature Control: How I Hacked My Air Conditioner to control my tanks temperatures
Replies
6
Views
325
Naso180
N
R
DIY AI-coded ESP32 based aquarium controller
Replies
0
Views
674
ronnyking
R
E
Neptune DDR diy question for AWC
Replies
3
Views
357
Reefing102
Reefing102
J
Heater controller
2
Replies
23
Views
1K
Dustin07
D
B
Question on Mean Well 3-1 dimming
Replies
15
Views
568
bmichaelb
B
Back
Top