All Activity

This stream auto-updates   

  1. Last week
  2. My office email rojar@edt.com.tw
  3. Hello @besitzeruf and welcome to the µGFX community! The unlimited license allows the license receiver (eg. a company branch or an individual) to use the µGFX library commercially on as many different devices from as many different products/projects as he likes as long as the license receiver is the responsible entity of the product/project. There are no royalty fees and it's a one-time fee. I hope that answers your question. Please don't hesitate to ask if anything is still unclear.
  4. Glad to hear that you managed to get it working Please contact us via e-mail if that is a serious request / wish so we can further discuss this.
  5. Hi, can please explain more about commercial licenses. Unlimited devices - does this mean an unlimited number of devices for each device line or model or does it also mean an unlimited number of product families? Thank you.
  6. Hi, I unzip again and open studio is correct now. May your company consider sell uGFX-Studio ver 0.15 source code to us ? Our company want to develop the RAD tool combine communication develop for a long term project. Maybe we can develop all thing combine uGFX engine by ourself. But I need to make a fast prototype to show for general manager that a man stupid for tech.
  7. Ettore, your zip file was extremely helpful thank you.
  8. The µGFX-Studio source is not open. Can you please be more specific and provide more information?
  9. Hi, if uGFX-Studio can get the source code ? and QQ I can't run uGFX-Studio 0.15 on win7-x64 ....
  10. Hello @RojarSmith, This is a comments section. Please post your questions in the corresponding forum: https://community.ugfx.io/forum/13-ugfx-studio/
  11. Great work guys! Much appreciated!
  12. QQ I can't run uGFX-Studio 0.15 on win7-x64
  13. Hi, if uGFX-Studio can get the source code ?
  14. The updates are now in the repo.
  15. The master repo has now been updated to FATFS-0.13 The GFILE FATFS demo has been added The makefile system has been upgraded to support .S files Thankyou @cpu20 for your fantastic work in getting this ready.
  16. The GDISP_FLG_SCRSTREAM flag has nothing to do with the current bus state. This flag is used to indicate that the current controller window covers the entire display area. It is an optimization that is only possible when the controller supports a position set operation. The flag improves the efficiency of setting pixels where no vertical wrap is required. Note also that it is perfectly fine to aquire the bus multiple times (or arguably even release it multiple times). It is the first aquire and first release that are effective. For a streaming driver the cycle is start/write.../stop. For a streaming driver with pos capability it is start/(pos/write).../stop. In both cases start and stop are typically used to obtain and release the bus. When you add fillarea into the mix things become a lot more complex. The fillarea is defined as being independent of the stream cursor window. If a driver maintains both streaming and fillarea it needs to be able to perform the fillarea without affecting the stream operation if any is in progress or to atleast reset the cursor window to its original state (and by implication the bus). Looking at the SSD2119 driver, the fillarea you are talking about is only activated in the DMA enabled situation. DMA is completely incompatible with a shared bus unless custom interrupt handlers are written to release the bus at the end of the dma operation and thus aquire/release are meaningless in that scenario. If you are finding writes on an otherwise unaquired bus this is likely therefore to be a driver bug. The simple solution in the short term is to simply turn off the accelerated fillarea (or the dma acceleration) in the gdisp_lld_config.h file for the driver. Looking at the few drivers that use streaming with a fillarea acceleration, it appears that the assumption of the cursor window being retained is actually not normally happenning. I have therefore made a change to the gdisp that should fix that for those few drivers. The changes will be in the repository soon and should also help with your aquire/release ordering (although it will not fix drivers that prematurely release the bus on a dma operation).
  17. In the function hline_clip(..) in gdisp.c, the following code is executed when GDISP_HARDWARE_FILLS is defined: // This is an optimization for the point case. It is only worthwhile however if we // have hardware fills or if we support both hardware pixel drawing and hardware streaming #if GDISP_HARDWARE_FILLS || (GDISP_HARDWARE_DRAWPIXEL && GDISP_HARDWARE_STREAM_WRITE) // Is this a point if (g->p.x == g->p.x1) { drawpixel(g); return; } #endif // Best is hardware accelerated area fill #if GDISP_HARDWARE_FILLS #if GDISP_HARDWARE_FILLS == HARDWARE_AUTODETECT if (gvmt(g)->fill) #endif { g->p.cx = g->p.x1 - g->p.x + 1; g->p.cy = 1; gdisp_lld_fill_area(g); return; } #endif I think the problem that I see is that drawpixel(..) is aware of the GDISP_FLG_SCRSTREAM flag, acquires the bus only if this flag is not set, and does not release the bus. However, the SSD2119 version of gdisp_lld_fill_area(..) (as well as many of the others that I checked) does not seem to be aware of this GDISP_FLG_SCRSTREAM flag, always acquires the bus and always releases the bus. So if this hline_clip(..) function is being called in a loop, as it is when drawing text, then depending on the order of single pixels vs. areas drawn we can mismanage the bus ownership. For instance, if we draw a single pixel and then an area, we will try to acquire the bus twice in a row, then perform a single release. Then if we draw another single pixel the GDISP_FLG_SCRSTREAM flag is already set and we attempt to access the bus without a first acquiring it. Have I misunderstood the intent of the acquire_bus(..) and release_bus(..) functions and they are supposed to implement reference counting?
  18. After some more looking at the code I think I understand that the GDISP_FLG_SCRSTREAM flag is meant to indicate that the bus is being held open and eventually autoflush(..) is supposed to release the bus. However, in my code I'm somehow getting into the drawpixel(..) function without owning the bus but the GDISP_FLG_SCRSTREAM is already set. So let me dig some more and I'll post an update once I've figured it out.
  19. In the drawpixel(..) function in gdisp.c starting at line 127 there is the following section: It seems to me that this code is missing calls to acquire and release the bus around the gdisp_lld_write_xxx(..) functions. The setglobalwindow(..) does call gdisp_lld_write_start(..), which acquires the bus, but setglobalwindow(..) is not always called. And of course there isn't anything to release the bus.
  20. I did check that I wasn't inadvertently selecting anything else, and I would always go visually inspect the list of folders in the filter box to make sure after all the selections/deselections are ultimately what they are supposed to be. Anyway, it's building now, time to pull out the logic analyzer to figure out what's going on on the SPI bus.
  21. Thanks to everyone, I could fix the Problem. The demo is working now at the Embest Board It actually had some issue with the gfxSleepmilliseconds. I changed the delay a little bit and now it works.
  22. You should not do this. It will work but altering the ChibiOS source files will give you alot of trouble (same goes for altering the µGFX source files). The proper way of adding the board.c file is adding: SRC = board.c in your Makefile. Yes, the purpose of the debugwrite is to indicate that the thread is working and sleeps correctly every 500/900ms. As mentioned in the main.c you could blink a led as that is far easier than writing to a file. For the errors you must remove the error message from the main.c file because it will always throw the error otherwise.
  23. Sorry of course my fault Do I understand that right that I have to change the macro "DEBUGWRITE" to something that is compatible to my platform? I tried that but get the same output?
  24. Earlier
  25. When using the shift click to select everything under drivers you must make sure to unselect the top folders gdisp and ILI9341 again. If you don't do this, then it indeed looks fine in the project explorer, but everything in the folder is still excluded. It's pretty annoying and maybe I should file a bug report. Good to hear you figured it out! Don't hesitate to ask if you have any other problems or questions!
  26. Ok, filter problem solved, if anyone has a similar problem: I was doing a click top item, Shift, then click last item to select everything under drivers, after, I click on CTRL and the item I want to exclude, it looks fine under the filters, but it doesn't get excluded in project explorer. Manually clicking on every item and skipping the excluded one under filter seems to work, or maybe I was doing something wrong with my shift selection? Thanks again CPU20 for your help, It builds now. Chafik
  27. Thanks for the suggestions, it makes sense now that you mentioned it, that fixed the errors I was getting, now I got a completely different problem. Throwing it in here maybe someone has a clue. I believe I know what the problem is, but not sure how to fix it: According to the instructions; in the filters, you remove /drivers, then you selectively filter everything out under /drivers, except your actual driver, in my case ILI9341, I did that, and made sure it's no longer greyed out in the project explorer. The undefined errors below seem to point to this folder, I checked it, and it is greyed out again, I checked my filters, and it is the only one not listed there, so it shouldn't be.... I cleared all filters and re-did them again, and it is still greyed out... Building target: Nucleo.elf Invoking: MCU GCC Linker arm-none-eabi-gcc -mcpu=cortex-m7 -mthumb -mfloat-abi=hard -mfpu=fpv5-d16 -specs=nosys.specs -specs=nano.specs -T"../STM32F767ZITx_FLASH.ld" -Wl,-Map=output.map -Wl,--gc-sections -o "Nucleo.elf" @"objects.list" -lm uGFX/src/gfx_mk.o: In function `hline_clip': D:\STM32F7\Nucleo\Debug/../uGFX/src/gdisp/gdisp.c:319: undefined reference to `gdisp_lld_write_start' D:\STM32F7\Nucleo\Debug/../uGFX/src/gdisp/gdisp.c:320: undefined reference to `gdisp_lld_write_color' D:\STM32F7\Nucleo\Debug/../uGFX/src/gdisp/gdisp.c:321: undefined reference to `gdisp_lld_write_stop' uGFX/src/gfx_mk.o: In function `gdispGClear': D:\STM32F7\Nucleo\Debug/../uGFX/src/gdisp/gdisp.c:1051: undefined reference to `gdisp_lld_write_start' D:\STM32F7\Nucleo\Debug/../uGFX/src/gdisp/gdisp.c:1059: undefined reference to `gdisp_lld_write_color' D:\STM32F7\Nucleo\Debug/../uGFX/src/gdisp/gdisp.c:1060: undefined reference to `gdisp_lld_write_stop' uGFX/src/gfx_mk.o: In function `_gdispInit': D:\STM32F7\Nucleo\Debug/../uGFX/src/gdisp/gdisp.c:606: undefined reference to `GDISPVMT_OnlyOne' collect2.exe: error: ld returned 1 exit status make: *** [Nucleo.elf] Error 1
  1. Load more activity