No announcement yet.

Change resolution and version problem

  • Filter
  • Time
  • Show
Clear All
new posts

  • Change resolution and version problem

    Hi, i've got 2 problems with my µVGA Picaso module.
    First one, if I change resolution to VGA (or QVGA) some commands are executed not quickly or module reply with ACK but the command does not run (for example if I want to draw two rectangles the second one is not drawn or if I change the background color next commands are executed very slowly).
    Second one, if I send the command 0x56 0x00 to know the device version, the Picaso sand back a NAK or some strange chars like 0x87.

    Can someone help me?

  • #2

    yuhuuuuuuuuuuuu! No one can reply to me?


    • #3

      Hello, I have the same problem. Did you find a solution for this?


      • #4

        The Power-Up default is mode = 0 (QVGA). When it is desired to change the resolution and this command is executed, it must be followed by the Auto Baud (‘U’) command. A resolution change changes the internal clock of the ?VGA which also affects the Baud Rate of the Serial Port hence the reason for resending the Auto Baud command.

        Please make sure you sent the Auto-baud command after changing the resolution.

        Also, when you change the resolution, you should make sure the dimensions you are setting for the rectangle are within the boundaries. Say, with QVGA (320x240) if you draw a rectangle with x1=10, y1=10, x2 =255, y1 =255 you will be exceeding the Y-resolution by 15.

        The Device/Version command is not implemented on the uVGA Picaso MD1.


        • #5

          Thanks 4dTechSupport,

          I am actually sending the 'U' auto baud detect as per the manual, but do not always get a valid ACK back which may be due to the previous ACK being wrong, which comes from the change baud command - this may be due to the following and so can you please clarify these steps:

          1. When the resolution change serial command is sent, does the PICASSO send back an ACK to acknowledge it has received the change resolution command or does it send an ACK once it has actually changed the resolution?

          2. When it sends this ACK, at what baud rate does it send this ACK - does it send it at the original baud rate or at the new baud rate matching the new clk rate? If it is at the new clk rate then I would not be able detect a valid ACK and so would get stuck in a loop looking for an ACK before I proceed to the next stage, which is when I send a 'U' to reset the baud rate.

          In the firmware, would it have been easier to note the previously set baud rate and within the change resolution command, once the clk rate has been changed, simply change the relevant parameters to reset the baud back to what it was before the change and then send an ACK at the originally set baud... just a thought, as all of the ACKs are at the running baud rate.

          I hope you can assist with my questions



          • #6

            Hi Steve,
            See the log of serial commands sent to the uVGA Picaso MD1 and the responses back from the processor. Note, Baud rate is never changed during the course of complete test. After changing the resolution when you send Autobaud command, you receive Ack twice.

            Attached files


            • #7

              Hi Bilal

              The log clears it up and explains what is going wrong. In your manual it specifically stated that each command to the Picasso receives an ACK (or NAK) back and so I have a universal routine to send a command then return to carry on with other processing duties as I cannot afford to be held waiting for the Picasso to complete its task. When the next command is needed to be sent, I first check that the Picasso has become free by testing for the last sent 0x06 and then proceed. I was waiting for an 0x06 coming back after the resolution change (as it is a specific command as implied in the manual) before sending the next baud rate setting 'U' and then separately looking for its 0x06 coming back.

              Do you have a method of testing if the Picasso is free for it to receive a new command, eg by the host sending a specific command and looking for specific reply as I cannot afford to sit in a loop waiting for the Picasso to execute the last command when there is such as reading ADCs, etc, to get on with.