Announcement

Collapse
No announcement yet.

How to use spiflash_LoadGCFImageControl(SPI0, USD_ENABLE) ?

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

  • How to use spiflash_LoadGCFImageControl(SPI0, USD_ENABLE) ?

    As I can see, when I create a new Visi program for Diablo16 (uLCD-90DCT) there is generated a new one section:

    // Uncomment the following if Flash and Flash based GCF images, fonts or strings used.
    /*
    // if SPI0 (Traditional uSD SPI port) Used
    spi_Init(SPI_FAST, SPI_ADDRESS_MODE4); // use SPI_ADDRESS_MODE4 if Flash memory is >16MB
    // if SPI1 (other SPI pins) Used
    // pin_HI(EnablePin) ; // EnablePin is PA pin connected to SPI_CS
    // pin_Set(PIN_OUT,EnablePin) ; // EnablePin is PA pin connected to SPI_CS
    // SPI1_SCK_pin(FlashSCK) ; // FlashSCK is PA pin connected to SPI_SCK
    // SPI1_SDI_pin(FlashSDI) ; // FlashSDI is PA pin connected to SPI_SDI
    // SPI1_SDO_pin(FlashSDO) ; // FlashSDO is PA pin connected to SPI_SDO
    // SPI1_Init(SPI_SPEED15, SPI8_MODE_5 x+ SPI_ADDRESS_MODE4x, EnablePin) ; // add SPI_ADDRESS_MODE4 if Flash memory is >16MB, EnablePin is USD_ENABLE or PA?
    spiflash_SetAdd(SPI0, 0x0010, 0);
    hndl := spiflash_LoadGCFImageControl(SPI0, USD_ENABLE); // SPIx is SPI0 or SPI1, as appropriate, EnablePin is USD_ENABLE or PA?
    */

    It looks that it can be very useful to load to the uSD card a newly created .gcf RAW file with a full binary structure.
    But I'm unable to communicate with uSD card by commands like spiflash_ReadByte(0, SPI0, USD_ENABLE)) and spiflash_Read(b, 512, SPI0, USD_ENABLE).
    And prepared command spiflash_LoadGCFImageControl(SPI0, USD_ENABLE) is nonfunctional too (I loaded .gcf to the RAW uSD card at correct offset).

    Is it a bug in comments and manual and it can be functional only on SPI1..3 interfaces or I make something wrong?
    Does anywhere exist any functional example or demo for these commands with use of standard uSD card through SPI0?

    Workaround can be usage of:
    - file_LoadImageControl(fname1, fname2, 2), but there must exists FAT16 partition on the uSD card with .dat file (and .gci file is loaded as RAW at correct offset).
    - media_Image(x, y); media_Video(x, y); media_VideoFrame(x, y, frameNumber); commands, but addresses/offsets and x,y positions are not generated as constants in the IDE and should be read from generated .dat file.
    - make a program to save data structures created by
    file_LoadImageControl(fname1, fname2, 2) from memory to uSD card by media_WrSector command and use them later, but this is not a standard solution.

    Thank you for any assistance

  • #2
    Hello Miroslav,

    The SPI interface is used for Flash storage, meaning you will need a flash chip to be connected to the Diablo pins. Once this is done, you have to change the file system in the 'Project' tab in Workshop4 to flash like so:

    Click image for larger version

Name:	fetch?id=74302&d=1605741380&type=full.png
Views:	51
Size:	6.7 KB
ID:	74307
    Click image for larger version

Name:	fetch?id=74303&d=1605741447.png
Views:	44
Size:	77.1 KB
ID:	74308

    Here you can select GCI Flash File Storage and which pins you will use for the SPI bus.

    After this is complete, you can comment out the code scaffold and adjust them according to what you have set in the options above.

    I have attached a sample project that uses the SPI interface for a demo program, keep in mind this demo project is for the 4Discovery 5.0 which has a built-in SPI flash chip that connects to the pins outlined above.

    If you would like to know about the SPI functions, I recommend you look at the Diablo16 Internal Functions Reference Manual. Look under the SPI Control and SPI flash functions sections to get an understanding of how it works.

    Hopefully this information should help,
    Adem

    Comment


    • #3
      Hello Adem,
      yes, it looks like to be functional on SPI1 port (I have no opportunity to test it).
      But my question was on usage on SPI0 port, where is connected standard uSD card as it is mentioned in the File System dialogue, generated source code and Diablo16 internal functions manual.
      When I modify your code for SPI0 port and upload generated .gcf file from raw sector 0x580000 (*0x200 = address 0xB000 0000), the spiflash_LoadGCFImageControl(SPI0, USD_ENABLE) command return NULL.

      Modified code is attached.
      Where is the problem and how to make it functional?
      Thanks
      Miroslav
      Attached Files
      Last edited by Miroslav Kovar; 1 week ago.

      Comment


      • #4
        Hello again Miroslav,

        It sound like you are trying to use the uSD card as a SPI Flash device with the SPI0 port, the rest of my reply is based on this assumption so please correct me if I am wrong. If I am right, however, uSD and SPI Flash commands are completely different, and as I said in my last message, you will need a flash chip connected to the SPI0 port in order to use the SPI Flash commands.

        A majority of 4D Products, including the uLCD-90DCT, have the uSD on SPI0, meaning that you should instead connect your flash chip to the SPI1 ports so programs like the sample one I sent can run.

        Can I inquire about your desire to use the uSD card in this way? It is uncommon and seems like extra effort when you could use the traditional method of uSD storage and file access. If you would like to access the uSD card by sector, I would instead recommend using media functions, which are outlined in section 2.20 of the Diablo16 Internal Functions Reference Manual.

        Kind Regards,
        Adem

        Comment


        • #5
          Hello Adem,
          yes, you are right.
          I'm trying to use SPI0 port for access standard uSD card, as it is HW conected in standard displays and as described in Diablo16 datasheet "Note: The additional SPI channel (SPI0) is dedicated to memory cards and cannot be reconfigured for alternate uses."
          And as it is described in Diablo16 Internal Function Manual at command spiflash_LoadGCFImageControl(spi#, Enablepin): "The SPI interface to which the Flash memory chip is located SPI0 for the uSD port, or SPI1, SPI2 or SPI3. | The enable, or CS pin for the Flash memory chip PA0-PA15, or USD_ENABLE for the uSD's enable pin."
          When I want to speed up video playback and other graphic processes, I decided to use RAW format of graphical data. But why to use text file .dat in FAT16 which should be additionaly modified by hand to absolute addresses (from generated offsets), and not a binary file .gcf which includes every needed information uploaded to choiceced absolute address of the uSD card?

          As I can see or think, there are a lot of bugs, not tested ideas of a solution or not logical procedures in EVE and IDE, so this described usage of SPI0 channel by this way is only one of them, don't it? The same way as in current PmmC non functional file_LoadImageControl in mode 0, no correct tracks in Internal Widgets, touch and corresponding value modification solved by programming and not by standard functions etc., etc.

          Now I made my own function to create data structures like file_LoadImageControl directly from .gcf file uploaded to RAW uSD card and even it is written in EVE, it is two time faster than original file_LoadImageControl in mode 2. It's terrible.

          I hope at least, you don't modify structure of generated .gcf in next IDE release ...

          Best Regards
          Miroslav

          Comment


          • #6
            Miroslav,

            The .GCF file system is designed for Flash, not uSD. There are at least two reasons why it is not suitable for uSD. The FAT/RAW system split that has existed for ages is designed for uSD. The FAT/RAW split technique will have the same performance as GCF, there is no need to try shoehorning one into the other.

            Similarly, the rest of your supposed issues, and performance comments appear to display a combination of a lack of understanding of the use of certain functions and/or the underlying limitations. Regardless calling something 'two times faster' without more information is just misleading. Have you taken the time to report them individually, so that we can instruct you in the correct usage and/or fix any real problems?
            Mark

            Comment


            • #7
              Mark (& Adem),

              Ok, I understand your information that .GCF is created for flash chips and not uSD cards primarily, but:
              - As our project grows we got to know that longer video files or video files at the end of .gci file slows down in mode 1 (and in mode 0 too). For example from 67 ms to 160 ms per frame!
              - For bigger .gci file it takes some seconds (2 GB takes 4,5 s) to load it in mode 1. Faster mode 0 is in current PmmC R24 non functional (it displays garbage only). I reported it at 22.9.2020.
              - Our standard .gci files with sizes of about 13 MB take 640 ms to load in mode 1 so any switching between them noticeably freezes the whole display.
              - But is there any possibility to create correct .dat file for mode 2 automatically? I don't think so, or not? Or is there any utility or IDE function for that? And utility for writing .gci file to RAW part of uSD at predefined offset? Yes File Transfer Utility is able to do it after manual sector calculation, but only by slow transfer. And in this utility there is again written information about SPI0 and uSD in Flash settings dialog: "SPI0 (Replaces uSD card)".
              - So any change in graphics needs loading of a new .gci file to a correct RAW address and reprocess .dat file for mode 2 again and again.
              - I know, it can be replaced by usage of media_... functions, but in the IDE there is no support for getting at least indexes and positions of objects, so the only usable way is to reprocess generated .dat file again.

              As real examples about the speed of loading .gci or .gcf file:
              3 objects in file with overall size 200 kB - loading in mode 0 takes 15 ms, mode 1 takes 24 ms, mode 2 takes 14 ms, our .gcf load written in 4DGL takes 7 ms.
              209 objects in file with overall size 13 MB - loading in mode 0 takes 84 ms, mode 1 takes 637 ms, mode 2 takes 160 ms, .gcf load written in 4DGL takes 152 ms.

              Problems with Internal Widgets I reported immediately after they appear in IDE as a demo a year before and lastly at 23.9.2020...

              Best Regards
              Miroslav

              Comment


              • #8
                The .dat file cannot be automatically created as Workshop cannot possibly know where the RAW partition starts on your uSD card.

                You can use ScriptC to copy the files to the uSD 'faster' when the uSD is plugged into your computer.

                I thought there was a more recent thread on this in the forum, but I can only find this one at the moment https://forum.4dsystems.com.au/node/38066

                As far as I am aware everything that was definitely classed as bugs in the Internal widgets was and has been fixed. If there is anything outstanding, please email me with information and/or examples.
                Mark

                Comment


                • #9
                  It will be very fine to have possibility to set needed RAW address directly in IDE, ideally as a constant in written code (in .4DG file or .inc) to have possibility to use the same constant in the program.
                  It will be useful for .GCI and .GCF too. And second constant can be for mode definition, so there will be no problem for IDE to generate .dat file with correct offsets directly...
                  And it is not important if this will be set as a constant written by user in code or set in any menu in IDE and the constant will be generated in ...Const.inc by IDE.

                  I think it will be very useful to generate every constants into ...Const.inc by IDE from graphical definitions like positions, dimensions, colors, min. & max. values, touch regions etc. for example in a form of iObject_min, iObject_xpos, iObject_TouchStart or iAlias_Color etc. So they can be used in a code and after any graphic modification it doesn't need to modify the code synchronically.

                  Now I get to know that when I compile .4DViSi with output to FileSystem FLASH, it reuses graphical objects with the same graphical definition and so creates much smaller .gcf file and .gci file too than with output to FileSystem FAT. It's very fine improvement! Thank you for that very much.

                  Thank you
                  Miroslav

                  Comment


                  • #10
                    The RAW address in the IDE has been taken on board.

                    I think it will be very useful to generate every constants into ...Const.inc by IDE from graphical definitions like positions, dimensions, colors, min. & max. values, touch regions etc. for example in a form of iObject_min, iObject_xpos, iObject_TouchStart or iAlias_Color etc. So they can be used in a code and after any graphic modification it doesn't need to modify the code synchronically.
                    What are you referring to here exactly? Are you referring to the #DATA definitions for Internal and Inherent widgets?

                    The duplication of widgets in the GCI files (and the large size of fonts) is done in an attempt to reduce the speed in which uSD cards become read disturbed.
                    Mark

                    Comment


                    • #11
                      Originally posted by ESPsupport View Post
                      The RAW address in the IDE has been taken on board.
                      What do you mean by that? Is there any possibility to set target RAW address of .gci or .gcf file in the IDE now? Ie. for automatic offset generation in a .dat file, RAW upload by IDE via RAWCopy and as predefined constants aHi and aLO that can be used in the spiflash_SetAdd(SPIx, aHi, aLo)?

                      Originally posted by ESPsupport View Post
                      What are you referring to here exactly? Are you referring to the #DATA definitions for Internal and Inherent widgets?
                      No, for Internal and Inherent Widgets with definitions in #DATA section there is no problem to use these directly (except specific offsets for start and end of track bar, text of the value, actual value position etc.).
                      But IDE didn't use these definitions in auto generated code nor is able to update self generated code - for example posn := gfx_XYrotToVal(x-156, y-204, XYROT_SOUTH, 45, 315, 0, 100);. Why not?

                      It is very important mainly for precomputed graphical widgets like Buttons, Gauges, Inputs, Labels, Primitives and System/Media. For example to auto generate not:
                      posn := gfx_XYlinToVal(x, y, 1, 254, 489, 0, 200) ;
                      img_SetWord(hndl, iTrackbar1, IMAGE_INDEX, posn);

                      but

                      value := gfx_XYlinToVal(x, y, 1, iTrackbar1_posX + iTrackbar1_ofsStart, iTrackbar1_posX + iTrackbar1_width - iTrackbar1_ofsEnd, iTrackbar1_Min, iTrackbar1_Max) ;
                      img_SetWord(hndl, iTrackbar1, IMAGE_INDEX, value - iTrackbar1_Min);

                      and in ...Const.inc file section something like this:
                      #CONST
                      iTrackbar1_posX 240
                      iTrackbar1_ofsStart 14
                      iTrackbar1_width 278
                      iTrackbar1_ofsEnd 29
                      ...
                      iTrackbar1_Min -100
                      iTrackbar1_Max 100
                      ...
                      #END

                      After that there will be no problem use these constants in the user code (colors, values, tracks etc.).
                      And primarily: any change of position, dimension, color, range etc. in graphical design doesn't need to recreate or modify one time written code ...
                      (The same can be useful for export to other programming languages in ViSi_Genie mode, I think.)
                      (And as a total bonus can be parametric graphic definitions, so that the user can define it's own constant, for example MyColor1, and use it as a color for buttons, backgrounds, gauges tracks etc.)

                      And for calculation of a new actual value position you can then use something like that (for draw an arrow or write text value at current value position):
                      pos := gfx_XYlinToVal(value, 0, 1, iTrackbar1_Min, iTrackbar1_Max, iTrackbar1_posX + iTrackbar1_ofsStart, iTrackbar1_posX + iTrackbar1_width - iTrackbar1_ofsEnd);

                      Originally posted by ESPsupport View Post
                      The duplication of widgets in the GCI files (and the large size of fonts) is done in an attempt to reduce the speed in which uSD cards become read disturbed.
                      Yes, it sounds practical, but what do you think is read from uSD card more often: background images or states of widget, buttons, LEDs etc.? And what occupy more space? I think it will be better to test read errors, may be to compute CRC and use more copies of the same smaller data and in time of corruption to switch to a new one and may be to repair the previous one ...
                      (This is what we are working on now.)
                      Last edited by Miroslav Kovar; 1 day ago.

                      Comment


                      • #12
                        To "take something" on board means "to consider an idea, problem, or situation and try to deal with it".

                        The 'Paste code' button pastes the minimum code required. For example the 'but' code you showed takes 15 bytes more codespace than the first code. Seems odd to be encouraging people to waste code space.

                        Unfortunately read disturb is a much more complex issue than it appears on the surface. eg data can be 'disturbed' without being read, this means any protection / recovery mechanism needs to understand the underlying architecture to be able to see where a disturbance could occur.

                        Mark

                        Comment


                        • #13
                          ok, sorry, I've never heard that phrase.

                          I agree that the compact form with numbers looks simpler, but I think only at first sight and until the first change of graphic design.
                          f the IDE pre-compute constant calculations during compilation like other compilers, the resulting length and speed of the code would have to be the same. However, I note that we have already discussed this issue together, mainly due to the higher range and possible accuracy of these calculations.

                          Yes, I agree with you about read disturbing, so we are working on more complex solution...

                          Miroslav

                          Comment


                          • #14
                            Again about usage of constants or numerical values generated by IDE:
                            The solution can be in:
                            1. improve Workshop compiler to make constant calculations during compilation, so direct numbers or numbers computed from constant calculations result the same code.
                            2. in ...Const.inc generate more redundant constants like iTrackbar1_Start := iTrackbar1_posX + iTrackbar1_ofsStart; iTrackbar1_End := iTrackbar1_posX + iTrackbar1_width - iTrackbar1_ofsEnd; iTrackbar1_Right := iTrackbar1_posX + iTrackbar1_Width; etc.
                            3. Write it to documentation as a tip for speed and code size improvement and let users to define their own constants computed from these generated (equivalent to 2.).

                            Regards
                            Miroslav

                            Comment

                            Working...
                            X