home automation bus

Go To Last Post
39 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi guys!

I stopped my bus project and fell back to planning it because I got some great input here making me believe my approach was far from good although it did work. This thread is for collecting ideas and planning the whole thing in a way that makes sense.

The approach so far:
-master module controls everything, offers web interface
-slave modules receive and send data and connect peripherals
-peripheral PCBs are directly attached to slave modules and are auto-detected

Some more goals:
-low bus frequency
-low (no?) interference with common household cabling
-use available cheap cables and connectors (e.g. cat5 / RJ45)
-power the slave modules through bus cable
-demanding peripherals get own PSU

My ideas:
-use cat5 ethernet cable
-one line in pair is signal, the other is !signal (like CAN bus IIRC)
-modules receive commands ("dim to #ccfa29 in 6 seconds")
-keep bus clock speed variable (distinct clock line), saves the need for xtals
-do kind of PWM between "power" and "data" to power slaves with data lines, capacitors fill the gap
-use high lines to power slaves (there are always high lines)
-master module is made of several AVRs, one for each task (true multitasking!) like memory management, reacting to state changes, connecting web interface, talking to bus, ...

things I don't know yet how to do:
-PNP / collision detection
-getting a reset / package start signal without extra line

Some background information:
-it's a university project, I have to create an own bus (no implementing something existing)
-it will control light, audio, motors for garage openers, window blinds, ... and get input from standard light switches, web interface, light barriers, PIR sensors etc.
-it's a cable-driven bus but should be wirelessly extendable (with IR or RF)

My first idea of how a package on the bus could look like:
-reset/start
-read interrupts (if any module pulls down the line for e.g. "light switch interrupt", these modules can be quickly scanned and reacted to)
-send address of module we want to talk to
-get attached peripherals signature (so we know what do do with the module)
-send command
-send or receive data, based on command
[-stop/end]

Please add your comments, ideas and suggestions here instead of the Database/ASM thread. This is a new approach, and this time I'd like to finish it, so it should be good. :-)

Markus

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

When anyone mentions "home automation" my first thought is "X10" - don't know about anyone else?

The fact is that all the problems you are looking at have been analysed to the Nth degree already and the outcome of all that was X10. So why re-invent the wheel?

http://en.wikipedia.org/wiki/X10_(industry_standard)

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

home automation + manchester encoding = DALI. You could also look at LIN as it uses a presync to eliminate the requirement for a crystal. Most of the stuff I've designed and seen do not rely on collision detection - they avoid it by using the master/slave paradigm. You've got CAN as well - this can cope with collisions.

Look at 'hacking' a wireless router - many of these run linux and have USB. Add usb->serial adapter and you've got a master controller with web server and WiFi for less than $50 euro

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparky23882 wrote:
it's a university project, I have to create an own bus (no implementing something existing)

X10, DALI etc. do sound good but already exist. So I try doing an own bus, build it into some homes, get good grades for it and everything's fine.

Questions I still have:
-how do you suggest getting a reset signal without an extra reset line?
-how do you suggest powering slaves through the bus without extra lines?

My ideas for now for cabling issues:
-3 pairs of cat5 are for data (3 signals)
-the 4th pair is the clock signal
-each pair has a "signal" and a "!signal" line, so one is always at Vcc
-power slaves through active lines (signals)
-both lines of the 4th pair to GND = reset

The reset idea is a bad one (I know that...) and I'm not sure if powering this way is smart, either. With the right drivers for the bus, it should work (supplying power this way) IMHO.

Markus

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparky23882 wrote:
... X10, DALI etc. do sound good but already exist. So I try doing an own bus, build it into some homes, get good grades for it and everything's fine.
Hi Markus.
Have you considered the marketing impact on selling yet another protocol. Remember VHS vs BETA [VCR (tapes)]. BETA is clearly a superior format but it lost because of very clever marketing and the public already owned the VSH machines.
You make every new customers scrap all of their current system just because you wish to write a new one. I don’t care if it is better you won’t sell as many and you won’t be helping your industry establish standards you will be further fragmenting it. We lived through this!
Most companies have learned to try and predict the winner in the standards wars and adopt the best protocol, add to it, and help it ‘win’ and become an industry standard! You will sell more and mix and match can be good as you keep replacing X10 modules over time. You will start selling components sooner!
Anyone who grew up in the computer industry pre-standards when we all created our own and nothing was compatible knows why this is a very bad idea for the industry and marketing.

That’s why Cliff and I both think of X10!

Just a business thought,
John

Resistance is futile…… You will be compiled!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

reading through your post I've got a couple of remarks:

- While you want to create your own bus I would not try to avoid proven ideas you'll get something unsuitable for the real world.
- I'd separate the power and data lines, this makes simple (low parts count) implementations easier.
- It looks like you are looking at master/slave only. This has limitations for home-automation: All communication has to go through the master. It is desirable to have point-to point communication too. (Ex light switch to dimmer).
- RS485 looks interesting for communication: It allows long distances, plenty of existing driver chips and you can use it for any to any communications.
- Using a suitable low-level code you don't need to transmit clock separately. (Manchester code)
- I would not worry about reset that much. I would not dedicate a physical wire. You might have a 'reset' instruction in your protocol though.
- You can get away with 2 wires for communications and 2 wires for power.
Markus

Markus

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparky23882 wrote:
X10, DALI etc. do sound good but already exist. So I try doing an own bus, build it into some homes, get good grades for it and everything's fine.

That's fair enough but I wouldn't ignore the work that has been done in those other protocols. I'd read about and try to fully understand all existing (and open) work done on the subject then just "cherry pick" the best features or see if you can determine "how they could have done XXX better" and then do it.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And there is the UPB protocol which is much like X10.

I'll believe corporations
are people when Texas executes one.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Have you ever experimented with X10?
The technology sucks big time.
Insecure, no positive ack on command receive, just to name a few drawbacks, makes it totally unreliable to any serious task.....
In any case, a secure protocol for communicating devices in a home network would definitely be a huge step forward, especialy if the home network is also used for burglar alarm applications...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What about having slaves to run you house?...you would need to be rich but no complicated electronics....What it has already been invented?

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Since we're re-inventing things I'd like it to be wireless and use a Zigbee-type protocol for handling message sending.

Go electric!
Happy electric car owner / builder

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparky23882 wrote:
sparky23882 wrote:
it's a university project, I have to create an own bus (no implementing something existing)

X10, DALI etc. do sound good but already exist. So I try doing an own bus, build it into some homes, get good grades for it and everything's fine.

Questions I still have:
-how do you suggest getting a reset signal without an extra reset line?
-how do you suggest powering slaves through the bus without extra lines?

My ideas for now for cabling issues:
-3 pairs of cat5 are for data (3 signals)
-the 4th pair is the clock signal
-each pair has a "signal" and a "!signal" line, so one is always at Vcc
-power slaves through active lines (signals)
-both lines of the 4th pair to GND = reset

The reset idea is a bad one (I know that...) and I'm not sure if powering this way is smart, either. With the right drivers for the bus, it should work (supplying power this way) IMHO.

I recommend you to reat about the ModBus consept:

http://www.modbus.org.

If it is good for the industri, then it is good for you.

HM

HM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I agree - X10 sucks, but for the time it was invented it has served its purpose well.

Some things to consider:
1/if you want power over the cable, you will probably have to run a star configuration. CAT5 is about 100ohms/1000ft (check this!) so for significant power transfer, you have to run a higher voltage. PoE (power over ethernet) uses 48V and achieves 30W over 200m, the newer spec is around 45W.
2/your parallel bus concept will be a rod for your back. Everyone else has used a serial scheme - for good reason. Async over RS485 at moderate baud rates is more than adequate and is cheap and easy to implement.
3/ As for no crystal - is this for cost saving? If so, crystals cost cents in quantity so be careful you don't cause more issues by avoiding crystals purely from a cost perspective. LIN was designed for systems without crystals mainly due to vibration and packaging concerns for automotive applications. DALI uses manchester encoding which has the clocking information encoded into it so that it doesn't need accurate timing to send and recover the data.

Dynalite have their DYneT protocol which is simple to implement - 9600 baud async RS485 which seems to work quite well in sizable commercial installations.

Do some research as Cliff says and pick and choose the features that suits what you want to do.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I haven't experimented with anything existing yet as this is my first (own) µC project. Before, I had the µC class (writing a traffic lights application), that's all.

I like the cherry-picking approach. Adding an extra power supply cable seems like the best idea. Adds more connectors but you're right, it saves on the other components count. I'd still like to use Cat5 cable for good shielding and not too high price.

The slaves approach sounds great too but I think I remember there's a legal problem with this implementation. I prefer not getting problems with the cops. ;-)

So you suggest IF I do something new, it should be secure, tolerate much abuse (like chopping off cables etc) and still work (for alarms) and maybe be a self-arranging P2P network. Help me a little and I'll do it!

For a P2P network, each peer needs to know what it and its neighbors are capable of (i.e. detect attached hardware and tell other peers about it). Each peer also needs a unique address, so either really big hard-coded addresses or some kind of PNP is required. If the modules also knew their position within the building, it'd be perfect. Manchester-Code also sounds like a good idea.

If modules know their positions and the points they are aiming at, the command sent could be like "switch light with color #ffcc2A on at center of living-room" and all matching modules would react.

For the topology, I prefer not using linear, ring or tree stuff but use a network with "wild" cabling, for security reasons (so the burglar can chop off quite a few cables and the system will still work). So each peer has a few connectors (e.g. 3) that connect to neighbor peers and sends all commands and data to them. They look if they know how to reach (which of the lines) the target for the command and send it further using these lines. Etc...

For insecure setups, some of the peer connectors can stay unconnected to save on cable costs.

What do you think about that idea? Would you use different cables? Is there an existing P2P home automation system? How would you detect the module position? GPS isn't really precise and it's pricy... maybe manually setting the position would be better? Or a completely different approach, with no known positions?

Markus

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Designing everything from scratch is an option, however is not a project for "a one man show"...
I would use already proven technologies and try to mix them in rather innovative ways.
For example, since you mentioned Cat5 cabling, there is a standard (IEEE 802.3af) to power remote devices over Cat5 cabling, widely used on ip-phones.
Ethernet is a proven technology, extends wirelessly, has various security options to play with, and even has redundancy via stp...
Just an idea.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So each module gets it's own IP address. Sure, it's possible and definitely not the worst of ideas :-) But it's high speed, I need at least 10MBit for Ethernet (to work with switches etc.), so I'll need a lot faster µCs than with an own protocol for this.

Markus

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

10 Mbit is the transmission rate, you don't have to sustain such high data rates.
There are ready made chips,such as enc28J60 hiding ethernet complexity and offering an spi interface, with filtering so as not to clog the main processor.
Have a look here...
http://www.tuxgraphics.org/elect...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AllN wrote:
sparky23882 wrote:
... X10, DALI etc. do sound good but already exist. So I try doing an own bus, build it into some homes, get good grades for it and everything's fine.
Hi Markus.
Have you considered the marketing impact on selling yet another protocol. Remember VHS vs BETA [VCR (tapes)]. BETA is clearly a superior format but it lost because of very clever marketing and the public already owned the VSH machines.
You make every new customers scrap all of their current system just because you wish to write a new one. I don’t care if it is better you won’t sell as many and you won’t be helping your industry establish standards you will be further fragmenting it. We lived through this!
Most companies have learned to try and predict the winner in the standards wars and adopt the best protocol, add to it, and help it ‘win’ and become an industry standard! You will sell more and mix and match can be good as you keep replacing X10 modules over time. You will start selling components sooner!
Anyone who grew up in the computer industry pre-standards when we all created our own and nothing was compatible knows why this is a very bad idea for the industry and marketing.

That’s why Cliff and I both think of X10!

Just a business thought,
John

I see X10 as useable on 110/127V,where usual thelephon components may be used. Then thing may be made cheep. If you goto 230V the pictura are diferent. The nodes tends to be very expencive due to the higher voltage. Cost should also be tought on,

HM

HM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, Ethernet could be a good choice. The interface is well defined and solves communications and power (PoE). There are plenty of suppliers of stuff for it. Development is easy as you are using standard equipment. The main drawback is that it is point-to point and you need a (poe capable) switch at the center.

You can concentrate on the implementation of low-cost hardware and the protocol. There is working hardware you can start with now (ethernut, for example).

For the protocol you have the choice of IP or your own mac level protocol.

Markus

Markus

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
For a P2P network, each peer needs to know what it and its neighbors are capable of (i.e. detect attached hardware and tell other peers about it). Each peer also needs a unique address, so either really big hard-coded addresses or some kind of PNP is required. If the modules also knew their position within the building, it'd be perfect.

It all sounds way to complex! For example we have a switch - the switch doesn't care where it is located although it may have this information stored into it. When the switch is pressed, it sends out a message like "switch xxx pressed". Now, if all other modules are listening, they can determine if and what they do with this event. All modules that need to respond to this switch have this switch number stored along with what the operation is to be performed. Say we add a IR remote control, the receiver has a lookup table to map the IR buttons to switch values. Our system can now respond to our original switch and now a IR remote control. To do a timed sequence, our master controller looks up a table of timed events, when it finds one it tells it to send out the "switch xxx pressed" command - the system acts as if our original switch has been pressed.

Each node could have a little database stored in eeprom with the following information:
model
type
serial#
date of manufacture
s/w version
physical location
event number

All modules don't need to know about each other - they just send and receive messages and only know what to send and what to listen to. As to how you get these messages distributed is the key as is not too difficult. Using async and RS485, you have the issue of collision detection - not too hard to overcome if you listen to what you send. Using manchester encoding , you could have a lead in signal that other nodes would use as a carrier detect and sending nodes could listen to what is being sent to determine a collision as ethernet does. Using a fixed length packet that just sends an event id and options would come to around 16 bits of data for a reasonable sized system so it would be fairly quick to send even at 10kbit/s. To send/retrieve the config data would be a little slow, but that would only be done when installed or when a change needs to be done.

Ethernet would be a good choice but the node cost is still a bit more than say RS485. Using ethernet has the advantage of ubiquity and the number of devices you can add to extend the reach. Longer distances you have fibre-optic and broadband. For PoE you have off the shelf switches and hubs, so that's one less item you need to design. The cost of ethernet nodes is dropping fast and the silicon is decreasing in cost rapidly. Just look at the number of lower end micros with built-in MAC & PHY. My latest products are going this way, but my market is more high end commercial. 10Mbit/s is more than adequate- one of my commercial systems has over 2400 lighting channels over a pre-WiFi wireless link at 1Mbit/s - and that's got room to spare. Even the effects are all event driven so there's a bit of traffic and the system is still responsive - you press a button and something happens. I'd say the average house would have nowhere near as many events or channels.

Unfortunately, the AVR family (except AVR32) do not have ethernet mac/phy in the family. The Sam7X has a 10/100 mac, as does some new microchip parts that have mac/phy, the Luminary LM3S6965 has 10/100mac/phy andthere's an ASIX chip with built in mac/phy and a 8051 core. Just add the magnetics and the RJ45 and you have 10/100baseT connectivity. Add a dc/dc converter and you've got PoE. Job Done.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Mos common used buses for automation ar the KNX, EIB and LonWorks. The formers are 'open' ones, while LonWorks is 'proprietary' (and expensive).

Guillem.

Guillem.
"Common sense is the least common of the senses" Anonymous.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

EIB is not as open as that. At least not for the individual. My sister has some equipment installed, but to change parameter she must call her electrician (or get an accreditation and special software for several kEuro).

Markus

Markus

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Okay, so:
-use enc28j60 (or a 32 bit AVR) for Ethernet
-boradcast everything, the modules will listen and pick what's for them

There's one thing that makes me not want to use Ethernet - the costs. These chips aren't cheap. I'd prefer using an own protocol over Cat5 cables (like ISDN over Cat5 does, too) instead.

SPI sounds good, using PoE switches is an interesting thought, too. Running this in a mixed network (i.e. the network you connect your computers and the internet to) doesn't look like a good idea though. Sure, I could send packages and directly control the bus. But if everything is broadcasted, I think it'll influence the network in a bad way. Sure, it's not much data but it does interfere with normal network traffic.

So having separate lines makes more sense to me, and buying pricy PoE switches to run the system doesn't seem sensible for the bus only. Falling back to an extra power line. This also saves on the single module cost.

So we now have:
-Cat5 cables
-P2P structure, multiple paths between modules for security
-Ethernet protocol(?)
-Broadcast "Button x pressed", all modules listen

What else to improve/change?

Markus

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

'Multiple paths between modules' - the installers will hate you! The less work they have to do to install it the better! The choices are BUS or STAR - for running power, bus is probably not the best solution, so you're left with STAR. The cost of the CAT5 cable vs the cost of installation is miniscule. Everything wires back to a hub for power and data distribution.

I'm sure the cost of the poe switches will drop - they're still bleeding edge at the moment and the demand from Voip will ensure there is a large demand. Normal 10/100 switches can be got for <$10euro! These used to be expensive!

As for broadcasting packets - for the most time the system is inactive! Only when something needs to be done is there traffic. There's nothing to say you can't run a separate network for the home controls and use a switch or bridge to link to the rest of the world. If the security system is running on the home network, I'd want it protected from the outside world. By the same token, there's no reason why you couldn't run your own protocol (as opposed to tcp/ip) over ethernet to make the system more immune to outside influences. Any traffic on a network 'interferes' with other traffic - in this instance one would think that the normal network traffic like video and a large file copy might flood the network and slow our control system. Broadcasts aren't an issue.

I was speaking with a Microchip FAE recently about the ENC28j60 device - his suggestion was to go for the controller based products in the family as they were only marginally more expensive and you got a cpu to boot! This means moving away from an AVR - but business is business (and I despise using PICs!).

Try running some comms simulation on two or more PCs - use Visual Basic/Delphi/C#/Java to write little apps that broadcast packets and do some timing. Load the network by doing video streaming and/or a large filecopy and see how it gets affected. Evidence beats conjecture hands down.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sounds to me like a job for a Zigbee wireless mesh network. No comms cabling at all and you would get the function of the cabled schemes suggested before. (albiet low speed)
It also sounds as though most of the transducer/actuator (slave) modules may be located right near mains power anyway such as lights and light switches. If they can draw power from the local mains then there goes all the power cabling as well.

Imagine, if you will, fitting out an existing building simply by unscrewing a light bulb and replacing it with a new (smart) wireless network managed one. Same with the switches; pull out the standard wall plate and replace with new improved one, and so on and so forth.

Obviously not available to all types of slave modules but it can mimimise some some of the additional cable requirements. (And you did say you wanted RF/IR extensions)

Hmm... sounds cool now. I'll have to give it more thought!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Installers will only hate me if the network is security related (triggering alarms, locking/unlocking doors etc), in other setups, a single line to each module will be enough. And I believe the installers will happily calculate some hours more for the extra cables where needed ;-)

I like the idea of having distinct physical cables that only connect my bus network. No other stuff (LAN), no interference (RF), no influencing stuff I have (IR remote). But because this isn't always possible, I may fall back to double-use a LAN and will extend the bus with RF, IR or UV (there are UV LEDs and photo-diodes available... don't know how good they are, but this frequency is rather unused - yet.) where needed. _only_ where needed.

The idea of replacing a light bulb and it's smart of course is great. But this either requires a lot of RF which can easily be influenced (a small sending device and the network doesn't work anymore - bad idea for security-related or for annoying neighbor kids) or using the power net in the house for transmitting signals (which unfortunately isn't easy with 230/400V in Germany).

Using the power line either requires silicon capable of constantly coping with 400V or a transformer in each module and silicon capable of working with very low voltage signals. (400V (peak) to e.g. 5V (peak) means 5V (signal) to 62mV (signal) which is ugly to handle)

So adding physical data lines IMHO is the most sensible approach for most occasions. A connector strip (I'm not sure it's the right word... e.g. 6x power outlet with a power cord, mobile) for example may get an RF or IR receiver to avoid the extra cables there.

Don't get me wrong, IMO RF, RFID, automated scanners, locating stuff and people (GPS or proprietary), face recognition etc. is great. But not always a good idea.

Markus

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here’s a couple Webinars coming up that may help.
Minimizing Packet Timing Uncertainties in Embedded Ethernet Systems:
http://www.techonline.com/learni...

And:

RF Board Design for Next Generation Wireless Systems
http://www.techonline.com/learni...

Good luck,
John

Resistance is futile…… You will be compiled!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Those webinars sound good, but they are available for WMV10 or Real only. WMV10 doesn't run on Mac (only WMV9 is available) and Real is a plaque I'm not installing :-)

Any more suggestions? If not, I'll dig into Ethernet and do something with broadcast and each module knowing which broadcasts to react to. Hopefully, Ethernet isn't too hard to do and not too expensive to build.

Markus

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Perhaps you should check for 'ethernet powered' uC. I would suggest ARM7 families like AT91SAM7X. Olimex have a good board (SAM7X256-EX or somthing similar) for them with free (and really cheap JTAG debugger) debugging chain and support for IP. For what you plan, it probably would be the fastest (and probably the cheapest and safest) way to go.

Guillem.

Guillem.
"Common sense is the least common of the senses" Anonymous.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The AT91SAM7X256-AU costs ~13 EUR, the ATmega16 + ENC28J60 sums up to ~8 EUR. Choosing a more powerful µC with integrated Ethernet support is easier, that's for sure. But buying a supercomputer for running Windows Calculator isn't exactly smart, if you're getting my point.

I even thought of downgrading to the ATtiny series for modules because they can do these simple calculations, too - and cost half or even less compared to the ATmega16 I'm currently playing with. SPI isn't available for the ATtiny series (at least not for the random-picked devices I looked at), so using ethernet with the ENC28J60 gets ugly (manually implement SPI?).

I'll first create a new set of commands and packages to be sent (in full bytes), build a module that uses them, test that with direct cables and then add the interface (Ethernet, RF, IR, whatever needed) to the module for real actual physical communication.

Thanks for all your suggestions!

Markus

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparky23882 wrote:
The AT91SAM7X256-AU costs ~13 EUR, the ATmega16 + ENC28J60 sums up to ~8 EUR.

But you cannot make a price comparison between a 256K controller and a 16K controller? I'll bet if you compared mega2560 and mega16 you'd find at least that price differential too.

Looking at the SAM7 section of the Atmel site it looks like the smallest SAM7 with ethernet is the AT91SAM7XC128 (admittedly 128K is still EIGHT times larger than the mega16). On Digikey in quantities of 100+ this lists at $7.78 which is €5.69

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Had you calculated the 'hidden tax'?: Developing time (for each option) * salary (per 'dev time unit') / number of boards to build/manufacture. It's an interesting calculation often overlooked.

Guillem.

Guillem.
"Common sense is the least common of the senses" Anonymous.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For the simple case of a dimmer or light switch where the microcontroller just needs to check two input pins (brighter/darker) and an output pin (triac) besides the communication (via SPI attached ethernet chip) there is no large program to fill a lot of flash.

It is quite true to compare the 256k AT91 with a Mega16+ENC28J60 is unfair. But as low cost for a simple app is the goal a it's the AT91 who is too big, not the Mega16 too small.

On the other hand, implementing even a functionally reduced IP stack will need space. Maybe too much for an ATtiny. For a simple prototype you can get away with UDP only and hardcoded IP parameters. This uIP implementation (http://www.sics.se/~adam/old-uip/size.html) requires around 6k FLAS and 1k RAM. This rules out most Tiny's. Besides this the stack works on AVR with gcc, this solves already one issue...

Markus

Markus

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The PIC18F66J60 at USD$9.05 beats them hands down as as well as being smaller.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I always thought that 'home automation' is something that in Spain say 'killing flyes with guns'. A whole M16 just to turn on/off a light? And when comm protocols came to the app, then program grows really easy, that is why usually small 'IP powered' apps run on ARM's instead of AVR's.

That also remembers me some discussions about ZigBee, that is intended for small applications like this, but many of them, that alone would run with <8KBytes of code, now need >32KB of Flash and >1KByte of RAM only for ZigBee stack. The reduced version, of course... For routers/coordinators, >64 Flash and >2 RAM minimum.

Seems that is se same for other common protocols (EIB, Konnex, LonWorks, etc). This is one reason why ModBus/RS-458 still lives.

Guillem.

Guillem.
"Common sense is the least common of the senses" Anonymous.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Guillem , you can run Modbus TCP/IP over ethernet! Sure it all sounds excessive, but adding a little complexity does solve a lot of problems.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, it is possible to run ModBus over TCP/IP. But I had implemented ModBus/485 protocol with Maser/Slave within M64/128, and found that it uses a respectable amount of flash (few KBytes, not too much) and few RAM. For Slave ModBus only, it is not really complex, and it can be reduced (depending on the needs) to even less than 2KBytes.

Anyway, if fits many AVR's without problem. Bigger protocols are another leage.

Guillem.

Guillem.
"Common sense is the least common of the senses" Anonymous.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Modbus is the protocol of choice for my daytime job. Interesting problem I came across today, I was getting 0.04% errors that I couldn't explain - should be 0% error. I've recently started using the LinearTech LT1785 485 transceivers due to their 60V tolerance, so after a bit of diagnostics on my Modbus code that I have used for countless project beforehand I found that I was receiving and sending the correct number of packets, but some were getting lost. Seems the LT parts are REALLY slow as compared with the max485 and 75176 - 2uS enable time vs 50nS! So I added some delays after enabling the transmit and my problems disappeared. So, not all RS485 tranceivers are the same!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sure comparing the AT91SAM7X256 with an ATmega16 isn't fair. The AT91SAM7S128-AU, the smallest available I found being sold on the internet to german customers costs 11.50 EUR, so the comparison still fits *somehow*. I don't compare some arbitrary stuff, I compare what I can get where I currently am. Maybe there are more online distributors selling other µCs, maybe with importing, ordering 100 pieces and saving on shipping, they're cheaper, I only did a quick check.

Development time for a module won't differ much if I do it fixed with Ethernet or do it open for any protocol and then add an Ethernet extension. Other protocols are only developed when/where needed, so no extra development time is wasted.

As Guillem said, controlling three channels of PWM or 2 digital ports with 8 bit each (the common two setups) isn't something you need a 32 bit µC for. It can be done with the smallest ATtinys. Using an easy, self-made communication protocol also is possible with a tiny. So why do I have to go 32 bit and dozens of MHz just to get a result I can have the easy way, too?

Sure, there are standards. And standards are always a good idea, I totally agree on that one. But if the communication protocol eats up most ressources - I don't know if that's worth all the trouble.

I will, of course, use techniques used in those standard protocols. Manchester-encoding sounds sensible, collision detection will also be implemented much like done in the Ethernet standard. I'm also thinking of doing the "signal" and "!signal" lines like in CAN bus to cope with a broken line. Cherry-picking.

Still, I'll keep the modular approach to be able to add e.g. Ethernet support at a later time without much trouble. This way, I can have easy installation and tiny modules and in case it's needed, build relays that transfer module data for example over an Ethernet. I guess most of the bus protocols didn't start as a full-blown monster-application, a jack-of-all-trades. I won't, either. But I'll keep the option open.

So in the unexpected case this bus actually sells a few times and is considered good, it can still be improved without disabling all old hardware.

Markus