5.5. PIC16 C System Design

• Hardware selection

• Software design

• System Integration

We have seen how to get started with building PIC microcontroller systems programmed in C. Simple examples have been used to illustrate the basic principles, so we now need to look at some issues relating to more complex microcontroller-based systems. Numerous texts are available, written by experienced and knowledgeable engineers, that discuss the finer points of real-time system design, so the intention here is to introduce the some basic concepts to help the reader to move toward a further understanding of real industrial applications. Another objective of this section is to review some relevant factors in the selection of the best combination of hardware, programming language, and development tools for any given microcontroller product design.

Hardware Selection

There is a range of related devices around which embedded systems may be designed, including a

• Microcontroller (MCU)

• Microprocessor (CPU)

• System on a chip (SoC)

The conventional microprocessor system embodies the traditional approach, where a central processing unit, memory, and peripherals can be put together to meet the requirements of a particular application as precisely as possible. Designing a custom-made CPU system is a relatively expensive option, and such an extensive range of other options are available that the conventional CPU-based system may be needed for only highly complex, specialist systems or where a low-cost, standard board such as the PC motherboard can be easily adapted. The discrete microprocessor does, however, allow multiprocessor systems to be designed that typically use shared hardware resources, especially memory. Current standard processors typically incorporate features to support multiprocessor operation, and the dual core processor is currently becoming standard in PCs.

The SoC takes the concept of the microcontroller to the next level. It is, in effect, a configurable microcontroller, where the designer has control over the internal arrangement of the hardware elements. Using a dedicated design system, the processor core is selected and the required memory and peripherals added. These hardware elements are supported by corresponding standard drivers provided as part of the package. With a complex interface, such as USB, for example, the provision of a standard protocol stack (software layers, not a hardware stack) is essential. The design can be fully tested in software, in the same way that a PIC program can be tested in MPLAB. Only when finally verified is the design fabricated by the hardware supplier.

If a design is to be created from scratch, then the most appropriate type of system may be selected from the three main options listed previously. However, this choice is unlikely to occur in isolation; factors such as the previous experience of the design team, existing company products, and so on are significant. Nevertheless, the designer should keep an open mind as far as possible and needs to keep up with a rapidly developing technology in the embedded systems field to make the right choice—not easy.

Microcontrollers

A designer who has a store of expertise using a particular microcontroller type and development system will need a good reason to look elsewhere for a solution. Gaining similar expertise in another system takes time and resources, and any change must also take into account the future strategy of the company or design group.

The PIC family may be our first choice for the following reasons:

• Low cost

• Simplicity

• Good documentation

• An established market

• A development system provided

• Third party support

The PIC is well suited to the learning environment as it was originally pitched at the low-end (high-volume, low-complexity) market and is well supported by third party products. Therefore, the assumption implicit in this book is that the PIC is the best starting point, even if the learner is later to progress to other processor types. At the time of this writing the main alternatives are Atmel (AVR), Freescale (Motorola), STMicroelectronics, Hitachi, Philips, and National Semiconductor.

We can approach hardware selection on the basis of the choice offered within the PIC range, which was outlined in section 1.1. Some of the main features to consider are

• The number of I/O pins.

• The interface types.

• The program memory capacity.

• The RAM capacity.

• The operating speed.

• The power consumption.

We assume that adequate development system support and driver libraries are available. A logical approach to design is to select a chip that has spare capacity in relation to the draft specification. The application can be prototyped in simulation mode without penalty using an overspecified device. When the I/O, memory, and peripheral requirements finally are established, a chip can be selected for hardware implementation that meets the specification at minimum cost.

The anticipated scale of production is also a factor. The cost of each individual unit produced becomes more critical as the scale of production increases. On the other hand, the firmware can be reproduced at effectively no cost, unless variants are required. If we assume a fixed cost, a, for design development (hardware and software) and each board costs b to produce, the cost per unit is given by

where x is the number of units produced. The fixed costs are divided by the number of boards produced. So, if the development costs are, say, 1000 units of currency (a = 1000) and the production cost 100 per board (b = 100), a curve showing the cost per board as the volume of production is increased is obtained, as seen in Figure 5.8. We can see that the cost per board is initially high, falling away and leveling off as the production volume increases.

Hardware Design

Taking the hardware design criteria in turn, we can consider some of the relevant factors in getting started with a design, assuming an agreed-on initial specification. Having said this, it is useful to know how much flexibility is allowed in meeting the specification, because a disproportionate cost might be involved. It may be acceptable to reduce the performance to reduce costs, for example, reducing the precision of analog measurements or the frequency range of a signal output.

The cost of the microcontroller tends to increase with the number of I/O pins, so it is probably a good idea to look for ways to reduce the pin count. One example we saw in previous sections is to use a serial LCD instead of a parallel one. The serial type requires only 1 output, while the parallel LCD seen earlier needs 7, or possibly 11 if 8-bit data are used. Certainly the serial interface should be considered the default choice, and the parallel used only if high-speed access to the display is needed. The serial link can also be physically longer.

Serial access sensors are becoming more common, where the data are sent to the MCU in serial form, rather than as an analog signal. We saw that any pin can be used as an RS232 port, because CCS C provides a driver that generates the required interface purely in software. This means dedicated analog ports may not be necessary, giving greater flexibility in the choice of MCU. On the other hand, the sensor is likely to be more expensive.

Program memory capacity requirements are not easy to anticipate before the software has been finalized. C programs generally need more memory than assembler, so the choice of language is important. This factor is considered further later, but for now, suffice it to say that memory requirements expand rapidly with program complexity. As regards RAM requirements, the PIC is strictly limited, as the only onboard RAM consists of spare file registers. External data memory may well be necessary, as in our data logger. An alternative type of MCU could even be necessary for data-intensive applications.

The PIC scores well on operating speed, however. The 16 series devices can generally run at 20 MHz, with the 18 and 24 series running at 40 MHz. The clock speed does affect the power consumption, as the current consumed is proportional to the switching rate in CMOS devices. Low-power MCUs are an important ongoing development in microprocessor technology. Reduced operating voltages (e.g., 3.3-V supply) are also increasingly used to reduce power dissipation. Power consumption is not one of the operating parameters normally predicted by simulation, so a real hardware prototype may be needed to finally specify the power supply. Obviously, power consumption is even more critical in battery-powered systems.

Software Design

There are two main options for creating the system firmware for low-complexity embedded systems: assembly language or C. There are other user-friendly programming options aimed primarily at learners, such as software that allows C code to be generated from a flowchart (see Appendix D). A wider range of high-level languages and proprietary development systems are available to support more advanced processors.

In general, assembly language is used for simple programs and those where direct access to control registers or speed is critical. Certainly, using assembler requires an intimate knowledge of the MCU architecture and is an essential tool for the practicing embedded engineer. If necessary, assembly language blocks of code can be embedded within a C program.

However, the premise of this book is that there are good arguments for starting with C. Less detailed hardware knowledge is needed, and programming is simplified. It is also a universal language, whereas each MCU type has its own assembly language. Used in conjunction with a user-friendly simulator, such as Proteus, useful applications for any microcontroller type can be created with a minimum of experience. The availability of a comprehensive set of peripheral drivers is also very helpful, as provided by CCS C. However, the main advantage is that C is by far the most widely used high-level language for embedded systems and can be applied by all embedded engineers, from beginner to expert.

The overall structure of the embedded firmware is determined by the complexity and, to some extent, the hardware features of the host MCU. A simple program can use polled I/O in assembler program. If the chip has an interrupt structure that allows task priority and timing to be adequately managed, then interrupts can be used in assembler or C. The RTOS approach may well be the best solution for more advanced applications; this is the next stage in microcontroller system design, to which I hope the reader will be able to progress because of the system design concepts outlined in this book.

There is never a perfect solution to the embedded design challenge, but we can try for the best one that lies within our own limits of experience and enjoy the challenge it presents.