Sufficient programming environment

[chodzikman]

Hi,

I have been playing with uGFX for a few days, I have made it run on STM32F746 in few different approaches, yet have not found comfortable way to work with it...

I have built sokoban example and template project from downloads and launched it, made few very simple tests with buttons, labels etc, then imported makefile project to eclipse, force it to properly build project and launched it with debugger an (static code analysis fails at some points but yeah... surely can get rid of it), yet it was a bit painful way, and still I have had some problems with config of library itself...

IMO improving its portability (not meaning platform-wise - it is quite impressive just now, but across IDE's) should be one of the essential goals to reach.

I would be more than happy to help on this, but first I need to get more familiar with library itself and at the moment I feel a bit like I am missing something... Please advice or let me know about your setup.

And keep working, at first glance it looks very interesting and powerful library driven by community!

[Joel Bodenmann]

Thank you very much for your feedback, we appreciate it a lot!

Do you have any idea how we can improve the "IDE friendlyness" other than writing guides for more IDEs and having more ready-to-run examples for different IDEs?
Your help is of course greatly appreciated as well  

[chodzikman]

I have few ideas, but they are based mostly on my STM32/LPC and Eclipse experience.

Ready-to-run examples for most popular boards are good idea regarding quick-start / demo, but to make it easy to port into your target application and use uGFX in multiple projects, preconfiguration tool could do the job. I imagine it would allow you to choose your IDE, processor family, used display driver and if needed peripherial which handles it, library modules and get template project for your IDE with gfx_config.h in place. Perhaps it should be designed with possible integration to uGFXStudio in mind.

In my case selecting System Workbench for STM32 and receiving static library project and configuration file ready to run with CubeMX generated base project seems do the business.

BTW I guess most people (especially hobbyists) nowadays generates init functions in CubeMX or similar tools for other manufacturers and possibility to easily integrate library with auto-generated project from it could be a huge advantage. Maybe cooperation with ST to integrate uGFX as third party block inside CubeMX is possible? I guess it should (I have slightly cooperated with them during our student society project and it was fun). It can be nice for them regarding their marketing (if they don't have some sort of exclusive contract with SEGGER).

Oh,  I almost forgotten that I created this topic to get better environement for working with it at this very moment. Please let me know what is your setup to develop this library, I am pretty sure it will save me some time 

[inmarket]

Our dev environment is actually a very interesting question.

I started on Win32 and Eclipse, migrated to CodeBlocks for a while, tried Visual Studio, I used Keil for a while, but now I use Elixpad (an editor framework that Joel wrote).

So 90% of all my dev is on windows and mostly using mingw compilers with make scripts with gcc for cross compiling.

Other tools I use are the cygwin unix utils, notepad++, WinMerge and SourceTree and of course the uGFX Studio for quick prototyping.

Hardware wise I run a wide range of hardware from MSP430's, STM, AT, to embedded x86. I run numerous types of screen and touch arrangements  (as would be expected as a main uGFX developer). Despite all the hardware, uGFX is largely developed and debugged on Win32 using the cross platform capabilities of uGFX.

Joel uses a different software mix to me and tends to run more linux than I do. Joel might like to describe himself what he uses.

 

[Joel Bodenmann]

Personally I do most of my developments on Windows these days (for various reasons but mainly because that's what customers use and because Windows has greatly improved over the past few years (my personal opinion!) and because Windows has a few features that I am missing on other operating systems). For customers projects I find myself just using whatever IDE the customer uses. These days that's mostly Keil µVision or some Eclipse based manufacturer specific IDE. I myself am not a fan of Eclipse so I try to avoid it wherever possible and I don't use it myself at all. All in all I tried several (like dozens) of different IDEs (both free and proprietary/paid ones) and different editors over the past . I never found something that satisfies my needs. This resulted in me starting to write my own IDE / Development-Framework about a year ago which I find myself using every day as my main tool ever since. As inmarket mentioned he's using it for µGFX development as well. That IDE (called Elixpad) is able to invoke existing Makefiles so my (and our) projects are usually fully make based wherever possible.
When working on Linux I started off with just good old plain vim + make and now moved on to using Elixpad on there as well. The same applies to FreeBSD (which is my main Unix OS) and Mac OS / OS X.

As for hardware I use whatever needs to be used. Again, this is mainly dominated by customer needs. For µGFX internal development we usually develop everything on Windows / Linux and then use the different STM32 discovery and evaluation boards.

I could go on and on and be more elaborating but I guess that should cover most things. I hope that helps.

[chodzikman]

Thank you!

I also have made long trip between IDEs, at the moment Eclipse feels most comfortable (and I am used to its shortcuts and specific behaviors), but now it makes my butt hurt a lot since I need it to use it in some other than stock (autotools) ways.

Does your Elixpad support code completition, call hierarchy etc? If so, is it available to try anywhere? Only mentions I have found were your posts on Qt forum

At the moment I am more than busy, but pretty soon I am going to use uGFX in some private projects. I guess I will continue using bare Eclipse with gnu-arm-eclipse-plugin, and when I'll break all the issues I'll share template project for DISCOVERY F746

I personally think that makefile-oriented system is making uGFX less eclipse-friendly. What benefits it gives that cannot be achieved in other ways?

Also, don't you think, that example config file should consists of all available options set to FALSE instead of being commented out? (or just commented defines without TRUE / FALSE)

[inmarket]

Makefiles are available to work with any compiler on any platform. Nothing else in terms of build platforms is that portable. Makefiles also work with 90% of IDE's and many internally use makefiles, including from memory Eclipse (although some IDE's use variant syntax).

The reason the config variables are commented out is because that gives the best future compatibility. If it is TRUE it is definitely TRUE, if it is FALSE it is definitely FALSE, but if it is not specified then uGFX will provide a default value. Thus not specifying an option allows the interaction between the options to be safest and if we change a default in the library then when the user recompiles they get the new default. This strategy came about from experience with compatibility between uGFX versions and will be particularly important in the move to uGFX V3.

As far as I know Elixpad is not available to the public (although only Joel can determine that as it is a product he is building to sell). It does not currently support code completion.

[Joel Bodenmann]

16 hours ago, chodzikman said:

I personally think that makefile-oriented system is making uGFX less eclipse-friendly. What benefits it gives that cannot be achieved in other ways?

@inmarket already talked about the benefits. I'd to ask why you think that it makes it less eclipse-friendly (or less-friendly in general)? You don't have to use the makefiles. You can integrated the µGFX library into any project and with any IDE without using the makefiles at all. We even provide a very convenient way that we call the "Single File Inclusion Mechanism" which allows you to add just one file to include the entire µGFX library into a non-makefile based project. That's explained here and here's a practical usage example for Keil µVision that doesn't support makefiles at all. And when it comes down to it you can always add every single file manually as you would just with any other library. The fact that we have makefiles available internally doesn't interfere with that at all, so I'd be really curious to know why you think that it has a negative influence?

 

16 hours ago, chodzikman said:

Does your Elixpad support code completition, call hierarchy etc? If so, is it available to try anywhere?

Elixpad currently doesn't support code completion and the like. However, everything is plugin based so adding so adding things like that is certainly possible. It started off as a pure hobby project (which it somehow still is) and until now I wrote everything on my own - there are no other 3rd party plugins or libraries (except for the Qt library which I'm using). Something like code completion and code analysis is rather complex and I think I have to resort to existing frameworks for that. It's something that will definitely follow in the next couple of months.
As mentioned Elixpad is currently not public. That's not by choice but rather because I never bothered. It's a tool that I wrote for myself which @inmarket now uses as well. If it turns out to be useful for other people as well that's a big plus for me. Although the tool runs on Windows, OS X / MacOS, Linux and BSD (all tested) I currently only have Windows binaries at my hand. I am happy to share them with you though. Feedback is always welcomed. If you want I can PM the binary to you.

[chodzikman]

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!

[Joel Bodenmann]

Thank you for your feedback on this. We're going to look into adding more example projects for a wider variety of different IDEs and hardware platforms.

I sent you the Elixpad binary with some explanatory text and a screenshot via private message. Looking forward for your feedback.