Jump to content

All Activity

This stream auto-updates     

  1. Today
  2. Hi Joel Bodenmann, Thanks for your help. It was really helpful.
  3. Yesterday
  4. Last week
    Thank you very much, it really helps. Zip itself could use some weight reduction because there's a lot of unnecessary files.
  5. Hello & welcome to the µGFX community! It would be definitely very appreciated if somebody could update the demo
  6. Hi I think demo is hard to complete as per https://wiki.ugfx.io/index.php/Using_ChibiStudio. Problem is that demo configuration of ChibiOS (176) and downloadable versions of ChibiOS (182, 191) are not compatible. Anyone willing to share an updated demo? /Peter
  7. Earlier
  8. Hello & welcome to the µGFX community! This is certainly possible. The graph widget demo also plots multiple values in the same graph. However, in this case you'll most likely just end up having more than one graph widget/window on the same "display page".
  9. Hi, I’m currently working on a Patient Monitoring Project. I need to know whether I can make this kind of multi-chart in a single window as seen in attached image. I’ve done a single chart in a window using uGFX but can we do multi-chart using uGFX??.
  10. Hi Joel, Below are the results of testing the macros against each other. PURE GREEN ============= r = 0, g = 255 b = 0 rgb565 = RGB2COLOR(r, g, b) = 0x07E0 ---------> TEST 1 - (((c) & 0x007E)>>3) ============= r1 = RED_OF(rgb565) = 0 g1 = GREEN_OF(rgb565) * = 12 b1 = BLUE_OF(rgb565) = 0 rgb565_1 = RGB2COLOR(r1, g1, b1) = 0x0060 ---------> Incorrect TEST 2 - (((c) & 0x07E0)>>3) ============ r2 = RED_OF(rgb565) = 0 g2 = GREEN_OF(rgb565) * = 252 b2 = BLUE_OF(rgb565) = 0 rgb565_2 = RGB2COLOR(r2, g2, b2) = 0x07E0 ---------> Matches pure green original
  11. Hello & welcome to the µGFX community! Thank you for bringing this to our attention. We'll put it on the ToDo list for checking. Could you please leave a short description (and if necessary examples) as to why you think that this is the case? Some screenshots might also be helpful if possible
  12. Hi, I think there is an error in gdisp_colors.h file line 219 which cause anti-alias font to display incorrectly. #define GREEN_OF(c) (((c)&0x007E)>>3) should read #define GREEN_OF(c) (((c)&0x07E0)>>3) Regards
  13. Can you explain more detail about controlling the CS???
  14. Hi inmarket, I've tried your idea, but the issue with it is that I'd like to have a Button Release event. I need to know both when it's initially pressed and when it's finally release based on events rather than polling. The checkbox does give me an event when I press but doesn't seem to issue any events when it's released. The functional requirement is like this: Person presses a screen button and that triggers an output function. Whilst the button is still pressed the output continues. The person releases the button and the output stops. If this is done with events then the button release event can trigger the appropriate output to stop. Otherwise I have to use a timer to poll that button, which is more tangled than just acting on the event. I had one hacky idea, which was to swap the checkbox type to a button type after it was pressed 🙂 That way I'd could get a GEVENT_GWIN_CHECKBOX for the press and a GEVENT_GWIN_BUTTON for the release.
  15. If you want to create a latched button use the checkbox instead with a button draw routine instead of the normal checkbox draw routine. The draw routine already exists and the checkbox provides the latched button state and events you are after.
  16. I'm looking for the correct way to add an event similar to GEVENT_GWIN_BUTTON for standard gwinButtonCreate() type buttons triggered from a touchscreen or possibly any input. The purpose is to create a type of latched state that is released by the normal GEVENT_GWIN_BUTTON. This way I can immediately respond to a button press, set an output to a state and hold that state until the button which in this case is a touchscreen is released and thus debounced by the uGFX button state management. I've attempted to create an event by using the customDraw (callout) parameter to capture the press state and to send my own type of GEVENT_GWIN_BUTTON back to the listeners so they can process the event and manage the latching output. I started looking at the hacky way of calling _gwinSendEvent but that breaks the API and if I was going to do that I may as well hack my own event into the gwin_button code. Although if I did add that code then I would also add the latch internally so that repeated events didn't occur. Basically adding GEVENT_GWIN_BUTTON_PRESS event. Any ideas and code snippets ?
  17. We managed to pack the arrays and structures of the c font file in a binary form. We are also able to load and unload such "binary" fonts into uGFX during runtime. My question is: how can we distinguish if the binary data in the font file is a RLE or a BW one based on the properties in struct mf_font_s? I assume that if the flags value is 2 (MF_FONT_FLAG_BW), then the file is a BW. RLE has flags value set to 0. Is this correct?
  18. Feel free to open a thread in the support section of this forum stating what you're trying to accomplish, what you already have (how far you got) and what problem(s) you're facing. "Doesn't even compile" is not enough information for us to help you in any way.
  19. Hi @inmarket i found the problem ! I didn't define the heap size in gfxconf.h, hence the invalid adressing and values of the GDISP variable. I defined it as 8192 and it woks like a charm ! I suspect i didn't allocate enough stack either to the thread so that's all fixed now. Thanks again for your time and for the library ! Cheers, Arthur
  20. Each display driver creates a GDisplay object to hold its run-time data. The first display in the system gets assigned to the GDISP pointer. All drivers, of any type, are maintained in a GDriver list. In your case because the init process is not happening correctly GDISP is totally invalid.
  21. Oh and is it normal that the GDriver* driverchain returns an unlimited amount of instances ? Cheers
  22. Hi again @inmarket and thanks for taking the time, Thanks for the direction, i'll look into it. I'm not that familiar with makefiles as a whole i'm quite a newbie in C development. Good reason to learn then ! So do you know if the initialized display driver has its own instance of GDisplay type or is it stored in the GDISP variable anyway ? Thank you again cheers, Arthur
  23. This looks like GDISP is set to some random value in flash. It is certainly not valid. The GDISP variable is not initialised until after the first display driver is initialised so don't expect it to be valid until after that. With regard to eclipse - I don't use it but I know there are many in the community that do. Personally I much prefer the make system - just create a makefile (I can't remember off the top of my head where the master example one is) and it does everything for you.
  24. Update : these are the values of the GDISP default variable (which i find really odd and i ca't change them whatsoever, including void* board and void* priv):
  25. Hi @inmarket and thank you for the swift reply, I rolled back the changes made to the gdisp_options.h file after posting my message. I followed the wiki using Eclipse at this link and went through the whole process but include paths look like i got everything (see linked image). I used the single file inclusion, do you think i should consider using the makefile approach ? I'm a bit kinky about what ST is doing with its compiler in SW4STM32. Thanks again for your time, Arthur
  26. I wanted to just use Python and ctypes to use ugfx as a lib instead. The example won't even compile so I can't get that far yet.
  27. The problem here is a build problem. GDISP builds in 2 possible modes - single display and multiple display. Which it uses is a complex combination of include paths, variables in gfxconf.h and linking. The build results in quite different code for the two options. If your gdisp_lld_init is not being called it means you have this process wrong. First GDISP_TOTAL_DISPLAYS, GDISP_DRIVER_LIST and GDISP_PIXEL_FORMAT should not be defined at all in your gfxconf.h for a single display. Instead the specific driver directory you want to use should be on your compiler INCLUDE path and the specific driver files should be included in the build. Also, the various _options.h files should not be altered. All your customizations should be in your gfxconf.h file. See the example demo programs and the provided gfx.conf.example file in the top directory. In general look carefully at the provided build files and the wiki if you have any questions.
  1. Load more activity
×
×
  • Create New...