Hello newsgroup,

Mark Pappin posted some C source to model the situation for the house I'm
remodeling.  I'm a long way from understanding both the hardware and the
software I would need to make it a reality.


 // #include <compiler's-magic-chip-specific-header>
  /* At this point, a number of objects have been declared
     that refer to the memory-mapped I/O ports. They probably
     have names full of acronyms from data sheets.  They also
     have been declared with whatever qualifiers are necessary. */

  #define HALLWAY_TEMP ADC_DATA_IN_0
  #define BEDROOM_TEMP ADC_DATA_IN_1
  #define WATER_LEVEL  ADC_DATA_IN_2

  #define SWAMPCOOLER_FAN DAC_DATA_OUT_0
  #define REFILL_SOLENOID RELAY_OUT_0

  /* hard-coded parameters for simplicity of sample */
  #define HALLWAY_MAX 35
  #define BEDROOM_MAX 30

  #define FANSPEED_MAX 100

  #define LO_WATER 10
  #define HI_WATER 40

  int main(void)
  {
    unsigned fanspeed = 0;
    while (1) {
      if (HALLWAY_TEMP > HALLWAY_MAX ||
          BEDROOM_TEMP > BEDROOM_MAX) {
        if (fanspeed < FANSPEED_MAX) {
          /* some output devices are truly output-only
             and it's necessary to keep your own record
             of their value, rather than accessing them
             _just_ like a real variable */
          SWAMPCOOLER_FAN = ++fanspeed;
        }
      }
      if (HALLWAY_TEMP < HALLWAY_MAX &&
          BEDROOM_TEMP < BEDROOM_MAX) {
        if (fanspeed > 0) {
          SWAMPCOOLER_FAN = --fanspeed;
        }
      }
      if (WATER_LEVEL < LO_WATER) {
        REFILL_SOLENOID = 1;
      }
      if (WATER_LEVEL > HI_WATER) {
        REFILL_SOLENOID = 0;
      }
    }
    return 0; /* for pedantry's sake */
  }
// gcc -o fan embed1.c

Not surprisingly, gcc notices some missing information:

C:\Documents and Settings\dan\Desktop\gfortran\source>gcc -o fan embed1.c
embed1.c: In function 'main':
embed1.c:28: error: 'ADC_DATA_IN_0' undeclared (first use in this function)
embed1.c:28: error: (Each undeclared identifier is reported only once
embed1.c:28: error: for each function it appears in.)
embed1.c:29: error: 'ADC_DATA_IN_1' undeclared (first use in this function)
embed1.c:35: error: 'DAC_DATA_OUT_0' undeclared (first use in this
function)
embed1.c:44: error: 'ADC_DATA_IN_2' undeclared (first use in this function)
embed1.c:45: error: 'RELAY_OUT_0' undeclared (first use in this function)

Mark is pretty close with this first guess, as far as how these mechanisms
work.  I have one fan next to the woodburner and another that feeds the
bedrooms, and a swamp cooler in the middle of everything.

How do I proceed?

Thanks and cheers,
-- 
The opera is to music what a bawdy house is to a cathedral.
H. L. Mencken

On Fri, 18 Jul 2008 17:48:33 -0600, Ron Ford <r...@nowhere.net> wrote:

>
>Hello newsgroup,
>
>Mark Pappin posted some C source to model the situation for the house I'm
>remodeling.  I'm a long way from understanding both the hardware and the
>software I would need to make it a reality.
[snip...snip...]
>Not surprisingly, gcc notices some missing information:
>
>C:\Documents and Settings\dan\Desktop\gfortran\source>gcc -o fan embed1.c
>embed1.c: In function 'main':
>embed1.c:28: error: 'ADC_DATA_IN_0' undeclared (first use in this function)

>Mark is pretty close with this first guess, as far as how these mechanisms
>work.  I have one fan next to the woodburner and another that feeds the
>bedrooms, and a swamp cooler in the middle of everything.
>
>How do I proceed?

Which processor? I seem to recall seeing some that automagically (when
properly initialized) continuously cycle through the ADC ports, dumping
the results in a defined memory space. Maybe there's an interrupt
service routine that should be running in the background? Insufficient
information.

Also suggest that you add a hysteresis band, using something like
  #define HALLWAY_MAX_ON  35
  #define HALLWAY_MAX_OFF 33
...
  if (HallwayTemp > HALLWAY_MAX_ON) {
    speed up the fan
  else if (HallwayTemp < HALLWAY_MAX_OFF) {
    slow down the fan
  }

-- 
Rich Webb     Norfolk, VA

On Fri, 18 Jul 2008 21:46:05 -0400, Rich Webb posted:

> On Fri, 18 Jul 2008 17:48:33 -0600, Ron Ford <r...@nowhere.net> wrote:
> 
>>
>>Hello newsgroup,
>>
>>Mark Pappin posted some C source to model the situation for the house I'm
>>remodeling.  I'm a long way from understanding both the hardware and the
>>software I would need to make it a reality.
> [snip...snip...]
>>Not surprisingly, gcc notices some missing information:
>>
>>C:\Documents and Settings\dan\Desktop\gfortran\source>gcc -o fan embed1.c
>>embed1.c: In function 'main':
>>embed1.c:28: error: 'ADC_DATA_IN_0' undeclared (first use in this function)
> 
>>Mark is pretty close with this first guess, as far as how these mechanisms
>>work.  I have one fan next to the woodburner and another that feeds the
>>bedrooms, and a swamp cooler in the middle of everything.
>>
>>How do I proceed?
> 
> Which processor? I seem to recall seeing some that automagically (when
> properly initialized) continuously cycle through the ADC ports, dumping
> the results in a defined memory space. Maybe there's an interrupt
> service routine that should be running in the background? Insufficient
> information.

AMD Athlon 64 3000+

I wouldn't want to leave my computer behind when I sell this house, so
there would have to be a different target.  Does anyone have any notion of
what hardware might work for this situation?

> Also suggest that you add a hysteresis band, using something like
>   #define HALLWAY_MAX_ON  35
>   #define HALLWAY_MAX_OFF 33
> ...
>   if (HallwayTemp > HALLWAY_MAX_ON) {
>     speed up the fan
>   else if (HallwayTemp < HALLWAY_MAX_OFF) {
>     slow down the fan
>   }

Hysteresis is what I think of when traffic caterpillars.
-- 
Every man sees in his relatives, and especially in his cousins, a series of
grotesque caricatures of himself.
H. L. Mencken

On Sat, 19 Jul 2008 20:45:06 -0600, Ron Ford <r...@nowhere.net> wrote:

>On Fri, 18 Jul 2008 21:46:05 -0400, Rich Webb posted:
>
>> On Fri, 18 Jul 2008 17:48:33 -0600, Ron Ford <r...@nowhere.net> wrote:
>> 
>>>
>>>Hello newsgroup,
>>>
>>>Mark Pappin posted some C source to model the situation for the house I'm
>>>remodeling.  I'm a long way from understanding both the hardware and the
>>>software I would need to make it a reality.
>> [snip...snip...]
>>>Not surprisingly, gcc notices some missing information:
>>>
>>>C:\Documents and Settings\dan\Desktop\gfortran\source>gcc -o fan embed1.c
>>>embed1.c: In function 'main':
>>>embed1.c:28: error: 'ADC_DATA_IN_0' undeclared (first use in this function)
>> 
>>>Mark is pretty close with this first guess, as far as how these mechanisms
>>>work.  I have one fan next to the woodburner and another that feeds the
>>>bedrooms, and a swamp cooler in the middle of everything.
>>>
>>>How do I proceed?
>> 
>> Which processor? I seem to recall seeing some that automagically (when
>> properly initialized) continuously cycle through the ADC ports, dumping
>> the results in a defined memory space. Maybe there's an interrupt
>> service routine that should be running in the background? Insufficient
>> information.
>
>AMD Athlon 64 3000+

Ahh... Rather larger than what typically comes to mind in the embedded
realm. So this is just the operating model and you're intending on
running something smaller for the controller?

>I wouldn't want to leave my computer behind when I sell this house, so
>there would have to be a different target.  Does anyone have any notion of
>what hardware might work for this situation?

I can imagine setups based around anything from distributed 8-pin, 8-bit
microcontrollers with a few bytes of RAM each (which can do a dandy job
of monitoring a thermistor or two and PWM'ing a DC fan or two) up to a
multi-gigawhiz, networked and web-enabled embedded Linux/XPe/VxWorks
monster with voice control and a really big wide-screen monitor.

-- 
Rich Webb     Norfolk, VA

On Sun, 20 Jul 2008 07:31:38 -0400, Rich Webb posted:

> On Sat, 19 Jul 2008 20:45:06 -0600, Ron Ford <r...@nowhere.net> wrote:
> 
>>On Fri, 18 Jul 2008 21:46:05 -0400, Rich Webb posted:

>>>>How do I proceed?
>>> 
>>> Which processor? I seem to recall seeing some that automagically (when
>>> properly initialized) continuously cycle through the ADC ports, dumping
>>> the results in a defined memory space. Maybe there's an interrupt
>>> service routine that should be running in the background? Insufficient
>>> information.
>>
>>AMD Athlon 64 3000+
> 
> Ahh... Rather larger than what typically comes to mind in the embedded
> realm. So this is just the operating model and you're intending on
> running something smaller for the controller?
> 
>>I wouldn't want to leave my computer behind when I sell this house, so
>>there would have to be a different target.  Does anyone have any notion of
>>what hardware might work for this situation?
> 
> I can imagine setups based around anything from distributed 8-pin, 8-bit
> microcontrollers with a few bytes of RAM each (which can do a dandy job
> of monitoring a thermistor or two and PWM'ing a DC fan or two) up to a
> multi-gigawhiz, networked and web-enabled embedded Linux/XPe/VxWorks
> monster with voice control and a really big wide-screen monitor.

I'm not sure how much memory I would need if I don't do the usual things
like #include <stdio.h>.  I like the sound of 8-pin, 8-bit controllers.
How do I find out more?  Are they RISC microcontrollers?

Again, I'll want to take my nice monitor with me when I leave this place.
-- 
The urge to save humanity is almost always a false front for the urge to
rule.
H. L. Mencken

On Sun, 20 Jul 2008 14:10:13 -0600, Ron Ford <r...@nowhere.net> wrote:

>I'm not sure how much memory I would need if I don't do the usual things
>like #include <stdio.h>.  I like the sound of 8-pin, 8-bit controllers.
>How do I find out more?  Are they RISC microcontrollers?

The ones I was thinking of are from this family:
<http://www.atmel.com/dyn/products/devices.asp?family_id=607#791>;

The fan controller was for an enclosure and it set the fan speed using
an A/D reading over a thermistor. Took 156 bytes for the program code
and no RAM other than the processor registers.

The really small ones don't have UARTS but with their slightly bigger
siblings and some interface chips you could setup an RS485 system where
they could chat among themselves or report back to a central monitoring
station.

-- 
Rich Webb     Norfolk, VA

On Sun, 20 Jul 2008 19:22:57 -0400, Rich Webb posted:

> On Sun, 20 Jul 2008 14:10:13 -0600, Ron Ford <r...@nowhere.net> wrote:
> 
>>I'm not sure how much memory I would need if I don't do the usual things
>>like #include <stdio.h>.  I like the sound of 8-pin, 8-bit controllers.
>>How do I find out more?  Are they RISC microcontrollers?
> 
> The ones I was thinking of are from this family:
> <http://www.atmel.com/dyn/products/devices.asp?family_id=607#791>;
> 
> The fan controller was for an enclosure and it set the fan speed using
> an A/D reading over a thermistor. Took 156 bytes for the program code
> and no RAM other than the processor registers.
> 
> The really small ones don't have UARTS but with their slightly bigger
> siblings and some interface chips you could setup an RS485 system where
> they could chat among themselves or report back to a central monitoring
> station.

It would certainly seem that Atmel is the norm for AVR RISC controllers.
The link didn't have any information about prices.  While it looked like
the chips themselves are a few bucks, am I correct to think that I would
also need a "workbench?"

AVR Startup Package
• JTAGICE-MK2
• ATSK500+501
• IAR Kickstart Workbench
Price € 339,00*
• JLINK JTag ICE (unlimited)
• SAM7S64-EK
• IAR Kickstart Workbench
Price € 250,00*

My question is what is the minumum cost of entry?  I saw other numbers that
were ten times as much.
-- 
A newspaper is a device for making the ignorant more ignorant and the crazy
crazier.
H. L. Mencken

Ron Ford wrote:

> My question is what is the minumum cost of entry?  I saw other numbers that
> were ten times as much.

I didn't tried it (I have some AVRs, but no time so far to try it), but
looks like this is a free and good tool:

http://atmel.com/dyn/products/tools_card.asp?tool_id=2725

You can build your own programmer, but it is not expensive to buy one, e.g.
from http://www.sparkfun.com . An USB programmer costs less than $50 and a
header board with an ATMega16 costs $22.95. So minimum cost entry would be
less than $100.

-- 
Frank Buss, f...@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

On Sun, 20 Jul 2008 21:55:10 -0600, Ron Ford <r...@nowhere.net> wrote:

>It would certainly seem that Atmel is the norm for AVR RISC controllers.
>The link didn't have any information about prices.  While it looked like
>the chips themselves are a few bucks, am I correct to think that I would
>also need a "workbench?"
>
>AVR Startup Package
>• JTAGICE-MK2
>• ATSK500+501
>• IAR Kickstart Workbench
>Price € 339,00*
>• JLINK JTag ICE (unlimited)
>• SAM7S64-EK
>• IAR Kickstart Workbench
>Price € 250,00*
>
>My question is what is the minumum cost of entry?  I saw other numbers that
>were ten times as much.

Minimum cost depends very much on what's hiding in your junk er ah spare
parts bin and how much you're willing/able to spend the time to roll
your own.

A minimal startup would need just a chip, breadboard (plus power,
connectors and so on), an in-system programmer, and the free AVR Studio
available from Atmel. There's also WinAVR (a gcc port)
http://winavr.sourceforge.net/ that plays well with Studio.

The in-system programmer is within the capabilities of end-users to
build but the standard AVRISP Mk2 (USB interface) is only US$36 and that
removes one variable when first starting out. Add an ATmega168 (16K
flash, 28-pin DIP) for another US$4 and you're good to go.

The STK500 is a stand-in for a breadboard + ISP, having sockets for all
of the DIP-flavored AVRs. Its programming headers can also be used to
program devices off-board (e.g., on a breadboard).

I'm not a huge fan of ICEs and they're certainly not necessary for a
minimal startup system. The AVRISP is quite sufficient to load code into
a device and get it running.

One caveat here: Most (all?) AVRs with internal RC oscillators come from
the factory with their fuses set to use the RC as the system clock,
typically at 1 MHz. The ISP programming clock should be set to no more
than 1/4 of the devices clock speed. If one doesn't realize that the
device is running from the internal oscillator, instead of the 14 MHz
xtal that's hooked up, the chip can appear to be faulty. The solution,
of course, is to lower the ISP speed to below 250 KHz in order to
communicate with the device to set the fuses to use the external
clock/crystal; after that, the ISP speed can be set higher if desired.

On the compiler side, I've been using Imagecraft for years and am quite
happy with them. They also offer an AVR starter kit (compiler included)
that may interest you. http://www.imagecraft.com

http://www.avrfreaks.net/ is a super resource with links to other
compilers, kits, tools, ...

One last thing. The SAM7 chips are ARM7 devices (32-bits). They're quite
nice as well but do be aware that it's a different family.

-- 
Rich Webb     Norfolk, VA

On Mon, 21 Jul 2008 10:40:51 +0200, Frank Buss posted:

> Ron Ford wrote:
> 
>> My question is what is the minumum cost of entry?  I saw other numbers that
>> were ten times as much.
> 
> I didn't tried it (I have some AVRs, but no time so far to try it), but
> looks like this is a free and good tool:
> 
> http://atmel.com/dyn/products/tools_card.asp?tool_id=2725
> 
> You can build your own programmer, but it is not expensive to buy one, e.g.
> from http://www.sparkfun.com . An USB programmer costs less than $50 and a
> header board with an ATMega16 costs $22.95. So minimum cost entry would be
> less than $100.

Then I'm in.  Do you have a header board?
-- 
Democracy is a pathetic belief in the collective wisdom of individual
ignorance.
H. L. Mencken