Announcement

Collapse
No announcement yet.

GRAM access

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

  • GRAM access

    Hello,

    In building an EFIS, I'm trying to read for SD with file_Seek then file_Read with destination = 0: nothing happens

    Then I try do just do a write of red color: still nothing

    No way to have GRAM write access working:


    70DT CLB

    Code:


    result := disp_setGRAM(IMGX1, IMGY1, IMGX1+179, IMGY1+55);
    putnumXY(700, 250, DEC, result );

    disp_WrGRAM(RED);

    result := file_Read(0, 20160 , handle);
    putnumXY(700, 270, DEC, result );



    The number of pixel of gram area is ok
    The number of bytes read is OK

    But... nothing, even the disp_WrGRAM(RED) does nothing.


    Any clue?
    François

  • #2
    Hello Francois,

    In the above example, the GRAM window would no longer be available as you have another gfx function 'putnum' straight after setting the window. Could you try it like this and let me know if it works.

    result := disp_setGRAM(IMGX1, IMGY1, IMGX1+179, IMGY1+55);
    result := file_Read(0, 20160 , handle);
    putnumXY(700, 270, DEC, result );

    Best regards

    Paul


    Comment


    • #3
      Hi Paul,

      Seems to work better.

      Do you confirm I can have a window of 40k (180x112) and have a read of 40k in one pass?

      Also, what the format I should read from disk? Raw RGB on 16bits, high or low first ?


      I intend to have a Java program building the 20000 possibilities of the AI positions (almost 1GB file on the SB card), that's the reason I can't use the custom images

      Comment


      • #4
        Hi Francois,

        I havent't tried an image of that size using this method but I will give it a go today.

        The format is RAW RGB565 16 bit colours. It is stored MSB first.

        I have done this using custom images on the SD card but mine only went 60 degrees in all directions and was under 10000 images. I too had an external program creating all possibilities, it was a lot of work to add all the images into the widgets and I ended up with a GCI file of over 3GB and works well.

        Best regards

        Paul

        Comment


        • #5
          Still struggling to make GRAM work...

          I have to seek the file by number of frames * size of a frame (80000 bytes = 200*200 pixels): this looks to be impossible as only umul1616 is available to do the calculation, and 80000 doesn't fit in 16 bits. I have two files with 18700 frames in each. If umul doesn't accept unsigned int (65535) at least in one of the members, there is no solution

          Still nothing shows in GRAM

          KR

          François

          Comment


          • #6
            Why aren't you using the routines supplied for the purpose? eg img_Show(), etc.

            Doing it 'manually' / longhand will lead to far slower displaying than using the supplied routines.

            If you really want to go down this slow path have a look at file_Index(), it will do the multiplication and positioning for you.
            Mark

            Comment


            • #7
              the standard routines would mean I have to select in Visi about 37000 images (so more than 16 bits signed) of 80000 bytes each:
              - Is it possible ?
              - Won't the editor hang ?

              If this is possible I'll try that

              Thx

              François

              Comment


              • #8
                And is recordnum in file index limited to signed 16 bits?

                Comment


                • #9
                  Video frame count is 16 bits unsigned, so that shouldn't be an issue.
                  Not sure how you created your file, but if you created it in the GCI format, then you can 'just use it'.
                  The editor shouldn't crash, the build will take a while, that should be about it.
                  Mark

                  Comment


                  • #10
                    And even this does not work:

                    gfx_Set(SCREEN_MODE,LANDSCAPE) ;
                    disp_setGRAM(IMGX1, IMGY1, IMGX1+199, IMGY1+99);
                    disp_WrGRAM(RED) ;

                    With IMGX1=140 and IMGY1=95


                    So there is an issue with how to use GRAM functions, may you send an example?

                    Comment


                    • #11
                      Your example should work just fine, you should have one pixel of red at 140,95
                      Mark

                      Comment


                      • #12
                        Using custom images is totally unmanageable:

                        - too many images: VISI hangs
                        - Sort order is not respected (random files to be moved... imagine with 37000 entries)

                        No other choice that making the GRAM work (I don't even have a single red dot)



                        OR


                        Building .dat and .gci by myself, but I would need the format. Could be the best solution as it would allow to update the full image set by program from the master psd files.

                        May you publish it ?

                        Comment


                        • #13
                          It's in the FAQ section https://forum.4dsystems.com.au/forum...isplay-modules Q4
                          Mark

                          Comment


                          • #14
                            OK Thanks, no info about .dat file, is it relevant ?

                            Comment


                            • #15
                              OK, could retrace it by analysing, this is text with lines as such:
                              "gaugename" offsetLowWordHex offsetHighWordHex Xhex YhexCRLF


                              Will try to build my own cgi & dat files, keep you posted

                              Comment

                              Working...
                              X