Price increase (sorry)

The price for C and the 8051 has remained constant since the latest edition was released… and considerably less expensive than most microcontroller texts. Unfortunately my printer, Lightning Source, has revised their price schedule and now defines the book size as ‘large’, increasing the per/page cost. While I do not aim to get rich, at the present price the book is netting me about $1 per copy sold and I soon might have to pay for each copy! So the price has been increased effective July 30 to $49.95 US. Of course, buying online Amazon works with their 50% discount to bring it in at a lower price to you, but it should provide a reasonable, say $10, royalty to me. If you are hesitating, now would be the time to buy before the price goes up.

A Real Comment!

While I welcome comments, I am dismayed by the flood of spam…totally unrelated to the topic…which flood this site. Only very rarely do I get any comments, so the following, posted with the author’s permission. is particularly significant:

> From: Никита Селедников
> Sent: Friday, March 14, 2014 11:39 AM
> To:
> Subject: Thank for your book and my point of view for 8051 microcontrollers

Good day, Thomas! I’ve finally made it to writing this letter.
First of all, I’d like to thank you for your giant work with the “C and 8051” book and describe you a little of how handy it is for me.

 I first got some interest in the early summer of 2012, right after I returned from the Army Service(Here in Russia it’s a duty for everyone). At that time I hardly imagine how the MCU works, but I had a strong willing to bound my future with the Internet of Things( I thought and think now that it’s The Next Big Thing). When I started digging, I discovered, that all serious wireless IoT systems work on the 8051MCU. I suppose you heard about ZigBee(though there are ARM solutions), but both Enocean and Z-wave(my favorite, which I’m working now with), all of them are working on 8051 MCUs. So right now the 8051 is not just alive, it perfectly fits the needs of the IoT, where small, energy-efficient MCU rules.

Since that time I studied some books, regarding MCU and C and finally past summer I got the job in a company, who creates Z-wave devices, my dreams were completed but then came the understanding, that I’m a complete ignoramus in programming. And then in a datasheet, I met the reference to your book. After it I found the scanned version of your book in the internet. It was a first edition, so a bit outdated, but it impressed me so much, that I bought your 4th Edition on the Amazon, and made it my everyday-book.

Right now the Z-wave MCU have a lot of built in functionality, I attach the brochure on last generation of MCUs.

All this modules have built in radio transceiver, and working with it is still a mystery for me, so I’d glad if you can recommend me anything, that can help me to clear it for me. —
Best regards, Nikita Selednikov

How about writing a guest post?

I admit it… my attention has wandered from electronics since I retired almost a decade ago… you can follow the link to Wood Islands Prints if you want to see where my attention has gone. Don’t get me wrong, I am grateful for the small but steady number of purchases of my C and the 8051 book that have continued despite the older version being (illegally) available on line and, I understand, a scanned version of the current edition as well. If you are economically challenged you have my blessing to go that way even though producing a paper copy must cost about as much as buying the official, nicely-bound book.

But I digress. I am starting to wonder what has been happening in the embedded microcontroller field lately. Have very high levels of integration made efficiency obsolete? Are high-end processors driving out the ‘ancient’ 4-bit processors? Has assembly language and C been replaced by very high-level languages in the field? Has surface-mount made most discrete electronics obsolete? These are the questions that plague me… on those rare occasions when my attention comes here.

So, what I am hoping is that some of you…from the at-least 10 visits a day, there must be someone listening… will come forward to offer guest posts on what has happened and where you think the embedded control field is going. I will be happy to edit whatever you provide if writing is not your strong suite, and surely give you full credit. If you are interested, contact my via email at

HTML like C (sort of)

I have been forced into editing the HTML file  that becomes my first E-book…WORD’s conversion leaves issues that Kindle’s tools don’t fix. Dragged in, kicking and screaming…figuratively…I was shocked to realize that there is a strong parallel in what makes readable C and readable HTML…and WORD doesn’t do it! The file produced may be technically correct but the equivalent of C’s curley braces { and }…perhaps <p> and </p> or <span> and </span> were scattered anywhere in the file…no starting a new line for readability or any such nonsense!

The only plus is that the converter to MOBI format seems very robust and forges ahead even when there are missing tag closures. I suppose I could just leave it when it looks good enough on the previewer,but I have the fear that some time later on some yet-to-be-developed reader, those warnings will come around and bite me! 

Good programming practice never goes out of style.

Shifting to Disqus for comments

I am trying the Disqus plug-in for comments in hopes that it will encourage more comments and block the multitude of spam that I have to delete every day. If it asks you for a login or some special procedure, my experience is that only once will do it for all sites that use it, but if you have trouble, please email me at


Web site traffic!

I have no idea who is out there visiting this site, but I find 15-20 visits a day…double or triple the visits to the other three sites I maintain. What really confuses me is the fact that no one adds comments here and I haven’t put up new posts for weeks, yet the visits continue. Granted the site has been in existence for over a decade, but other than being directed to buy the book or the target microcontroller board, there seems to be no basis for such regular traffic!

If you are visiting I would welcome any hints as to why you arrived here…unless you are spamming with ads for purses or Viagra!

Microcontroller communication today?

As personal computer technology continues to evolve, I have wondered if my book is becoming hopelessly obsolete in the area of communications. As levels of circuit integration increase, I have this vague dread that my emphases on efficiency have been trampled down by the march of technology. Even a decade ago Silicon Labs was showing what could be done when the lowly 8051 microcontroller became simply the ‘core’ of an IC with hosts of additional features…analog input and output, huge number of I/O pins, timers almost without number, and a USB interface to keep port pins free…and the cost declined to the point where using older versions of the 8051 with additional wired-in devices became of questionable economic value.

So I am asking for input on the communication section of C and the 8051. I devote several chapters to RS-232 as well as other low-performance protocols. These are extremely efficient, using only a couple of port pins and low enough speed to have no wire routing issues, but you can barely find anything on a PC that is that primitive. Is there still any use for simple microcontroller-to-microcontroller communication, or should all attention shift to USB? As I say in the chapter on USB, it is complex beyond imagination. Admittedly the newer versions of USB demand backwards compatibility with the very slow modes, but the entire process of exchanging a message seems quite cumbersome. Are the newest devices coming with completely pre-programmed USB controllers so the microcontroller designer only leaves off a message for the separate sub-system to handle?

In short, is anyone willing to make comments on the present state of microcontroller communication?

Adding to the scheduler

Scheduler:Traffic Light With Walk

Since the scheduler example for a traffic light of a week or two ago had nothing to do in the background, this next example uses the idle time to watch for a button push. The program is Figure 13.5, flowcharted in Figure 13.4. I add two buttons to be used by pedestrians to request a walk cycle. The scheduling of the light cycle will still happen in the real-time interrupt as before. I set up two flags (bits in walk) to keep track of anyone pushing the button (which comes in as a logic 0). By ORing the port with the variable, if the button was pushed previously, the logical OR will simply keep a 1 in that bit position. No matter how many people push the button, there will be just one walk cycle, and the bit can be cleared when the walk is actually provided. It is cleared by & ~0x02, which is a more understandable way of getting the 0xfd to clear that bit from a 1 to a 0. When a walk bit is detected, the switch expression substitutes a different pointer to give a walk instead of a normal light cycle. [This is very crude, and you would want a DON’T WALK light and perhaps a flashing period before the walk cycle ends. Also you would want to coordinate with turning cars, and so on. A true traffic light program is significantly more complicated than this.]

There are at least three options for keeping track of users pushing the walk buttons:

  1. Polling in the main routine is the easiest way to recognize walk requests. This is the solution I have chosen to show here.
  2. The buttons could be scanned in the scheduler interrupt itself—add another counter and once every 40th interrupt, perhaps, read the buttons. If there were much else for the processor to do, this would be the preferred solution because long background tasks (in main()) would not alter the button scanning.
  3. The buttons could be tied to external interrupts. There are at least two of them, and they could be made edge-triggered so the software would interrupt whenever a button is pushed. This is a bit wasteful of hardware and has limited expansion capability—there aren’t many external interrupts. Besides, it is a waste of hardware when it can be done easily by the earlier methods.

Flowchart: Traffic Light With Walk

Traffic Light With Walk Buttons
#define uchar unsigned char
#define uint unsigned int
#define LEDS P1
#define WLKBTNS P3
uint countdown; uchar index,walk;
code struct{uint delay;uchar pattern;}cycle[]=
//(0)=—R,–Y-; (1)=-G–,—R; (2)=–Y-,—R;
{5000,0×14}, {3000,0xc1},{5000,0x1c}};
//(3)=—R,-G–; (4)=WG–,—R; (5)=—R,WG–;

void initialize(void){
WDTCN = 0x07; WDTCN = 0xDE;//Disable WDT WDTCN = 0xAD;
XBR2 = 0x40;//enable crossbar
P1MDOUT = 0xFF;//P3 push-pull out
OSCICN = 0x04;//enable int oscillator
countdown=1;//start at once
walk=0;//none pending
index=3;//lead to first state
TMOD=0x10;//tmr1 16-bit
TR1=1;//enable timer 1
IE=0x88;//enable timer1 int

void msecint (void) interrupt 3 using 1{
uchar i;
if(–countdown==0){ //end of delay
switch(index){//override for walk
case 1:if((walk&0x02)==0){
walk&=~0x02; i=4;
case 3:if((walk&0x01)==0){
walk&=~0x01; i=5;

void main(void){
walk=walk | WLKBTNS;

Communication by Shared Variable With the first solution I must get the value of walk to the scheduler from the main (background) program; in a formal sense you can say the two tasks communicate. In effect communication is by shared variablewalk is global and can be accessed by both the interrupt and the main program. Later chapters will go into other communication methods.

For the pattern going to the LEDs I arbitrarily chose to position the walk lights as the most significant bits of the nibbles.

Although the interrupt in this stoplight example has grown more complicated, the basic approach has not changed. The program flow never waits in the interrupt function. Rather, it moves through and returns to the main as quickly as possible.

Multitasking via scheduler

A scheduler may seem too simple and too efficient to qualify as a multitasking operating system. You write all the code, there are no operating system commands to learn, and you can achieve full real-time performance. In one sense a scheduler just makes good use of a real-time clock. Yet the concept is so powerful it rates its own chapter [this post is from chapter13].

What is a scheduler?

Chapter 11 Hardware: Interrupts & Timers went into detail on the production of a regular interrupt—a real-time clock running tasks at specific times is a scheduler. It is an arrangement of software that calls task functions after a specific number of system ticks. Suppose you have a system tick every millisecond. You might have a keyscan task running every 40th tick and a stepper motor pulse task being called every 10th tick (100 steps/S). If the step rate changed, the scheduler might call the step function every 20 ticks (for a 50steps/S rate). All the activities key off counters initialized for a desired delay and then decremented every tick interval. When the counter for a specific task reaches zero, the count is reset, and the given task function is called.

Since scheduler tasks have to fit in between system ticks, you should write the code of any task to execute as quickly as possible and return. Never write while() or for(;;) loops in a task if exiting the loop depends on an outside event. Likewise, if there is a lot of processing to do, set a flag in the scheduler interrupt. Have the main function poll and detect that flag and then handle the processing in the background. Continue reading

Want to buy 3rd edition?

I find I have a box of the 3rd edition (the purple one) still kicking around. It is the version you can download for free courtesy of the publisher who illegally gave permission to Google books…but then they didn’t pay royalties either, so why should I be suprised. If you have an interest email me at Shipping costs plus $5 would satisfy me.