Announcement

Collapse
No announcement yet.

uVGA-II graphics. Serial or GFX

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

  • uVGA-II graphics. Serial or GFX

    I am currently working on some gauges and have had some descent results. What I have so far is in the linked video. This is using a uVGA-II in serial mode with a pic uP running the show. Its basically displaying a bmp background and then overlaying the image with circles as the indicators. This is not hooked up to live data yet, but it is all controlled from the pic, so as far as the uVGA goes, its live. I think it is turning out decent, but nice needle gauges would be better. The problem with needles it that you have to redraw what was erased with the overlay. Not to mention drawing a simple triangle at different angles is difficult in that you have to recalculate which point to send to the uVGA first depending on the which direction the triangle is pointing. Another untested thought of that, is will it be fluid enough to look smooth when being redrawn. Now on the the point of my post... Is there a better way to do what im trying to accomplish? The hi-res backgrounds look great, but the indicators could use some work. Should I be using serial, or would GFX mode be more powerful without causing me a brain aneurysm learning yet another language?

    http://www.youtube.com/watch?v=nEfsvmiyxkA&feature=related[/video]]

    Thanks

    Jason

  • #2


    Looking good so far.

    The concept for a nice looking needle gauge is to have all the positions as prerendered frames (where the frame is only the size of the gauge) on a uSD card and then just display the relevant frame. This can only be done in GFX and should look quite smooth.

    As soon as you have to send a lot of commands via SGC the serial link starts bogging you down.

    Another language isn't all that hard, expecially 4DGL, since it has bits of C, Basic and Pascal, so everyone should have a fair bit of familiarity with it. Some people get stuck with 'low level' bits/bytes/ascii, not sure why, if you've grasped that in one language you've grasped it in the lot.

    It's up to you, I don't really see why a needle is needed in the 21st century (my new phone has a 5th century BC clock and I'd love to replace it with a modern one)
    Mark

    Comment


    • #3


      Ok, I'll give the 4DGL a shot. Just ordered the programming cable from Saelig. Now, can the serial PMMC be modified and reloaded? Is it possible to pull a PMMC from the Picaso and see the source code? For one, I'd like to use the serial PMMC as a base for what I need to accomplish and second, if its modified, I dont want someone making copies of what I modify should any of these end up out in the field.

      Thanks again.

      Jason

      Comment


      • #4


        The PmmC is 4D proprietary, you cannot view/see/whatever the source code, or alter it in any way.

        The 4DGL code, cannot be read once it is loaded into the flash memory of the display.

        You can swap between SGC (serial) and GFX(4DGL) PmmCs any time you like.
        Mark

        Comment


        • #5


          So the SGC and GFX PMMC's are kind of an onboard interpreter? So when I write in 4DGL, is that part of the PMMC or just what the PMMC runs? Is the 4DGL code protected once loaded as well?

          Thanks

          Jason

          Comment


          • #6


            The PmmC file contains the low level micro-code information (analogy of that of a soft silicon) which define the characteristics and functionality of the device.

            When you write in 4DGL, that is what the PMMC runs.

            The 4DGL code, once loaded, cannot be read.
            Mark

            Comment


            • #7


              Ok, so I have the cable, loaded the GFX PMMC and it works fine. The language isnt too difficult to pick up. Now, new question. From a 'smoothness' standpoint, drawing the needle in a needle gauge. There are three options as I see it...

              1> Draw a triangle, erase it, draw a new triangle, etc.
              2> Call frames from a media file, as you have previously suggested.
              3> Use sprites even if it requires multiple sprites to align correctly.

              Is there a technical reason that any of the 3 would be smoother than the others?

              Thanks again for the info. You have been most helpful.

              Jason

              Comment


              • #8


                If you don't have a 'background' that needs refreshing 1 is the easiest and fastest.

                2 will enable a background to be maintained 'easily'

                3 will be harder to program than 2 and will still have the issues of 1.
                Mark

                Comment

                Working...
                X