atmelmicrocontrollerpower
I am using the ATMEL ARM SAM4S MCU for a project. It supports a single-supply mode where an internal voltage regulator provides the 1.08-1.32V necessary for VDDCORE and we need only provide 1.62-3.6V to VDDIO.
I'm just interested to know if there is any situation where one might NOT take advantage of this feature and supply the core externally as well?
Switch mode power supplies (SMPS) can be difficult to make by hand, without a custom PCB. You have several issues. Even on a 2 layer custom PCB this can be difficult but is many times harder when you are hacking things together on a perf board or worse. The reason for this is that the stability of a SMPS is highly dependent on the inductance and "routing" of the signals. If a signal is not routed nicely then it can pick up too much noise and the SMPS becomes unstable. This alone is a topic worthy of several books.
Things can be much more difficult when using tools like National Semiconductors WEBENCH. While WEBENCH is useful for getting you "approximately in the right neighborhood", it falls far short of getting you a robust and reliable design. WEBENCH, and tools like it, often don't check for some basic things that become very important when designing SMPS. There is the easy stuff, like are you violating the power specs on resistors or voltage specs on diodes? Or the intermediate stuff like are you violating the duty cycle limits for the SMPS chip? Or the hard stuff like, is the tool properly simulating the MOSFET/Diode/Cap you're using or does it allow you to add/change the snubber circuit? I have seen WEBENCH and tools like it fail to properly take these things into account-- resulting in a circuit that just barely works or even fails catastrophically. WEBENCH will give you a place to start, but it is no replacement for reading and understanding the datasheet and doing the proper homework on the design. You can't just take a WEBENCH design and run with it as if it were a fully tested and robust design.
My advice: If you're building your own custom PCB then make your own SMPS. Add into your schedule a good amount of time to tinker and tweak the SMPS circuit. If you are going with a one-off build then use something like the UBEC.
Advice #2: Linear Tech's LTSpice simulator is an order of magnitude more useful than WEBENCH. It is also good for non-SMPS analog circuits. You will still need to do your homework, but LTSpice will get you much farther along. The downside is that Linear Tech's chips are a little more expensive than National Semi's and others. But, in my opinion, unless you're building thousands of these things then the better software tools is worth the extra cost.
CAN sounds the most applicable in this case. The distances inside a house can be handled by CAN at 500 kbits/s, which sounds like plenty of bandwidth for your needs. The last node can be a off the shelf USB to CAN interface. That allows software in the computer to send CAN messages and see all the messages on the bus. The rest is software if you want to present this to the outside world as a TCP server or something.
CAN is the only communications means you mentioned that is actually a bus, except for rolling your own with I/O lines. All the others are point to point, including ethernet. Ethernet can be made to logically look like a bus with switches, but individual connections are still point to point and getting the logical bus topology will be expensive. The firmware overhead on each processor is also considerably more than CAN.
The nice part about CAN is that the lowest few protocol layers are handled in the hardware. For example, multiple nodes can try to transmit at the same time, but the hardware takes care of detecting and dealing with collisions. The hardware takes care of sending and receiving whole packets, including CRC checksum generation and validation.
Your reasons for avoiding PICs don't make any sense. There are many designs for programmers out there for building your own. One is my LProg, with the schematic available from the bottom of that page. However, building your own won't be cost effective unless you value your time at pennies/hour. It's also about more than just the programmer. You'll need something that aids with debugging. The Microchip PicKit 2 or 3 are very low cost programmers and debuggers. Although I have no personal experience with them, I hear of others using them routinely.
I see some recommendations for RS-485, but that is not a good idea compared to CAN. RS-485 is a electrical-only standard. It is a differential bus, so does allow for multiple nodes and has good noise immunity. However, CAN has all that too, plus a lot more. CAN is also usually implemented as a differential bus. Some argue that RS-485 is simple to interface to electrically. This is true, but so is CAN. Either way a single chip does it. In the case of CAN, the MCP2551 is a good example.
So CAN and RS-485 have pretty much the same advantages electrically. The big advantage of CAN is above that layer. With RS-485 there is nothing above that layer. You are on your own. It is possible to design a protocol that deals with bus arbitration, packet verification, timeouts, retries, etc, but to actually get this right is a lot more tricky than most people realize.
The CAN protocol defines packets, checksums, collision handling, retries, etc. Not only is it already there and thought out and tested, but the really big advantage is that it is implemented directly in silicon on many microcontrollers. The firmware interfaces to the CAN peripheral at the level of sending and receiving packets. For sending, the hardware does the colllision detection, backoff, retry, and CRC checksum generation. For receiving, it does the packet detection, clock skew adjusting, and CRC checksum validation. Yes the CAN peripheral will take more firmware to drive than a UART such as is often used with RS-485, but it takes a lot less code overall since the silicon handles so much of the low level protocol details.
In short, RS-485 is from a bygone era and makes little sense for new systems today. The main issue seems to be people who used RS-485 in the past clinging to it and thinking CAN is "complicated" somehow. The low levels of CAN are complicated, but so is any competent RS-485 implementation. Note that several well known protocols based on RS-485 have been replaced by newer versions based on CAN. NMEA2000 is one example of such a newer CAN-based standard. There is another automotive standard J-J1708 (based on RS-485) that is pretty much obsolete now with the CAN-based OBD-II and J-1939.
Best Answer
The main reason would be for power efficiency. The voltage regulator inside the chip is a linear one, which means that its efficiency is: (VDDCORE/VDDIO). So if your VDDIO is 3.6v, then your efficiency might be only 33%! This is a terrible waste of energy, especially in a battery powered portable device where a long battery life is an important selling point for the device.
Poor power efficiency not only leads to a shorter battery life, it also generates heat. In this case it doesn't seem like much, but it can make all the difference. In a hot environment, that extra heat might push the chip over its specified operating conditions, leading to failure. In some applications, you might have lots of chips, which could create quite a lot of heat. In one application, we had 20 ET1200 chips, all using their internal regulators. Each chip's core uses just 75mA. But 20 chips means 1.5A on the cores, and a total of 1.2W of power dissipated just as wasted heat. The inside of the enclosure got pretty hot.