Why do I use Ethernut ?
Ethernut is a nice little controller with a lot of IO-pins. I
use it to control heating in my house.
In contrast to the old (version 1) C-control 1
provides an ethernet-port, ten
times increased clockrate, 100 times more RAM, serious programming
in C, a GPL development environment and an OS with POSIX support,
no programming restrictions compared to the latest ccontrol.
Ethernut consists of HW and SW. Both are for free under GPL, but HW is
easiest bought at egnite. The SW
consists of a bundle of application
examples and an impressive operating system called Nut-OS.
In writing my heating control SW, I profited much of the helpfull
ethernut community. As a give back you find here my source code which
you may use as programming example, especially for your own HW control
application in your house.
Download: this tarfile contains my
enhanced eboot and the application code
"Solaranlage", all based on NutOS 3.9.5.
NEW: I totally reworked the code, made it cleaner. I'd not time yet to
post it here ...
eboot: the original eboot unconditionally downloads the
every reset. This wasts write cycles. My eboot first looks for an
update indication on the DHCP-server
starting any downloads. for details see the commentary in eboot.c.
app/1wire: I introduced two changes into this device driver:
moved the cpp-definitions for port-accesses from 1wire.c to my
"Solaranlage.h" in order to rise the level of abstraction. Then I
few timings and port accesses in the bit functions; in my view these
fits better to dallas datasheets. (my HW works: 9 DS1820 on 20m
Solaranlage: this application consists of an header and
cfile. It was
designed to control my solarthermal facility
Solaranlage.h: bit-port access is abstracted by locating the
HW-mapping information into a structure, and by using a cpp-function
changing IO-bit-values, eg.
ioporset(valve,s,s) sets a "valve" bit to 1. This functions does the
job to look
for the bit-number and port-id associated to valve. More exaples in
Solaranlage.c. The structures support Dallas sensors, analog inputs and
output-bits called "Relais".
Solaranlage.c:For detailed explanations glimpse into the
instead of constraining my input analog
ports to 4 (the upper
nibble is blocked by JTAG) I preselect 8 inputs by means on the chip
LTC1390. Selection is done
all strings are located in flash in
order to relieve RAM. Done with
Dallas devices are read with full
precision and crc-check.
everybody not requiring sub-kelvin
precision for temperature
use a simple NTC instead of Dallas devices. Advantage is a broader temp
range and saving money.
NTCADC() and NTC2T() read the NTCs and return the absolute temp.
I store my sensor data each hour into
the eeprom of Ethernut.
initializes this job, the Thread Eeprom stores the data and
retrieves it into the open stream (V24 or ethernet).
A simple user interface is provided
which may be contacted with a
telnet under linux. EthNew() initializes the channel. I have to admit
isnt used: it always crashes if the ethernet port is unpluged (but DHCP
eboot, I cant explain this).
The thread Ethernet listens to any incoming telnet request and provides
a set of
commands like status, help, set output ports to fix values...
msg_P() handles all print-messages. It
forks them to V24 and
it stores important messages into a fifo which will be displayed on the
a watchdog thread reboots if the main
hint: I still dont understand how to assign memory to the threads. too
few heap results of course in a crash, but to mush also. No indication
was available, and I failed to get NutTrace operating. The current
values works, for now!
HausMain.c: in future I'll
provide the code for my house-Ethernut, that controls all heating
devices and an LCD-terminal.
A plot of the measured temperatures in my solarthermal facility is here.
My Ethernut is connected to a lot of dallas devices. This is a graph of
all dallas temperate-sensors in my house:
This shows the used heating power for my house:
I started calculating this power in May 2006.
These graphs are of course generated on my linux-PC, based on
I extended the IOpins:
- keyboard: a standard digit keyboard is connected to one of the
analog inputs. A cascade of resistors allow identification of the
- display: a standard LCD 1*40 character display is connected to a
digital output. the driver within the nutOS is in use (a small
alteration was required)
- Dallas 1wire temperature sensors: due to the long wiring, a ESD
clamping diode was inserted. the driver may be found in the tarball
- Flowsensor: this sensor measures the liter per hour of heating
wather used; it generates impulses with a frequency linear to the flow.
It is connected to one one the digital inputs connected to pulse
counter module within the atmega. this counter is supported in
the API of nutOS
- AC outputs: a bar of 24V AC switches is provided by means of
optocoupled triacs. The atmega directly, w/o amplifier, drives
the LED in the triac with 5mA. The triac switches 24V AC
with nearly up to 200mA load. I use it mostly
to drive the flow-regulators for the heat spreaders in my rooms
("Sammelverteiler mit 3W Ventilen").
- high voltage outputs: I bought at conrad a board with 4 opto
coupled triac, capable to switch 230V AC with 2A, each. The LEDs are
directly driven from atmega. If more than 100W are switched, use a heat
spreader. Take care to shield the high voltage parts ! (yes, I try to
- decoupled output: my gas burner has an overruling input which has
to be potential free switched. I use a photoMOS