Syndicate This Blog |
Conserving MCU pins via the I2C busTuesday, January 27. 2009
In which your narrator finally gets around to demonstrating something he's been talking about for the better part of a year... About a year ago I found myself beginning to work with the I2C bus when I
decided that I needed a decent print buffer on the Tommelise 2.0 reprap machine.
I ran across a 512Kbit EEPROM chip at quite reasonable prices that connected to
the I2C bus rather than requiring a committed port on my 18F4550 MCU. For me
that was wonderful in that I was committed to a single board controller solution
rather than the multiple board scheme that the mainstream Darwin used.
I was astonished at how easy it was to integrate I2C EEPROMS with my
existing board. They've worked brilliantly as a print buffer ever since
then.
At that point I began to look around at other I2C enabled chips and
discovered a wide variety of things that I could do with my MCU via the I2C bus.
There were some things, however, that were simply not available in I2C format.
After much grumbling, I finally had a "DUH!" moment. It seemed reasonable that
Philips Electronics N.V, who had developed the I2C standard would have HAD to
have created a generic I2C slave chip that could be interfaced to ordinary
port-enabled IC's. If they hadn't, the I2C bus would have never got off the
ground.
Sure enough, a short catalog search revealed that Philips had indeed
created several such chips and that several other suppliers had developed their
own I2C slave chips as well. I then ordered a dozen of their excellent PCF8574
I2C slave chips, manufactured by Texas Instruments for a few dollars apiece. The
PCF8574 gives you access to a single 8-bit port through the I2C bus while its
bigger brother, the PCF8575, gives you
access to two, 8-bit ports. You can hang eight of either chip type off of a
single I2C bus. Mind, most firmware IDE's offer you software emulation of I2C
comms which will let you assign more than one I2C bus.
The demands of my day job and other, more pressing issues with Tommelise
2.0, like making it mill plastics and printed circuit boards kept me from
actually using the generic I2C slave chips on anything for many months. Last
week, however, I got Tommelise 2.0 milling things properly and was able to take
a deep breath and look at my "to do" list.
One big item on my "to do" list was to build an infrared ranging system,
very short range radar if you will, for a telepresence robot that I eventually
want to get running. Since the ranging system is a spot detector, I have to have
an alti-azimuth positioning system which, of course, requires running a pair of
stepper motors. I had been putting off designing new boards until I'd got the
printed circuit board milling system working. Last weekend, however, I saw the
pile of Euro board format stip boards and decided that I might as well use one
of them and see, as well, if I could prove out the notion that the PCF8574 I2C
slave chip could be used to run the 754410 high-current half-H driver that I
would be needing to drive the steppers.
I'm a very conservative board designer. I used the 18F4550 MCU that I have
loads of hands-on experience and firmware from the Tommelise 2.0 project. I also
have PC-side USB support software for that chip as well. It took me a couple of
hours to design and wire up the board and about the same amount of time to chase
down and fix the wiring errors that I made on it.
This morning, I took a few hours off and copy/pasted up the firmware to
drive one of my little Kysan 25BY2414
tin can steppers that I keep for testing. Oddly, I was not able to get it
running with wave (single phase) stepping. That is puzzling in that wave
stepping tends to work on anything. When I switched over to full (two phase)
stepping, however, it ran without so much as a qualm.
At that point, I decided to see if I could use one of my Lin Engineering 1.8 degree step Nema 17's that I'd bought in bulk when I first started working on the Reprap project. I wouldn't be using this stepper ultimately on my IR radar system because it was two heavy and drew far too much power (2.5 amps/phase) for what I needed. To choke it down to something my 754410 chips could handle ( less than 1.1 amp/phase) I put 15 ohm power resistors in series with each phase.
There had been some talk that I2C and steppers wouldn't be happy together. That appears not to be the case. The data sheet on the PCF8574 says that a read/write takes 4 microseconds. That's not long enough to matter even if we're running three or four steppers in concert. What using 12C slave chips like I have lets you do is avoid having to go over to surface mount chips which let you have many more pins on your MCU which are directly accessible. Through the hole DIP chips are usually limited to a maximum of 40 pins with the rare 48 pin offering making an appearance from time to time. What happens with DIP chips is that the chipmaker makes one pin do duty for sometimes as many as six of the pins that would have been available on a surface mounted package for the same chip. I've tried to use some of these stacked up function assignments on 40 pin chips. It seems at times that you have to do a dance around a fire on a full moon and sacrifice a goat to get at some of the functionality of stacked DIP MCUs at times. What I suspect is happening is that IDE vendors get tangled in their own compiler coding trying to make one set of code fit dozens of slightly different models in the same MCU family. It's certainly a pain for an unwary board designer. In any case, hanging output and not-interrupt input functions that would ordinarily occupy IO ports on the I2C bus leaves you with very clean board landscape around your MCU. That's a big plus for me in that I'd like to keep my controller board design to a milled single-sided or simple double-sided board and avoid having to send my designs out to a board etching firm and pay set-up and minimum run charges. It's been pointed out on any number of occasions that learning how to surface mount chips is no big deal. I have no doubt that that is true. What I do know is this. When you insist that audience know how to use Linux or at least how to do Linux-like builds on a Windows machine in order to get a mainstream Reprap machine running at all and when you insist that in addition to that that they learn C, not exactly the most user-friendly compiler out there to make changes to your firmware, adding to that learning how to do surface mount soldering seems to me to unnecessarily create a positively Himalayan set of barriers to people building and modifying mainstream machines. That is not at all to say that there are not a lot of people out there who either already possess either some or all of those skills who are also interested in 3D prototyping. There palpably are or Reprap Darwin wouldn't be the amazing success story that it is. I just keep coming back to my archtypical bright twelve-year-old. While there are a lot of them out there, the number that have knowledgeable father figures who can help them over the bumpy bits on the path to success is limited and getting smaller by the year as our society ... um ... "progresses". That's why I stick to Windows, which the twelve-year-old probably already has on his or her PC, Basic, which is trivial to learn for all its limitations and DIP chips. Going for surface mount chips, for all their advantages and for all that the chip industry sees them as the future, for me is just adding another layer of difficulty to an enterprise which is already more than difficult enough. Trackbacks
Trackback specific URI for this entry
No Trackbacks
Comments
Display comments as
(Linear | Threaded)
Just a few late results. I shifted the stepping regimen to half stepping which made the motion of the NEMA 17 very, very smooth. I duct taped the anti-backlash assembly to the drive shaft of the NEMA and was able to get it to deliver about 1,100 pps under a useful load and transition at a rate of about 7 mm/sec using a 1/4-20 threaded rod (1.27 mm/turn metric pitch).
Have you tried extending the i2c bus to get an idea how long it can be before interference becomes a problem?
Nophead has said that the I2C standard is primarily an on-board bus and shouldn't extend more than a few inches at most. That is the rule of thumb that I have been using. I believe Nophead's primary motive in such a short length is that apparently I2C is particularly sensitive to EMI. Repraps, which use both brushed and brushless motors are rife with this sort of situation. OTOH, last night Vik, referenced a FAQ about I2C {http://www.esacademy.com/faq/i2c/q_and_a/faq/i2cqa1.htm} which indicated that distances of 9-12 feet could be reached without a lot of drama as long as bus cables were shielded. While for me the I2C bus length question is interesting, as a practical matter I can't see myself exploring it since I have no need for long I2C buses in the work I am pursuing.
Another I2C IO expander worth playing with is the MAX6956. It has 20 IO lines in DIP package form. These have a very flexible access scheme. You can address any of the ports in multiple bit widths at arbitrary start locations. It supports on-change interrupts, using one of the IO pins as an IRQ handshake line. It also drives LEDs with its adjustable constant current setting.
The best part is you can sample them free from Maxim :)
I use them here:
http://arduinonut.blogspot.com/2008/10/tier-jerker.html
Love the writing.
Charlie
At a bit over $8 from Digikey, that's a pretty pricey chip. For now, I am favouring cheaper, lower capacity chips that I can scatter over my board design and connect to the MCU via the bus to clean up the complexity of traces.
You can stick to Windows if you want... but your archtypical bright twelve year olds are all running Linux already. I don't know where they picked it up, but a quick survey of my nieces and nephews found that nearly all of them knew of, and used regularly Firefox and Ubuntu. Welcome to the middle of the adoption bell curve.
http://en.wikipedia.org/wiki/Usage_share_of_operating_systems
While the stats that I have access to are not broken down by age echelon, the simple truth of the situation is that Linux use on desktops averages about 1% of the market. Even if usage by 12 year-olds is a magnitude higher than the overall average it is still not a significant fraction. I'm not a Microsoft cheerleader. Their nutjob DRM fixation makes me crazy. All the same, the reality out there for at least the next several years is that they've basically got the market.
You're (perhaps unintentionally) preferentially selecting a dataset to match your claim. Initially the discussion was about bright (above average intelligence) twelve year olds, now you're talking about the (presumably less intelligent) population of desktop computer users in the developed world. Admittedly we've got a dearth of data, but you started with a group that (for instance) navigates social networks with ease, and just cited a group that largely doesn't know what a social network is.
Not all of my younger relatives used Ubuntu on their home machines... most didn't (their parents wouldn't know what to do with it). However, they all responded nonchalantly "Yeah, we use it at school to get around the myspace block" or "so-and-so has that on his computer, it's cool I guess. It has firefox!".
Take it for what you will... There certainly appears to be a generation gap.
"There certainly appears to be a generation gap." Oh, there certainly is. I have a son who is graduating university in April. He certainly used a Linux startup disk to get around blocks at his high school and as well used another to crack passwords in windows systems for which the passwords had been lost. He knows his way around Linux and knows how to use it to accomplish his purposes. What is important though, is that, for him, Linux is merely a means to an end. He has, over the years, not found Linux compelling enough to commit to it as a full-time operating system. As to which "bright" twelve year olds I am talking about, I'm talking about the top 5-10% (IQ120+), not the top 1-2%(IQ130-135+). My son is in about the top 0.1%
Indeed. Unfortunately, switching from one thing to another is always hardest for those of us most skilled in the use of the original. In other words, counter-intuitively, those of us who are most intelligent, and most actively use computers, have the hardest time switching to linux -- we have the most functionality to re-learn and replace. That's gotten easier over the years (when I switched to using Linux 100% of the time, the only browser was Netscape 4.x and there was no such thing as a word processor, let alone an office suite). It can still be a challenge for the most accomplished users to switch, but for the regular folk, and even above average folk, it's a cakewalk these days.
|
