Digital Circuits and Systems - Circuits i Sistemes Digitals (CSD) - EETAC

Dev. & test

Prototype

To demonstrate how a sequential circuit can be implemented using a microcontroller for instance in a target chip PIC18F46K22 and the latest Microchip MPLAB X IDE and XC8 tools, let us implement some features of a typical 1-digit BCD counter type 74HCT160 or 74HCT190. Full rec.

Adapting the counter

Fig. 1. Internal structure of the classic counter chip 74HCT160 to be implemented using a μC. Note: As you see, we fix LD_L = '1', thus chip's parallel load functionality is always disabled. Synchronous parallel load may be proposed as another plan Y application.

The chip and features to be implemented can be readapted as represented in Fig. 2 using our naming conventions as in Counter_BCD_1digit example on plan X.

Fig. 2. Symbol (Visio) and function table as studied in Chapter 2.

Propose a timing diagram as in Fig. 3 and adapt it to use RAM variables. Thus, a question arises immediately: how to make the microcontroller sensitive to CLK signal edges? Is it the same that reading inputs (polling) in the main program or we have to find a way to detect signal edges? What is the difference between this external CLK that runs the counter application and the quartz oscillator OSC at 4 MHz that runs the microcomputer?

Fig. 3. Example of timing diagram for the initial design phase #1. Signals will be converted in to RAM variables.

Switches will be read using polling in read_inputs(), as proposed in P9. Push-button actions (pressing or realising) or equivalently, signal transitions or active edges will be detected using the key concept of interrupt.

2. Planning

Dev. & test

Prototype

The project design flow when using microcontroller technology is depicted in Fig. 4.

Fig. 4. Design flow for developing and testing a single design step at a time.

Therefore, as all our proposed projects in this Chapter 3, the design of the Counter_BCD_1digit, will be organised in several phases and steps. This tutorial covers only the first step #1 of the design phase #1.

- Design phase #1: Basic counter.

- Step #1: Design the basic up counter with TC10 and CE.

- Step #2: Add reversibility (UD_L)

- Design phase #2: Counter with LCD. Example: Counter_BCD_1digit_LCD

- Step #1: Display only static text messages, the "Hello World" for testing hardware and software.

- Step #2: Display dynamic data such numbers.

- Design phase #3: Using internal timers to replace the external CLK. Example: Counter_BCD_1digit_LCD_TMR0

- Step #1: TMR0

- Step #2: TMR2

What is time resolution, accuracy, precision, reliability? Which timer is more accurate? Which is the key component for high resolution timing?

Note: enumerating states is perfect for designing FSM. As you see, we also propose state enumeration Plan X for implementing counters. However, it has its limitations when the counter has many states or many state transitions. As we did in P7 for large counters, we will study how plan Y is adapted to mC in the second tutorial of this laboratory Counter_mod1572. Besides, other features such parallel load (LD and Din) are easily implemented when var_current_state is encoded as a number in binary sequential (radix-2).

Design phase #1. Step #1: Design a basic up counter with TC10 and CE. For instance as it was done in Counter_BCD_1digit.

Draw the state diagram as in Fig. 5. Note that in this chapter we use memory variables to solve the diagram. External signals such pin CE will be polled in read_inputs() so that var_CE will contain its value. CLK active edge will be detected using the external interrupt INT0. In this application, all state transitions happens only when var_CLK_flag is set. Output variables such var_BCD_code in parenthesis are written to the corresponding microcontroller pins.

Fig. 5. State diagram driven by interrupts on external edge detection.

Let us repeat this substantial concept: be aware of the difference between a level.sensitive signal such CE (read/poll) from a switch, and an edge-sensitive signal (interrupt) from a push-button, because they are interfaced using specific mechanisms. The nature of such signals will be highlighted in the naming convention of RAM variables: an edge-sensitive signal like CLK will be named var_CLK_flag. , while a level-sensitive input such CE will be named simply var_CE.

A) Planning hardware

Circuit and port connections are represented in Fig. 6. We can use any pin from any mC port to connect inputs and outputs. For the target chip PIC18F46K22, we have to pay attention to connect external interrupt sources such CLK to RBO/INT0, RB1/INT1 or RB2/INT2.

If the system has to be prototyped in a later design stage on a training board such CSD_PICstick, PICDEM2 PLUS or EXPLORER 8, we can use the board connectors to attach input and output components such switches, resistors, LED, etc. Or instead we can use the boards resources when available. CSD_PICstick contains up to 8 LED, one switch and one push-button.

Fig. 6. Hardware used in this application. The idea is to connect the CLK signal to an external interrupt pin (INT0). We can select which edge, falling or rising, is going to trigger the interrupt flag (INT0IF = 1).

With the proposed RC values for the active-low master clear (the typical CD_L) the system reinitialises in less that 1 ms. It means that the μC's program counter register goes pointing the first program memory position to start executing code from the first instruction (read the datasheet chapter on MCLR_L).

B) Planning software

The general idea for solving the FSM architecture is represented in Fig. 7a. The concepts of CC1 and CC2 combinational circuits inherited from Chapter 2 are the same. However, this time, we will implement these truth tables using software routines and input and output RAM variables. The state register and the next_state signal is not required because we simply use a RAM variable like var_curent_state to encode state labels. The next state value wil be asserted after executing the state_logic function.

The CLK synchronisation mechanism is different from Chapter 2. The FSM function state_logic() will be executed only when there is a CLK edge detection (var_CLK_flag = 1) by means of the exernal interrupt mechanism.

a)
b)
Fig. 7. The FSM adaptation and the software organisation used in this application.

This special C code organisation allows you to take full advantage of previous Chapter 1 and 2. Almost all the content learnt since now can be fully applied here again when we switch to programming microcontrollers. Furthermore, even if we choose other microcontrollers such Arduino or microcomputers like Raspberry Pi or any other similar platform, the main ideas and adaptations remain the same. The the huge advantage that represents organising as separate and independent pieces of software the hardware-dependent functions such read_inputs or write_outputs that act as interfacing drivers.

In Fig. 8 there is an example of software-hardware diagram. Another advantage of this organisation is that software functions output_logic() and state_logic() are completely compatible among platforms and programming languages. Only hardware-dependent functions (drivers) have to be rewritten when changing microcontrollers or programming environments.

Fig. 8. Hardware-software diagram. Hardware interface functions are drawn in blue and software functions based on RAM memory in black. The picture also shows the circuit and the associated configuration bits for allowing the external interrupt INT0 to detect CLK's falling edges or rising edges (it is configurable).

All the main RAM variables to handle the FSM are represented in Fig. 9. All the variables are kept char type for being able to watch them easily in our simulation and debugging tool.

RAM memory varialbes used in this application

Fig. 9. RAM variables list.

Draw the main ideas of init_system(). Configure input and output pins. Consider as well interrupt configuration bits to enable INT0. Configure the INT0 active edge for triggering interrupts .

Fig. 10. TRIS configuration bits.

Notice how organising the software in this very specific set of functions, each one with a very well defined objective, it is easy to work in group with several team members working concurrently in different functions of the same project.

Draw the flowchart of read_inputs(). Basic function to poll input voltages as in L9.3. Translate the flowchart into C using bitwise operations.

Draw the flowchart of write_outputs(). Basic function to write pins voltages as in L9.4. Translate the flowchart into C using bitwise operations.

Infer how to organise the interrupt service routine ISR() to handle CLK's falling edge detections.

Fig. 11. Interrupt service routine for setting var_CLK_flag. This key function is for synchronising the execution of the FSM on active CLK edges.

And now, it is necessary to discuss how to transfer all the state transitions into a truth table.

Draw state_logic() truth table.


	Fig. 12. Truth table for state_logic() function. When the input var_CLK_flag is used for all transitions there is no need to add it to the truth table (As we did with the CLK signal in Chapter II projects).

Translate it into a behavioural flowchart. All transitions are affected by the CLK edge detection interrupt as expected in counters. The function read_inputs() executed before state_logic() captures the pins of interest and generates their corresponding RAM variables.

Fig. 13. Translating state_logic() truth table into a behavioural flowchart as we did in VHDL plan B. In this way the C statements can be easily imagined.

Finally, what is left to finish this project planning is the same idea but for the outputs, how to translate all the outputs in parenthesis into a truth able and its equivalent flowchart?

Draw the output_logic() truth table.


	Fig. 14. Truth table for output_logic() function.

Translate the truth table into a behavioural plan B flowchart in the same way we did in VHDL.

Fig. 15. Translating output_logic() truth table into a behavioural flowchart so that C statements can be easily imagined.

Once the RAM variables are updated, they will be written into pins using write_outputs() function.

Additional questions:

- How long does it take to execute the code and thus which is the reading/polling speed?

- How many RAM bytes are used in this application?

- Which configuration bits has to be programmed to setup interruptions from INT0?

- How to program the INT0 active edge (rising or falling)?

- How many external interrupt sources INT has the microcontroller that you can choose from?

Project location:

C:\CSD\P10\Counter_BCD_1digit\(files)

Important remarks: Do NOT write C code without having discussed in sheet of paper your planning and flowcharts. Therefore, four or five sheets of paper are expected to clarify and organise every aspect of hardware and software. Reuse as much as possible materials from previous projects, however, do NOT use digsys pictures in your reports, but analyse and redraw them in your own way. It is the only fashion to grasp full details and be able to ask meaningful questions to comprehend projects.

Step #2: Enhance the previous circuit adding the UD_L feature. Only when step #1 is fully develop and debugged using step by step execution and watching variables of interest.

(Optional) Step #3: Add the parallel load (LD), which means changing completely from plan X to plan Y. Additionally, some actions has to be considered when an invalid data is inputted by the user (D = 1010, 1011, ... 1111) to prevent unexpected states, for instance, reset the system to build a safe FSM. Therefore, it is better to solve this step #3 after studying the next tutorial below on plan Y.

Planning

3. Dev. & 4. test

Prototype

A) Developing hardware

This is an example of circuit schematic Counter_BCD_1digit.pdsprj . This capture is easily generated copying and adapting a similar example.

Fig. 16. Hardware connections to solve step #1 of this project. A switch allows you to select the CLK source: single pulses from a push-button or an external oscillator.

B) Developing software

The C source file Counter_BCD_1digit.c for step #1 where only count enable and up counting are developed. Add the config.h header to your project to fix the mC configuration bits.

Run the IDE and start a new project in the corresponding folder. Name it as usual: Counter_BCD_1digit_prj.

Compile and generate the COF and the HEX output configuration files.

Check the number of resources used: the size of the program, the number of memory bytes (RAM).

C) Step-by-step testing

Run Proteus and test the circuit using step by step, break points and the watch window tools. Remember that the key strategy is to write a few lines of code at a time, compile, run and test. And only when it works, add some more code after having transferred truth tables and algorithms into flowcharts.

Fig. 17. Example capture from Proteus running the application setting 20 Hz as the CLK frequency.

Questions:

- How long does it take to run the main loop?

- How long does it take to execute an interrupt? and therefore, what is the maximum CLK frequency you should apply in order to make it run correctly?

- How can you compare these magnitudes with values attained in chapter II designing hardware counters in VHDL for target FPGA or CPLD?

Example of logic analyser capture of the screen

Fig. 18. a) Example capture from Proteus logic analyser instrument screen and the analysis to determine whether the circuit works correctly (CE = 1). b) Printing the logic analyser screen for the project report requires changing colour configuration using white background to save printer ink and generate clear documentation.

This is the compiled Counter_BCD_1digit.zip project.

Dev. & Test

5. Prototype

Report

Example 1: Board CSD_PICstick. Target microcontroller: PIC18F46K22. Tools: MPLAB X + XC8 + Proteus MPLAB SNAP in-circuit debugger/programmer

This example is proposed as the default application design phase #1 for testing the board.

Example 2: Board PPicdem2+. Target microcontroller: PIC18F4520. Tools: MPLAB X + XC8 + Proteus + PicKit 3 or ICD3 debugger/programmer

We can use the prototyping area for soldering push-buttons, switches and LED. /p>

Fig. 19. Prototype built on a PICDEM2 board.

Example 3: Simple mC target board. Target microcontroller: PIC18F46K22. Tools: MPLAB X + XC8 + Proteus + MPLAB SNAP in-circuit debugger/programmer

We can try the same experiment using another target board and developing resources. Fig. 19 shows the adaptations for connecting a similar microcontroller. The hardware circuit a href="Counter_BCD_1digit/PICDEM/counter_BCD_1digit.pdsprj"> Counter_BCD_1digit.pdsprj and the source file Counter_BCD_1digit.c so that we can pay attention on how to initialise configuration bits and ports for this specific target microcontroller PIC18F46K22.

Fig. 20. Circuit connecting the PIC18F46K22.

We can program and debug the circuit as we did already did in Proteus. Fig. 21 shows the setup using the MPLAB SNAP.

Fig. 21. Laboratory setup to verify our design.

A good idea is to make a minimum target PCB with all port pins available through sockets like Arduino. In this way it can be used repeatedly with different shields or protoboards to verify application circuits. Fig, 22 shows the debugging environment in MPLAB X to run step by step watching variable values and using breakpoints.

Fig. 22. Using the debugger embedded in MPLABX IDE.

Example 4: Board Explorer 8. Target microcontroller: PIC18F4520. Tools: MPLAB X + XC8 + Proteus + PicKit 3 in circuit debugger/programmer.

The same project but changing the pins to adapt to port connections as shown in Fig. 23 and Fig. 24. /p>

	Fig. 23. Microcontroller pins for Explorer 8 board. Button S1 will generate external CLK interrupts. Button S2 will be CE_L control input. Schematic for COSC and MCRL_L are also represented pasted from the board's user manual.

The schematic connections are different thus hardware functions read_inputs() and write_outptuts() have to be modified accordingly. This is the advantage of programming the application using our style, only minor adaptations are necessary when changing prototyping platforms. This is the adapted project counter_BCD_1digit.pdsprj and counter_BCD_1digit.c. Project location: /p>

C:\CSD\P10\Counter_BCD_1digit\EXP8_PIC18F4520\(files)

The design can be also emulated in hardware using for instance ICD 3 tool monitoring variables, breakpoints, watch windows, etc.

Fig. 24. Prototype built on Explorer 8 board.

Instrument such Analog Discovery 2 or VB8012 may be used to drive CLK signal using the waveform generator and measuring outputs connecting the logic analyser.

Example 5 optional, beyond the CSD learning objectives. Board Explorer 8. Target microcontroller: PIC18F46K22. Tools: MPLAB X + XC8 + MCC (Microchip Code Configurator) + Proteus.

In this case, multiple files are specified by the MPLAB Code configurator. /p>

The LCD populating Explorer 8 is wired and operating, but not used until the next design phase #2: counter_BCD_1digit_LCD.

Project location:

C:\CSD\P10\Counter_BCD_1digit\EXP8_PIC18F46K22\(files)

Fig. 25. Proteus captured schematic of some Explorer 8 circuits. As usual, if component models exist, we will try firstly to develop and run the prototype application in Proteus.

This is the adapted project counter_BCD_1digit.pdsprj and counter_BCD_1digit.zip.

NOTE: To work with this new programing environment, do not start a "new project" but instead "open project" from the unzipped example given saved previously to the destination location.

Fig. 26. Open project in MPLAB X. This project, once running can be copied as the stating point for the next design phase #2.

6. Report

Follow this rubric for writing reports.

Lab9

Laboratory

Laboratory 10: adapting FSM to C language. Interrupts to detect signal events (CLK)

[P10] Plan X: FSM state enumeration. Plan Y: FSM: large counters: Counter_mod1572.

Lab11

top

3.5.4.4. Counter_mod1572 (large binary counter, plan Y)

1. Specifications

Dev. & test

Prototype

Implement a FSM using C language (plan Y, large number of states)

How can we save a large number of states in a FSM? If there are too many states or too many state transitions, the FSM cannot be enumerated or it is impractical to do it, thus, let us organise the architecture as in chapter 2 plan Y, where var_current_state is defined as std_logic_vector signal. The equivalent this time is to use a RAM variable type int (short, long, etc. depending on the number of bits required). A char or uint8_t variable can hold up to 256 states. A int variable can hold up to 65536 states. A 32-bit double int variable can hold 4.294.967.296 states (this is for instance counting seconds for 135 years!). Therefore, try to imagine how a real-time calendar chip such as DS1307 may be organised considering concepts from L7.3 chaining counters.

To demonstrate how a sequential circuit can be implemented using a microcontroller PIC18F46K22 and IDE tools (Microchip MPLABX, XC8), let us implement a large counter such as Counter_mod_1572 using plan Y. Fig. 1 represents the symbol and functional table using our naming conventions, which are the same one studied in Counter_mod1572. Full rec.


	Fig. 1. Symbol (Visio) of the chip functionality. As usual, we can click a button to input CLK edges or instead, connect an oscillator. Let us this time to drive the counter with CLK's falling edges.

In a first design step the basic counter can be implemented as shown in Fig.1.

Additionally, because you know now that this is only the beginning, in a second design step, parallel inputs or reversibility can be added as a new feature for this binary counter.

On the other hand, as an additional complementary exercise, you can even imagine the circuit using plan C2 and counter_mod16 as components adapted to C language.

Your great advantage now: FSM foundations are already studied in P7, and thus, solving it using a different technology based n microcontrollers, is not going to change its conceptualisation in any way. Indeed, from the point of view of engineering, we will have the advantage of comparing circuit realisations for the same entity (power consumption, speed, component list, flexibility to implement modifications, etc.)

Draw an example of timing diagram as in Fig. 2. Deduce how many states the system may include.

Fig. 2. Example of timing diagram directly inherited from Counter_mod1572 and adapted to μC using interrupts to detect falling CLK edges. The polling function read_inputs() for capturing the CE_L level can be executed continuously in the main loop or only when there is an INT0 detection. Which option would be better?

2. Planning

Let us organise the plan as usual taking large counters from P7 plan Y as reference.

Draw the circuit's state diagram as proposed in Fig. 3.

Fig. 3. Example of state diagram adaptation. Every state transition depends on the detection of the CLK active edge by means of the interrupt service routine. Signals are transformed into RAM variables. As in the previous project, all state transitions are effective only when var_CLK_flag is asserted, thus INT0 interrupts must be enabled all the time (INT0IE = 1, GIE = 1) from init_system(). When there is no interrupt detection (var_CLK_flag = 0), the system is doing nothing but wasting time looping the main program.

A) Planning hardware

The electronic circuit is represented in Fig. 4. Port pins like RA3 and RB0 are connected to inputs. Other 12 pins are outputs to show the counter's current value and terminal count.

Fig. 4. Hardware used in this application. The idea is to connect the CLK signal to an external interrupt pin (INT0) that has the specific circuitry to detect an active edge (configured falling) and set the hardware interrupt flag (INT0IF).

This unit explains the key concept of external interrupt for detecting edges.

B) Planning software

The general idea is represented in Fig. 5. The concepts of CC1 and CC2 combinational circuits inherited from Chapter 2 are the same, however this time, we will implement these logics using software routines.

Fig. 5. Software organisation used in this application. Because var_urrent_state is saved in a memory position and updated every main loop cycle, there is no need of var_next_state variable as it was the case in Chapter 2 to drive the FSM's state register.

The idea of designing a chapter 2 synchronous circuit is not that clear now. On the one hand, the microcontroller (a general purpose processor) is a synchronous device where the external OSC generates the necessary signals to synchronise all the architecture operations; on the other hand, the application, this time an 11-bit binary sequential counter, requires the detection of an external interrupt to be updated (CLK), and, to attend an interrupt there is an overhead of some OSC periods (in the range of some μs). Therefore, think and discuss about it.

Furthermore, when polling (why not sampling?) CE_L values there is also a problem related to the general loop: the more assembly instructions to execute the larger the loop and slower is going to be the polling frequency to read inputs. A higher OSC frequency implies shorter instruction execution times, and thus, a larger polling frequency.

Fig. 6 below shows a clearer flowchart representation of the software organization. What signals to read? what signals to be connected to external interrupts? While running in the infinite loop, any time that an INT0IF is detected the system jumps to attend the interrupt routine for a few μs. In this way, state diagram transitions can be reassessed.


	Fig. 6. General interrupt-driven FSM-style program organisation.

In Fig. 7 there is an example of software-hardware diagram. Another advantage of this organisation is that software functions output_logic() and state_logic() are completely compatible among platforms and programming languages. Only hardware-dependent functions (drivers) have to be rewritten when changing microcontrollers or programming environments.

Fig. 7. Hardware-software diagram. Hardware interface functions are drawn in blue and software functions based on RAM memory in black. The picture also shows the circuit and the associated configuration bits for allowing the external interrupt INT0 to detect CLK's falling edges.

All the main RAM variables to handle the FSM are represented in Fig. 8. Pay attention that var_Q (and this time also var_current_state) is 11-bit wide, thus a convenient type is int or uint16_t (16-bit wide). All the other variables are kept char or uint8_t type for being able to watch them easily in our simulation and debugging tools.

Fig. 8. RAM variables list.

Draw the main ideas of init_system(). Configure input and output pins. Consider as well interrupt configuration bits to allow INT0.

Fig. 9. TRIS configuration bits.

Draw the flowchart of read_inputs(). Basic function to poll input voltages as in L9.3.

Draw the flowchart of write_outputs(). Basic function write pins voltages as in L9.4.

Infer how to organise the interrupt service routine ISR() to handle CLK's falling edge detections.

Fig. 10. Interrupt service routine for setting var_CLK_flag.

Draw state_logic() truth table. And now, it is necessary to discuss how to transfer all the state transitions into a truth table. This time a convenient behavioural interpretation using the "+" arithmetic operator makes it very easy.

Fig. 11. Truth table for state_logic() function and its equivalent behavioural flowchart using arithmetic operators that are included in C language by default.

Draw output_logic() truth table. This plan Y has the advantage that sequential binary code outputs are simply a copy of the internal state. And the var_TC1572 is deduced with the same logic expressed in Fig. 1.

Fig. 12. Truth table output_logic() and its behavioural interpretation.

Project location:

C:\CSD\P10\Counter_mod1572\(files)

Optional. When the project is complete and running make the counter reversible using the control signal UD_L.

Optional. When the project is complete and running, add the parallel load (LD) feature as another design step. Consider the number of port pins required. What to do when an application requires a large number of pins?

3. Dev. & 4. test

Prototype