• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 2 answers
  • Subscribers 97 subscribers
  • Views 1715 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

BeagleBone GPIO with StarterWare and TFT LCD

Travis Estep
Prodigy 60 points

So, I have been playing with the BeagleBone and Starterware for some time now and today I decided to try to hook up my TFT and play around for a while. This TFT is one that I usually use with my STM32F4 board. It has an 8-Bit parallel interface as it was made to be used with an Arduino. I finally got the code written and everything hooked up and was eager to see this thing refreshing MUCH faster than it does on my STM32F4, but to my surprise, it was about 5 times slower. After researching, I found that most people who are looking for speed from the GPIO are using the PRU module. However, all examples I have seen are using Assembly.  I'm 100% comfortable with using assembly, but am curious as to how this can be used with the StarterWare package. Can my StarterWare app handle the logic and pass on the data to the PRU to update the screen? If so, are there any tutorials on how to load the code into the PRU from within my StarterWare app? Do I need to flash the PRU code onto the SD card and load it from there, or is there a more accepted way to do it? I've downloaded the PRU starter pack with the tools and the examples, but this stuff is getting into an area that I am not at all familiar with.  Any help or guidance provided would be MUCH appreciated.

Also, if there is a way to get more speed from the GPIO without using the PRU, I would also be interested in that as well. I would be more than happy to post a video of this thing running to show just how slow it really is. On a 320 x 240 screen, it takes about 2 seconds to do a full screen update. The same update on my STM32F4 with 168MHz (50MHz GPIO speeds) I can refresh the screen in under half a second.

Thanks in advance.

  • 0
    TI__Guru 65040 points

    Your observation of the accesses to the GPIOs from the Cortex-A8 is a function of the complexity of that CPU architecture and the complexity of the interconnect architecture.  Microcontrollers tend to not have such complexity and built in latencies in a cross-bar switch for the internal interconnect, etc.

    The PRU subsystem of the AM335x on the Beaglebone has direct access to a set of GPIO pins which is why you see examples targeted to use the PRU.

    A possible alternative would be to use DMA to drive writing to the GPIO module, but this would only be appropriate if the GPIO pins to the TFT panel are outputs from the AM335x.  You could trigger a DMA event to perform the back-to-back writing from memory to the GPIO module.  This is just an idea and not one where I have a built up example.

    Regarding your question on whether a StarterWare app can pass data to the PRU, the answer is yes.  The PRU firmware and the StarterWare app would need to agree and align on where these buffers exist to pass information between them.  I don't have information at hand if there are any examples of this at the moment.

  • 0 in reply to BrandonAzbell
    Prodigy 60 points

    That's what I absolutely love about using TI components. You all have been there for me every single step of the way. Thanks so much for the timely response.

    Quick question. What kind of speed increase would I see by using DMA over what I am seeing now? As stated in my original post, I am mostly exploring the chip and attempting to get familiar with all of the peripherals. Getting this TFT to work at a production level is NOT a goal. Would I get more benefit from ditching this TFT and getting one that I could use with the LCD peripheral that is included on the chip? I'm assuming that particular functionality would give me the performance I am looking for. I have seen other developers using StarterWare as a base for video players on the BeagleBone. That alone tells me that what I am looking for is possible. Maybe I just need to change my hardware to something more appropriate for the task I am working on?

  • 0 in reply to Travis Estep
    TI__Guru 65040 points

    Travis Estep said:

    Quick question. What kind of speed increase would I see by using DMA over what I am seeing now?

    I don't have a good feel for what you would actually see by using DMA.  Certainly, you should see several cycles worth of improvement considering the DMA is not executing code to perform the writes to the GPIO registers, but rather perform a series of back-to-back writes to the GPIO registers.

     

    Travis Estep said:

    As stated in my original post, I am mostly exploring the chip and attempting to get familiar with all of the peripherals. Getting this TFT to work at a production level is NOT a goal. Would I get more benefit from ditching this TFT and getting one that I could use with the LCD peripheral that is included on the chip? I'm assuming that particular functionality would give me the performance I am looking for. I have seen other developers using StarterWare as a base for video players on the BeagleBone. That alone tells me that what I am looking for is possible. Maybe I just need to change my hardware to something more appropriate for the task I am working on?

     
    I would suspect using the actual LCD controller integrated in the device would prove to be appropriate, but since I don't know what you expectation is of "performance I am looking for", I will refrain from just blinding saying, "yes, it will".