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



Laboratory 9: microcontrollers. Digital input and output

[P9] Specifications (1) and planning (2)



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

3.4.4. Example projects Dual_MUX4

1. Specifications

Our goal is to design again a dual 4-channel multiplexer (Dual_MUX_4) like 74HCT153 that was already solved in P2-P3 using plans A, B and C2. This time the circuit will be based on a microcontroller (μC). Input and output signals have been distributed in different ports of the microcontroller so that you can practise on software organisation and on how to read and write individual pins.



Fig. 1. This is the chip 74HCT153 that is taken as a reference and the symbol of the Dual_MUX_4. The symbol includes the port pins of the microcontroller where the input and output signals are connected.

Fig. 2. represents the sketch of the symbol and truth table as it was described in Chapter 1 project Dual_MUX_4.

Truth table

Fig. 2. Symbol and truth table.


2. Planning

Let us use the target μC chip: PIC18F4520 in Fig. 3. Target chip can be any other microcontroller or Arduino (ATmega328P). Our aim is to practise with digital inputs and outputs.


Fig. 3.  Pin out diagram of 40-pin PDIP PIC18F4520 μC.

Design steps:

A) Planning hardware

Hardware circuits and port connections 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. 


Fig. 4. Schematic.

B) Planning software

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.


Fig. 5. Software organisation. 


Here we will include a new tool: the hardware-software diagram.

hardware software diagram

Fig 6. The new conceptual representation tool: hardware-software diagram. 

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. 

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 RAM bytes are required, and some more are required for partial results, such as var_buff

In our simple programs RAM variables will be global (accessible from anywhere in the code), but var_buff for saving partial results within a function may be local.

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.


Fig. 8. Init_system() to set pin directions. 

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.

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.  

Conveniently, 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. Flowchart is translated to C code instead of VHDL. The advantage of such code organisation based on hardware-independent functions is that flowchart is translated to C for any microcontroller, to ino for Arduino or python for Raspberry Pi.

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

Thus, what you see here is a powerful concept: all software algorithms are hardware-independent, meaning that they rely completely in RAM variables being totally compatible between hardware computer 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 in Fig. 12.


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 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:


Target μC chip: PIC18F4520. Target prototyping board: PICDEM2 plus.




Laboratory 9: microcontrollers. Digital input and output

[P9] Debugging tools: break points, step by step mode, watch windows, etc. Developing (3) and testing (4) interactively



3. Development & 4. Testing

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 to check that the voltage value is correctly digitalised as a valid digital value in RAM memory. Write one output at a time and run to check that your code is correct to light LED connected at output pins. Solve the truth table algorithm and run.

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 assignment to three students working in the same 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.
. 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. 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 code the planned flowchart and add it to the previous program Dual_MUX_4.c.
Open project
Secon reading operation

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

Repeat  new steps to complete all inputs.

Writing outputs
Step #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.
. 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.
. 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 PIC18F4520 and compile. Run and add the watch window to monitor the RAM values related to the truth table execution.
Truth table

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

Initial steps to start a new project in MPLABX for target PIC18F4520, compile and simulate rec.

A) Developing hardware

Child sheet

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.

B) Developing software

Run the integrated development environment IDE MPLAB X (with the included XC8 C compiler) and start a new 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.

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

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


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. 


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.


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

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?


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


5. Report

Follow this rubric for writing reports.  

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


6. Prototyping

Use training boards and perform laboratory measurements to verify how the circuit works.

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


3.4.5. (optional) Prototyping and laboratory experimentation Chip programmer and program download In-circuit debugging Measurements and characterisation