CubeIDE, TouchGFX, and Support Website Questions, ST DEVELOPERS PLEASE READ;

[HGran.1]

Dear ST management in charge of Embedded Tools and Website Management,

This year, I have embraced your hardware and tools for our new product development.

To say that has been a challenge, is a major understatement.

Not due to the microcontroller hardware design complexity, but almost solely due to the development tools ecosystem.

You HAVE made many innovations in this arena, for which you should be applauded, but seem to continue to miss many easy to accomplish, but very critcal improvements

that would dramatically improve your acceptance among professional developers and ultimately result in more revenue.

Here is a list of some things that I have noticed, that if addressed, would make me comfortable to spec and use your controllers and components in all my embedded design.

If other developers reading this agree, please acknowlege this to ST as well. 

1 Remember Login across all ST (Remember Me, should actually REMEMBER ME) 

2 FIX EXTREMELY SLOW WEBSITE FOR Technical Resources, typically 60 seconds or more for anything other than marketing info (SLOWER THAN ANY OTHER SIMILAR VENDOR)

3 Provide either pdf document indexing app to aid in document identification and access AND/OR better human readable (more descriptive) document naming

4 Add Persistance for screen size and position on TouchGFX (NOT JUST Maximized)

5 Add Persistance for screen size and position on Hardware Selection (Not just full size on Y axis)

(I know what works best for my screen(s), PLEASE let me be in control of that simple thing)

6 Fix TouchGFX project naming and location to better intetgrate with CubeIDE when using multiple projects with same controller type

7 Create single cohesive guide to FULL installation of Cube infrastructure ST software tools procedures INCLUDING TouchGFX

8 Create single cohesive guide to FULL updating of Cube infrastructure ST software tools procedures INCLUDING TouchGFX

9 Create guide for TouchGFX/CubeIDE integrated workflow focusing on 

A. Create project in CubeIDE

B. Add TouchGFX project (either from scratch OR template)

C. Edit MVC in CubeIDE

D. Debug in CubeIDE

E. Modify/Refine/Enhance UI in TouchGFX

F. Reiterate steps C-E many times

10. Stay committed to fixing known SEVERE existing ST tools bugs, instead of just putting them off and complaining of not enough time or prioritization.

11. Fix the samples and board support code to work with CubeIDE infrastructure without requiring users to debug missing code resources and incorrect paths

12. Provide an honest, realistic list of what samples/examples/templates actually work out of the box with CubeIDE and TouchGFX. Maybe also use this as an internal todo list to standardize the quality of same.

Nothing is more frustrating than to falsely set expections that something works, then to find out that it's not the case, but you already knew of it, but didn't provide transparency, wasting valuable developers time.

It is obvious that it's hard to intitially provide a wide variety of samples/example code, but if developers were aware of the existing state of such resources, they could choose their level of participation in the debugging process to achieve functionality. 

13. All the YouTube videos from ST that I've seen, seem to be marketing related, without any real technical merit, instead of really helpful technical information that

a development engineer would watch and witness the ease of implementation, driving them to consider using your components.

It's really a shame, and a telltale sign that all the actually usable technical information on YouTube, comes from hobbyists, and not ST's engineering group.

Once these items are addressed, ST will have a genuine Premier development tool infrastructure and will undoubtably gain widespread increased marketshare, 

as a result of actually delivering the tools that they have already promised, but not actually delivered yet to the required professional standards.

The existing ST vision of CubeIDE and related infrastructure is a bold one, but it's execution history seems to have left many professionals feeling let down 

due to its execution. 

Again, if any other professionals out there agree with this, PLEASE add to this voice so ST management may realize the importance of these items.

This is not a RANT, but honest, thoughtful criticism, offered only with the best of intentions, with the hope that it will be thoughtfully considered...

Thank you,

Heather

[Martin KJELDSEN]

Hi Heather,

Thanks for your feedback. I only know stuff about TouchGFX, so i'll focus on that.

> 4 Add Persistance for screen size and position on TouchGFX (NOT JUST Maximized)

I'm not entirely sure what you mean here. Do you mean the TouchGFX Designer?

> 5 Add Persistance for screen size and position on Hardware Selection (Not just full size on Y axis). (I know what works best for my screen(s), PLEASE let me be in control of that simple thing)

Again, unsure what you mean. By "Hardware selection" i'm thinking Application Templates for boards - Are you talking about TouchGFX Designer still? Can you add some screenshots to show your point?

> 6 Fix TouchGFX project naming and location to better intetgrate with CubeIDE when using multiple projects with same controller type

There's definitely an issue with naming here. Importing multiple projects from the same AT will result in the same name (based on the board). We've been wanting to fix that.

> 7 Create single cohesive guide to FULL installation of Cube infrastructure ST software tools procedures INCLUDING TouchGFX

I think that'll be helpful, yes.

> 8 Create single cohesive guide to FULL updating of Cube infrastructure ST software tools procedures INCLUDING TouchGFX

Also helpful in conjunction with 7.

> 9 Create guide for TouchGFX/CubeIDE integrated workflow focusing on 

> A. Create project in CubeIDE

> B. Add TouchGFX project (either from scratch OR template)

> C. Edit MVC in CubeIDE

> D. Debug in CubeIDE

> E. Modify/Refine/Enhance UI in TouchGFX

> F. Reiterate steps C-E many time

Unsure what you mean by C. I understand that you would like a solid documentation on an iterative CubeIDE/TouchGFX workflow

Thanks again for the feedback.

@Amel NASRI​ - Can you take some of this general input?

[HGran.1]

Good Morning Martin,

First, thank you for your reply. I realized I had a lot of content to address in the post, and really appreciate your response.

>4:

Yes, the TouchGFX Designer always launches in windows Maximized mode, filling my entire screen. This happens regardless of the method of launching, (from within a CubeIDE project, or from the stand alone designer. Like many developers now days, I have used multiple monitors for my development, for many years.

(From HD (1920x1080) to 4K to even 8K at native scaling) Running at 4K, 100% scaling, which many developers use, having the TouchGFX Designer launch automatically to full screen, is not efficient at all. As a full stack NET/JAVA developer, I realize that it should be quite simple to employ some kind of persistance to save the Designer main screen window state, location, and size. Then simply use those settings on subsequent designer launch. On modern multi-monitor workstations, that does require also a little code to validate if the multimonitor environment has changed since the persistant settings were last saved, and invalidate , and revert those settings to 'standard' default settings to always position the screen in a visible position, but that is not very difficult. Also to provide a menu option, to 'Reset screen position' to 0,0 on the main monitor, may be useful. This would be a easy to implement, and really user friendly enhancement to the Designer functionality.

>5:

Again the 'Device/Board Selection' window in CubeIDE also always appears, not maximized, but with the height set to the main screen's maximum client window height. This is also a place where this same sort of screen size and position persistance would be a welcome enhancement. If CubeMX also uses this strategy, it would be really helpful to employ it here as well.

It may be possible that the same or similar strategy may be able to be used for all three applications in order to make implementation and management of these enhancements easier. By such an implementation, this enhanced functionality will simply become transparent to the users, as it is very intuitive and exists more and more in all modern application user interfaces.

<6:

I realize that this issue is a bigger fish to fry and will take more time to properly implement and debug, BUT... perhaps as a interim measure, to identify specifically in what files these hard coded references exist, effectively identifying where to manually change them, will not only be useful for existing users to manually change them as required, but also may be useful as a roadmap for ST engineers to implement a more robust solution.

<9:

MVC (Model, View , Controller). My current workflow is to initially create my UI in TouchGFX Designer, then wire it up to the hardware in CubeIDE, debug in CubeIDE, then add more components and/or further refine UI using TouchGFX Designer, then go back to CubeIDE to again manipulate/enhance related Model/View/Controller/RTOS code and debug, then as the common shampoo instructions go: 'Rinse and Repeat' . This iterative process is the most effective workflow I have found. If there is a better workflow, please let me know. Writing complex code within the TouchGFX Designer has been tedious for me, whereas is it much easier with CubeIDE.

I want to say that your vision of CubeMX, CubeIDE and TouchGFX as a single, cohesive infrastructure is a fantastic one that should put ST in a advantagous position in the marketplace once the implementation is fully properly executed. But I'm sure you all realize that already. Again, THANK YOU FOR ALL YOUR HARD WORK TO DATE !

As they say, 'There IS light at the end of the tunnel, (and it is not just a reflection ;)' and I for one am excited to see the development infrastructure evolve to the point where a project engineer can simply download, install the tools, connect any 'active' discovery board, and design, debug and demonstrate proof of concept functionality quickly, without frustration or sleepless nights, insuring the confidence and faith to be able specify and use ST product for current and future product development without hesitation.

Looking forward to your feedback and Amel's reply.

Thanks,

Heather

[Martin KJELDSEN]

#4 - I'll create a ticket internally on this so we can discuss it - seems reasonable :)

​#5 - @mattias norlander​ - This is a CubeIDE specific request.

#6 - Not necessarily - I'll look into it. I've been fooled before because you can't import multiple projects from the same AT in CubeIDE since they're called the same (e.g. "STM32F429-DISCO") - There's already a ticket for this internally in my team actually

#9 - It makes sense to focus more heavily on a good workflow - to show people our vision and how to best work with the toolchain - I totally agree. I'll create this ticket also.

Thank you for some lovely feedback and your kind words :) Let me know if there's anything i can do to help you, workflow wise, etc.

/Martin

[mattias norlander]

Hi,

@HGran.1​, thanks for all the feedback. And I think we agree on all points.

• To comment on #5, we have created a ticket for this and started discussions with the relevant stakeholders.
• About #9C, could you elaborate on the "Edit MVC in CubeIDE"?

[HGran.1]

Good Morning Martin and Mattias,

I sincerely apologize for referring to the Model / View / Presenter technology as MVC (Model, View, Controller), I was of course, actually referring to MVP rather MVC.

I will strive to be more precise in my use of proper terminology use in the future, as this is a perfect example of improper terminology creating confusion and wasting everyone's time trying to decode the real meaning. Again I apologize for that...

Mattias, I hope my elaboration in the recent reply to Martin and above terminology use correction, clarifies your question, if not, I will elaborate further.

Two more question concerning TouchGFX,

1. when I have multiple discovery boards connected at the same time, a H7xxx and a F7xxx boards, for instance,

I don't understand what mechanism TouchGFX uses to identify which connection to use to run code on the target. Perhaps the first enumerated USB device ?

Once I disconnect the other device(s), TouchGFX does interface with the desired board. It's not a big deal at all, if there is a limitation to only one connected device at a time. If that is the case, I believe I can simply run two concurrent virtual machine development environments, one for each board. That way I can interactively develop and debug applications which utilize multiple boards in peer to peer, and client/server architectures at the same time.

2. When I create a example application for a F746 disco board, using the SlideMenu example for instance, with the standalone TouchGFX 4.15 environment, the resulting code generates a 2.2GB extflash.bin file in the TouchGFX/build/bin folder. This consumes a lot of disk space should I want to explore a lot of examples.

In CubeIDE, I can disable the bin file generation, reducing the disk space overhead, but with TouchGFX integrated environment, I don't see how to handle this.

Does the generated extflash.bin file need to be 2.2GB ?

Could you please point me to any existing documentation that details the latest, current best workflow to create a project for a F746 or H7Bxxx board, that utilizes a TouchGFX application template (with touch enabled of course) , RTOS, resulting in a CubeIDE project, with the ability to use TouchGFX for UI mods, and CubeIDE for coding and debugging as described previously?

In the past, I have followed some previous instructions, requiring significant manual file manipulation in the project. Are those instructions still relevent or is there a better workflow since CubeIDE 1.3.1 and TouchGFX 4.13 ?

I realize that this is part of the whole communication and point <9, but I do need to create a couple of new projects for both the F746 and H7Bxxx disco boards right away, and want to create them in the most efficient manner.

Again, Thank you for your valuable time and help.

Heather

[Martin KJELDSEN]

​Just a quick comment: Don't connect multiple boards :) We're just using the Cubeprogrammer CLI to connect to the first board it finds. Some boards have a board identifier in the st-link chip and i have a tool that can do stuff with that, but it can't be generally applied because the IDs for the st-link chips change over time.

/Martin

[HGran.1]

Good Morning Martin,

I totally get the connect to the first board identified strategy, and I'm sure that works fine for all but fringe use cases. I did end up actually configuring and testing the virtual machine scenario I described above to address this unusual case requirement, and it works perfectly with vmWare Workstation 15+, having the additional feature having a popup window that appears when the device is first connected, that allows you to designate which virtual machine the board will automatically be connected to upon subsequent connection, it also has the ability to map the folder that the device presents to specific guest vm as well. The only caveat is that as you mentioned, some boards present their st-link differently, and appear with the same description in vmWares usb list, potentially making it confusing to decide which connection is for which board. But even that is very easy to resolve, by just plugging in each board, one at a time and completing the vm guest usb assignment before moving to the next board.

Yet one more reason that having free development tools that are not bound by rigid workstation installation limitations and licensing requirements makes great sense in the modern real development world. I couldn't have done this with another workstation development IDE that has concurrent use restrictions and cost thousands per workstation instance...

I had also been running through a lot of the TouchGFX examples yesterday, and noticed that when targeting actual boards, each example does indeed generate more than 2GB code as I mentioned previously, 10 examples = 11GB + code... Am I doing something wrong in my workflow, or is there a setting that I missed that will result in not generating that 2.2GB extflash.bin file ?

Thanks,

Heather

[mattias norlander]

Hi Heather,

Regarding the question on 2.2GB files. The reason is that bin-files does not manage large memory gaps well. It fills the space between flash and external flash with 0x0.

0x90 000 000 – 0x8 000 000 --> bin-file size on disc ~ 2.2 Gbytes.

We generate bin-files by default to allow some other use cases commonly used by mass-market. This is the sad side-effect.

Please for your use case disable the bin-file generation and rely on elf-file instead.

Build Settings > Tool Settings > MCU Post build outputs > Convert to Binary file <-- Uncheck this one!

Kind regards, Mattias

[HGran.1]

Good Morning Mattias,

I have made the setting change as you provided, and that works fine in CubeIDE.

When I create an example from the TouchGFX 4.15 stand alone designer, i get a 2GB file as well, named extflash.bin as compared to the bin file in the debug folder with

the same name as the project. Your solution works with the <projectname>.bin file, but isn't the extflash.bin file that TouchGFX generates, a different asset?

Can the extflash.bin that TouchGFX designer generates in stand alone mode be either eliminated of reduced in size?

Thanks,

Heather