chrisjn52

Video of my first ugfx project - a numeric Spinbox widget. Hardware is STM32F103C8T6 using RAW on 320x240 SPI colour display. Useage - ghSpinBox1 = gwinSpinboxCreate(0, &wi, 0, -200, 200, 5, ".", 2, "V"); // init, min, max, step, decimalmark, places, units Apologies if video a little shaky, it was difficult to use sylus between camera and fragile breadboard setup. P1000162.MP4

You are correct, adding 1 to the x axis for the two right hand side coordinates of the up arrow improves the uniformity and the aesthetics when viewed in close proximity to a down arrow that serves as a visual reference.

Since a picture is worth a thousand words...............

I'm sorry but I am not sure what you are asking for in your last sentence? Are you asking me to test a left and right arrow? The Uparrow triangle polygon is missing the bottom complete row of pixels rather than just one pixel to the right?

Whilst developing a Spinbox widget I discovered that the arrow triangle polygons drawn when using gdispGFillConvexPoly were not the same for the following code snippet. static const point upArrow[] = { {0, SPIN_ARROW_SZ}, {SPIN_ARROW_SZ, SPIN_ARROW_SZ}, {SPIN_ARROW_SZ/2, 0} }; static const point downArrow[] = { {0, -SPIN_ARROW_SZ}, {SPIN_ARROW_SZ, -SPIN_ARROW_SZ}, {SPIN_ARROW_SZ/2, 0} }; gdispGFillConvexPoly(gw->g.display, gw->g.x+iwidth+((SPIN_SCROLLWIDTH-SPIN_ARROW_SZ)/2+2), gw->g.y+2, upArrow, 3, ps->edge); The upArrow has the last row of pixels missing and is due to lxc being equal to rxc in gdisp.c which results in one less iteration of the loop in gdisp.c in the following section of code at line 2844. /* Scan down the line segments until we hit a boundary */ for(; y < ymax; y++) { lxc = NONFIXED(lx); rxc = NONFIXED(rx); /* * Doesn't print the right hand point in order to allow polygon joining. * Also ensures that we draw from left to right with the minimum number * of pixels. */ if (lxc < rxc) { g->p.x=tx+lxc; g->p.y=ty+y; g->p.x1=tx+rxc-1; hline_clip(g); } else if (lxc > rxc) { g->p.x=tx+rxc; g->p.y=ty+y; g->p.x1=tx+lxc-1; hline_clip(g); } This behaviour can be fixed by increasing ymax by one if lxc == rxc but I am not sure if there are other ramifications.

Could you confirm whether there are any plans to create a numeric control widget such as is shown here, (Amplitude [V]), before I attempt to create one based on the textedit widget with dial input capability?

Hi Joel, thanks for that, I took the "ToDo" text on this page as gospel and I mistakenly believed that toggle was only for mouse buttons although I did think of delving deeper into toggle as a start for the momentary button incorporated into the Rotary Encoder. Cheers

Hi Joel, I am currently using uGFX in a project that requires a Rotary Encoder and Touchscreen for user interface navigation. Clearly touchscreens are already well catered for, but the Encoder & Switches are on your ToDo list. Before I attempt to tackle this myself, (I fall into the same category as a recent requestor for Dials!), are you able to give me some idea as to the development schedule for these? If the schedule is thought to be over the horizon then any thoughts you have with regard to the Rotary Encoder interface would be helpful, should I be brave enough to attempt myself in the meantime. uGFX is great by the way!

Hi guys, I have noticed in the documentation that RAW32 was a port but I have been unable to find any info on its origin. Just for my interest and education can you point me towards any articles? Thanks.

To cut a long story short I finally managed to get my display to run a simple demo after chasing many ghosts in an effort to track down what seemed to be an intermittent SPI issue. After many hours of debug that led nowhere I went back to basics and re-read some of the documentation whereupon I surmised that the problem might be due to an unserviced interrupt. The solution, (I am almost too embarrassed to say), was that I had somehow deleted the interrupt handler source file from my project, (probably during the period when I was trying to get the Eclipse System Workbench environment setup to compile). The ILI9341 board file was fine all along and I spent quite awhile with a logic analyser in order to prove that the SPI bus was working as it should, and even then I struggled to convince myself that the problem lay elsewhere. Sometimes it's good to have a few problems, it taught me a lot!

Hi Joel, just in case you are scratching your head and contrary to my last post, I get the following message in the console after a clean and re-compiling.......... #error "GDISP Driver: Either GDISP_HARDWARE_STREAM_WRITE or GDISP_HARDWARE_DRAWPIXEL must be TRUE" Thanks

Hi Joel, I see no change to the behaviour when the value of GDISP_HARDWARE_STREAM_WRITE is set to FALSE in /drivers/gdisp/ILI9341/gdisp_lld_config.h . The code is executing gfxInit() in main(), and the vmt->postinit(pd) funtion in gdriver.c executes gdispGClear(gd, GDISP_STARTUP_COLOR) in order to clear the screen. At line 1058 in gdisp.c the code and/or debugger fails after quite a number of SPI writes, (~300), as it tries to clear all 76800 pixels. Running the code without using the debugger does not result in any display and the number of SPI writes appears to be similar in number when viewed on the logic analyser This is a base project, STM32F103C8T6 Bare Metal with no other stuff, and I started the debug process before connection the display to check that all the SPI signals etc. were as required but unfortunately I am unable to track down the problem, possibly because of the debugger issue but probably because I have errors elsewhere. I have attached my board_ILI9341.h file, it's a little untidy as I initially thought this problem was due to a SPI timing issue, (Peripheral clock has also been reduced to 8Mhz). I am currently attempting to read the controller chip to verify it is in fact a ILI9341 device by executing a 0x04 command although I don't believe this is the issue as the Clearscreen function appears not to complete. board_ILI9341.h

Hi, I'm trying to debug my ILI9341 driver, (standard peripheral library), and I am getting this message in the console window: Is this an issue? I am using the Eclipse System Workbench (Ac6) and the code hangs in gdisp.c at the following location: 1058 for(; area; area--) 1059 gdisp_lld_write_color(g); 1060 gdisp_lld_write_stop(g); line 1060 never gets executed. The following link shows how to increase the timeout but in the System Workbench version this option isn't available. http://help.eclipse.org/luna/index.jsp?topic=/org.eclipse.cdt.debug.application.doc/reference/cdt_u_gdb_mi.htm I tried changing the Command Timeout (mS) option as shown in the attached image but it didn't help, the code still appeared to hang in the same place after a few hundred write cycles so I am not sure if this is a GDB debugger issue hampering my attempts at debug? Any help appreciated.

Doh! thanks for the pointer Joel. I had this correctly setup from the start but deleted the include path in my efforts to understand what was going on. I then added it back it sometime later BUT in the assembler section instead of the C compiler section of Eclipse. I completely understand your recommendation but once I had started I was determined to fix the problem, particularly as it prompted much head-scratching and forum research into how things work and as a result I have now sorted the include paths and the project now compiles perfectly ok under STM32 System Workbench. Many thanks.

I now have compile issues with mcufont etc. and would really appreciate a further pointer! The issue seems to be one of relative/absolute paths since #include MF_FONT_FILE_NAME in mf_font.c resolves to src/gdisp/fonts/fonts.h: No such file or directory. If I change this to "#include ../fonts/font.h" I can progress to more errors of the same with other files. Simply adding the folders to the include path in Eclipse did not fix the issue. Am I doing something wrong or will I need to change these paths? make -j2 all 'Building file: C:/Users/Chris/workspace/ugfx_2.5/src/gdisp/mcufont/mf_font.c' 'Building file: C:/Users/Chris/workspace/ugfx_2.5/src/gdisp/mcufont/mf_wordwrap.c' 'Invoking: MCU GCC Compiler' 'Invoking: MCU GCC Compiler' C:\Users\Chris\workspace\uGFX_STM32F103\Debug arm-none-eabi-gcc -mthumb -mfloat-abi=soft -DSTM32F1 -DNUCLEO_F103RB -DSTM32F103RBTx -DSTM32 -DDEBUG -DUSE_STDPERIPH_DRIVER -DSTM32F10X_MD -I"C:/Users/Chris/workspace/uGFX_STM32F103/src" -I"C:/Users/Chris/workspace/ugfx_2.5/drivers/gdisp/ILI9341" -I"C:/Users/Chris/workspace/nucleo-f103rb_stdperiph_lib" -I"C:/Users/Chris/workspace/uGFX_STM32F103/inc" -I"C:/Users/Chris/workspace/nucleo-f103rb_stdperiph_lib/CMSIS/core" -I"C:/Users/Chris/workspace/nucleo-f103rb_stdperiph_lib/CMSIS/device" -I"C:/Users/Chris/workspace/nucleo-f103rb_stdperiph_lib/StdPeriph_Driver/inc" -I"C:/Users/Chris/workspace/nucleo-f103rb_stdperiph_lib/Utilities/STM32F1xx-Nucleo" -O0 -g3 -Wall -fmessage-length=0 -ffunction-sections -c -MMD -MP -MF"ugfx_2.5/src/gdisp/mcufont/mf_font.d" -MT"ugfx_2.5/src/gdisp/mcufont/mf_font.o" -o "ugfx_2.5/src/gdisp/mcufont/mf_font.o" "C:/Users/Chris/workspace/ugfx_2.5/src/gdisp/mcufont/mf_font.c" C:\Users\Chris\workspace\uGFX_STM32F103\Debug arm-none-eabi-gcc -mthumb -mfloat-abi=soft -DSTM32F1 -DNUCLEO_F103RB -DSTM32F103RBTx -DSTM32 -DDEBUG -DUSE_STDPERIPH_DRIVER -DSTM32F10X_MD -I"C:/Users/Chris/workspace/uGFX_STM32F103/src" -I"C:/Users/Chris/workspace/ugfx_2.5/drivers/gdisp/ILI9341" -I"C:/Users/Chris/workspace/nucleo-f103rb_stdperiph_lib" -I"C:/Users/Chris/workspace/uGFX_STM32F103/inc" -I"C:/Users/Chris/workspace/nucleo-f103rb_stdperiph_lib/CMSIS/core" -I"C:/Users/Chris/workspace/nucleo-f103rb_stdperiph_lib/CMSIS/device" -I"C:/Users/Chris/workspace/nucleo-f103rb_stdperiph_lib/StdPeriph_Driver/inc" -I"C:/Users/Chris/workspace/nucleo-f103rb_stdperiph_lib/Utilities/STM32F1xx-Nucleo" -O0 -g3 -Wall -fmessage-length=0 -ffunction-sections -c -MMD -MP -MF"ugfx_2.5/src/gdisp/mcufont/mf_wordwrap.d" -MT"ugfx_2.5/src/gdisp/mcufont/mf_wordwrap.o" -o "ugfx_2.5/src/gdisp/mcufont/mf_wordwrap.o" "C:/Users/Chris/workspace/ugfx_2.5/src/gdisp/mcufont/mf_wordwrap.c" C:/Users/Chris/workspace/ugfx_2.5/src/gdisp/mcufont/mf_font.c:26:27: fatal error: src/gdisp/fonts/fonts.h: No such file or directory compilation terminated. make: *** [ugfx_2.5/src/gdisp/mcufont/mf_font.o] Error 1

Hi Joel, thanks for that, I knew I was doing something stupid! I am still climbing the steep learning curve for Arm, System Workbench and uGFX. Thanks.

Hi, I am trying to compile my first uGFX project from within STM32 System Workbench IDE, (eclipse), for a STM32F103 chip using a SPI driver for the ILI9341 lcd controller. I have setup the IDE in a similar fashion to that shown in the Wiki for the Keil IDE....... http://wiki.ugfx.org/index.php/Using_Keil_µVision_5_MDK-ARM and I have the following compile error(s). I am unable to find a type definition for 'SPIConfig' in order to make any further progress. I have attached the board_ILI9341.h file. Many thanks. 10:11:14 **** Incremental Build of configuration Debug for project uGFX_STM32F103 **** make -j2 all 'Building file: ../ugfx/gdisp_lld_ILI9341.c' 'Building file: ../ugfx/gfx_mk.c' 'Invoking: MCU GCC Compiler' 'Invoking: MCU GCC Compiler' C:\Users\Chris\workspace\uGFX_STM32F103\Debug arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -mfloat-abi=soft -DSTM32F1 -DNUCLEO_F103RB -DSTM32F103RBTx -DSTM32 -DDEBUG -DUSE_STDPERIPH_DRIVER -DSTM32F10X_MD -I"C:/Users/Chris/workspace/nucleo-f103rb_stdperiph_lib" -I"C:/Users/Chris/workspace/uGFX_STM32F103/inc" -I"C:/Users/Chris/workspace/nucleo-f103rb_stdperiph_lib/CMSIS/core" -I"C:/Users/Chris/workspace/nucleo-f103rb_stdperiph_lib/CMSIS/device" -I"C:/Users/Chris/workspace/nucleo-f103rb_stdperiph_lib/StdPeriph_Driver/inc" -I"C:/Users/Chris/workspace/nucleo-f103rb_stdperiph_lib/Utilities/STM32F1xx-Nucleo" -I"C:/Users/Chris/workspace/uGFX_STM32F103/ugfx" -I"C:/Users/Chris/workspace/ugfx_2.5" -I"C:/Users/Chris/workspace/ugfx_2.5/drivers/gdisp/ILI9341" -I"C:/Users/Chris/workspace/uGFX_STM32F103/src" -O0 -g3 -Wall -fmessage-length=0 -ffunction-sections -c -MMD -MP -MF"ugfx/gdisp_lld_ILI9341.d" -MT"ugfx/gdisp_lld_ILI9341.o" -o "ugfx/gdisp_lld_ILI9341.o" "../ugfx/gdisp_lld_ILI9341.c" C:\Users\Chris\workspace\uGFX_STM32F103\Debug arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -mfloat-abi=soft -DSTM32F1 -DNUCLEO_F103RB -DSTM32F103RBTx -DSTM32 -DDEBUG -DUSE_STDPERIPH_DRIVER -DSTM32F10X_MD -I"C:/Users/Chris/workspace/nucleo-f103rb_stdperiph_lib" -I"C:/Users/Chris/workspace/uGFX_STM32F103/inc" -I"C:/Users/Chris/workspace/nucleo-f103rb_stdperiph_lib/CMSIS/core" -I"C:/Users/Chris/workspace/nucleo-f103rb_stdperiph_lib/CMSIS/device" -I"C:/Users/Chris/workspace/nucleo-f103rb_stdperiph_lib/StdPeriph_Driver/inc" -I"C:/Users/Chris/workspace/nucleo-f103rb_stdperiph_lib/Utilities/STM32F1xx-Nucleo" -I"C:/Users/Chris/workspace/uGFX_STM32F103/ugfx" -I"C:/Users/Chris/workspace/ugfx_2.5" -I"C:/Users/Chris/workspace/ugfx_2.5/drivers/gdisp/ILI9341" -I"C:/Users/Chris/workspace/uGFX_STM32F103/src" -O0 -g3 -Wall -fmessage-length=0 -ffunction-sections -c -MMD -MP -MF"ugfx/gfx_mk.d" -MT"ugfx/gfx_mk.o" -o "ugfx/gfx_mk.o" "../ugfx/gfx_mk.c" In file included from ../ugfx/gdisp_lld_ILI9341.c:25:0: C:/Users/Chris/workspace/ugfx_2.5/drivers/gdisp/ILI9341/board_ILI9341.h:30:8: error: unknown type name 'SPIConfig' static SPIConfig spi_cfg = { ^ C:/Users/Chris/workspace/ugfx_2.5/drivers/gdisp/ILI9341/board_ILI9341.h:31:3: warning: initialization makes integer from pointer without a cast [-Wint-conversion] Quote board_ILI9341.h