DIY controller

[fppf]

"Since this is standalone and can connect to a Pc to setup and record data you double the programming required."

I banged out my interface code for the micro in assembler in about a day. The PC based support code took about another day. My biggest time soak was supporting the dam display and keypad navigation.

Na, software is my area. That and I used all SMT and packed it as tight as I could at first, then went through about 10 revs of the design before I even ordered a board getting costs down and making for good mfgring. Of coarse the free layout software had a little to do with the time. I totally agree on the autorouter. We always used it as a place to start then went from there.

 

[ronc98]

funny, display and keypad where the easiest task in my project.

Writing user interface takes time plan and simple. Cal routines and variable setup took must of the time

 

[BeanAnimal]

I have looked at tons of proto and fab houses. I have never been able to justify the cost for most of my projects. ExpressPCB is kinda neat, but they use proprietary software and it is kinda limited. I love the masks, but think I am to cheap to pay for em.

Nice design... Can't wait to hear more.

Bean

 

[fppf]

Cal is not that bad, take 2 readings at given points and do a little math, store some factors, done.

My next big jump will go from a set amount of timers and control loops to any amount of timers and control loops until the EEPROM is full. Thats going to take some code.

 

[BeanAnimal]

some code? Don't ya wish you had resuable object collections! I keep remembering why I don't like system level programming any more.

Drag drop...autocomplete... and did I mention I love through hole.

Bean

 

[ronc98]

You must not write any user interface for your cal routines. not as simple as take two readings and do the math. User interface using a display and only four buttons takes sometime asy but takes time. Then add all the different menus to pick and chose what you are calibrating/mapping or variable setting. somthing that is not written in a day to say the least.

 

[BeanAnimal]

I would image your menu service routine and logic is pretty confusing with that kind of featureset.

Kinda makes me want to look harder at XP embedded.

Bean

 

[ronc98]

I prefer writting firmware, anything where I have to writing around Mr Gates bugs bums be out. I would rather have complete control of the processor where in the Pc based end you have those extra layers Mr Bill controls. I would never make a controller based on an Microsoft operating system. Too many blue screens of death.

 

[ronc98]

Once you get the kernel written and some decent menu routines it is not that bad. I used a kernel from another instrument I designed I just had to yank out the stuff that was not needed.

 

[BeanAnimal]

you trying to say that bill wastes a few cpu cycles?


I am just not comfortable enugh with assembler or C anymore. It's been way to long. My only option at this point seems to be to push forward with my ATMEGA128 design using the bascom-avr basic compiler.

This thread (and fppf's) have got me re-inspired to go uC instead of windows. I have replaced the pretty bikini model on my desktop with that curvey sexy soldermasked board.

Bean

 

[cduran02]

Where did you have the PCB made, Ive used the PCB123 people and their a bit expensive. Never mind I just read you did it yourself.

BTW, great job, cant wait till Im completely done with mine. Mine is based on a PIC 18F2620, but Im taking a more modular approach. Going to design 21bit ADC modules with SPI output for probes, and still toying with using X10 for control (jury still out on the X10).

 

[fppf]

Once you have the menu setup done the cal is easy.

But yes the dam menus and key navigation is the pain part.
About half way through I thought, why don't I just use all computer interface?

It really comes down to what your background is. Everyone has different strength and weakness points.

Bean, I reuse almost all my micro code. I have subs written to do just about everything. I have been using some subs for that last 4 years. I guess thats another reason I stuck with this chip, oh well. Its all about how you write your code and how its structured. That is why I don't open my stuff up for multi developer unless at work. Its really easy to write bad code that still works.

 

[ronc98]

True Fppf on using subs over and over and sticking with a product line you are used to.

Free code is never bad code unless it does not work. If it works it is automatically Good code! I ahve looke back at some of my stuff and wondered what I was thinking

 

[cduran02]

Depends.....Bad code doesnt mean it doesnt work....Free code also doesnt have the pressure of being FIRED lol.

True Fppf on using subs over and over and sticking with a product line you are used to.

Free code is never bad code unless it does not work. If it works it is automatically Good code! I ahve looke back at some of my stuff and wondered what I was thinking

 

[csammis]

Free code is never bad code unless it does not work.

Even if it does work, it could still be ugly, or unmaintainable, or undocumented, or the coder's definition of "works" is different than the customer's idea of "works," or any other one of a hundred things that would make me drop free code in a heartbeat over a non-free but better implemented solution. Free does not imply good, just as non-free doesn't imply bad

 

[fppf]

I put food on the table with 100% of software coding work.
Free code can be bad.
I have seen some really $$$ that is out right horrable.
Try telling a customer that what he paid for is not worth anything and its just going to be cheaper to start over. When you say that most of the time they start screaming. Then you give them the hour est. and its only 1/4 of what it took the other people to do. Then you given them an hourly rate of 50% more. So in the end we may have a higher hourly rate but you get what you pay for, one of our hours is like 3 or 4 of the other guys hours.

 

[csammis]

Amen to that, fellow software engineer :artist:

 

[Mind_nl]

Looks very impressive! But what's up with all the cappacitors on the 7805? I normaly only use 4 on mine... then again: my main field of expertise is software.

 

[ronc98]

They are not just for the 7805. That is just the general place I put all decoupling caps for the 5 volt devices. You need them someplace in line for the netlist to generate properly. There is also a huge bank of caps across the +-12 volt lines. Same thing for those.

 

[ronc98]

Code update. I have just added a few more features for the controller.

I finished the moon simulator. It basically drives blue and white LED clusters depending upon the intensity of the moon. The intensity follows a 29 way cycle. You pick the day of the new moon and it stores this day in NV ram. As the moonlights are coming on the Led's intensity is set. I can drive two LED arrays individually at 15 watts each.

I am finishing up the dimming portion of the VHO lights. I would have had this finished however I just found out my 660 ballast does not support dimming. bummer I guess I have to send it back for the upgrade. This dimming functions works in parallel with the light schem I already have. It just throttles the lights from 10 to 100 percent in a setable time. When the lights come on and the dimming feature is enabled the light comes on at 10 percent. then slowly increases itself to 100 percent in a set time interval. I do the same when the light goes off, it decreases from 100-10 percent in that same time. I have been toying around with a weather feature where each day it will have a random weather feature. There is not much I can do other then adjust the intensity of the lights(VHO) and perhaps adjust the wavefunction. This might be an ever changing feature because I am not completely sure what I am going to do with it yet.

Finished onboard storage function. I have enough room to store 320 days of data. The data will consist of sunrise/sunset time, moon phase, min/avg/max temp,ph,orp,AUX probes. I am also going to store any status errors that happen and period of time level Switches(inputs) where active. All of this can be stored via the host pc, or viewed by day on the controller itself.

Next on the drawing board is a conductivity meter. I have a good circuit layout just need to prototype it.


I will post another update in a week or so.