31. March 2008 by pilot.

 Of the many tools I have used in the recent years, while working on various embedded control projects, there is one that I have quickly learned to love: the INTRONIX Logic Port.

Now I am sure you have seen and possibly tested plenty  of USB based tools that rely on your PC to do the heavy lifting and promise to replace some expensive and bulky traditional oscilloscope, logic analyzer or meter for a fraction of the cost. Well I have tested my share, and while they all shine for their ingenuity and often they speak well about the creativity and good intentions of the designer, they all kind of fall short of delivering on their promise and definitely pale in comparison to the LogicPort!

The LogicPort is not the cheapest of the USB logic analyzers you can find online nowadays, nor the one with the fanciest plastic case, but it does work.  It does exactly what the brochure says it would and most importantly it does what an embedded control designer needs with an effective and intuitive interface.

I know that their use has spread inside the company like a virus, by word of mouth, or I should say by our constant borrowing of each other’s tools… that’s the way I learned about it in my turn… now you are warned it’s addictive!
P.S.: Jon, I promise, I will return it to you … one day!

Posted in Tools | 1 Comment »

23. March 2008 by pilot.

Not all I2C Serial EEPROMs are created equal. In fact there is a lot of variety out there as the memory size increases the addressing schemes change, the number and use of the device select pins change as well. The size increase reflects more or less closely the passing of time (years) and with it the evolution of the market of serial EEPROMs within and beyond the confines of the original specifications of the bus.

To be able to adapt the code developed in the previous postings, you will need to pay close attention to the details. To simplify the task, I have tried to collect in one big table the key elements that differentiate each device.
Read the rest of this entry »

Posted in I2C | No Comments »

19. March 2008 by pilot.

In a few previous postings we started exploring the I2C interface and in particular its use to access the most common and inexpensive type of Serial EEPROMs (24xxx). After the long preamble, it is about time to start talking about code. Today we will write a set of functions to read and write 16-bit integers to and from a Serial EEPROM device (a 24LC16 to be precise) similarly to what we have done in chapter 7 with the SPI interface to the 25lc256 device. Read the rest of this entry »

Posted in I2C | No Comments »

18. March 2008 by pilot.

This past weekend I found another perfectly good excuse to spend a Saturday flying across Arizona. Ivan, a friend from the old continent, sent me an email during the week, he was in Arizona for company training but stuck without a car in Tucson for the weekend. Could we meet? And when a friend calls, how can you not listen?

The trip by car would have been a couple of hours (each way) of absolute boredom driving across the desert for hundreds of miles assuming perfect traffic conditions (an improbable assumption on this stretch of highway). By airplane, it would have been less than 50 minutes. There were no doubts in my mind on which way to go except for the weather. A cold front was supposed to cross the state right that day. Precipitation was not part of the picture, this is Arizona after all, but a fair amount of wind (variable direction and gusting to 25knots) was showing in the Terminal Area Forecasts (TAFs) on Friday night. Saturday morning, an update showed that the front was late and would have crossed Arizona only in the afternoon and off I went to beat the wind and reach Tucson by air.

Read the rest of this entry »

Posted in Flying | No Comments »

16. March 2008 by pilot.

In two previous postings (Chapter 7 1/2, I2C Interface) we have started looking into the I2C interface, some of its applications and the very basics of the communication protocol.

It’s time to start sending and receiving data bytes and learn how to form commands to communicate with what is perhaps the most common type of device requiring an I2C interface: the Serial EEPROM (SEE for short). Read the rest of this entry »

Posted in I2C | 1 Comment »

12. March 2008 by pilot.

I read with interest today an errata for the Explorer16 demonstration board…

I know, it seems strange to think of an errata for a demonstration board, but it can happen and as in this case, there is a good lesson to learn for all of us, living the dangerous lives of the Embedded Control designers on the edge between 5V legacy technology and the new 3V generations of products.

In order to keep their options as open as possible, the Explorer16 designers arranged for a number of different LCD displays to be used alternatively on the board. Three different layouts were pre-wired and, depending on market conditions (price) and availability, one of several different models of LCD displays (from different manufacturers) will be mounted at any given point in time. Since they are all compatible (or I should say there is a common minimum denominator among all of them) there are virtually no changes required to the demos and code offered with the board.
Interestingly some of these LCD displays are 5V and some are 3V devices. Since most of the PIC24 digital I/O pins are 5V tolerant, theoretically the two technology can be alternated without consequences except for one case that was recently uncovered.

When the Lumex™ LCM-S01602DTR/M module was used (the errata document will teach you how to recognize it) things got more complicated. This 5V LCD module has internal pull-up resistors connected to the 5V rail. When the PIC24 I/Os connected to it (for example PMPA0 which is multiplexed with the AN15 analog input function) is left three stated (very high impedence) it will let 5V get inside the PIC24!

Notice that this will not necessarily damage the part (the pull ups are pretty weak after all), but it will produce a more subtle problem, it will skew the internal analog voltage references and produce a large offset on the A/D module readings for example.

Reading the errata carefully, you will realize how an essential part of the problem is the high impedence of the input pins once three stated, which produces, with the LCD internal pull ups, a partition with a very high output voltage (close to 5V).

Decreasing the impedence, by turning pins to outputs (as you do when you enable the PMP), or by adding pull down resistors (even if of relatively high values) solves the problem as the partition is modified to produce a lower voltage …

The lesson learned: Once more, make sure that when you interface to a 5V device you either:

• use exclusively pins that are pure digital inputs (5V tolerant)
• use open drain outputs if you want to swing a 5V signal

Watch out from all pins that are multiplexed with analog functions, even if you have the analog function disabled in your particular configuration.

The pin-out cross reference table published in the previous posting “The Missing Pinout Table” might help you double check…

Posted in Tools, Tips and Tricks | No Comments »

12. March 2008 by pilot.

The I2C bus is based on a very simple protocol, a small set of rules that dictate how the two lines SDA and SCL are supposed to operate to allow the transfer of data.

With the premise that, at idle, both lines are high (pull up):
Rule 1) During the transfer of a bit, the SDA line can change status only when the SCL line is low.
Rule 2) When the SCL line is high, the SDA line status indicates the value of a bit.

Two exceptions to the above rules create special conditions that are used to delimit the beginning and end of each “transaction” between two devices on the bus.

A START condition is indicated when (in violation of rule 1) the SDA line changes from high to low while SCL is high.

A STOP condition is indicated when (again in violation of rule 1) the SDA line changes from low to high while SCL is high.

The figure below extracted from a typical device datasheet is worth a million words.

Read the rest of this entry »

Posted in I2C | 1 Comment »

7. March 2008 by pilot.

Over the last year I have received a couple of emails from readers inquiring about the absence of examples on the use of the I2C(tm) synchronous serial ports of the PIC24. I imagine many more of you would have liked to ask the same or at least might have wondered why the omission.

I have to make the premise that it was never my intention to write the “definitive guide” to the PIC24… there are already too many books that start with that claim (often in the title) and fall (way) short or end up basically rephrasing the entire device datasheet. So I set my goal to provide meaningful/entertaining examples on as many features of the PIC24 architecture as I could fit in 300 pages (you will notice that I ended up with almost 400 pages, and that was after the publisher got mad at me and had to reduce the font size twice…)

I also set my sight on one specific hardware platform: the Explorer16 board, trying to exercise all of the features available and then expand using the small prototyping area or the PICTail(tm) connector.

It just happened so that the I2C port was left behind, although it is briefly introduced in chapter 7 and compared to the other main synchronous option: the SPI port.

This omission is in no way an indication of a lesser importance of the subject to the embedded control programmer, on the contrary, if anything the popularity of the I2C interface is growing in the recent years. This is reflected in the continuous introduction of new devices that are based on or support it, but also new advanced application specific protocols that use I2C as their physical level / transport layer.

Examples of devices recently introduced by Microchip and based on the I2C interface are:

• 1Mbit Serial EEPROMS: 24xx1025
• 18-bit delta sigma ADCs: MCP3421
• 16-bit delta sigma ADCs: MCP3425
• 12-bit SAR ADCs:MCP3221
• 12-bit D/A: MCP4725
• Integrated Temperature Sensor (+/-0.5C): MCP9803
• I/O Expander 8/16-bit: MCP23016/MCP2308

Examples of application specific protocols based on the I2C interface are:

• SMBus, the System Management Bus, used in personal computers (and servers) for low speed system management applications
• IPMI, the Intelligent Platform Management Interface, used to monitor the system health and manage (mostly servers) systems remotely.
• PMBus, the Power Management Bus, used by advanced digitally controlled power supply units to monitor, configure and control power.

The PIC24 datasheet and reference manual provide ample documentation on the I2C peripheral features and options available but I will try and provide a little more perspective and practical advice in this and the next few postings.

The hardware requirements of the generic interface are very simple:

• A clock line (SCL) is controlled by the Master(s)
• A data line (SDA) is controlled alternatively by Master and Slave devices
• Two resistors (typically 2.2k ohm each, but the value will vary with selected speed and voltages) are used to pull up the two open-drain output buffers

That’s all!
To begin with, we should ask ourselves if we truly need to use a peripheral module or if we could do without (like most 8-bit PIC microcontrollers used to do)!? In fact the I2C specifications indicate a range of relatively low bus speeds. The original documentation (published by Philips decades ago) indicated 100kbit/s maximum and even if the more recent updates brought the speed up to 400kbit/s first and more recently to 1Mbit/s this is clearly within the realm of software (bit-banged I/O) solutions.

When we consider the most common application, that sees the PIC microcontroller as the only master addressing a handful of devices (typically 24xx serial EEPROMs) this is definitely an option. The advantage of a software approach is in the freedom it provides to choose any I/O pin we want, and the task is further simplified on the PIC24 since all I/Os can easily be configured for open-drain operation (see ODCx registers).

(Trick: In the single master case, the SCL line control never changes and therefore a common hardware and software simplification includes reducing this line to a standard CMOS output.)

In the good old times, on 8-bit PIC microcontrollers and using only assembly programming, I have seen implementations of I2C (single master) interfaces to serial EEPROMs in as little as 40 instructions (ever heard of the famous “Frank code”!?).

Another common trick used in power constrained applications is that of powering the entire peripheral device off one of the I/Os of the PIC microcontroller. In particular referring again to the common Serial EEPROMs (say a 2kbytes capable 24LC16), you will verify that their power consumption is limited to 3mA max. (even when operating at 400kHz) a value that is well within the capabilities of any PIC24 I/O port.

On Microchip web site you will find several examples of “software” I2C libraries (AN1100 for example) , don’t ignore them just because we have the luxury of having two hardware interfaces on the PIC24Fj128GA series … check all your options first!

(to be continued)

Posted in I2C | 2 Comments »

5. March 2008 by pilot.

PICTail(tm) Plus is the name that Microchip uses for the expansion socket offered by the Explorer16 boards. It is one of the easiest and most flexible options available for prototyping out there. All the signals from a 100 pin PIC microcontroller are grouped logically and conveniently in three sections so that if only a few signals are required a smaller board can be arranged. The edge of any PCB can be quickly transformed in an inexpensive (as in free) connector as soon as you realize that all it takes is a set of 1mm spaced traces (gold plating is an option you might consider for longevity). NOTE that all connections are clearly documented in the appendix of the Explorer16 User Guide (DS51589) .

The AV16 board that I developed to support the code examples of the book is only one example of PICTail Plus expansion board, on microchiDIRECT you will find many other options to support: IrDA, Graphic displays with touch sensing, Ethernet, SD Cards and more.

But my all times favorite is the simplest one of all: AC164126  also known as the:

Prototype PICTail Plus board 

For $20 you get 3 (three) boards actually. All the signals are accessible in a standard spacing four row line up with silk screen call outs. Get your soldering irons warm!

Posted in Tools, AV16/32 | 1 Comment »

2. March 2008 by pilot.

Oh the things a pilot would not do just to find an excuse to fly some more!

Well, gambling is one of them! For the fourth year in a row, the last week end of January, a benefit Poker Run was organized by the association of women pilots of Arizona (the 99-ers) and I invited Marc, a colleague and old friend, to fly with me and test his new digital SLR. Jake, another pilot/colleague joined us flying his own, recently acquired, C172.

For those of you who never heard of a Poker Run, a simple explanation is due, at least with regards to the details of the flying version of the event, as they tell me that similar things are common in the boating/sailing world. The organizers pick five locations, airports within a given radius of several hundred miles, in our case in cities along the Colorado river. They establish a beginning and end time. At each of the five locations each pilot can pick a poker card (in a sealed envelope). The location chosen this year where, from South to North:
Blythe, Parker, Lake Havasu, Sun Valley and Needles.

The order the airports are reached is not important as long it is done within the allowed time slot. Each pilot is free to pick the flight path that is optimal considering his place of origin and the capabilities of the aircraft. The last card is typically retrieved in the final destination airport (Lake Havasu in our case) where all participants convene for the cards to be played (opening the sealed envelopes in front of the judges). The highest scores are noted and a small portion of the benefit money gathered with the registrations is used up as a jackpot for the winners.
I had been intrigued by the idea to join the Poker Run for the last couple of years but for one reason or another I had never been able to. This time the weather was perfect and at 5am (well before dawn) we were preflighting the planes at the Chandler municipal airport. Wheels up at 6:30am.

Mark brand new Nikon D300 took some gorgeous pictures throughout the flight although, enthusiastically experimenting with all the new features of the camera, he tried very hard to botch them. When the sun came up, we had already covered a lot of desert and we were almost approaching the edges of the border between Arizona and California marked by the Colorado river.

Landing in Blythe, almost exactly at 8am, was easy as the air was still so calm and it seemed like we were the first ones to reach the location. When we made it into the FBO and found it empty, a terrible doubt dawned on us… Was the Run starting at 8am MST (Arizona time) or 8am PST (California time)? The event brochure was not mentioning the detail and coming from Phoenix we had so naively assumed… Were we one hour early? Waiting one hour in an empty airport office in the middle of the desert was not exactly and exciting prospective. Fortunately, after a few minutes of perplexity, a friendly face showed up behind the counter exclaiming “so… is it today?” and offered us a box full of sealed envelopes to pick from…

While taxing back to the runway, a few voices started coming from the radios… we were not alone anymore… other pilots were joining the race…

Flying north toward Parker, our next stop, I remembered that there were some interesting indian “paintings” (or I should say carvings) that could be observed only from an airplane as they lay on the flat desert floor. 40-50 feet in size they were meant probably to be seen by some ancient gods. But as we started searching for them we realized that those gods had to have pretty good eyes. As big as they were, when flying anywhere above 500 feet from the ground the images would be too small to be detected against the rugged terrain. Here is just one of the many gorgeous pictures we took…

After Parker, we continued up along the river passing Lake Havasu,

(where we would return later)

and all the way up to Sun Valley, a minuscule airport with such a narrow runway that we struggled to distinguish it from the network of streets of the surrounding developments. Then South again along the river to Needles, where cadets from the local military base handed us the envelopes right to the plane (nice!).

The final short hop back to Lake Havasu things got a bit hectic. All of a sudden the radio was filled with voices from a dozen airplanes all converging to the final airport at about the same time.

After a long(!) landing and a quick tie down, we raced to the judges’ counter to see our hand: a king, a queen, a nine, a ten and a… five!

Oh well, we were there for the flying after all. As a bonus the organizers offered an excellent BBQ to all participants and a short technical seminar (on mountain flying) was offered in the afternoon to tempt us and stay longer…

To top the day, the local FBO had the lowest fuel prices to be found in Arizona (and California too). What more can you ask for in a beautiful January day?

Posted in Flying | No Comments »