UPC EETAC Bachelor's Degree in Telecommunications Systems and in Network Engineering EEL

Lab 7

Laboratory

Laboratory 9: microcontrollers. basic digital I/O. Software organisation

[P9] IDE and mC tools: C language, break points, step by step mode, watch windows, etc.

Lab 10

[8/5]

Individual post lab assignment PLA9 to be discussed next Lab10. Study and execute in your computer this lab tutorial before attempting to solve the post lab assignment.

3.4. Digital I/O. Combinational circuits in C for learning how to organise simple programs

3.4.1. Specifications

3.4.1.1. Truth table, symbol, timing diagram

3.4.1.2. Symbol

3.4.1.3. Timing diagram

1. Specifications Planning Dev. & test Prototype report

Solve the combinational circuit Dual_MUX_4 depicted in Fig. 1 using a PIC18F46K22 microcontroller.

Our goal is to design again a dual 4-channel multiplexer like 74HCT153 that was already solved in P2-P3 using plan A, B and C2. Symbol and truth table is copied again in Fig. 1 as it was described in Chapter 1 project Dual_MUX_4.

Truth table

Fig. 1. Symbol and truth table.

This time the circuit will be based on a microcontroller (μC) PIC18F46K22. Input and output signals have been distributed in different ports of the microcontroller so that you can practise on how to read and write individual pins and software organisation.

Dual_MUX4

Symbol

Fig. 2. This is the chip 74HCT153 that is taken as a reference and the symbol of the Dual_MUX_4. The symbol includes the microcontroller's port pin assignment where the input and output signals are connected. This assignment is arbitrary, laboratory groups can be assigned different pin sets.

 

Specifications 2. Planning Dev. & test Prototype  report

3.4.2. Planning: hardware, software, oscillator, MCLR_L, switches, LED, etc.

Let us use the target mC chip: PIC18F46K22 in Fig. 3. Target chip can be any other microcontroller or Arduino (ATmega328P). Our aim is to practise with digital inputs and outputs. Thus, several pin options will be proposed for reading inputs and writing outputs.

PIC18F46K22 package DIL and pin functionality

Fig. 3.  Pin out diagram and pin functionality of the 40-pin PDIP PIC18F46K22 μC.

A) Planning hardware

3.4.2.1. Hardware schematic

Hardware circuits and port connections are represented in Fig. 4. Here the signals are connected to different ports in order to practise reading (polling) and writing digital pins using bitwise logic operations. Digital inputs are generated using switches or push-buttons. Connecting LED at the output is the simplest way to visualise the circuit's truth table.

Schematic in hardware

Fig. 4. Hardware schematic using switches and LED.

Hardware schematic must include as well the processor oscillator (an external quartz crystal connected between OSC1 and OSC2 pins)  and the system reset (MCLR_L).

 

B) Planning software

3.4.2.2. Software organisation: setup, main loop

3.4.2.2.1. Hardware-software diagram and software organisation

3.4.2.2.2. RAM variables

3.4.2.2.3. init_system(): I/O port pin configuration data direction register TRIS.

3.4.2.2.4. read_inputs()

3.4.2.2.5. truth_table(), behavioural description, algorithm

3.4.2.2.6. write_outputs()

Fig. 5 shows the general proposal in CSD for organising the software, this is our coding style to make designing circuits simple and repeatable, each function has a specific task to solve.

Software

Fig. 5. Software organisation to poll inputs from port pins, to organise the RAM variables, to calculate the truth table and to send the generated variables to output pins in an infinite loop.

Here in Fig. 6 we include a new tool: the hardware-software diagram that allows us to visualise how the functions are related and what information are processing.

hardware software diagram
Hardware_software diagram

Fig 6. The new conceptual representation tool: hardware-software diagram to visualise how the system is organised. 

In Fig. 7 there is the list of RAM variables used.

Variables RAM

Fig. 7.  Example of some convenient variables "var" that will allow the processing of information in truth_table() independently of the microcontroller hardware (this is the important concept of hardware abstraction or hardware abstraction layers HAL. 

Program variables will be stored in RAM memory addresses and so, they are volatile.

Accordingly to our programming style to assign a byte per variable, seven global RAM bytes are required.

NOTE: In our simple programs RAM variables will be global (accessible from anywhere in the code), but other variables for storing partial results while processing such var_buff may be declared local within the scope of a function, and thus reusable. 

 

Hardware interface functions. Firstly, init_system() to set pin directions as in Fig. 8. Read notes on how TRIS register bits configures a pin to be an input or an output using tri-state gates. All unused pins will be configured as outputs by default.

Init_system

Fig. 8. Init_system() to set pin directions using the data direction register TRIS (it means TriState).

 For most ports, the I/O pin's direction (input or output) is controlled by this data direction register TRIS.

 

Secondly, read_inputs() as represented in Fig. 9 on how to read a digital input rec. for reading/polling/capturing inputs voltage values.

And this is another rec. on how to start a new project from this tutorial following the step by step strategy (one line of code at a time).

Reading inputs

Fig. 9. Read/poll/capture/acquire inputs. The concept "sampled inputs" is better applied in contexts where there is a CLK signal as it was for synchronous systems in Chapter 2 or as it will be in next LAB10.

 

And thirdly write_outputs() in Fig. 10 on how to write a given pin into a port while preserving the information of the other pins of no interest. The idea is that even if the pins of no interest are not connected, they may be used in a future enhancement of the application.

Write outputs
Fig. 10. The concept of writing RAM variable values in a specific pin of a port using a single write-port operation and preserving at the same time the unused pins for future modifications.  

NOTE: To write we can use indistinctively both PORTx or LATx instructions for writing to port pins. You will find that most of our code examples use LATx to emphasise the differences between reading and writing.

 

Finally, it is time to interpret the truth table in Fig. 11 (or algorithm or processing function) in a behavioural way exactly as we did in Dual_MUX_4 plan B. The truth table flowchart is translated to C code instead of VHDL. The advantage of such code organisation based on hardware-independent functions is that it works for any microcontroller. Therefore, it also applies for Arduino programs (ino extension) or for Raspberry Pi applications written in python.

Truth table behavioural

Fig. 11. Example of behavioural interpretation of the truth table.

Thus, what you see here is the powerful concept of hardware abstraction: all software algorithms are hardware-independent, meaning that they rely completely in RAM variables being totally compatible through all microcomputer platforms. If the technology has to change only the hardware-dependent functions must be adapted, and this is what hardware drivers do in computer organisation. This concept is explained colouring functions in Fig. 12.

software

Fig. 12. Software organisation from the compatibility point of view.

 

Important remark: As you have seen, and also from your experience in Chapters 1 and 2, do not write C code without having sketched firstly hardware schematics and program flowcharts. Because as in VHDL, C code is yet again a simple translation of the information already studied and fully annotated in paper. Therefore, the C code of a given project, even if it is correct, has no value and is not assessed unless handed in accompanied by the corresponding work in paper.

Project location:

C:\CSD\P9\Dual_MUX_4\(files)

Target μC chip: PIC18F46K22. Simulation using Proteus. Prototyping board: CSD_PICstick.

 

Specifications Planning 3. Dev. & 4. test Prototype report

3.4.3. Development and testing

Install MPLABX + XC8 software development environment.

Learning how to develop and test interactively microcontroller projects

Key indications for saving study time and learning these materials correctly: Step-by-step tactical approach for developing and testing the project: Read one input at a time and run simulations to watch that the voltage value is correctly digitalised as a valid value in RAM memory. In the same fashion, write one output at a time and run to check that your code is correct to light a LED connected at the assigned output pin. Solve the truth table algorithm and run t watch RAM variables.

The three functions are totally independent and the order in which they are coded is not important. Or alternatively, the development and testing of the three functions can be assigned to three students working in the same cooperative group.

Reading inputs

Step #1): Hardware. Consider the circuit with oscillator, reset, and only the pin E_L connected to pin RC3.
This is the file Dual_MUX_4.pdsprj. Save it at the working directory.
                 Software. Comment or delete all the code that is not referred to CE_L. Translate the Fig 9 flowchart into C code. This is the file Dual_MUX_4.c (include as well config.h in your project). Save it at the working directory. Start a new project for a PIC18F4520 and compile. Run and add the watch window to monitor the RAM value var_E.
Run and watch

Fig.  13. First programmed code running.

Step #2): Hardware. Add a new input in the schematic, for instance Ch3(1..0) Dual_MUX_4.pdsprj.
                 Software. Translate to C the planned flowchart and add it to the previous program Dual_MUX_4.c.

Watch the evolution of Ch3

Fig.  14. Adding the Ch3(1..0) hardware and running again the re-compiled code watching variables.


Repeat new steps to complete all inputs.

Writing outputs

#1): Hardware. Add a pair of LED to visualise Y(1..0). This is the file Dual_MUX_4.pdsprj. Save it at the working directory.
                 Software. Comment or delete all the code that is not referred to var_Y. Translate the Fig 10 flowchart into C code. This is the file Dual_MUX_4.c. Save it at the working directory. Start a new project for a PIC18F4520 and compile. Run and add the watch window to monitor the RAM value var_Y when at the same time you check that the LED are lighting correctly.
Testing how to write

Fig.  15. Testing how RAM values are written to port pins.


Add similar writing steps in projects with more outputs.

Truth table

Hardware. Consider the circuit only with oscillator and reset. This is the file Dual_MUX_4.pdsprj. Save it at the working directory.
Software. Variables read (as outputs from read_inputs() function will be simulated by fixed values in successive compilations. Translate the Fig 11 flowchart into C code. This is the file Dual_MUX_4.c. Save it at the working directory. Start a new project for a PIC18F46K22 and compile. Run and add the watch window to monitor the RAM values related to the truth table execution. Try other variable values recompiling the code. 
Truth table

Fig.  16. Testing only the truth table code watching RAM variables.

Example video rec to show initial steps on how to start a new project in MPLABX for target PIC18F, compile and simulate

3.4.3.1. Proteus schematic capture: pdsprj file

A) Developing hardware

Full circuit captured in Proteus
PIC18F46K22_pin assignment

Fig. 13. The block to be designed and the microcontroller connections captured in Proteus-VSM. It is better to use switches (or push-buttons) and resistors to generate inputs instead of ideal LOGICSTATE values. These ideal simulation values impose voltages in port pins that are not correctly handled by port circuitry and TRIS register cannot program correctly pin directions.

3.4.3.2. MPLABX project for PIC18F46K22: C source file

3.4.3.3. Project compilation and chip configuration files: hex, cof

B) Developing software

Run the integrated development environment IDE MPLAB X (with the included XC8 C compiler) and start a new project.

project

Fig. 14. Project name and folder.  

Compile the C code, generate the HEX and the COF chip configuration files, and attach the latest to the microcontroller properties window for debugging purposes.

Compiler options

Fig. 15. This is the way to configure project properties so that the COF file to be used with Proteus is generated. 

Compilation results, RAM and ROM memory used.

IDE environment when compiling and debugging

Fig. 16. Compilation results, outputs files and memory used (11 bytes of RAM).

 

Properties

Fig. 17. This is the way to attach in Proteus the hex or the cof to the chip properties, which in the simulator is equivalent to downloading the configuration code to the real chip populating the prototyping board. 

 

3.4.3.4. Proteus simulation and testing. Step by step debugging, watch variables window

C) Step-by-step testing

Run Proteus and test the circuit using step by step, break points and the watch window tools, as shown in Fig. 18.

Simulation

Fig. 18.  Example of "run" simulation  that includes a watch windows for monitoring variables of interest.

 

3.4.3.5. Software execution time

D) execution speed measurements

In Fig. 19 there are some questions of interest related to this initial program and process of reading inputs. What are the advantages and drawbacks?

Remarks

Fig. 19. Final slide with some questions and remarks.

For example: how to measure the time that the microcontroller takes to execute the loop? As shown in Fig. 20, you can use a single breakpoint located anywhere in the loop and click run several times. The time elapsed since the last break is the loop execution time.

Loop execution time

Fig. 20. Measurement of the loop execution time using breakpoints.

In the same way, using two breakpoints you can measure how long does it take to execute some instructions. Fig. 21 show the execution time of the write_ouputs() function. And, as usual, the speed limit is on the technology and also in the tradeoff with the dynamic power consumption (see L4.3 to review these concepts on how gate switching speed is related to dynamic power consumption).

Execution time a a function

Fig. 21. Measurement of the loop execution time using breakpoints.

The microcontroller crystal oscillator frequency is a fundamental parameter. A 16 MHz executes assembly instructions four times faster than a 4 MHz crystal. You can adjust this parameter in the chip's edit properties window.

OSC frequency

Fig. 22. Setting the simulator's OSC microcontroller frequency. 

See how long does it take to execute an assembly instruction. Most of the instructions takes four OSC periods TOSC to execute.

 

Specifications Planning Dev. & Test 5. Prototype Report

3.4.5. Prototyping and laboratory experimentation

3.4.5.1. Chip programmer and program download

3.4.5.2. In-circuit debugging

3.4.5.3. Measurements and characterisation

Use training boards and perform laboratory measurements to verify how the circuit works. We can design a basic board for PIC18F mC such CSD_PICstick.

 

Specifications Planning Dev. & Test Prototype 6. Report

Follow this rubric for writing reports.  

About code listings and ideas on how to print coloured code.

 

Optional. The same example (hardware and software source C code) for other microcontrollers: