0% found this document useful (0 votes)
74 views9 pages

Scanning and Identifying The Key

The document discusses several future trends in real-time operating systems (RTOS) for embedded systems: 1) RTOS will become more application specific to optimize for specific requirements and reduce overhead. 2) System on a chip (SOC) technology will integrate more functions onto a single chip, improving size, cost and power efficiency for consumer electronics and wireless devices. This may include multi-core processors. 3) Automatic code generation tools may allow application code to be generated from graphical diagrams, reducing development time.

Uploaded by

niravsoni001
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
74 views9 pages

Scanning and Identifying The Key

The document discusses several future trends in real-time operating systems (RTOS) for embedded systems: 1) RTOS will become more application specific to optimize for specific requirements and reduce overhead. 2) System on a chip (SOC) technology will integrate more functions onto a single chip, improving size, cost and power efficiency for consumer electronics and wireless devices. This may include multi-core processors. 3) Automatic code generation tools may allow application code to be generated from graphical diagrams, reducing development time.

Uploaded by

niravsoni001
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 9

At the lowest level, keyboards are organized in a matrix of rows and columns.

The CPU accesses both rows and column through ports; therefore, with two 8-bit ports, an 8*8 matrix of keys can be connected to a microprocessor. When a key pressed, a row and column make a connect; otherwise, there is no connection between row and column. In IBM PC keyboards, a single microcontroller (consisting of microprocessor, RAM and EPROM, and several ports all on a single chip) takes care of software and hardware interfacing of keyboard. In such systems it is the function of programs stored in the EPROM of microcontroller to scan the keys continuously, identify which one has been activated, and present it to the motherboard. In this section we look at the mechanism by which the 8051 scans and identifies the key.

Scanning and identifying the key

As above shows a 4*4 matrix connected to two ports. The rows are connected to an output port and the columns are connected to an input port. If no key has been pressed, reading the input port will yield 1s for all columns since they are all connected to high (Vcc) If all the rows are grounded and a key is pressed, one of the columns will have 0 since the key pressed provides the path to ground. It is the function of the microcontroller to scan the keyboard continuously to detect and identify the key pressed. How it is done is explained next.

Fig:6.3

29

Grounding rows and reading columns

To detect a pressed key, the microcontroller grounds all rows by providing 0 to the output latch, and then it reads the columns. If the data read from the columns is D3-D0=1111, no key has been pressed and the process continues until a key press is detected. However, if one of the column bits has a zero, this means that a key press has occurred. For example, if D3-D0=1101, this means that a key in the D1 column has been pressed. After a key press is detected, the microcontroller will go through the process of identifying the key. Starting with the top row, the microcontroller grounds it by providing a low to row D0 only; then it reads the columns. If the data read is all1s, no key in that row is activated and the process is moved to the next row. It grounds the next row, reads the columns, and checks for any zero. This process continues until the row is identified. After identification of the row in which the key has been pressed, the next task is to find out which column the pressed key belongs to. This should be easy since the microcontroller knows at any time which row and column are being accessed.

Assembly language program for detection and identification of key activation is given below. In this program, it is assumed that P1 and P2 are initialized as output and input, respectively. Program goes through the following four major stages:

Keypad Interfacing

;Keyboard subroutine. This program sends the ASCII code ;for pressed key to P0.1 ;P1.0-P1.3 connected to rows P2.0-P2.3 connected to columns MOV P2,#0FFH K1: MOV P1,#0 MOV A,P2 ANL A,00001111B ;make P2 an input port ;ground all rows at once ;read all col. (ensure all keys open) ;masked unused bits

CJNE A,#00001111B,K1 ;check til all keys released K2: ACALL DELAY MOV A,P2 ;call 20 msec delay ;see if any key is pressed ;mask unused bits

ANL A,#00001111B

CJNE A,#00001111B,OVER ;key pressed, await closure SJMP K2 ;check il key pressed ;wait 20 msec debounce time

OVER: ACALL DELAY MOV A,P2

;check key closure ;mask unused bits 30

ANL A,#00001111B

CJNE A,#00001111B,OVER1;key pressed, find row SJMP K2 ;if none, keep polling ;ground row 0

OVER1: MOV P1,#11111110B MOV A,P2

;read all columns ;mask unused bits

ANL A,#00001111B

CJNE A,#00001111B,ROW_0;key row 0, find the col. MOV P1,#11111101B MOV A,P2 ;ground row 1

;read all columns ;mask unused bits

ANL A,#00001111B

CJNE A,#00001111B,ROW_1;keyrow 1, find the col. MOV P1,#11111011B MOV A,P2 ;ground row 2

;read all columns ;mask unused bits

ANL A,#00001111B

CJNE A,#00001111B,ROW_2;key row 2, find the col. MOV P1,#11110111B MOV A,P2 ;ground row 3

;read all columns ;mask unused bits

ANL A,#00001111B

CJNE A,#00001111B,ROW_3;keyrow 3, find the col. LJMP K2 ;if none, false input, repeat ;set DPTR=start of row 0

ROW_0: MOV DPTR,#KCODE0 SJMP FIND

;find col. key belongs to ;set DPTR=start of row 1

ROW_1: MOV DPTR,#KCODE1 SJMP FIND

;find col. key belongs to ;set DPTR=start of row 2

ROW_2: MOV DPTR,#KCODE2 SJMP FIND

;find col. key belongs to ;set DPTR=start of row 3

ROW_3: MOV DPTR,#KCODE3 FIND: RRC A JNC MATCH INC DPTR SJMP FIND MATCH: CLR A MOVC A,@A+DPTR MOV P0,A LJMP K1

;see if any CY bit low ;if zero, get the ASCII code ;point to next col. address ;keep searching ;set A=0 (match is found) ;get ASCII code from table

;display pressed key

;ASCII LOOK-UP TABLE FOR EACH ROW 31

ORG

300H '0','1','2','3' '4','5','6','7' '8','9','A','B' 'C','D','E','F' ;ROW 0 ;ROW 1 ;ROW 2 ;ROW 3

KCODE0: DB KCODE1: DB KCODE2: DB KCODE3: DB

END

CHAPTER 7
32

Getting The Embedded Software Into The Target System


The locator will build a file that describes the image of the target softaware. Let us see the issue of getting that file into the target system.

PROM Programmers

The classical way to get the software from the locator file into the target system is to create a RAM or PROM . Creating ROM is appropriate only when software development has been completed,since the too long cost to build ROMs is quite high.

Putting the program into a PROM requires a device called a PROM programmer. This is appropriate ifvolumes are not large enough to justify using a ROM, if plan to make changes to the software, or while we are debugging . If we plan to use PROMs and a PROM programmer for debugging purposes,it is usefulto build the version of the taaget system in which the PROM is placed in a socket on the target system rather than being soldered directly into the circuit. Then when we find a bug, we can remove the PROM containing the software with the bug from the target system and put it into the eraser or into the waste baket ,program a new PROM with software that has the bug fixed, and put that PROm into the socket. pin Well in socket to receive chip Contact switch to receive chip

Internal connection between contact in well& targetboard

Socket soldered to targetboard

Target board

Fig:7.1

Schematic view of socket


33

ROM emulator

Rom emulator is a device that replaces the ROM in the target system. From the point of view of the rest of the hardware in the target system, the emulator looks just like a ROM. However, the ROM emulator contains a large box of electronics and a serial port or a network connection through which it can be connected to our host. Software running on host send files created by the locator to the ROM emulator , which will act like a ROM that has been programmed with the software we have written.

ROM emulator

Serial network connections connects ROM emulator to host Ribbon cable attaches probe to ROM emulator

Probe from ROM emulator plugs into the memory chip socket

Fig:-7.2

CHAPTER 8
34

Future Trends In Embedded System RTOS


There is a flood of trends rushing through the embedded market today, many influencing the RTOS requirements in conflicting ways. It is hard to envision that five years from now RTOS products will bear much resemblance to what is supplied today. Some of these trends are application driven while others are device driven, and it is important to understand the influences these trends will have.

Application Specific:

In several markets, the end users have banded together to issue specific requirements for RTOSs to be used in their future products. They have purposely chosen to drop their proprietary behaviors of the past in order to get the benefits of multiple suppliers and interoperability of software. In this manner, only the needed software is linked into the application, preventing additional overhead and allowing for an extremely efficient kernel implementation.

System On A Chip (SOC):

As mentioned earlier, SOCs are beginning to appear throughout the embedded market, in at least three different ways. First, the semiconductor suppliers are providing developers the ability to pick and choose from a combination of industry standard functions integrated around a 32-bit core processor. These functions may include memory, IO drivers, a bus interface, network protocol support, or algorithms for special functions, such as an MPEG decoder. Second, end product manufacturers are integrating custom ASICs with common 32-bit core processors to provide complete solutions. Some recent examples include cable modems and ATM switches. And third, startups are emerging that will provide custom design services, complete with optimized RTOS, compiler, and debuggers.

SOC will be particularly well suited for a whole range of consumer electronics and wireless communications devices where size, cost, and low power requirements are crucial. It will also drive cost reductions in networking and telecom equipment, where more functionality can be added at lower costs. A subset of this SOC trend is the emergence of multi-core devices on single silicon. The most common to date has been the combination of standard microprocessors and Digital Signal Processors (DSPs). In some cases, the DSPs are dedicated function processors, but emerging trends have the DSP as a full programmable device.

Automatic Code Generation: 35

Probably the most radical notion is the idea that application code can be generated automatically from graphical diagrams depicting the logic flow for the end product. To a limited extent, this has already been accomplished, with products like MATRIX, BetterStat, Statemat, and MATLABbeing used for application modeling and code generation. In the case of MATRIX, flight ready code for the international space station has been used for some time now, and the technology is being extended into the more restrictive automotive market. If these tools were to become reality, the whole notion of commercial RTOS and development tools will be upset, as the developer will only interact with the graphical tool, and will be totally isolated from the resulting software implementation.

CONCLUSION:
36

This seminar helped in understanding the following concepts.

1. Embedded systems application development. 2. The components of embedded systems.

3. The design issues. 4. The applications in which embedded systems are used. 5. RTOS and its features. 6. How to carry out effective presentation.

APPENDIX A
REFERENCES AND BIBILIOGRAPHY:
1. THE 8051 MICROCONTROLLER AND EMBEDDED SYSTEM BY MUHAMMAD ALI MAZIDI, JANICE ALI MAZIDI, ROLIN D. MCKINLEY 2. 3. 4. 5. 6. WWW.EN.WIKIPEDIA.COM WWW.EMBEDDED .COM WWW.8051PROJECTS.INFO WWW.EMBEDDEDRELATED.COM WWW.KEIL.COM

37

You might also like