This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Part Number: TM4C129XNCZAD
I am reaching some timing limit for my LCD display. The TM4C129X LCD module is set to read from external SRAM through the EPI bus. The graphics libarary is configured to write to the same SRAM through the EPI bus.
Writing 1200 pixels seems to be my problem. Trying to writing this number of pixels results in an LCD interrupt, LCD_INT_UNDERFLOW. Writing 1,100 pixels give no problems. I am using 4BPP so writing a pixel is actually a read-modify-write because I only change 4 bits of a byte at a time.
Is there a way to prioritize reads from the EPI bus? Rendering the current frame is much more important than drawing the next frame. I would like a way to tell the writes to "chill" with the read FIFO is running low.
Other ideas are welcome.
In reply to Ralph Jacobi:
Hi Ralph, Could you seek out a more objective answer? Everything is slow or fast compared to something else. 30 miles an hour is fast for a bicycles, but slow for a car on the interstate. These terms don't mean anything without context. If you insist a more expensive chip is essential, then I need an objective bandwidth to justify cost and effort. The RAM speed should work by the numbers. The LCD screen needs 12 megabytes per second to avoid underflow. The EPI bus is configured for 60 megabytes per second. The EPI bus spends ~80% of its time idle while the screen is being fed pixel data. Why can this idle time not be used efficiently for writing new data? This idle time can be used for writing ~500 bytes before the FIFO runs dry. Why can't I pend on a semaphore when the FIFO is low? What is stopping this configuration from working?
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to Peter Borenstein:
Sorry for the delay, wanted to fully verify the following information before commenting.
The TivaWare API is correct and also is in line with the datasheet if you look at the EPIBAUD register on Page 895.
Peter BorensteinWhat is actually happening when the system clock is faster than 60MHz and you write EPIDividerSet(EPI0_BASE, 0);?
Unfortunately, by doing this you are actually causing the device to operate out of specification in this situation. The dividers must be utilized correctly to get the correct frequency per data sheet specifications. The way the library API's are setup make this dependent on the user to do so (whether that's the right approach is a different story, but that is just how it is setup with the API). So that line is actually forcing the EPI Clock to operate at 120MHz and thus out of specification.
While it may be the case that one device still works with the out of spec configuration, there is absolutely no guarantee such operation would be retained across devices in production. Therefore, I'm sorry to say but that is not a reliable solution to the issue you are facing with the timing constraints...
Ralph, Could you clarify the timing retirements? The datasheet gives different EPI max speeds for different modes and doesn't specify Host Bus 8 mode, which is what I use.
From the datasheet, Table 32-39 says SDRAM mode has max 60MHz. Table 32-42 says General Purpose has max 60MHz Table 32-43 says PSRAM has max 50MHz. Table 32-41 discusses Host-Bus 8, but gives no max. Host Bus 8 mode may not share this limit because the clock signal is not used in the external interface. Compare figure 32-20 with figure 32-21. There clock signal is not used! I think this reasoning is my saving grace. The lower 4 bits of EPICFG define these modes.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.