Rochester Institute of Technology CMPE 663/EEEE 663 Graduate Student Project

Transcription

1 Rochester Institute of Technology CMPE 663/EEEE 663 Graduate Student Project Graduate Student Project: Extend the USART Demo project to include blocking and non-blocking (interrupt driven) versions of USART_Read, USART_Write and USART_Printf. Demonstrate the use of both versions of USART_Printf in a running system in the presence of varying amounts of simulated work. NOTE this is an individual project that is required for all students enrolled in CMPE 663 or EEEE 663. Although you may get assistance and guidance, the work you submit must be your own. Discussion: A common technique used in debugging embedded projects is to use print statements to display variables to a console in real time as the program is running. Printing is fast, easy, and sometimes less cumbersome than setting breakpoints and single stepping through code. The first UART project provided a simple USART_Read and USART_Write API that connected to a console application over USB and was used for just this purpose. While the UART Demo project allowed us to demonstrate the STM32 microprocessor, in practice, this would not be very useful implementation because of its blocking nature. Task 1: There are two issues with the demo USART_Write function. First, the software using this function must explicitly find the length of the string prior to calling the USART_Write function. Second, there was no method provided for creating a formatted string similar to printf. Task 1 is to create a USART_Printf function to address these issues. Use one of the C library vprintf family of functions to do the formatting into a buffer. Then send that buffer using the USART. Be careful to avoid overflowing the buffer s array size. Task 2: Task 2 is to create three non-blocking functions that mirror the blocking versions. The USART_Read function has two issues: First, the USART_Read function blocks as it waits for the user to type a character and then reads and returns that character. If the user is not ready to type a character, the USART_Read function just waits and waits. Second, if a user types multiple characters while the main program is not actively polling the USART receive register, those characters will be lost. The USART_Write function has the issue that it writes a number of bytes to the USART transmit register, waiting after each write for that byte to be serialized and transmitted. The

2 function does not return until the last byte has been written. Almost all of the time spent in the USART_Write function is spent waiting for the USART transmit register to empty. Since your USART_Printf function probably uses the blocking USART_Write function it will have the same issue as the USART_Write function. Create these three non-blocking functions using the following function prototypes: // nbread returns the received character or -1 if nothing received. // You may want to pull the character from a read buffer that is managed // by the USART and filled at RXNE interrupt time. // Note: the return is of type int to accommodate a -1 return. int USART_nbRead (USART_TypeDef * USARTx); // Same signature as USART_Write // When invoked, the buffer will be copied to a write buffer maintained // by the USART class, and emptied at TXE interrupt time. void USART_nbWrite(USART_TypeDef * USARTx, uint8_t *buffer, uint32_t nbytes); // Same signature as USART_Printf // Note: the use of the vararg... designator. // This is the C designation of a variable length parameter list. void USART_nbPrintf(USART_TypeDef * USARTx, const char *fmt,...); The second task will require the enabling and handling of two USART interrupts (see the User s Manual and the Zhu textbook for details): RXNE received data register RDR is not empty (you need to buffer the incoming byte). TxE transmit data register TDR is empty (you need to load the TDR with the next byte to transmit). What happens when a character is sent to the STM32 chip? It is de-serialized in the RX Shift Register. When a full byte has been received, it is copied to the RDR register and the RXNE interrupt is fired. An appropriately configured IRQHandler() will catch the interrupt, see the RXNE bit was set, read the character from the RDR register (which automatically clears the RXNE bit), queue the character in a read queue for USART_nbRead(), and return. A similar set of actions happens when the STM32 transmits a character. The sequence is started by enabling the TXE interrupt and writing a byte to the TDR register. The hardware copies this to the TX Shift Register and the TX pin begins transmitting the data. When the last bit has been transmitted the TXE fires. The IRQHandler() will catch this interrupt, and pull the next byte from the transmit queue to write to the TDR register (clearing the TXE bit). When there are no more bytes to be transmitted, the TXE interrupt may be disabled.

3 Task 3: You will demonstrate the differences between the blocking and non-blocking versions of code you have written in a small simulation that uses both. Create a test using the following pseudocode: Each time through the outer loop you will simulate work for delay milliseconds. You may program up a timer for this timekeeping activity. Then, not more than every 10 milliseconds, print 100 characters (taking about 100 msec of print time). Keep track of the number lines printed, the number of times we loop for each line printed, and the total times through the loop. Run the test for both blocking and non-blocking versions of your USART Printf(), and do this for simulated work times of 0 ms, 50 ms, and 100 ms. for (1 second) { // do some simulated work for 'delay' milliseconds simulate_work(delay); // blocks for delay milliseconds // not more than every 10 milliseconds, print something (useful when delay=0) if(more than 10 ms since last Printf) { // print about 100 chars using either blocking or non-blocking Printf() char *fmt = "%5d%37d %50d\r\n"; if(is_blocking) USART_Printf(USART2, fmt, lines++, loops, millis); else USART_nbPrintf(USART2, fmt, lines++, loops, millis); // update some state variables total_loops += loops; // keep track of loop count over 1 second loops = 0; // reset loop count between prints end += 10; // wait at least 10 ms to print again } loops++;

4 } // Note: when using interrupts, you may need to wait until ring buffer has emptied // using code like the following pseudo code to wait for the ring buffer to empty. while( ring buffer not empty ) ; // Print out final tally for this test USART_Printf(USART2, "Finished printout at %d msec, lines=%d, total_loops=%d\r\n", millis, lines, total_loops); For a 5% bonus in the transmit ISR write one * character to the USART TDR when the test timer has expired. A Note on UART Timing: As you might guess, a 9600 N81 serial connection will transmit data at 9600 bits per second, with 1 start and 1 stop bit used for each byte for synchronization. So you would expect to send 10 bits over the wire for every byte transmitted. Thus each byte should transmit at a rate of 1 ssssssssssss 10 bbiiiiii 1.04 mmmm = 9600 bbbbbbbb 1 bbbbbbbb bbbbbbbb This is easily confirmed by a screen capture from a logic analyzer the time between cursors A1 and A1 is indeed 1.04ms. In the figure, the blue box tells us the letter being transmitted, as deduced by the serial protocol analyzer which looks at the data line. The protocol analyzer samples the data at each white dot. Thus for the 5, the data bits are It is standard for the LSB to be transmitted first (the UART takes care of this for you). Thus reversing the bit order, the 5 = 0b = 0x35. Report: In your report for this specific project you must include the following: For the blocking case you must include a timing diagram showing when each line is printed. For the non-blocking case you must include two timing diagrams. One indicates the foreground activity when data is buffered and simulated work time and a second showing lines being written to the UART. In addition to the demonstration of your project, a brief report is required to illustrate your design. List the trade-offs and assumptions of your implementation. Include printouts for each run of the test, making sure you label what is being tested (for simplicity and integrity, you may want the program to print this for you). Your source code must be included in your electronic submission. This project will be demonstrated in class. The project will not be considered complete

5 without a demo, and a complete electronic report with screen captures and source code in the dropbox. Grading Criteria: - Program Operation - 50% - Program Design - 15% - Source Code Structure and quality - 10% - Report Content including a discussion of the results - 25% - Total credit assignment (e.g. if you only complete Part 1 your maximum score is 30%): Part 1 30% Part 2 40% Part 3 30% Part 3 bonus of 5% as described in Part 3.