Category Archives: Coding Guides

8051 8-bit CPU Coding Tricks & Tips

The death of the 8-bit CPU has been prognosticated for over a decade but these old tiny workhorses keep going and going and going. Z-Wave is currently based on the venerable Intel 8051 CPU but we’re about to get an upgrade to a 32-bit ARM CPU via the 700 series which is due out later this year. In this posting I’ll give a few tips on coding in C for the 8051 to typically improve speed of execution.

I’ve been writing code for 8-bit CPUs since the 1980s and I designed a few in the 1990s. I also designed a couple of 32-bit RISC CPUs in the 1990s and early 2000s. I often had to squeeze the code just a little harder to get an operation to happen just fast enough to meet a system requirement. This meant that I either had to code in assembly or often just coding C in a slightly different way would convince the compiler to generate the most optimal assembly code for me.

8-bit CPU Architecture

I could go thru a long discussion of the block diagram of the 8051 CPU but instead I’ll just cut to the  chase – the 8051 is not at all “C friendly”. The 8051 was architected back in the bad ol’ days of assembly programming – especially for embedded systems where resources were in very short supply (think 1K ROM and 64 bytes of RAM). Thus the architecture has all sorts of funny things that a C compiler can’t take advantage of efficiently. The PSR flags, the D pointer, the single accumulator, memory mapped registers and the SFR registers are all parts of the 8051 that make it special but unfortunately are just not efficient in C. The folks at Keil have worked really hard to make their compiler as efficient as possible and to make access to these non-C hardware resources available without too much effort. But at the end of the day, a C compiler really wants a nice simple block of 32-bit registers to perform integer arithmetic on and a simple flat memory – in other words, a RISC CPU.

In the Z-Wave world, the 8051 in the 500 series chips is a 32 MHz 8051 with 128K bytes of FLASH and 16K bytes of RAM. “But wait” you say, “the 8051 is an 8-bit CPU with a 16-bit Program Counter, how can it address 128K bytes?”. The answer is Bank Switching which is just plain crazy but I won’t get onto that soapbox in this posting. The Z-Wave code from Silicon Labs is delivered as pre-compiled C libraries that the application developer links into their code. The application code is written in C and the Keil compiler does a fine job of squeezing a reasonable amount of code into the tiny 8051. Fortunately in IoT, the task to be performed is usually pretty simple – turn a light on or off by activating a relay connected to a GPIO so we don’t need a multi-Gigahertz CPU with gobs of RAM.

The Silicon Labs SDK comes with a number of sample applications and a bunch of “helper” routines all written in C. Thus, a Z-Wave application can generally be written completely in C, compiled using the Keil compiler and it’ll generally squeeze into the limited code space as long as you don’t try to do too much on this little CPU. But it seems there are always some little things that I just need to do a little faster. The following tips are just a few of the simple tricks I’ve learned from decades of embedded coding.

The Fastest 8051 Loop

What is the fastest 8051 loop you can execute in C?

The most common loop is a simple FOR loop:

for (iter=0;iter<16;iter++) {
...
}

Which is easy to read and does the job just fine – if we don’t need to do it very fast. Often the innermost loop is executed a lot and squeezing just a few instructions out of the code will significantly improve the performance of the routine.

The for loop above compiles into the following assembly code:

B02:0xA04D E4 CLR A
B02:0xA04E FF MOV R7,A
B02:0xA04F 0F INC R7                    ; TOP OF LOOP
B02:0xA050 EF MOV A,R7
B02:0xA051 B410FB CJNE A,#demodState(0x10),B02:A04F

Which as you can see is quite a few instructions and even longer when you consider that each instruction is at least 4 CPU clocks. The Compare and Jump if Not Equal (CJNE) is a 3 byte instruction which requires many clock cycles to execute. If we can squeeze a few instructions out of the loop then it will run much faster. Obviously we could code in assembly but this exercise is to show that HOW you code in C can make a big difference in the performance. An alternative coding of the for loop above is:

iter=16;
do {
...
} while (--iter);

With this slight change in the coding style the while loop turns into a single byte DJNZ opcode as shown below so this is the fastest and most efficient looping structure when targeting the 8051.

B02:0xA055 7F10 MOV R7,#demodState(0x10)
B02:0xA057 DFFE DJNZ R7,B02:A057         ; single instruction loop

The real trick to improving the performance of your code is to see what assembly instructions the code compiles into.

How to See What Your C Code Turns Into

You can’t improve the performance of your code unless you can measure what the performance is and where all the time is being spent. A classic method of measuring the performance is to set a GPIO pin high or low during specific routines. Then use an oscilloscope to observe how long the routine takes. Other options involve printing out markers out a UART or using a hardware timer to measure the duration of a routine.

KeilDebug1A simple method to observe the instructions our C code generates for our little 8051 CPU is to use the simulator built into the Keil C compiler. By default the Keil IDE does not have a simulator when using the Silicon Labs sample projects so you have to assign one. Right click on the project then select “options” then click on the “Debug” tab. Then enter “s8051” into the CPU DLL box as shown here. You can now click on Debug->Start/Stop Debug Session or press <CTL>F5. This will enter the Keil Simulator for the 8051. One thing to understand is that this simulator does NOT understand the bank switching of the Silicon Labs version of the 8051 used in the 500 series. Unfortunately you can’t debug code much using this simulator as any bank switching doesn’t work. But it will work well enough to debug small snippets of code and of course to see what you code turns into.

KeilDebug2Once the debugger opens in the IDE, click on the line of code you are interested in and the Disassembly window (use View->Disassembly if its not visible) will take you right to the line of code you are interested in as shown here. Note that the C source code is mixed in as comments in the assembly code. This helps guide you to match the C code to the assembly code which can be a little convoluted depending on the optimization the compiler has applied. You can see here that the Do-While has turned into our desired DJNZ single instruction loop.

Don’t rely strictly on the instruction count to guide your C coding style. One slow-down I often see in the Silicon Labs code is they call a subroutine, that calls a subroutine, that calls (several more) subroutines which finally just returns a value. While this may be structured C coding it is very slow in an 8051. Each subroutine call pushes and pops a number of registers and parameters on the stack and each of those takes several clock cycles to perform. Ideally a C macro is used to specify a value or a register which becomes just a single instruction fetch of the value from a register or memory instead of all this pushing and popping.

Unrolling Loops

Another easy speedup in C is to unroll short loops. A classic situation for unrolling loops is when emulating a serial protocol like I2C with a GPIO. Since the loop is typically only 8 passes you can often significantly improve performance by unrolling the loop – often taking the I2C bit rate from under 10Kbps to nearly 100Kbps.

for (bitnum=0x80; bitnum!=0;bitnum>>1) {
    I2C_SEND_BIT(data & bitnum);  // macro to set SDA then toggle SCL
}

When unrolled turns into:

    I2C_SEND_BIT(data & 0x80);
    I2C_SEND_BIT(data & 0x40);
    I2C_SEND_BIT(data & 0x20);
    I2C_SEND_BIT(data & 0x10);
    I2C_SEND_BIT(data & 0x08);
    I2C_SEND_BIT(data & 0x04);
    I2C_SEND_BIT(data & 0x02);
    I2C_SEND_BIT(data & 0x01);

Which works well for short fixed length loops but obviously won’t work in every case. The slow down with the FOR loop involves reloading the accumulator and the D pointer with various constants and the iteration value. The inline version doesn’t have any of these nor are there any delays from looping. This technique also works well on 32-bit RISC processors.

Conclusion

There are a lot more tricks when coding for small 8-bit CPUs. But I’m hoping I won’t have to bother with them for much longer and the dominance of the 32-bit CPU will finally crush the 8-bit out of existence. The price of silicon continues to drop and 32-bit CPUs are often as cheap or even cheaper than these ancient 8-bit boat anchors. The modern CPUs also come with advanced debuggers unlike the 8051 which has… wait for it… printf or worse yet simply toggling an IO. Ugh.

 

 

Z-Wave Summit 2017 at Jasco in Oklahoma City

“IoT Device Testing Best Practices” by Eric Ryherd

Summit1Click HERE to see the entire presentation including my notes. If you are a Z-Wave Alliance member a video of the presentation is usually posted on the members only section of their web site. The main takeaways from my presentation are:

  • Have a written test plan
  • Use the Compliance Test Tool (CTT) as the START of your test plan
  • Vary the environmental conditions during testing
  • Test using real world applications
  • Test using complex Z-Wave networks with routing and marginal RF links
  • Test with other hubs and devices
  • Automate testing using tools like the ZWP500
  • Code firmware with failure in mind
  • Utilize the WatchDog timer built into the Z-Wave chip

ZWaveSummit2017aThe presentation goes into detail on each of these topics so I won’t duplicate the information here. I also go thru several failures of devices I’ve been working with. You learn more from failures than you do when everything just works. Feel free to comment and let me know what topic you’d like to see for next years summit.

Z-Wave Summit Notes

One of the main purposes of the summit is to learn what’s new in Z-Wave and what Sigma is planning for the future. The most important news at this year’s summit is SmartStart. The goal for SmartStart is to simplify the user experience of installing a new device on a Z-Wave network. The concept is that a customer will open the package for a device, plug it in, the hub is already waiting for the device to be joined and the device just shows up on their phone without having to press a button or enter the 5 digit pin code. This is a “game changer” as Sigma pointed out many times during the summit. Typically a user has to put their hub into inclusion mode, read the product manual to determine the proper button press sequence to put the device into inclusion mode, wait for the inclusion to go thru, write down the NodeID number, with an S2 device they have to read the teeny-tiny 5 digit PIN code printed on the product (or scan the QR code) and then MAYBE the device is properly included. Or more often, they have to exclude and retry the process all over again a couple of times. SmartStart as you can see will make the user experience much easier to get started with Z-Wave.

SmartStart enables “pre-kitting” where a customer buys a hub and several devices as a kit. The hub and the devices in the kit are all scanned at the distribution warehouse and are all white listed on the hub web site. When the customer plugs all the devices in, they automatically join and all just magically show up ready to be used without the frustration of trying to get all the devices connected together. Unfortunately there are no devices that support SmartStart and there are no hubs that support it either – yet. We’ll get over that eventually but I suspect it’ll take a year before any significant numbers of SmartStart supported devices show up on Amazon.

SmartStart is enabled in the SDK release 6.81 which occurred during the summit. There are some other handy features in this release. The main new feature (after SmartStart) is the ability to send a multi-cast FLiR beam. One problem with FLiR devices is that they are all sleeping devices and briefly wake up once per second to see if someone wants to talk to them. Prior to 6.81 you had to wake up the devices one at a time and each one would take more than one second to wake up. If you have battery powered window shades like I do, there is a noticeable delay as the shades start moving one at a time instead of all together. Both the shades and the remote (or hub) will need to be upgraded to 6.81 before we can use this new feature. That means it’ll be again probably another year before this feature is widely available, but it’ll get there eventually.

There are rumors that Sigma will be announcing a new generation of the Z-Wave transceiver chip in early 2018. I am hoping it will will finally include the upgrade from an 8-bit 8051 CPU to a more capable 32-bit ARM CPU.  The current 500 series relies on the ancient 8051 with very limited debugging capabilities which significantly slows firmware development. With an ARM CPU developers like Express Controls will find it easier to hire engineers who can code and debug firmware and thus we’ll be able to bring more Z-Wave products to market in less time.

A new web site, Z-WavePublic.com, has been populated with the Z-Wave documentation as well as images for the Beagle Bone Black and Raspberry Pi loaded with Sigmas Z/IP and Z-Ware. With one of these boards and a USB Z-Stick anyone can start developing with Z-Wave without having to sign a license agreement. Nice way to get started with Z-Wave for you DIY nerds out there. There were many other presentations on Security S2, Certification, The CIT, Z/IP, HomeKit and many other topics on the technical track of the summit. The marketing track had a different set of presentations so I recommend sending both a technical person and a marketing person to the summit.

Summit isn’t all work, work, work

IMG_20170927_090355The Summit isn’t all work all day though the days are long and tiring. Tuesday evening was a reception at Coles Garden which is a beautiful event venue. Unfortunately it was raining so we couldn’t wander thru the gardens much but Mitch, the Alliance Chairman, kept us entertained.

Wednesday evening was the Members Night at the Cowboy museum. Oil profits made a lot of wealthy Oklahomans who were able to make sizable donations to this huge museum. There is a lot more to see than we had time to explore so I’d recommend spending more time here if anyone is visiting Oklahoma City. Lots of food and drink made for an ideal networking environment with your fellow Z-Wave developers.

 

10 Questions when Reviewing Embedded Code

Design News posted a great article “10 Questions to Consider When Reviewing Code” and I’m just posting the list here. Follow the link for the full article with the details behind each question.

  1. Does the Program build without warnings?
  2. Are there any blocking functions?
  3. Are there any potential infinite loops?
  4. Should this function parameter be a const?
  5. Is the code’s cyclomatic complexity less than 10?
  6. Has extern been limited with a liberal use of static?
  7. Do all if…else if… conditionals end with an else? And all switch statements have a default?
  8. Are assertions and/or input/output checks present?
  9. Are header guards present?
  10. Is floating point mathematics being used?

My personal pet peeve is #3 – I am constantly reviewing that uses WHILE loops waiting for a hardware bit to change state. But what if the hardware bit is broken? Then the device is DEAD. Always have some sort of timeout and use a FOR loop instead of a WHILE loop. At least the code will move on and won’t be dead. Maybe it won’t work properly because of the broken hardware but at least the device can limp along.