• State
  • Locked Locked
  • Replies 16 replies
  • Subscribers 33 subscribers
  • Views 2065 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

GrLib Graphical Editor

user4221161
Expert 1050 points
Other Parts Discussed in Thread: SEGGER

Hello Folks,

is there a graphical editor for the GrLib? I mean a surface where one can define "Screens" and place Items on the screens and the wizard generates the
tree structure.


I haven´t found something like that. Is it just economicaly not usefull or are there technical reasons?

best regards!

  • 0
    Guru 47900 points

    user4221161 said:
    Is there a graphical editor for the GrLib?

    I believe yours to be a significant question.   I do not believe this vendor offers such a "surface."  

    As one in the "Display Biz" there may well be reasons operating against your, "Surface Defining" approach:

    • Such a fundamental, general approach requires the investment of time, funds, talent to create
    • Any individual vendor may be unable to recognize a quick, sizable benefit from such a creation
    • Are not (other/similar) methods (already) in existence?
    • Should one vendor create such "surface" - how can they "lock it down" so that (other) MCU users cannot benefit?

    PC Paint stands as one long-standing (other) method used for more than a decade by those sharing your desire.   The .bmp file it produces though - simply "eats" memory - thus it has fallen into disfavor w/many.

    Several vendor's w/in this "M4" MCU class include a .jpg "engine" w/in the MCU.  (M7's capability improves, as well)    And too - some M4's provide effective "Graphic Accelerators."

    Multiple firms offering, "Complete Display Sub-Systems" include just what you seek - yet the software & hardware have been (near) "locked" to the firm's specific display & applications.   Your survey of such products are sure to trigger ideas - some of which - you may be able to exploit...

  • 0
    TI__Guru**** 244400 points
    Hello user4221161,

    No there is nothing like a graphical editor for grlib. The only technical reason is the effort v/s return. A lot of customers have their own graphics library which they have used in the past and intend to go with it. Also a Graphical editor requires a lot more code processing and the interactions with sensors and actuators since a graphic UI on a microcontroller is not a place where we would be expected to perform fancy graphics.

    Solutions however do exist for graphic UI and editor from 3rd party's. We are working with them to embed TM4C into the code offering.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Guru 47900 points

    Amit Ashara said:
    We are working with them to embed TM4C into the code offering. 

    Such "working with" would receive major assist with the inclusion of .Jpg engine, Graphic Accelerator, far faster System Clock - would it not?...

  • 0
    Guru 27665 points
    You are moving into the realm of an HMI. There is a vendor who does offer such an item prepackaged as an IC (with a serial interface and an LCD interface). There are also SW vendors (Segger comes to mind but there are probably others) that produce graphic libraries with such support.

    Robert
  • 0 in reply to Robert Adsett
    TI__Guru**** 244400 points
    Hello Robert

    TouchGFX is another vendor, but there are certain requirements that limit to a few micro's

    Regards
    Amit
  • 0 in reply to Robert Adsett
    Guru 47900 points
    Indeed Segger comes to mind (yet biased to higher performing - M4 MCUs).

    When last I looked Segger had a rich library - but NOT the "Drawing Surface" which was poster's quest... Has Segger included such "surface?"
  • 0 in reply to cb1
    Guru 27665 points
    Look at emWin GuiBuilder. Looks like what I'd expect. The OP may have different requirements.

    Robert
  • 0 in reply to Robert Adsett
    Guru 47900 points

    The GUI Builder you reference does appear rather complete - although it may not (fully) meet poster's "Drawing Surface" expressed desire. (that sounds very much like PC Paint)

    I just reviewed that product's Graphic feature list - they are extensive & far exceed that offered here. Biggest weakness we note is lack of (any) support for .jpg files and uncertain ability to properly exploit the "graphic accelerator" present w/in other M4 devices.

    BMP files saved (only) as C files insure that MCU memory is "burned" and that "live" data (such as .jpg camera data) cannot be efficiently handled. (perhaps not handled - at all!)   Our firm has long found it far better to "store" graphic image data, "Off MCU" w/in external memory which proves far more efficient than requiring an MCU re-programming - upon each/every image update.   It should be noted that image storage was not expressed as a poster "concern" - his central thrust was the ease & efficiency of screen drawing creation...

  • 0 in reply to cb1
    Guru 27665 points
    I keyed in more on screens. Placing items of screens (where the screen is the drawing surface) is pretty much how HMIs are programmed.

    For such the images are small (buttons and icons) so the memory limitations are not a great concern at least as long as the same icon doesn't get multiple copies when repeated.

    If that's the use though, I'd be inclined to go for a more prebuilt option for smaller quantities. With the additional advantage of offloading the display handling from the control micro.

    Robert
  • 0 in reply to Robert Adsett
    Expert 1050 points
    Yes, i thought it´s basically an economic issue. Of course i see, that it takes afford to do that and brings no direct return.

    My idea would be, that the wizard creates the tree and returns a pointer to each "screen-structre". Similar like it is done in Qt with the ui-> pointer. Damn, if i had more time it would be really interesting to make a GrLib Editor :)
  • 0 in reply to user4221161
    Guru 27665 points
    Don't completely discount the idea of just buying an HMI. A few hundred dollars doesn't buy a lot of design time.

    You trade off the SW and electrical design for the display for implementing something like Modbus (most HMI's understand Modbus RTU and will act as masters). I'd expect a net time gain myself, your mileage may vary.

    Something like Amulet represents a middle ground.

    Robert
  • 0 in reply to Robert Adsett
    Guru 47900 points

    While (that) brand represents a "middle ground" - tis an (old) middle ground!

    Latest/greatest, high-performing TFTs (i.e. "MIPI-DSI") cannot be supported by such, "locked in (past) time" display chips.
    Dawns - as we're here - "locked in (past) time" inflicts not (only) display chips!

  • 0 in reply to cb1
    Guru 27665 points
    It's still probably younger than many HMIs. They don't tend to follow a frantic update path and only the high end needs high performance.

    The limiting factor tends to be how fast you can get data from the unit. Any until you get fairly information dense that's not a limit either.

    The number of screens, ease of layout, how easy it is to configure network access, cost, environmental factors usually loom larger than display performance.

    Robert
  • 0 in reply to Robert Adsett
    Guru 47900 points

    Robert Adsett said:
    number of screens, ease of layout, how easy it is to configure network access, cost, environmental factors usually loom larger than display performance.  

     

    If that's true - it's (mostly) only true in our "Industrial/Scientific" field.

    Displays' "Figure of Merit" (Viewing Angle, Contrast, Backlight Uniformity/Brightness, and modern, reduced interface) all are key/critical factors in the dominant display movers.   (Cells, Tablets etc.)   And it is the ready encroachment of these Screens which "highlight" the inadequacies of, "time past them by" Displays, Display Chips & MCUs...

  • 0 in reply to cb1
    Guru 10570 points
    Oh, absolutely. Consumer in particular has different driving forces.

    Robert
  • 0 in reply to Robert Adsett72
    Guru 117855 points

    Re: "One size does NOT fit all."

    Agreed - and (even) the constant, chronic, over-promotion of the MCU does NOT, "A Kitchen-Sink make."