Write in addressing code for IDE app to program. Not counting pushing and pulling registers to the stack, or the lines of code executed by a subroutine, write the keypad in $20$ lines of code or less$\mathrm{.}1.$ Initialize Port U $($address $$268)$ so the upper four bits are outputs and the lower four bits are inputs by doing the following: Write value $FO to the Data Direction Register of Port U $($address $$26$A$)$ to make bits$1-3$ inputs and bits $4-7$ outputs. Write value $FO to the Polarity Select Register of Port U $($address $$26$D$)$ to set the pins$1-3$ as a pull$-$up device. Write value soF to the Pull Device Enable Register of Port U $($address $$26$C$)$ to activate the pull$-$up device on pins $0-3\mathrm{.}2.$ STEPS TWO THROUGH FOUR SHOULD BE ISOLATED IN A "KEYPAD" SUBROUTINE IN A SEPERATE FILE. Check each row of the keypad by writing a logic low to the output pin of Port U connected to that row and a logic high to the other output pins of Port U$.$ Then read back the value to check for a press. Steps: The sequence that needs to be sent to Port U continuously to scan all four rows of the keypad is $$70,$ $$0,$$DO$,$ $E$0.$ Make this into a constant array. Load the address of the sequence into a register Send a value of the sequence to port U$,$ and increment the sequence's address Perform a lms delay $-$ You are REQUIRED to use another subroutine for this! Read port U back in $($this is one of only two times you should read port U$!)$ If value SxF $($where x means "don't care" in a digital logic manner$)$ is read from the lower nibble, we know no key is pressed in the row currently being "sent". For example if you read $DF$,$ you would've just sent $DO and would now know that no key is pressed in the $3$rd row. All rows share the lower nibble being $F$,$ hence why we can generalize this process by saying $xF for all rows. However we must "scan" all four rows which means four cases, but if we eliminate the upper nibble we only have to account for one! So$,$ mask the upper nibble $($bits $4-7)$ by performing an AND operation on the read value. If the remaining value is equal to $OF$,$ branch back to where you will then send the next item in the sequence. If not, you have a key press, and will simply proceed to the next step, the LUT $($look$-$up$-$table$)$ portion. But think, you will need the value you read in for the LUT but you just destroyed it by masking it$!$ Without reading port U again, how can you save it before the masking so you can retrieve it again after for the LUT?... Go back and add a way to do this. Once all $4$ rows are scanned, reset the address of the sequence, and repeat the process. Think: How do you know you have reached the end of the sequence? A terminator? Counter? Etc... What works best here? You will likely need to go back and make some additions to your code for this feature$\mathrm{.}3.$ Wait for the button to be released before continuing. Otherwise, what you consider a quick press of the button is enough time for the subroutine to run hundreds of times! This will create the appearance of the button press' value being displayed on both LED nibbles simultaneously. Think about the mouse on your computer: Most 'clicks' don't go through until you release.a$.$ Read port U$.$ This is the second of ONLY two lines which you should check it$.$b$.$ Mask it and see if there is any sort of press. Same as before. Except this time we don't care about the value at all, so theres no need to save.c$.$ Now it is the opposite as before... We are waiting for no press. If the input eventually matches $Of$,$ only then we will continue. Otherwise you should loop back to the beginning $($a$)$ of this step. This effectively stalls out the code which isn't in the RTI and forces one press at a time, no matter how long$\mathrm{.}4.$ If a key is pressed use the lookup table process from Laboratory $4\mathrm{.}3$ to check for a match.The index of this match in the sequence corresponds to the key that is being pressed $($e$.$g$.,$ if a $\text{'}2\text{'}$ is pressed on the keypad, the upper nibble with read value $$7$ and the lower nibble will read $B$).$a$.$ This is similar and simpler than the "sending" step, but more details on LUTs are in lecture notes and lab $4.$b$.$ Load the address of the 'key' sequence and initialize a counter in another register.c$.$ Load a value of the array ideally using post auto$)$ and compare to your saved value read in as a key press from step $2.$d$.$ If equal, leave this inner loop, and store your counter as the pressed$-$key's value. e$.$If not, increment your counter, and loop back to retrieve and compare the next value in the 'key' arrayf. Make sure you've accounted for your registers, and leave the subroutine$\mathrm{.}5.$ Now in your main loop, after calling your keypad subroutine, write code to accomplish the following: The first keypress value displays on the right four LEDs, the second keypress displays on the left four LEDs while maintaining the value of the first keypress, the third keypress displays on the right four LED while maintain the value of the second keypress, and so on$.$ This can be accomplished using AND, OR$,$ and shift instructions.a$.$ The LEDs should NOT flicker!b$.$ Think: In order to know if the current key press should go on the left or right, your program must remember what side it did last time! How can you create this behavior exploiting the features of assembly language? How would you do it in C$?$