Since most microcontroller vendors offer I2C master and slavecapabilities on most of their devices, there is nothing to prevent anembedded designer from taking advantage of I2C. The designconsiderations when creating a custom I2C slave device were the focusin Part1.
In this part, we will concentrate on strategies for a smoothverification of a custom I2C slave device, taking advantage of the factthat I2C is a low- to medium-data-rate master/slave communication bus.
Rember, the physical layer is a simple handshaking protocol thatrelies upon open collector outputs on the bus devices and the devicedriving or releasing the bus lines. The simple hardware design andrelatively low data rates allow any engineer to take advantage of I2Cas a communication solution.
Test Strategy Proceeds from DesignStrategy
It is a given that a smooth design needs a planned verificationstrategy. With a master/slave communications system, the both partsneed to be validated. Postponing verification until both master andslave are complete is the wrong strategy. What follows is a strategy toefficiently test both the master and slave as independently aspossible.
Four things from our discussions in part one, the design phase,specifically support an efficient verification:
1) Clearly definedinterfaces,
2) Master initiates alltransfers, and supports “emergency” calls by the slave,
3) Slave’s communicationprotocol is kept independent from main functional task, and,
4) Slave maintains datacoherency at all times.
While everything during the design phase impacts verification, theabove list is specific considerations that support our test strategy.This strategy can be summarized as:
* Separately test themaster and the slave,
* Increase test coverage byusing as “real” an environment as possible,
* Put slave and master togetherfor integration early and often.
Separately Test the Master from theSlave
We designed our master and slave to be separate, uncoupled, and thedesign process concentrated on developing interfaces that are not tiedto the design details (covered in part one). This separateness supportstesting each part separately, both physically and chronologically.
But to successfully test the master and rely upon the results, theremust be some form of the slave early on, the test slave. The test slaveshould be a shell of the design that provides the agreed-uponinterfaces and some additional test hooks (like a loop-back or anadditional register that contains the data slightly modified).
The goal of the “shell” slave is to allow the master to implementand test its interfaces. The best platform for this “shell” or testslave is the microcontroller that will be used for the slavedevelopment. In fact, if the same device is used for testing the masterthat ultimately will be used to develop the final slave, the “shell”provides the test platform for the slave’s interfaces (the firstdevelopment stage for the slave).
To complete the slave’s side of testing as a separate item willrequire more master capability than will likely be available from thereal master. The last thing you need in your project, an already atight development schedule, is more functionality developed for thereal master simply to support testing. The test master should be ageneric master, and most projects will benefit from a PC-basedapplication that talks to the slave through a PC-to-I2C bus bridgedevice (see “Slave Test Considerations” section for more on thesebridge solutions).
Use a “Real” Environment toIncrease Test Coverage
The last thing you want is to complete the separate testing of themaster and slave and realize when they are put together for finalintegration that neither master nor slave got a “real” workout. Testingthem in an environment that does not resemble the final product willresult in at least some wasted testing that needs to be repeated. Infact, a very nasty surprise could be waiting for you in the end if thetest environment is not close approximation of the real environment.
To avoid wasted efforts, test and design must proceed with knowledgeof each other. And test will primarily need the interfaces solid(locked in concrete) and not changing. The interfaces, if well definedand closely adhered to, will define the “real” environment, and specifythe design of the test environment.
Certain signaling and timing peculiarities will only presentthemselves at final integration, but the majority of the functionaltesting will be representative of the final product when aninterface-driven test environment is used for both master and slavetesting. In the unlikely (unwelcome, to be avoided, preventable) eventthat an interface changes, it must immediately flow down to the testenvironment.
Integrate Slave and Master Earlyand Often
A separately tested master and slave will only be complete whenintegrated and tested together. As mentioned above, certainpeculiarities will demonstrate themselves only during integration. Theweek before the project deadline (or night before) is not the firsttime you want to encounter this.
The interface-driven, separately tested strategy also supports earlyintegration, not as a substitute for well-covered separate testing, butas an insurance policy that interfaces and device behavior is wellunderstood. To support integration, both master and slave must be atmutually acceptable points of completion, therefore the design planningmust encompass these phases of integration.
Here are some of the phases or test cases to plan an earlyintegration for and why you need to pay attention to them:
Considerations for the I2C Master
As we discussed in part one, the I2C master is usually a master of manyother functions in the system and has the least flexibility for addingrequirements or making changes. Therefore, as we stated in part one,the master controls the interfaces.
During the definition phase, both master and slave have input, butwhen it comes to the detailed decisions, the master can force aninterface decision simply because one approach is easier for themaster. The slave earns extra credit for making things easier for themaster. The master will (and should) resist changes to the interfaces,so the slave designer must make his or her arguments early and livewith them.
Also, while we said changes to the interfaces should only come fromthe master (or with the master’s agreement) the test impact must alsobe considered, especially the impact on an “environment” that has beenconstructed to support testing. Concentrate on the interfaces upfront,get agreement from master, slave and test teams, understand the testimpact/benefit from specific interface decisions, and then
Create a surrogate slave to support the master testing (and it isbest if this can come out of the slave development). The surrogateslave may not resemble the final slave since its main role is tosupport the interface testing and verification; for the slave, thiswill mean extra, non-production functionality in the surrogate/testslave. Extra functionality to include might be extra registers usedonly for test purposes and/or special I/O actions to indicate functionsor acknowledge commands. Leaving these functions in the final slavewith conditional compilation may later help support regression testingif changes arise.
Finally, integrate the master and real slave (at a defined stage ofdevelopment) early and often to catch the inevitable “unspecified”behavior. The sooner real devices all encounter each other on the realI2C the sooner their peculiarities will be known and accommodated.
Considerations for Testing the I2CSlave
Just as we discussed in part one, the focus of the design activity isthe slave, and it should consume the majority of the effort (unless itis re-used from another project). The test effort will also focus onthe slave, and the slave will need to be implemented in line with theneeds of the master and its testing.
It is likely the slave will need to adapt to anything that islearned during integration, so the earlier that happens and the more“real” the testing can be the better. Convince the master team thatmore integration points are better; it will help the project anddirectly benefit the slave’s development.
For the majority of the testing, an I2C master test device, not thereal master, will control the slave. The flexibility required to getcomplete test coverage of the slaves will not likely be present in thereal master, and most times the real master carries other baggage(configuring other devices, timing needs, an end-user-centricinterface). The benefit of I2C is that a master test device is notcomplex and many are available. Everyone on the team NEEDS a testmaster, but they do not have to be costly or complicated.
For the I2C test master there are three approaches you can pursue. Ihave used all three types of solutions, and I find reasons to recommendeach in different situations. The three types of test masters are:
The last consideration for testing the slave, which cannot berepeated enough: integrate with thereal master early and often .
I2C bus communication is a popular element of many embedded designs.Every embedded design can benefit from offloading some functions to I2Cslaves, both for efficiency and for potential for reuse of well-testedfunctional blocks across many projects. Follow the design and teststrategy laid out in this article and your custom slave project shouldproceed with few hiccups: Partition the functions between slave andmaster, incorporate strong, unchanging interfaces, test the master andslave as much as possible on their own, and integrate the master andslave early and often during the design process.
Philips created the I2C bus and embedded designers have adopted itbeyond the purposes envisioned by the inventors.Microcontroller-implemented custom I2C slave devices can take yourcompany toward a catalog of reusable plug-and-play functions thataddress the repetitive portions of product designs.
Follow the rules and guidelines for design and test and you cansuccessfully exploit I2C in your products with more time to concentrateon the next whiz-bang feature marketing dreams up. It just might helpyou meet their unreasonable schedule demands as well.
To read Part 1 inthis series, go to
Jon Pearson is the productmanager for PSoC development tools at CypressSemiconductor, located in Lynnwood, WA. He can be reached email@example.com.
More Embedded.com Resources:
1) Embedded.com –
2) Embedded.com –