Jump to content

chodzikman

Members
  • Posts

    20
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Sure, it is fine when you need to write a new thing like a widget, but if I want to replicate a solution or understand/debug something visual inspection of inclusions greatly speeds up the process. The other thing is some of your customers might need to stay along with standards like MISRA C, in this case you will have static code analyzer that checks compliance with allowed subset. (the other thing is if uGFX is anywhere near the subset and if you are interested in this part of market)
  2. I forgotten to ask you to split these two topics Ok, this is exactly the way I am thinking about it. Just wanted to make sure that I am not thinking against design pattern here BTW, In my Eclipse environment I am constantly dealing with ifdef 'misunderstandings' from Indexer Everything else is working fine, but this is somehow frustrating and prevents me from creating tutorial. Maybe some other users will have some ideas...
  3. Ok, additional question: is there any desired pattern for testing if flush operation is completed or should I just test DMA peripheral 'low-levelish' directly inside draw pixel?
  4. I recommend you this one (I guess you will have local distributor of this company around): https://riverdi.com/product/rvt4-3b480272cfwc81/ Or just plain FT800/FT801/FT811 chip to connect standard 4,3" RGB module It seems to be quite popular, and I have been using this chip for one of the projects, so I can advice on any problems
  5. I have to point out that at this moment it is hard to implement uGFX driver for displays that works in approach of command list (this is similar situation as with FT80x), since they have clear limitations with standard pixel drawing method. It can create huge value for some customers if uGFX could create list of primitives to share with graphic coprocessor, since it can allow better styling capabilities than enginge built in hardware driver. As far as I know uGFX would be the only library to provide such behavior at the moment. What I meant was contribution to the library with expansions (hopefully) consistent to current design patterns by simply adding new Optional Routines. EDIT: there will be still some problems with handling texts
  6. Hi, I think you can search where gdisp_lld_fill_area() is called when you draw rectangle primitive, implement draw_circle as gdisp_lld_draw_circle() and add call to this funtion in circle primitive routine same way as it is called in rectangle and proceed with each accelerated functions.
  7. Hi, Woudn't it be nice to have optional C++ wrapper on top of existing gwin functions to simply group all possible calls and its structure for each widget instead of passing pointers to them? It should significantly improve ease of writing it in C++ based systems. The library itself looks for me like it was written with this in mind, what do you think?
  8. Thank you very much, by now I think I know everything to do it following your concept for the library. I didn't noticed these flush calls during my quick research.
  9. Ok! Thank you for the info. I want to add this double-buffering feature (I'll have some time for it within two weeks hopefully - next week I am at Hannover fair...), but I have just jumped through code and the way I want to implement it would require some kind of additional trigger from higher layers - It could be either sent automatically on redrawing widget finished or manually by user. It can make it a bit ambiguous for programmer (manual buffer-swap triggering) or (in case of auto-triggering) make some visible delays between drawing each widgets on lower memory throughput (for example 4 big widgets in each corner of the screen, 8-bit data bus for SDRAM and 4.3" display) due to DMA buffer copying time. Maybe you have some other ideas / advice? As far as I understand, If i were to implement it with the spirit of existing code, I should add definition option for LTDC in main config file and include my code in corresponding ifdefs. Should I know about anything else regarding name convention or anything else? Again, perhaps there should be a guideline for contributors. Perhaps in V3 some generic events/flags from higher levels to the driver should be implemented to create generic way to make display drivers rely on some of driver-specific synchronisation features? (Maybe it already exists and I haven't found it) How it behaves now on larger LCD TFT drivers with slow serial communication? Is it efficient enough (not visible) to draw pixel by pixel instead of sending longer packets? Regarding contribution to V3 - I don't want to promise anything, but I find it interesting to work a bit on things you written in my spare time.
  10. Ok, thank you for the information, it's a start. So few more questions: -Is V3 branch in repo usable at this moment or not at all? -If I want to contribute some high level features, is it possible? Should I do it for V3 or V2? (perhaps I'll write more advanced graph widget)? -If I want to contribute some low level features, is it possible? Should I do it for V3 or V2? (perhaps I'll write driver-dependent advanced anti-aliasing for primitives)? -Are you interested in low-level double-buffering LTDC for 2.x? It would behave like this: Declaring two framebuffers and two pointers, writing to buffer which is hidden, when finished, buffer pointers are swapped and DMA mem2mem is requested to update hidden buffer. It will prevent screen tearing in some rapid redrawing stuff without changing any high-level behavior If you want to gain more contributors to the library itself, I'd recommend you to insert a guide on the wiki, at this moment it feels a bit like you want to develop core of library by yourself and let users contribute some high level stuff (which is understable for me, but it would be better to make it clear).
  11. Is there a list of TODO / new features for version 3.0 available? Also what is planned time to officialy introduce it? I would like to convince my company to purchase the licence, but at the moment it lacks some features which surely will be pointed out (most importantly double buffering for LTDC driver - just by now I can see screen tearing on simple graphs, also anti-aliasing on primitives as an option). Don't necessarily want to feed you with the list of features which hopefully are already on the schedule. On the other hand, regarding release date, don't want to bother implementing needed functions on older version and then challenging compatibility issues. Also at this moment if I want to contribute some code to the project, I risk messing with your plans / vision.
  12. I wanted to check it one more time (also I have figured out problem with Indexer), and suddenly magic smoke escaped from my board due to ESD I am going to receive new one in few days, and will let you know then, ok? BTW I also had some questions regarding more advanced stuff in library, but in this case I need to pass until I will get new one
  13. Hi, I am afraid that implementing FT80x driver is not that simple task since communication with this driver is more like communication with OpenGL library. You are creating command list and as far as I know even if you can draw single pixels it is very ineffective way and display list is 4k or 8k so direct drawing is VERY limited. On the other hand, It is a bit irrational to implement whole library like uGFX to drive such advanced chip which design goal is to get much simpler MCU while achieving nice looking LCD-TFT UI Attached is example how to draw a clock using this chip from its manual.
  14. Attached is template project for Eclipse for F746 discovery (4,3" cap-touch screen) based on make template project from downloads. It was created in Neon.3 CDT version with GNU ARM Eclipse Plugin (no vendor-dependent plugins). Should be added to workspace using Import feature. Works out of box on my machines, including debug features. Due to some search path problems with static code analysis errors and messages are based entirely on GCC output after build (static analysis disabled). When I will find some time, I will try to write some description how I have done it. Please let me know in case of any problems or just that it works properly. f746_downloaded_make_eclipse.zip
  15. Ok, Don't get me wrong, makefile managed Eclipse project is quite consistent way to work (I am not used to do it that way yet, but I need it also for other reasons, most important thing is that your build system is independent from IDE and fully replicable which is essential in continuous integrity development). Again, my thoughts are targeted to beginner who is already pretty much confused with all toolchain / openocd / gdb stuff, it is another thing to distract. I have read (or at least saw) all these guides and found it useful, maybe I am too much concerned about sweet-candy user experience in project targeted to devs (on daily basis I deliver solutions to end client)... Perhaps consistent template projects for more IDEs makes same thing. Thank you for the explanation about config file. Regarding Elixpad - surely I want to try it, I would welcome this binary, but I'll get on it after I get rid of some legacy stuff that bothers me (probably next week or so) Thank you very much for your support, not only it is helpful but also engages me a lot!
×
×
  • Create New...