Announcement

Collapse
No announcement yet.

Display Image-Icon timeout?

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Display Image-Icon timeout?

    Working with uOLED-96-G1 SGC. Mostly it works fine. However, I'm trying to increase speed for rendering a large graphic. Draw Image-Icon ('I') takes about 160ms even with highest legal baud (230400), and most of this is communication time. To speed things up, I'm tying to use '@I' (Display Image-Icon from Memory Card) command instead.
    I have been able to load images onto a uSD card into subsequent blocks of sectors. If I single step through the code, it works perfectly. The "ACK" for the command is almost immediate -- 0 or 1ms based on my 1ms timer resolution.
    Problem is, if I let the code free-run, it displays a few images (typically between 5-10) and then it hangs. I am guessing that there is some additional timeout that needs to be met in addition to the ACK timeout, perhaps the time to stop the block read on the uSD card. But I found no information about this in the manual, and the indication from messages here on the forum is "the card is always ready for a command as soon as you receive the ACK".
    It appears to me this latter statement isn't true, but I'm wondering how I can ensure proper behavior without having to reset the display periodically.
    Thanks,
    Greg Nelson

  • #2


    For what it's worth, by tinkering with the delay between commands, I've come to the conclusion that 14ms is a sufficient delay and 13ms is not. I'm using a 1GB Transcend uSD card, if that matters.
    Oddly, around 12-13ms, I am seeing some other "garbage" being rendered onto the display in place of (at the upper lefthand corner of) the data that I want to display. Perhaps something in a buffer that's still getting streaming data in from the uSD from the last read?
    Obviously 15ms is way better than 160ms, but I'm uncomfortable about the potential variability with vendor, sector number, temperature, etc.
    Greg

    Comment


    • #3


      The ACK is sent once the command is complete, as soon as you receive it you can send the next @I command.



      Is it possible the problems you were seeing were happening when using the Draw Image-Icon ('I') command at high speed? If so, this is a different issue, caused by the data coming in so fast that the draw image command is being swamped.
      Mark

      Comment


      • #4


        I'm only sending @I (draw image) commands, and I'm sending them as fast as the device will let me, in other words starting a new one as soon as I get the ACK for the previous one. I'm not sure what's happening at a technical level when you say "the draw image command is being swamped." Maybe the serial command processor is done but the data is still being piped out to the GRAM?
        I assumed that once I got the ACK, all processing of that command was complete and I could issue any other command (including another @I) immediately. If not, then how do I tell programmatically when it's ready to receive another @I command so I ensure that the communication never fails? (Once it fails, I have to reset the whole module it seems.)
        Thanks,
        Greg

        Comment


        • #5


          As I said, as soon as you get the ACK you can send the next command.



          Check that you aren't sending more than one command at a time accidentally (either a valid or invalid command) this would cause two responses to be sent and trick you into thinking a command had been ACKed that hadn't.



          Can you 'precisely' recreate this?



          If so check everything you have sent for possible 'errors'



          If you still can't work it out post the command stream here along with the speed you are communicating at and we will try and recreate it here
          Mark

          Comment


          • #6


            You nailed it. I had two problems. Autobaud ('U') was returning a garbage character before the ACK character, which I wasn't eating up correctly. Then I was sending '0' (0x30) where I should have been sending 'O' (0x4f) to set the opaque text mode. I would get the ACK for the Autobaud for the '0' and the NAK for the '0' for whatever followed, and was off by one.
            The 14ms is pretty close to the actual time it was taking for the '@I' command to complete, so if I was out of sync because of the previous errors, the 14ms delay would let the command complete, and I'd get to send another command which remained out of sync. Without the 14ms delay, I was sending another '@I' before the first completed, and eventually it got really unhappy with that.
            Thank you,
            Greg Nelson

            Comment

            Working...
            X