kengineer

So I'm most likely going to use the gwinShow and gwinHide functions (with widgets or containers) to show things properly based on the current screen I'm on. I've set a custom style with a background color for some buttons, however I find that when I hide them, they are replaced with a white background where the button used to be. Is this normal behavior or am I doing something wrong?

FYI it's "Kinetis Design Studio" not "Kinetics"

That helps a lot Joel thanks. I'm still learning the system so I'll likely have more questions in the future.

"may be" completely different I meant...

Hello, I was wondering about the proper or intended use for the GWIN module when creating multiple screens. By screens, I mean separate screen layouts that may not be completely different. Is the intended use to create and destroy the widgets every time, or should I be reusing widgets across multiple screens? What is the most efficient way to use this?

Hi Joel, I was talking about the specific implementation in the board file. I figured out the issue though, it was adjustments to the #defines in the board file. The calibration routine wasn't starting automatically because I had defined GINPUT_TOUCH_STARTRAW as true. I disabled it and now it starts, so problem solved. Thanks!

So what I'm not understanding is what values I should be returned by the read_xyz function. Remember this is a resitive touch display so I'm using the MCU touch driver. Returning raw values in my board file does not work for the ginputCalibrateMouse() calibration routine. However if I adjust these emperically to get a lower range, it seems to see my touches. I assumed that I could provide raw ADC values and the calibration routine would figure out how to map these properly to actual x y coordinates based on my touches. FYI, I have confirmed that when I touch I can get ADC values proportional to my x,y location, it's just that these are raw ADC values (i.e. 3000,3000 in a corner). In the two board file examples I see in uGFX, it seems like they calculate it slightly different with each.

Hi Joel, I got FreeRTOS up and running and now read_xyz() in being called on a regular basis. Just trying to figure out how ginputCalibrateMouse() works now.

So the only other real solution other than fixing one of those issues you mentioned in your previous post is probably to run FreeRTOS or something?

Hi Joel, I tried defining #define GFX_CPU GFX_CPU_CORTEX_M0 the other day but this generates many compile errors, seems maybe there is some incompatibility between the two: lo register required -- `str sp,[r2,#20]' lo register required -- `ldr sp,[r3,#20]' invalid register list to push/pop instruction -- `push {r4,r5,r6,r7,r8,r9,r10,r11,lr}' etc.

Hi Joel, I didn't even have to do your example, I just tried implementing a simple gfxSleepMilliseconds and following where that went. With GINPUT disabled (no threading), sleep function works fine. When GINPUT is enabled, after CXT_RESTORE(newt->cxt, 1 (aka longjmp) is called, I land in an exception handler for my part (Hard Fault). I'm using Atmel's SAMD series (Cortex M0+) which uses ARM GCC. I'm looking at your other link that you sent me regarding the longjmp bug.

My display is currently working so I'm going to try the threading example you told me above.

Currently the option to use gtimer is commented out, maybe this is part of my problem. //#define GFX_USE_GTIMER FALSE

Hi, I'm trying to get the MCU touch driver working on uGFX. I've implemented all the methods (and tested) needed to successfully use the MCU touch driver with an ADC and put these in the board file under read_xyz(). I've included the driver as well in my build. I've also set the following: #define GFX_USE_GINPUT TRUE #define GINPUT_NEED_MOUSE TRUE #define GINPUT_TOUCH_STARTRAW TRUE What I'm not understanding is how to properly utilize this driver. I assumed that read_xyz() would be regularly polled by uGFX, however it seems that it only gets called once sometime during startup and then never again. I then try calling ginputCalibrateMouse(0) after init. I see the calibration come on screen but then it enters a loop waiting for a condition to happen. Do I need to implement the call to poll the touchscreen read myself some how like in an interrupt? This is a bare metal system currently and I don't have threads or anything like that setup. Anyways, just looking for a little insight as I'm not understanding the proper usage of the module and how to run a simple calibration example.

Yes unfortunately non DMA SPI is pretty slow on my platform. Pixmaps sound like a good idea. I can allocate a good portion of RAM if needed so this might be a good solution.

So I cannot change this correct? Any other tips on speeding up draw time other than just sticking to drawing functions rather than images?

Thanks this works out quite well at least for doing things like clearing the screen (just have splash screen example running right now). One thing I'm not certain of yet because I haven't done this is for displaying images or graphics. Let's suppose for example when the display starts I need to draw a background image. What determines how much of an image is actually buffered at a time and therefore how much of it can really be DMA'd at once without breaks?

Hi Joel, Yep that's exactly what I did, worked out great thanks.

Got it, I'll see what I can do on my side. Thanks for the advisement.

I was trying to convert a Chinese font using the ugfx online font converter. If I filter it, it seems to work. If I run the font with no filter, it will run for a minute and then come up with a "Connection Timed Out" page from the server.

Doesn't this mean with streaming enabled that I have to modify the gdisp driver as well? Look at the example below for the code used when streaming to clear an area of the screen: // Next best is streaming #if GDISP_HARDWARE_CLEARS != TRUE && GDISP_HARDWARE_FILLS != TRUE && GDISP_HARDWARE_STREAM_WRITE #if GDISP_HARDWARE_STREAM_WRITE == HARDWARE_AUTODETECT if (gvmt(g)->writestart) #endif { uint32_t area; g->p.x = g->p.y = 0; g->p.cx = g->g.Width; g->p.cy = g->g.Height; g->p.color = color; area = (uint32_t)g->p.cx * g->p.cy; gdisp_lld_write_start(g); #if GDISP_HARDWARE_STREAM_POS #if GDISP_HARDWARE_STREAM_POS == HARDWARE_AUTODETECT if (gvmt(g)->writepos) #endif gdisp_lld_write_pos(g); #endif for(; area; area--) gdisp_lld_write_color(g); gdisp_lld_write_stop(g); autoflush_stopdone(g); MUTEX_EXIT(g); return; } #endif That for loop at the bottom was written to make individual calls to gdisp_lld_write_color for the number of pixels being written meaning I cannot write a stream of bytes at a time without changing this correct?

Understood, thanks for the quick reply. Just wanted to make sure this was the case before I started modifying the code. Thanks!

Thanks for the info guys!

I had a question regarding support for DMA SPI in the ILI9341 driver. I've got a display that utilizes the ILI9341 that I plan to drive using the uGFX library. One thing I've noticed, is that the ILI9341 driver does many individual writes to SPI. On my system, even with a 24 MHz SPI bus, due to the large gaps in between successive SPI write calls, the init calls and screen draws are visually slow. The part I'm using has DMA SPI and I have gotten this working. My question is that do I need to restructure the driver code to utilize this method, seems the answer is yes. I'm also wondering how this is going to play into reading from SPI flash in the future though I haven't gotten that far in regards to understanding the entire uGFX library.

Hello, just got gfx up and running on a cortex M0+ based microcontroller. I implemented gfxSystemTicks and gfxMillisecondsToTicks functions similar to how suggested here. I didn't however actually use a system systick, but rather enabled an accurate 1 ms timer interrupt in my code, and used this to increment a timer variable. This was easy and quick to setup as I didn't really look too much into how systick works. What I'm wondering, is when should this timer be cleared to 0? Otherwise it's just going to run forever until it overflows. I'm not sure how an actual systick is handled so maybe this usually isn't an issue. Thanks.