eeweb pulse - volume 26

PULSE EEWeb.comIssue 26

December 27, 2011

Rob GrayFreelance Embedded Electronics Designer

Electrical Engineering Community

EEWeb

Contact Us For Advertising Opportunities

[email protected]

www.eeweb.com/advertising

Electrical Engineering CommunityEEWeb

Digi-Key is an authorized distributor for all supplier partners. New products added daily. © 2011 Digi-Key Corporation, 701 Brooks Ave. South, Thief River Falls, MN 56701, USADigi-Key is an authorized distributor for all supplier partners. New products added daily.

www.digikey.com/techxchange

It’s all about connections.

The user-to-user forum is for everyone, from design engineers to hobbyists, to discuss technology, products, designs and more. Join the discussions that match your interest or offer your expertise to others.

Join the discussion now at:

discussions

hobbyists

engineers

industry experts

resourceslinks

technical documentswhite papers

reference designs

application notes

community

power

microcontroller

lighting

wireless

sensor

students

http://bit.ly/kDYHm7

EEWeb | Electrical Engineering Community Visit www.eeweb.com 3

TABLE O

F CO

NTEN

TSTABLE OF CONTENTS

Rob Gray 4Freelance Embedded Electronics Designer

BUSnet/MAXX 9BY ROB GRAY

Featured Products 15Using Hall Effect Measurements to Characterize MaterialsBY MARY ANNE TUPTA AND ROBERT GREEN WITH KEITHLEY

Buffered Communication Between 19 Real-Time Software ProcessesBY DAVE LACEY WITH XMOS

RTZ - Return to Zero Comic 24

Learn about Rob Gray’s current project—an RS-485-based async network for the commercial to light-industrial monitoring and control market.

Interview with Rob Gray

Characterize the properties of graphene or graphene-based material structures using Hall effect measurements.

Allow software processes to communicate using various programming languages.

16


INTERVIEWFEA

TURED IN

TERVIEWFreelance Embedded

Electronics DesignerHow did you get into electronics/engineering and when did you start?I was living in London for a year between 1978 and 1979. At the time I was a photographer but I’ve always had an interest in electronics since I was a lad; I remember wanting to control the direction of a motor when I was about 10 years old, so I made what I now recognize as an H-bridge from switches and wires nailed to a square of chip board.

I’ve also always had an interest in model railways, so moving on 15 years and several continents, I found myself sitting in my London flat wondering how I would control the boom gates on a model train layout such that when a train approached a crossing the gates would lower and cars would stop.

I started drawing circuits using the technology that I was familiar with, namely magnets and reed switches, and while the results weren’t very clever the seed was sown.

I then bought some books, most notably one called The CMOS

Cookbook, and was amazed at the possibilities these little black multi-legged devices offered.

On my return to Australia I started door knocking at all the engineering firms I could find in the phone book. I had nothing but my enthusiasm and some rolled up circuit diagrams under my arm and while I’m sure my circuits didn’t impress anyone, my enthusiasm obviously did, and

I found myself changing vocations after talking to the owner of the first firm I approached.

What are your favorite hardware tools that you use?Without a doubt my logic analyser. How anyone can design micropro-cessor/controller systems without one I have no idea, and I’ve used them since the 80s although the re-

Rob Gray


INTERVIEWFEA

TURED IN

TERVIEW

quirements have changed over the years. In those days most peripher-als were external to the processor and we were dealing with both data flow and timing issues so a wide and fast (read: expensive) analyser was needed.

These days most high speed peripherals are internal to the controller. The hard stuff has been done by the IC manufacturer, so while there are still some timing issues, it’s more a case of looking at data flow on serial links of various persuasions. For this you can get a really good analyser with serial decoders for $150 and a fantastic one for about twice that.

What are your favorite software tools that you use?My PC-based logic analyser client application.

What is the hardest/trickiest bug you have ever fixed?I don’t remember the details but it was with some code running on a 2900 series bit-slice processor. The processor had a very limited stack depth, maybe only four or five levels, and the program was large and had been around a long time so it was impossible to analyse the stack depth at any particular part of the code. So when a code patch was decided upon I was never game to insert a call to a function. The result was a program that was all but impossible to follow where half the code consisted of jumps to patches within jumps to patches, and the custom 64-bit wide instruction set didn’t help.

One bug took days to track down and this was in a core part of

the network co-processor on a mainframe, so the pressure was on.

As is often the case, it was a simple error—something like code that fell through to a return, or performed a push when it shouldn’t have—it was finding it that was the hard part. Not the stuff of legends but it was pretty difficult at the time.

I find that everything is moving too fast. We all joke about a product being

obsolete by the time it gets to the shops,

but that forces reduced time spent in

R&D and therefore reduced quality.

What is on your bookshelf?One book on VB.NET, one on Swing, two about PHP and a single Java tome. There are also three bird-watching guides, and a hot air soldering station. The usual mix really. That’s a total of eight books, of which none are applicable to embedded processor design.

These days I find that there is no need to have multiple shelves groaning under the weight of books as I did in the past. Most information

can be found on the Web in PDF or other formats, for example IC data books. I used to have maybe 20 Natsemi data books, each one two inches thick, then maybe another 15 from TI, a few Zilog publications and a dozen from Motorola just to name a few. Now if I want data on an IC I let my fingers do the walking and Google do the searching.

Do you have any tricks up your sleeve?With modern SMD components it’s no longer practical or even possible to connect test equipment directly to the component for debugging prototypes. And trying to hold a probe on a TQFP leg is an accident waiting to happen. This means a method of connecting test gear should be implemented on the PCB and the most obvious method is to add a header.

However, these same SMDs also mean smaller and tighter boards; even a 6-way standard-pitch header consumes a huge amount of board real estate.

My solution is distributed test points.

I identify the signals that will be needed for debugging and ensure that there is an access point somewhere on the board for those signals.

This can be as simple as not having solder mask tenting on a via, but normally I place an over-sized via on the signal, either replacing an existing via or just dropped on the signal trace in a convenient location.

This test via is hexagonal in shape to help identify it and I often add an overlay label as well. It also has


INTERVIEWFEA

TURED IN

TERVIEW

a larger hole to make it easier to securely hold a probe on the test point or even solder in a flying wire.

What has been your favorite project?Probably a wireless remote cattle trough monitor I designed in the late 80s. This had two halves, the remote was a 6805-based solar-powered unit that slept for most of the time but woke occasionally to test the water level in the trough and transmit a short burst of data to a base station.

The base station used a popular Z80-based personal computer of the day. The computer provided keyboard and screen IO but used audio tapes to load programs. I considered this to be a major stumbling block for what was essentially a consumer product. So I designed a mezzanine board that had EPROMs to hold the application code, a real time clock and a serial port to interface with the RF receiver.

Then I had the problem of turn-around time for program iterations when developing, as that required EPROMs to be burnt, so I designed an EPROM emulator that featured a 20V10 programmable logic array and a Z8 microcontroller.

The “Romulator” as it became known earned me the “Inventor of the year” award for my home state and went on to be a product in its own right. In fact, it was much more successful than the system it was designed to help build.

C cross-compilers were expensive then and they weren’t very efficient at generating code for these resource-challenged processors, so all the

above was written with thousands of lines of Z80, Z8 and 6805 assembly code.

Those were the days.

Do you have any note-worthy engineering experiences?While working in the R&D section of a large multi-national computer firm I was asked to cycle the power on one of the mainframes. The computer in question had been shut down with all apps terminated, disks spun down and databases closed. All I had to do was press the power button.

...one challenge will be to get reliable

products out in less time than we used to. Fortunately, the tools are much better these days and that helps,

but I hate the fact that something I design may have the life

span of a house fly.

The button in question was a type that did nothing electrically when pressed but went open circuit when released which was fortunate because the instant I pressed it I

realised I was about to pull the rug from under the wrong mainframe. Now killing the power of a mainframe in mid stride is a very bad thing but I had not released the button so no harm was done, but like a soldier standing on a landmine I couldn’t move and therefore couldn’t tell anyone of my predicament.

Eventually someone came into the room, they informed all concerned parties and an orderly mainframe shutdown was started. But I had to stand there for some time providing the chief source of office entertainment until I could release the button.

On a more serious note, I was electrocuted once (well several times really but once of particular note). With digital clocks in every home appliance from TVs to toothbrushes it can be a real pain to reset them all after disconnecting power from a house. So given that I’m a lazy fellow I tend to work on simple jobs with the wiring “hot.” Normally the first time I touch a bare wire I use the back of my hand so if it’s live my muscles will pull the hand away, but on this occasion I was not concentrating and grabbed the bare wires between my thumb and first finger.

The experience is not something I would recommend and my hand would not let go of the wires. It all happened very fast but I think what saved me was the fact that my bicep also contracted and pulled my arm away from the wire, as the wire was short and mechanically fixed at the other end so my arm muscles overrode my finger muscles and pulled my hand off the wire.


INTERVIEWFEA

TURED IN

TERVIEW

For some time I had burn holes in my skin, and I no longer have any mains-driven digital clocks.

And in the “famous last words” category, I remember looking at a microprocessor data sheet for the first time in the early 80s and thinking, “These things are useless.”

What are you currently working on?I have two major fields of interest: serial monitoring and control networks and embedded processor debugging tools. I’m currently spending a large part of my time designing two specific projects in these domains.

The networking project is called BUSnet and it has an associated project called MAXX that is a monitoring and control system.

On the debugging tool front I’m working on a tool that will help with the debugging and testing of embedded microprocessor designs. Its working title is “QUADD” which stands for Quite Useful All-purpose Debugging Device and it sports a LPC1768 as the control processor. This project will also let me work with some PC-based GUI programming, another field I enjoy.

What direction do you see your business heading in the next few years?After what I consider to be a reasonably successful career in IT and embedded design, I semi-retired in 1999 at the age of 45. I have no real need to work, and in fact I have not done so since. I do miss the embedded design

world though and have recently thrown my hat back in the ring as a freelance designer under the name GRAYnomad Designs. If you’ve seen my website you’ll understand where the “nomad” part comes from.

So I guess my “direction” is to work with projects that I find really interesting.

What challenges do you foresee in our industry?I don’t have my finger on the pulse as much as I used to, but that actually may have allowed me to see some things clearer. I think I may see changes more than someone who’s been in the job all that time, in the same way that you can keep buying larger jackets over the years and not notice that you are getting fat, and then you try on your old school blazer and find that you’d need a second one to make the ends meet.

In light of that rather tenuous analogy, one thing I am noticing after an absence from the game is the short lifespan of some components. There was a time when you could design a circuit using a few 74xx00-series ICs and be reasonably certain that your grand kids would use the same components should they become engineers. That is definitely no longer the case. For example, I spent some time recently selecting a particular IC; I found one that had just the right features and started working it into a design. Then I thought I should check its price as there is no point including a $10 chip in a project with a $20 retail price point.

Blow me down if the chip was

already listed as end of life, and it wasn’t that old.

In general I find that everything is moving too fast. We all joke about a product being obsolete by the time it gets to the shops, and that forces reduced time spent in R&D and therefore reduced quality.

So I suppose one challenge will be to get reliable products out in less time than we used to. Fortunately, the tools are much better these days and that helps, but I hate the fact that something I design may have the life span of a house fly.

Images taken by: Paul Hoelen

To request a free evaluation board go to:

Avago Technologies, an industry leader in IGBT Gate Drive technology solutions introduces our Next Generation series!

Based on BCDMOS technology Avago can deliver higher peak output current, better rail-to-rail output voltage performance and faster speed than previous generation products. The increased drive and speed along with the very high CMR (common mode rejection) and isolation voltage will enable you to build more efficient and reliable motor drive and power conversion systems. In addition the SO6 package which is up to 50% smaller than conventional DIP packages facilitates smaller more compact design.

www.avagotech.com/optocouplers

Avago Technologies Optocoupler Solutions

2 Times Faster, 50% Smaller, True Rail-to-Rail Output Voltage IGBT Gate Drives

Benefits

• Suitable for wide range of IGBT class for different market applications

• High output peak current for fast and efficient IGBT operation

• Rail-to-rail output voltage for reliable IGBT operation

• Lower system power budget

• Suitable for bootstrap power supply operation

• Reduce dead time and improve system efficiency

• Prevent erroneous driving of IGBT in noisy environment

• 40%-50% smaller than DIP package for space and cost savings

Applications

IGBT/MOSFET Gate Drive

AC and Brushless DC Motor Drives

Renewable Energy Inverters

Industrial Inverters

Switching Power Supplies

http://bit.ly/jpn9V5


PROJECTFEA

TURED PRO

JECT

BUSnet/ MAXX

By Rob Gray

My current project is a RS-485-based async network aimed at the commercial to light-industrial monitoring and control market. The protocol is called BUSnet and the hardware goes by the name MAXX (a homophone for an acronym for “Monitoring And Control System”).

BUSnet is a low-speed (up to about 115,200 bps, but maybe faster) network designed to make connecting embedded microprocessors both easy and robust. It is essentially a “network of point-to-point links.”

BUSnet has three layers that are rather imaginatively named: layer 1, layer 2 and layer 3. These are roughly analogous to layers 1, 2 and 7 in the ISO model. Layer 1 is the physical layer, that being point-to-point full-duplex RS-485 links (See Figure 1). Layer 2 is concerned with getting a payload of data from an application onto the network without

errors and with receiving data from the network without undetected errors. And layer 3 handles security, safety, end-to-end feedback and interlocks.

So does the world need another async network? Well probably not, but on the other hand I’ve researched about 50 existing networks and I cannot find a single one that is cheap, simple and robust while allowing relatively large

payloads and long distances.

Following is some of the criteria I looked for:

Open: Many existing networks are closed; you have to buy everything from the network vendor. Others are “open” but you have to pay thousands of dollars to join the consortium or buy the specifications. That’s not open to a hobbyist or even a small business.

Robust: BUSnet uses RS-485 line drivers, a genuine industry standard that provides a high level of protection for the signal. Payloads are protected by a sequence number, payload length field and a 16-bit CRC. Also with BUSnet, each node is a mini system in its own right—the IO on a node can operate even if the network is down. And in a further step to making the network robust, each node can detect a rogue neighbor or damaged cable and isolate it.Figure 1


PROJECTFEA

TURED PRO

JECT

Small: Some existing networks require a huge amount of hardware even for a small node. I’ve seen one that needs about 9” square of PCB for the simplest node, while another needs 28 components. With BUSnet it is possible to build a functional (albeit very simple) node on a PCB less than 1” square using three active and a few passive components. With fewer human-friendly SMD components even smaller should be practical.

Informal: Some networks require a system to be “designed” and “implemented,” and then “tuned.” Make changes and the process has to be repeated even to the point of re-flashing processors. BUSnet is very informal; you can start with two nodes then add nodes as requirements or finances dictate.

Cheap and accessible cables and jacks: BUSnet can use any telephone 6-way cable with RJ12 6P6C connectors defined as being standard. Power is optionally distributed on the network cable so if more current carrying capacity is required, larger cables can be used.

BUSnet is not designed to compete with companies like Modbus, Profibus and others. Firstly, there is of course no chance of doing so, but also there’s no point. The industrial PLC market is sown up by some very capable players, but they are expensive and I feel there’s a niche for smaller and cheaper systems that are still robust—something that’s above the hobbyist’s requirements but below those of, for example, a natural gas plant. Such systems may be in a pet shop where all the

reptiles have to have a controlled environment, a solar power system that needs monitoring, or a cattle trough on an outback station (a.k.a. a ranch or farm to my non-Australian readers) that can report the water level.

Point-to-point, advantages and disadvantages

BUSnet does not use the normal multi-drop topology; it uses point-to-point links between nodes.

The decision to go point-to-point was not taken lightly as it does add expense and indeed the design was multi-drop for a long time. However, I think that overall point-to-point in a ring topology (with data flowing in both directions) will make for a better and more reliable system.

One may argue that the robustness of a ring system is subject in turn to the robustness of the code running on the processors that directly interfaces with the PHY level as these processors must store and forward data to the next node.

That’s true, but it’s also true of a multi-drop system and indeed any system that uses microprocessors to interface with the bus. With a multi-drop system, a failure in the interface processor can bring down the entire network simply by forcing the data levels to a fixed state or by transmitting continuous garbage. With point-to-point these faults can only affect the node’s immediate neighbors; and even then it should not stop them from functioning as they can still communicate through their neighbors on the other side.

The following sections detail my thinking on the pros and cons of

this topology over a more standard multi-drop bus.

Pros

Bus clashes: There are no bus clash issues. This makes the software simpler and, in theory, more robust.

Mixed data rates: Slow and fast nodes can coexist. Also, links that are potentially more error prone (e.g., because the link passes through a noisy environment) can run at a slower rate while the rest of the network runs at high speed.

Adaptive links: Nodes can dynamically adjust a link’s data rate according to the number of errors encountered on the link.

Fault isolation: A single cable or node fault cannot bring down the entire network; it may have no effect at all or may only affect one or two nodes. With multi-drop, a short circuit between the data conductors stops all data flow.

Mixed PHY layers: Links can be implemented with any physical transmission medium. Currently only RS-485 is defined but there’s no reason RS232/422, LIN, CAN or TTL can’t be used for the entire network or at least some individual links.

Bus length: As each link between nodes is an RS-485 connection, the normal parameters apply to it. Therefore, distances between nodes can be up to 4,000 feet or 1.2 kilometres. As there can be 256 nodes, there is a theoretical maximum bus length of over 190 miles or 300 kilometres—something I assume will never be tested.


PROJECTFEA

TURED PRO

JECT

Cons

Expense: Each node requires two RS-485 transceivers and the bus cable needs two more conductors. Even with multi-drop, I planned to use 6-way cable, so this is essentially just one extra transceiver and the cost increase is negligible.

Propagation delay: All frames are delayed by one byte time per node because a node obviously has to receive a byte before it can transmit it. It also has to check if the frame originated with itself.

Branches/stubs: Branches and stubs require two cables. You cannot simply T off an existing cable; you have to run cable out and back.

Polarity conscious: With multi-

Hardware

So what hardware is required? Put simply, the core interface circuit consists of a “protocol handling” processor and two RS-485 transceivers. Add your application processor and whatever logic is required for the node IO (see Figure 3).

The original design goal was to have nodes as small as possible and to this end I started with a small processor, namely the ATtiny85. While this did satisfy the “small” criteria, unfortunately the chip does not have the grunt to do the job of bus interface as well as the node’s application. So I moved on to bigger things.

The next relatively stable design featured an ATtiny84 that acted as the low-level bus interface and watchdog to a larger chip (the ATmega328 or similar). With this model I actually got to the point of sending PCB designs for fabrication. And then a (potential) technical/sales partner suggested the LPC1111 32-bit microprocessor.

My initial reaction was along the lines of “32 bits for a temperature sensor!” I was very surprised, but I followed up the suggestion anyway, all the time looking for excuses not to use the chip. One thing I have learned over the years though is that it’s very easy to be too close to a problem and to hold onto the existing solution like a man overboard grasping a length of driftwood, especially when a lot of time has been invested in a particular solution.

But the more I looked into the LPC idea the more I liked it, and

that is where the design stands at present, with one small change. The LPC122x has features above the LPC111x, namely better ESD protection, two UARTS, improved provision for non-volatile storage in flash, more high-current pins, and a unique serial number burned into each chip. These features make it more suitable for this application.

And the irony of using a 32-bit processor is that rather than make things more complicated, it has in fact simplified the entire design and reduced the cost. More functionality with less hardware, and hardware is a recurring expense.

Robustness

One of the primary goals of BUSnet/MAXX is robustness. As long as the robustness is practical, it should not be possible for the entire network to be brought down by a single fault or even multiple faults.

The system incorporates many features that will make it robust, however it is not supposed to be a mil-spec or Triplicated Modular Redundant (TMR) system. So maybe you would ask, “Why bother spending so much effort making it robust?”

I suppose the simple answer is that’s the sort of thing I enjoy doing, but also I see little point in designing something that is not robust. A system may not have to survive a SAM missile hit, but if all your fish die when the aquarium control system fails simply because a wire was jammed in a door, you would be very upset.

So MAXX is not about averting one-in-a-million disasters. If an out-

drop it’s practical to make the nodes detect and correct polarity inversions caused by incorrect wiring. This is not practical with full-duplex point-to-point.

Figure 2


PROJECTFEA

TURED PRO

JECT

of-control semi trashes an entire workshop, you will probably have other things on your mind; but it should be able to handle the events that are reasonably expected to happen. For example, if a forklift trashes a cable duct, the safety interlocks on nearby machinery should still work.

That is the level of robustness I am aiming for using the following techniques:

Line interface chips: Each node talks to the network through a Physical Interface and Protocol Engine (PIPE) chip. The PIPE appears as an I2C slave to the node processor and handles the following functions:

• Frame handling: The PIPE accepts data payloads from the node processor, formats them into a BUSnet level 1 frame and transmits the frame onto the

network. Conversely, it receives frames from the network, strips the frame overhead and sends the payload to the node processor.

• Application processor watch-dog: The PIPE will detect vari-ous errors caused by the node’s application processor and it has the ability to reset the processor either autonomously or under control from an HMI elsewhere on the system.

• Bad line detection: The PIPE will detect faults on the links in either direction. When a fault is detected, that link is logically disconnected. Assuming that the node on the other side of the fault does the same, the fault is isolated. If the fault fixes itself (the source goes away) or is fixed (by the maintenance man), the PIPE will reinstate the link.

Ring topology: It is preferred that the nodes on a network are connected in a ring topology. Thus, if the cable is cut, all nodes are still connected to each other. However, this is not a hard requirement as sometimes it is not practical, so a bus topology can be used. This does however remove one level of robustness because a bus is really just a ring that’s already been cut once.

Multiple master: BUSnet uses a multiple master protocol whereby all nodes can publish data at will. Thus the loss of a single master node does not kill the system.

Autonomous nodes: A node is essentially a small system in its own right with several processors and possibly dozens of IO points. Functions that operate internally can do so even if the network is down.

Backup nodes: It is easy to have “backup” nodes running in warm standby. Such nodes will read sensors and perform computations exactly the same as their primary counterparts. However, they will not publish the results unless they detect that the nodes have gone offline. A non-critical example is the time of day (ToD) function; a network may have an RTC node and also a GPS node with both being capable of publishing ToD data. The GPS will be the primary source because it is more accurate. So while it has a signal it publishes the ToD, and the RTC node is simply a subscriber that uses the data to synchronize its own clock. Should the GPS go offline, say because the signal is lost, the RTC will take over the role of ToD publisher. This same principle can of course be applied Figure 3

BUSnet/


PROJECTFEA

TURED PRO

JECT

to more critical applications.

Galvanic isolation: The hardware is not isolated by default, however the architecture lends itself to easy upgrading to a fully or partly-isolated system. As every node communicates to the network via a PIPE, and the node processor connects to the PIPE with just two wires, all you need to do is use a version of the interface PCB that isolates these wires and the power supply if that’s not local. Thus, a non-isolated system can easily be upgraded at any time. Also, a system that in general doesn’t need isolation but has one or two nodes that can be accommodated by using isolated interface PCBs on just those nodes. Taking this a step further, the points on a node can be made to be isolated, thus the isolation “granularity” can be increased such that individual IO points can be isolated even if others on the same node are not. If isolated RS-485 transceivers are used then the entire node is isolated, including the PIPE.

The above mechanisms should handle the following faults.

Rogue node processor: If a node application processor fails to regularly and correctly poll the PIPE, the PIPE will logically disconnect the node from the bus and optionally reset the processor.

High error rates on a link: If the PIPE detects a high error rate on a link, it can downgrade the data rate. If the errors persist it can shut down the link entirely.

Rogue PIPE: Similarly, if a PIPE detects rogue behavior by one of its

immediate neighbors, it will shut the link down.

Clean cable cut (single): If a ring topology is employed and the cable is cleanly cut, there should be no effect at all on the network. If the network is organized in a bus topology then some sections will be orphaned. Orphaned nodes can, however, still communicate with each other if a local power supply is available.

Clean cable cut (multiple): In the case of multiple clean cuts, functionality will be lost. Whether or not this is critical (or even noticed) depends on the location of the cuts because, like an earthworm, the remaining parts can function as if nothing happened as long as power is available to the affected nodes.

Dirty cut: By a “dirty” cut I mean one that causes the conductors to be permanently shorted together or to other conductive materials. While BUSnet has power on the bus wires, each node passes power to its neighbors through resettable fuses. Thus, a short circuit in a section of cable should be dealt with locally with no effect on the network.

It is clear that for a system to be very robust, local power supplies are required for each node or at least each section of network that is at risk. If the requirements for an application don’t call for this level of robustness, then a global power supply can be used.

So where does MAXX get involved?

There’s no point in having a protocol without a useful application, and for

me that application is a monitoring and control system designed for what I call “commercial to light industrial” use.

A MAXX system can have up to 256 nodes, each with a node supervising processor and up to four plug-in IO nodules (IONs), each with its own processor (see Figure 5). Each ION can, in turn, have as many IO points as required to perform the ION’s task. Typically though, an ION will perform only one or two functions as I aim to keep a fine granularity to the system.

Thus, a node can be easily tasked for any application by simply plugging in the correct combination of IONs.

Figure 4

Each node then is a small subsystem that includes its own bus that the supervising processor uses to interface with the IONs. Therefore, events that occur on a point connected to an ION on a node that affect another ION on the same node can be handled with no network involvement. This of course


PROJECTFEA

TURED PRO

JECT

has good speed and reliability implications as more critical event/action couplings are not only faster ,but still work if the network is down.

An example is an emergency stop switch on some machinery; if the input that reads the button and the output that actuates a shut-off contactor are on the same node, the event/action is handled with no network involvement.

While having processors at every level does increase the complexity, it also increases the modularity, which in turn provides fault firewalls at every step. A failure at a given level does not necessarily affect functions at lower levels.

Another advantage to having processors on IONs is that the node supervisor does not have to know how to interface with every

sensor and actuator known to man. The ION is designed to do what it does and if that is to interface to a thermocouple or an LCD display, that is of no concern to the supervisor.

Therefore, once the supervisor code is stable it should never have to be changed. And yet, one more advantage is that ION processors can do much of the heavy lifting with regard to calculations based on the data it harvests. Where a hard connection to the outside world is known as a “point” or “physical point,” an ION can publish “virtual points,” — points that have no single item of associated hardware. They are entirely based on a calculation or algorithm. Examples are, the minimum, maximum and average values for a voltage input, the aggregate of several physical

points to provide the total battery bank voltage, or the duty cycle of a motor.

All this in turn means that simple systems can be plug-and-play; once IDs for published data types are agreed upon, a display node can be plugged into an existing system and immediately display, for example, the battery bank voltage or refrigerator’s compressor duty cycle—no setup or configuring required.

So where to now?

I guess that’s the 64 dollar question. I’ve been working on ideas for about a year, and in that time the system design has evolved many fold from a simple hobbyist connection for a few processors to a reasonably strong design for commercial use.

A recent major paradigm shift from multi-drop to point-to-point has set the design back markedly with many algorithms I designed being no longer applicable. On the plus side however, they are no longer needed. But others are, so in some respects it’s back to the drawing board.

Also, while I spent many years working in this field designing and building systems, I am now semi-retired and no longer have the resources to build a lot of hardware. Designing is essentially free; building is costly in both bench space and money, both of which I have in limited amounts.

So for the time being, the design will continue and I will start producing specification documents.

Watch this space.

Figure 5


FEATURED

PROD

UCTS

FEATURED PRODUCTS

350MHz to 6GHz Integer-N PLLLinear Technology announces the LTC6945, a high performance 6GHz integer-N frequency synthesizer with outstanding -226dBc/Hz normalized closed-loop in-band phase noise, excellent -274dBc/Hz normalized in-band 1/f noise, a wideband phase noise floor of -157dBc/Hz and best-in-class -102dBc spurious output. In a typical 900MHz application, these performance attributes enable a closed-loop phase noise of -100dBc/Hz at 1kHz offset. The LTC6945 is designed to work in conjunction with an external low noise VCO up to 6GHz. In addition, the device has an on-chip output divider that is programmable from 1 through 6 to extend the

tuning frequency coverage to as low as 350MHz. The LTC6945 comprises a low noise reference buffer, a reference divider,phase-frequency detector (PFD) with phase-locked indicator, an ultralow noise programmable charge pump and an integer feedback divider to attain very low noise PLL operation. The on-chip SPI-compatible bidirectional serial port allows frequency tuning and control, and read back of the register and loop status information.For more information, please click here.

Battery Overvoltage Protection ICThe bq2946xy family of products is a secondary level voltage monitor and protector for Li-Ion battery pack systems. The cell is monitored for over voltage condition and triggers an internal counter once the OVP threshold is exceeded and after a fixed set delay the out is transitioned to a high level. The output is reset (goes low) if the cell voltage drops below the set threshold minus the hysteresis. For more information, please click here.

OUT

V1

VSS

VDD

RVD

CVD

RIN

CINVOV

OSC

DelayTimer

PACK +

PACK –

INT_EN

REG

PWRPAD

gnirotinoM

elbanE

signal for frequency shifts. CW01 features a high speed D flip-flop and a high speed MOSFET to minimize phase noise to a typical level of -171dB below carrier. The D flip-flop allows CW01’s input frequency to be aligned to a high frequency clock. When a logic high is clocked into the D flip-flop, the N-channel MOSFET is turned on. Data are then clocked in during the low to high transition. The IC also features VDD and VLL undervoltage lockout to prevent spurious turn on.. For more information, please click here.

Four-Channel Continuous Wave TransmitterSupertex, a recognized leader in high voltage analog and mixed signal integrated circuits (ICs), introduced CW01, a four channel, low phase noise, continuous wave transmit IC designed for use in transmitters of diagnostic medical ultrasound machines and fluid flow measurement devices. The IC continuously sends a constant amplitude wave into the region to be examined. A resistor then processes the echo of the wave

HVOUT1

PGND1

Translatorand Driver

VD1VLL

270µH

0.1µF

0.1µF

5.0V

2.5V

2.0 to5.0MHz

96MHz

VD1

VDD

OE

VLL

DIN1

CLK

VSS

DIN1 Q1 CLK

BAV99

Tx

PZT

8.0V

BAV23

(one of four channels)

http://www.linearnews.com/press/LTC6945/LTC6945.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+LinearTechnology+%28Linear+Technology%29&utm_content=Google+Reader

http://www.ti.com/product/bq294602

http://www.supertex.com/pdf/press/press_release_111220.pdf


Engineers have been using Hall effect measurements to characterize materials since Edwin Hall discovered the phenomenon in 1879. The Hall effect is the generation of a voltage, called the Hall voltage, across a sample of a material when that sample is exposed to a combination of a magnetic field through the sample and a current along the length of the sample (see Figure 1).

In the electronics industry, integrated circuit manufacturers and crystal manufacturers use Hall effect measurements in materials research, device development and device manufacturing. In addition to measuring the Hall voltage, companies use Hall effect measurement systems to determine quite a few material parameters including carrier mobility, carrier concentration (n), Hall coefficient (RH), resistivity, magnetoresistance ® and the conductivity type (N or P).

The recent interest in Hall effect measurements is being driven by the search for next-generation semiconductors that can overcome the barriers of size and speed posed by silicon-based materials. The goal is to maxamize carrier mobility with materials that can create smaller components and minimize heat dissipation. There is great hope that nanomaterials and single atomic layer crystals such as graphene or graphene-based material structures will be the solution. To characterize the properties of these new materials, including analyzing carrier mobility, Hall effect measurements are essential.

A basic Hall effect measurement system will likely include the following:Figure 1

MAG

NETI

C FLU

X

CURRENTHALL VOLTAGE

Use Hall EffectMeasurements toCharacterizeMaterials

Robert GreenSenior Market Development Manager

Mary Anne TuptaSenior Staff Applications Engineer


TECHN

ICA

L ARTIC

LETECHNICAL ARTICLE

• A constant-current source. For low resistivity material samples, the source must be able to output from milliamps to amps of current. For high resistivity samples (such as intrinsic semiconductors), the constant current source may have to be able to go as low as 1 nanoamp. But in general, a source capable of producing from 10 microamps to 100 milliamps will suffice.

• A high input impedance voltmeter. The voltmeter used must be able to make accurate measurements anywhere from 1 microvolt to 100V. High resistivity materials may require ultra-high input Z or differential measurements.

• A permanent magnet or an electromagnet. These are typically available with ranges from 500 to 5,000 gauss.

• A sample holder.

Depending on the application, your test system might also include some other equipment. The recommended technique to get the best quality measurements requires that multiple measurements be made at multiple edges of the sample; thus, a switching matrix is recommended to reliably acquire all measurements. Also, because Hall mobility is dependent on sample temperature, you may want a temperature measurement probe capable of 0.1°C resolution.

Measuring Mobility

To determine carrier mobility (µH), first measure the Hall voltage (VH) by forcing both a magnetic field perpendicular to the sample and a current through the sample. Accurate measurements of both the sample thickness (t) and its resistivity (ρ) are required. With just

these five parameters (B, I, VH, t, and ρ) calculate the Hall mobility using the following formula:

µH= |VHt| / BI ρ

To obtain results with high confidence, we recommend taking eight different measurements. Reverse the source current polarity, source on additional terminals, and reverse the direction of the magnetic field. If the voltage readings differ substantially, it’s advisable to recheck the test setup to look for potential sources of error.

For more on this topic, see the Keithley application note, “Hall Effect Measurements in Materials,” downloadable from Keithley’s website: http://www.keithley.com/data?asset=55773.

About the Authors

Robert Green is a senior market development manager at Keithley Instruments, Cleveland, Ohio, which is part of the Tektronix test and measurement portfolio. During his career at Keithley, Green has been involved in the definition and introduction of a wide range of instrumentation. He holds a BS in electrical engineering from Cornell University and an MS in electrical engineering from Washington University in St. Louis, Missouri.

Mary Anne Tupta is a Senior Staff Applications Engineer at Keithley Instruments, Inc. in Cleveland, Ohio, which is part of the Tektronix test and measurement portfolio. Mary Anne holds an M.S. in Physics and a B.S. in Physics/Electronic Engineering from John Carroll University in Cleveland, Ohio. She has been an engineer at Keithley for more than 20 years.

Figure 2: Illustrates the measurement configurations for both the Hall effect voltage (a) and the resistivity measurement (b). The resistivity measurement is made without a magnetic field.

B

SAMPLE

1

24

3

MEASV

FORCEI

noB

SAMPLE

1

24

3

FORCEI

MEASV(a) (b)

http://www.keithley.com/data?asset=55773

http://www.keithley.com/data?asset=55773

Single, Low Voltage Digitally Controlled Potentiometer (XDCP™)ISL23315The ISL23315 is a volatile, low voltage, low noise, low power, I2C Bus™, 256 Taps, single digitally controlled potentiometer (DCP), which integrates DCP core, wiper switches and control logic on a monolithic CMOS integrated circuit.

The digitally controlled potentiometer is implemented with a combination of resistor elements and CMOS switches. The position of the wipers are controlled by the user through the I2C bus interface. The potentiometer has an associated volatile Wiper Register (WR) that can be directly written to and read by the user. The contents of the WR controls the position of the wiper. When powered on, the ISL23315’s wiper will always commence at mid-scale (128 tap position).

The low voltage, low power consumption, and small package of the ISL23315 make it an ideal choice for use in battery operated equipment. In addition, the ISL23315 has a VLOGIC pin allowing down to 1.2V bus operation, independent from the VCC value. This allows for low logic levels to be connected directly to the ISL23315 without passing through a voltage level shifter.

The DCP can be used as a three-terminal potentiometer or as a two-terminal variable resistor in a wide variety of applications including control, parameter adjustments, and signal processing.

Features• 256 resistor taps

• I2C serial interface- No additional level translator for low bus supply- Two address pins allow up to four devices per bus

• Power supply- VCC = 1.7V to 5.5V analog power supply- VLOGIC = 1.2V to 5.5V I2C bus/logic power supply

• Wiper resistance: 70Ω typical @ VCC = 3.3V

• Shutdown Mode - forces the DCP into an end-to-end open circuit and RW is shorted to RL internally

• Power-on preset to mid-scale (128 tap position)

• Shutdown and standby current <2.8µA max

• DCP terminal voltage from 0V to VCC

• 10kΩ, 50kΩ or 100kΩ total resistance

• Extended industrial temperature range: -40°C to +125°C

• 10 Ld MSOP or 10 Ld µTQFN packages

• Pb-free (RoHS compliant)

Applications• Power supply margining

• RF power amplifier bias compensation

• LCD bias compensation

• Laser diode bias compensation

FIGURE 1. FORWARD AND BACKWARD RESISTANCE vs TAP POSITION, 10k DCP

FIGURE 2. VREF ADJUSTMENT

0

2000

4000

6000

8000

10000

0 50 100 150 200 250

TAP POSITION (DECIMAL)

RES

ISTA

NC

E (Ω

)

August 15, 2011FN7778.1

Intersil (and design) is a registered trademark of Intersil Americas Inc. Copyright Intersil Americas Inc. 2010, 2011All Rights Reserved. All other trademarks mentioned are the property of their respective owners.

http://bit.ly/nHxRhB


I/O Server Client

Suppose you have two processes: a server and a client. The server process reads some I/O from a hardware interface and passes the data on to a client process. These processes may or may not be running on separate processors. In particular, they do not have a common shared memory area.

Figure 1

In this situation the server and client have to communicate over some explicit pipe between them. This communication mechanism may be implemented in different ways depending on the system.

The server part of this system can be run with code similar to the following pseudo-code:

Figure 2

and the client part can run with the following code pattern:

In this case, the server initializes the communication and the client waits for and responds to the communication. So the server is the master and the client is the slave. This is perhaps to be expected since the whole process is driven by the arrival of data on the hardware interface.

So far, so simple. However, things get a bit more complicated if timing requirements are taken into account. Depending on the needs of the system, the protocol between the two processes may have to be more complicated.

Blocking behavior and buffering

Assuming there is only limited buffering within the

Figure 3

while (1)

get_data_from_pins();

send_data_to_client();

while (1)

wait_for_then_get_data_from_server();

process_data();

BufferedCommunicationBetweenReal-TimeSoftwareProcesses

Dave LaceyTechnical Director of Software Tools


TECHN

ICA

L ARTIC

LETECHNICAL ARTICLE

When the client is busy,the fifo fills up

When the client is ready again,the fifo can empty

Serverdatadatadatadata

Client

FIFO

communication pipe itself, the call to send_data_to_client() in the server process will be blocking; it will wait until the client is ready. This is fine if the client is ready in time and the data can be communicated before the next item of data needs to be read from the hardware.

However, if this isn’t the case and the client is too slow, then next data from the hardware will be missed.

There are different methods to get around the blocking problem. If the hardware has some kind of flow control it may be possible to hold off the interface and push the delay upstream in the data flow. But sometimes this is not possible.

The rest of this article looks at situations when there is no flow control, the pull of the client has variable timing and the push of the hardware has fixed timing. In this case the common solution is to use a buffer for the data.

With a buffer, the server process reads data from the hardware interface and places the data in a fifo. The client process asks the server to provide data from the other end of the fifo. The buffer needs to be big enough to cope with the amount of data that can arrive during the longest processing time of the client. (See Figure 4)

The question is how to design a communication protocol between the two processes such that the server can read from the hardware when it needs to and the client can get data when it needs to.

Polling

One solution to the problem is for the server to repeatedly poll the client for readiness in between each time it

Figure 4

gathers data from the hardware. The code would look something like this:

Figure 5

and the corresponding client code would be the following:

Figure 6

The server may send several items of data between hardware interactions or none, in which case the buffer will start to fill up to be emptied later.

while (1)


add_data_to_fifo();

while (!time_to_get_data)))

client_ready = poll_client();

if (!fifo_empty() && client_ready)

get_data_from_fifo();


while (1)

signal_ready_to_server();

get_data_from_server();

process_data();


TECHN

ICA

L ARTIC

LETECHNICAL ARTICLE

Event-based programming: selects

Writing the communication with a loop that repeatedly polls for a fixed amount of time is a slightly clumsy way of writing this kind of code. A better method is to use a programming style that instructs the processes to directly react to events that occur in the system.

The key to coding in this style is the use of selects to wait for an event to happen out of a specified set and then react when one of them occurs. The select construct in the XC programming language does this, as do constructs in other areas (e.g., the select system call in Unix or the wait call in SystemC).

An XC style select statement has a similar form to a switch statement in C:

Figure 7

The statement waits for one of event1, event2, and so on to occur and then executes the code in the relevant case body. Given this construct the server code can be rewritten in a non-polling style:

Figure 8

Making the client a slave again

The act of adding the buffer causes the client process to be the master of the communication. It signals the start of the transaction of data between the server and client. This is a problem if the client wants to react to other events in a select statement as well as the incoming data.

You can make the client a slave again by introducing an intermediate process that pulls from the server and pushes to the client:

In this case the pseudo-code for the intermediate process is

Now the client process can react to the event of the intermediate process pushing data and the server process can react to the event of the intermediate process pulling.

Making it more efficient: exploiting communication buffers

The introduction of the intermediate process is inefficient. There is a whole process just concerned with shoveling data to change the master/slave relationship of the other processes. This is not a problem if processes are cheap, but in many cases they are expensive or limited. Luckily, you can do without the intermediate process if there is a small amount of buffering in the pipe.

If there is enough buffering to store a byte in the pipe itself, the server can send a notification byte and then carry on processing. When the server first puts data in its buffer it sends a notification:

Figure 10

Figure 11

select

case event1:

...

break;

case event2:

...

break;

....

while (1)

select

case pins_ready();


add_data_to_fifo();

break;

case !fifo_empty() & client_ready():



break;

I/O Server Inter Client

Figure 9

while (1)




I/O Server N ClientSend Notification


TECHN

ICA

L ARTIC

LETECHNICAL ARTICLE

The client can then react to the event of this notification arriving and know there is now data available. It can then signal to the server that it is ready for data:

The server can respond to this (provided it is not busy dealing with hardware) and send the data to the client:

Figure 13

After this transaction is completed, the pipe is clear of the notification byte. So the server can send a new one if there is more data in its buffer.

Figure 14

Figure 15

If the buffer is empty then the pipe remains clear until the server receives more data. At any given time, there is only ever one notification byte in the pipe so the pipe buffer will never overflow and block the server process.

In this case the code for the server shown in Figure 15.

An important thing to note with this code is that the send_notification_to_client call will not block, the code will always carry on. On the other hand, the call to send_data_to_client will block until the client is ready. However, in this case the client will be ready since it signals its readiness to the server.

The client code for this case is shown in Figure 16.

This version of the communication protocol allows the client to be a slave and the server buffer to be in the right place without the need for an intermediate process.

Doing it in XC

On XMOS platforms using XC, the server and client processes will be XC threads and the communication Figure 16

Figure 12

I/O Server ClientSignal Ready

I/O Server ClientSend Packet

I/O Server N ClientSend Notification

int notified = 0; // this variable tracks

// whether a notification

// is sitting in the pipe

while (1)

select

case pins_ready():


add_data_to_fifo();

if (!notified)

send_notification_to_client();

notified = 1;

break;

case !fifo_empty() && client_ready():



if (fifo_empty())

notified = 0;

else

send_notification_to_client();

notified = 1;

break;

while (1)

select

case get_notification_from_server():



process_data();

break;

...


TECHN

ICA

L ARTIC

LETECHNICAL ARTICLE

mechanism will be XC channels.

The notification from the server needs to use the asynchronous outct primitive to send a control token without the normal XC synchronous handshaking on communication.

This control token should be a XS1_CT_END token to make sure that any inter-core switches between the threads are free after the token is delivered into the destination channel end buffer:

Figure 18

The client can select on this notification in code similar to that in Figure 18.

You can find XC communication examples of this type in the open source repository found at http://github.com/xcore/sw_thread_comm_examples

Join Today

www.eeweb.com/register

Electrical Engineering CommunityEEWeb

Figure 17

send_notification_to_client(chanend c)

outct(c, XS1_CT_END);

select

...

case inct_byref(c, tmp): // receive notification

c <: 0; // send ready signal

c :> len; // receive data length

for (int i=0;i<len;i++) // receive data

c :> data[i];

break;

About the Author

Dr. David Lacey works as Technical Director of Software Tools at XMOS Ltd. With over ten years of research and development in programming tools and compilation technology, he now works on the development tools for XMOS devices. As well as tools development, he has worked on application development for parallel and embedded microprocessors including work in areas such as math libraries, networking, financial simulation, and audio processing. XMOS Website.

http://github.com/xcore/sw_thread_comm_examples

http://github.com/xcore/sw_thread_comm_examples

http://bit.ly/jd6Wcw

http://www.xmos.com/


RETURN TO

ZERORETURN TO ZERO


RETURN TO

ZERORETURN TO ZERO

EEWebElectrical Engineering Community

Contact Us For Advertising Opportunities

[email protected]

www.eeweb.com/advertising

http://bit.ly/l6u6Cx

eeweb pulse - volume 26

Documents

engineering firms

rob grayfeatured products

new products

hall effect measurements

authorized distributor

supplier partners

control market

digikey corporation