2019-04-02 08:19 PM
I have the STM32F769 Discovery kit to evaluate using the F7 for a future project. I want to enable a timer input, so rather than claw through the poorly written examples (for instance, the TouchGFX example doesn't even load onto the chip) I thought I'd use MX to enable the peripheral I want.
Except when I run MX and tell it I have a Discovery board, it gives me a screen full of conflicts and unsupported features. MX does not, itself, understand how to configure a Discovery board (despite being able to pick it out of a menu), nor is there an .ioc file available for the Discovery board.
So STMicro's big new thing, that sets them apart from everyone else, a graphical configurator for board setups... isn't used by STMIcro.
Why even bother to make a discovery board if you're not going to support it with your own software? How, exactly, am I supposed to discover how to use their great tools and chips if they can't be bothered to finish the example? Why would anyone think this is a selling point?
If their software isn't good enough for their engineers, why would they think it's good enough for their customers?
I am not going to invest the time necessary to completely configure a complex board just so I can enable a timer. I'm just going to look at the example code and do it by hand. Of course this means when I go to actually do the project I won't bother with MX either. So two of the selling points of this product - TouchGFX and CubeMX - are already knocked down as useless vaporware.
Not a good start to an evaluation.
2019-04-12 11:25 AM
I'm using STM32CubeMX Version 5.1.0 and downloaded the Firmware Package STM32Cube FW_F7 V1.15.0, when requested by the CubeMX.
I was able to select the STMicroelectronics STM32F769I Discovery Board and use all the default names and configurations for the pins, generate the code and compile successfully a test application (with Keil compiler) (all in less than 10 minutes)
I'm not sure why you were not able to configure a test project previously, but I would suggest give it another try, because the tools do work.
2019-04-12 11:29 AM
2019-04-14 05:04 PM
I can see the value of these tools to people who already know everything about this chip and just want help organizing it. For a company that is already heavily invested in ST, I imagine CubeMX is quite handy. However, I am not in that group; I am building my company's first ARM product.
When I used the default configuration for my board, I noticed two things: first, over half the pins were yellow, which made me wildly uncomfortable (I do not ship products that compile with warnings), and second. the Graphics were disabled by default. And I couldn't figure out how to enable them. Since graphics were a critical part of my evaluation this was an immediate problem.
I did use CubeMX to generate code for initializing my timers (by only enabling the specific timers I wanted and disabling everything else), which was handy, but unfortunately this also failed as apparently the timers can only count external events via external clocking, rather than as a direct input capture signal, and none of the external clock pins are exposed on the discovery board. I suspect they are being used for something else - which I could have verified if STMicro had shown me exactly how their board was laid out.
The fundamental issue remains: if CubeMX is the "proper" way to configure a board, then STMicro should lead the way. Their .ioc files should be models for the rest of us, showing what a professional approach looks like. Their discovery board should show off their tools to their best advantage, and vice versa.
The fact that they fell down on this highly visible task does not inspire confidence that they will be there when I am in a tight spot. Hence, the poor evaluation score. I mean, there are other options out there, and some of those manufacturers are getting decent evaluation scores.
2019-04-14 09:44 PM
Could you give your manufacturer ranking respective to evaluation score results?
2019-04-14 11:24 PM
In order of best to last, based mostly on the tools and middleware (because the chips are all pretty good): Renesas S7G2, STM32F7, NXP IMXRT 1064. The Renesas is only an M4 rather than an M7, but at 240 mHz it's as fast as I need.
2019-04-14 11:50 PM
>... but at 240 mHz it's as fast as I need.
"m" is a valid unit prefix, as well as "M" - albeit the difference is 9 orders of magnitude ... ;)
I did evaluate 3 boards for a "semiprofessional" CAN project recently, an Atmel SAME70 XPLained, a F746 Nucleo, and a Keil MCB1760.
For both the Atmel and the ST, you either accept the restricting framework it comes with (CubeMX or ASF), or you do everthing anew.
And even worse, there is no LL support for the F74x CAN peripheral in the latest Cube package.
The MCB1760 has a NXP M3 MCU, but it took me about 1 hour to get the CMSIS driver lib based example up and running, adapting it to my purposes, and receive actual CAN frames. Sad to say, said driver lib for the LPC1768 is "legacy" too, like the SPL. NXP jumped a similar point-and-click frameware bandwagon.
2019-04-15 12:41 AM
Thanks for sharing. ;)
2019-04-15 06:39 PM
So far - and I stress I've only spent 2 weeks on each project - the Synergy framework for the Renesas has met my expectations. Of course they all fall down at some point, but ideally they fall gracefully, allowing you to patch only the parts you need to patch. I have seen a number of comments complaining that CubeMX does not play well with others.
2019-04-15 10:41 PM
It depends on what do you expect from such a framework.
In almost all cases, they are fine for a rapid prototype or proof-of-concept, or to provide some sense of achievement for a beginner.
Application for professional, robust, maintainable and and effective software is a wholly different matter. Most of the MCU supplier's large frameworks fail here more or less.
My main critic with Cube - it's virtually all or nothing. The "frameless" LL layer would be fine, it it was nearly complete and somehow robust (tested).