8051 microcontrollers

PROJECT 10.3—Voltmeter with RS232 Serial Output In this RTOS project, which is more complex than the preceding ones, the voltage is read using an A/D converter and then sent over the serial port to a PC. The project consists of three tasks: Live, Get_voltage, and To_RS232. • Task Live runs every 200ms and flashes an LED connected to port RD7 of the microcontroller to indicate that the system is working. • Task Get_voltage reads channel 0 of the A/D converter where the voltage to be measured is connected. The read value is formatted and then stored in a variable. This task runs every two seconds. • Task To_RS232 reads the formatted voltage and sends it over the RS232 line to a PC every second. Figure 10.12 shows the block diagram of the project. The circuit diagram is given in Figure 10.13. A PIC18F8520-type microcontroller with a 10MHz crystal is used in this project (though any PIC18F-series microcontroller can be used). The voltage to be measured is connected to analog port...

PROJECT 10.2—Random Number Generator In this slightly more complex RTOS project, a random number between 0 and 255 is generated. Eight LEDs are connected to PORTB of a PIC18F452 microcontroller. In addition, a push-button switch is connected to bit 0 of PORTD (RD0), and an LED is connected to bit 7 of PORTD (RD7). Three tasks are used in this project: Live, Generator, and Display. • Task Live runs every 200ms and flashes the LED on port pin RD7 to indicate that the system is working. • Task Generator increments a variable from 0 to 255 continuously and checks the status of the push-button switch. When the push-button switch is pressed, the value of the current count is sent to task Display using a messaging queue. • Task Display reads the number from the message queue and sends the received byte to the LEDs connected to PORTB. Thus, the LEDs display a random pattern every time the push button is pressed. Figure 10.9 shows the project’s block diagram. The circuit diagram is ...

CCS PIC C Compiler RTOS The CCS PIC C compiler is one of the popular C compilers for the PIC16 and PIC18 series of microcontrollers. In addition to their PIC compilers, Customer Computer Services offers PIC in-circuit emulators, simulators, microcontroller programmers, and various development kits. The syntax of the CCS C language is slightly different from that of the mikroC language, but readers who are familiar with mikroC should find CCS C easy to use. CCS C supports a rudimentary multi-tasking cooperative RTOS for the PIC18 series of microcontrollers that uses their PCW and PCWH compilers. This RTOS allows a PIC microcontroller to run tasks without using interrupts. When a task is scheduled to run, control of the processor is given to that task. When the task is complete or does not need the processor any more, control returns to a dispatch function, which gives control of the processor to the next scheduled task. Because the RTOS does not use interrupts and is not preemptive,...

PROJECT 10.1—LEDs In the following simple RTOS-based project, four LEDs are connected to the lower half of PORTB of a PIC18F452-type microcontroller. The software consists of four tasks, where each task flashes an LED at a different rate: • Task 1, called task_B0, flashes the LED connected to port RB0 at a rate of 250ms. • Task 2, called task_B1, flashes the LED connected to port RB1 at a rate of 500ms. • Task 3, called task_B2, flashes the LED connected to port RB2 once a second. • Task 4, called task_B3, flashes the LED connected to port RB3 once every two seconds. Figure 10.7 shows the circuit diagram of the project. A 4MHz crystal is used as the clock. PORTB pins RB0–RB3 are connected to the LEDs through current limiting resistors. The software is based on the CCS C compiler, and the program listing (RTOS1.C) is given in Figure 10.8. The main program is at the end of the program, and inside the main program PORTB pins are declared as outputs and RTOS is started by c...

The Real-Time Operating System (RTOS) Real-time operating systems are built around a multi-tasking kernel which controls the allocation of time slices to tasks. A time slice is the period of time a given task has for execution before it is stopped and replaced by another task. This process, also known as context switching, repeats continuously. When context switching occurs, the executing task is stopped, the processor registers are saved in memory, the processor registers of the next available task are loaded into the CPU, and the new task begins execution. An RTOS also provides task-to-task message passing, synchronization of tasks, and allocation of shared resources to tasks. The basic parts of an RTOS are: • Scheduler • RTOS services • Synchronization and messaging tools The Scheduler A scheduler is at the heart of every RTOS, as it provides the algorithms to select the tasks for execution. Three of the more common scheduling algorithms are: • Cooperative...

State Machines State machines are simple constructs used to perform several activities, usually in a sequence. Many real-life systems fall into this category. For example, the operation of a washing machine or a dishwasher is easily described with a state machine construct. Perhaps the simplest method of implementing a state machine construct in C is to use a switch-case statement. For example, our temperature monitoring system has three tasks, named Task 1, Task 2, and Task 3 as shown in Figure 10.1. The state machine implementation of the three tasks using switch-case statements is shown in Figure 10.2. The starting state is 1, and each task increments the state number by one to select the next state to be executed. The last state selects state 1, and there is a delay at the end of the switch-case statement. The state machine construct is executed continuously inside an endless for loop. State machines, although easy to implement, are primitive and have limited applicatio...

CAN Bus Programming To operate the PIC18F258 microcontroller on the CAN bus, perform the following steps: • Configure the CAN bus I/O port directions (RB2 and RB3) • Initialize the CAN module (CANInitialize) • Set the CAN module to CONFIG mode (CANSetOperationMode) • Set the mask registers (CANSetMask) • Set the filter registers (CANSetFilter) • Set the CAN module to normal mode (CANSetOperationMode) • Write/read data (CANWrite/CANRead) PROJECT 9.1—Temperature Sensor CAN Bus Project The following is a simple two-node CAN bus–based project. The block diagram of the project is shown in Figure 9.15. The system is made up of two CAN nodes. One node (called DISPLAY node) requests the temperature every second and displays it on an LCD. This process is repeated continuously. The other node (called COLLECTOR node) reads the temperature from an external semiconductor temperature sensor. The project’s circuit diagram is given in Figure 9.16. Two CAN nodes are connected to...

Nearly all microcontroller-based systems perform more than one activity. For example, a temperature monitoring system is made up of three tasks that normally repeat after a short delay, namely: • Task 1 Reads the temperature • Task 2 Formats the temperature • Task 3 Displays the temperature More complex systems may have many complex tasks. In a multi-tasking system, numerous tasks require CPU time, and since there is only one CPU, some form of organization and coordination is needed so each task has the CPU time it needs. In practice, each task takes a very brief amount of time, so it seems as if all the tasks are executing in parallel and simultaneously. Almost all microcontroller-based systems work in real time. A real-time system is a time responsive system that can respond to its environment in the shortest possible time. Real time does not necessarily mean the microcontroller should operate at high speed. What is important in a real-time system is a fast response...

mikroC CAN Functions The mikroC language provides two libraries for CAN bus applications: the library for PIC microcontrollers with built-in CAN modules and the library based on using a SPI bus for PIC microcontrollers having no built-in CAN modules. In this section we will discuss only the library functions available for PIC microcontrollers with built-in CAN modules. Similar functions are available for the PIC microcontrollers with no built-in CAN modules. The mikroC CAN functions are supported only by PIC18XXX8 microcontrollers with MCP2551 or similar CAN transceivers. Both standard (11 identifier bits) and extended format (29 identifier bits) messages are supported. The following mikroC functions are provided: • CANSetOperationMode • CANGetOperationMode • CANInitialize • CANSetBaudRAte • CANSetMask • CANSetFilter • CANRead • CANWrite CANSetOperationMode The CANSetOperationMode function sets the CAN operation mode. The function prototype...

PIC Microcontroller CAN Interface In general, any type of PIC microcontroller can be used in CAN bus–based projects, but some PIC microcontrollers (e.g., PIC18F258) have built-in CAN modules, which can simplify the design of CAN bus–based systems. Microcontrollers with no built-in CAN modules can also be used in CAN bus applications, but additional hardware and software are required, making the design costly and also more complex. Figure 9.11 shows the block diagram of a PIC microcontroller–based CAN bus application, using a PIC16 or PIC12-type microcontroller (e.g., PIC16F84) with no built-in CAN module. The microcontroller is connected to the CAN bus using an external MCP2515 CAN controller chip and an MCP2551 CAN bus transceiver chip. This configuration is suitable for a quick upgrade to an existing design using any PIC microcontroller. For new CAN bus–based designs it is easier to use a PIC microcontroller with a built-in CAN module. As shown in Figure 9.12, such devices ...

Nominal Bit Timing The CAN bus nominal bit rate is defined as the number of bits transmitted every second without resynchronization. The inverse of the nominal bit rate is the nominal bit time. All devices on the CAN bus must use the same bit rate, even though each device can have its own different clock frequency. One message bit consists of four nonoverlapping time segments: • Synchronization segment (Sync_Seg) • Propagation time segment (Prop_Seg) • Phase buffer segment 1 (Phase_Seg1) • Phase buffer segment 2 (Phase_Seg2) The Sync_Seg segment is used to synchronize various nodes on the bus, and an edge is expected to lie within this segment. The Prop_Seg segment compensates for physical delay times within the network. The Phase_Seg1 and Phase_Seg2 segments compensate for edge phase errors. These segments can be lengthened or shortened by synchronization. The sample point is the point in time where the actual bit value is located and occurs at the end of Phase...

Types of Errors The CAN bus identifies five types of errors: • Bit error • CRC error • Form error • ACK error • Stuffing error Bit errors are detected when the output level and the data level on the bus do not match. Both transmit and receive units can detect bit errors. CRC errors are detected only by receiving units. CRC errors are detected if the calculated CRC from the received message and the received CRC do not match. Form errors are detected by the transmitting or receiving units when an illegal frame format is detected. ACK errors are detected only by the transmitting units if the ACK field is found recessive. Stuffing errors are detected when the same level of data is detected for 6 consecutive bits in any field that should have been bit-stuffed. This error can be detected by both the transmitting and receiving units.

Overload Frame The overload frame is used by the receiving unit to indicate that it is not yet ready to receive frames. This frame consists of an overload flag and an overload delimiter. The overload flag consists of 6 dominant bits and has the same structure as the active error flag of the error frame. The overload delimiter consists of 8 recessive bits and has the same structure as the error delimiter of the error frame. Bit Stuffing The CAN bus makes use of bit stuffing, a technique to periodically synchronize transmit-receive operations to prevent timing errors between receive nodes. After 5 consecutive bits with the same level, one bit of inverted data is added to the sequence. If, during sending of a data frame or remote frame, the same level occurs in 5 consecutive bits anywhere from the start of frame to the CRC sequence, an inverted bit is inserted in the next (i.e., the sixth) bit. If, during receiving of a data frame or remote frame, the same level occurs in 5 consecut...

Remote Frame The remote frame is used by the receiving unit to request transmission of a message from the transmitting unit. It consists of six fields (see Figure 9.10): start of frame, arbitration field, control field, CRC field, ACK field, and end of frame field. A remote frame is the same as a data frame except that it lacks a data field. Error frames are generated and transmitted by the CAN hardware and are used to indicate when an error has occurred during transmission. An error frame consists of an error flag and an error delimiter. There are two types of error flags: active, which consists of 6 dominant bits, and passive, which consists of 6 recessive bits. The error delimiter consists of 8 recessive bits.

Data Frame The data frame is in two formats: standard (having an 11-bit ID) and extended (having a 29-bit ID). The data frame is used by the transmitting device to send data to the receiving device, and the data frame is the most important frame handled by the user. Figure 9.7 shows the data frame’s structure. A standard data frame starts with the start of frame (SOF) bit, which is followed by an 11-bit identifier and the remote transmission request (RTR) bit. The identifier and the RTR form the 12-bit arbitration field. The control field is 6 bits wide and indicates how many bytes of data are in the data field. The data field can be 0 to 8 bytes. The data field is followed by the CRC field, which checks whether or not the received bit sequence is corrupted. The ACK field is 2 bits and is used by the transmitter to receive acknowledgment of a valid frame from any receiver. The end of the message is indicated by a 7-bit end of frame (EOF) field. In an extended data frame, ...

The Controller Area Network (CAN) is a serial bus communications protocol developed by Bosch (an electrical equipment manufacturer in Germany) in the early 1980s. Thereafter, CAN was standardized as ISO-11898 and ISO-11519, establishing itself as the standard protocol for in-vehicle networking in the auto industry. In the early days of the automotive industry, localized stand-alone controllers had been used to manage various actuators and electromechanical subsystems. By networking the electronics in vehicles with CAN, however, they could be controlled from a central point, the engine control unit (ECU), thus increasing functionality, adding modularity, and making diagnostic processes more efficient. Early CAN development was mainly supported by the vehicle industry, as it was used in passenger cars, boats, trucks, and other types of vehicles. Today the CAN protocol is used in many other fields in applications that call for networked embedded control, including industrial automation,...