I'm wondering whether anyone else here has given up completely on KEIL and moved onto something else that is more coherent and cohesive, and whether that made up for any of the deficiencies that I seem to keep experiencing.
I have spent approximately $450,000 on my design that encompasses the STM32 line of products - including licensing the KEIL product for multiple developers. Everyone that I've spoken with is of the consensus that it's useless. And I am beginning to question my own sanity regarding the decision to invest so heavily in a design that relies upon an IDE that - well, frankly - seems so buggy.
Keep in mind that I'm entirely within the STM32 / KEIL ecosystem. Fully licensed and sanctioned - using real software and keeping both the CubeMX32 and the KEIL program fully updated. Regardless - it's SUCH a painful process - that I am wondering whether there's anyone who has used it to develop actual real products. Seriously. And I have a legacy of working for over 20 years in technology designing everything from embedded systems to very sophisticated transactional processes. But KEIL? Waste.
ANyway, if anyone can give me recommendations for what to move to - in lieu of KEIL - I would really appreciate it. I'm tired of seemingly doing everything right, and still getting countless error messages. Even small things like "xxx requires white noise" where - well, KEIL provides libraries that include TABS instead of SPACES in defines., etc.
What a terrible, lousy product.
Thanks.
(image of example errors which - despite being resolved elsewhere - continue to plague me). customer.telswitch.com/.../keil.jpg
Can't agree. Keil may not be perfect, but it's way better than many I've tried.
@Aaron Woolfson,
Come on man. Give us some details - what is precisely the problem? Did it really take 450000 USD to figure out something you or your great (?) developers should have figured out in no time (remember: YOU called the product a waste!). Either elaborate or go get a life...! Happy new year.
To answer your question - yes, I have created many products with the tool chain - often from scratch, in combination with open source packages and without.
So is your beef really with Keil itself, or the interaction with ST's tools, etc?
I would have to agree that uVision is not great - but I can't say that any of the others stand out as superior in all areas. As ever, they all have their strengths & weaknesses.
What fraction of this was actually spent on tools, assuming you didn't buy a 100 seats?
I wouldn't trust CubeMX/HAL to be a solid platform to build anything on, and I've found Keil to be significantly more robust than GCC in terms of compiler induced failures.
Here's the details:
$26,303 on back office / AWS $122,334 on Firmware Development (mostly worthless!) $33,845 hardware layout / part 1 (worthless!) $14,490 hardware layout / part 2 (great company - Jumping Point Technologies, Brentwood California. WONDERFUL EXPERIENCE!!!!) $11,506 project management $10,298 legal $39,052 iPhone app development $3,420 MVNO / Mobile $4,000 graphics / branding $6,156 industrial design $12,000 keil $44,550 hardware manufacture $42,000 training / travel / misc. $68,000 organizational support (staff, help, etc).
Now, my frustration is this. a) I have a great product. b) I have a great idea of what has to go into it. c) I have wonderful backers who are well known and appreciate my integrity.
So my experience doesn't sound a-typical. It sounds rather typical. I do, in fact, have my entire device built around the STM32F417 variant of the part. Otherwise, I would have used an ATMEL part. I really was persuaded toward STM because (a) I have a strong relationship with Arrow, and (b) because I've felt particularly good about my interactions with STM. And the support from KEIL had been good when I've used it.
It sounds like - however - I really need to hire a local (bay area) consultant who is willing to let me hire them for a day-a-week to hang out and just have them help me through some of the idiosyncrasies of the KEIL product.
Anyone available?
(See details a couple of posts up).
The problem with embedded development is that it is quite far from PC development. This means that whatever tools is selected, the developers will have to suffer a significant learning curve.
The world is moving more and more towards RAD (Rapid Application Development) concepts to speed up development times. Just that RAD works best when one company supplies all parts.
The embedded world consits of mostly small companies. They all have limited cash to invest in integration of their individual offerings - even if the license fees are high there is still quite few paying customers.
Big companies in the PC world can throw in many millions in "interprocess communication" to set up work groups to decide on how to integrate their tools. But while that can lead to better integration, it also tends to result in slow progress. A 100-man or 1000-man team isn't as nimble as the small embedded companies.
The Keil tools do have lots of functionality that could be improved. But a more important thing here is to do a pre-study of the different library layers that exists and then decide what tools to actually make use of. And how much you want to depend on different libraries you may not have the source code for, compared to writing own code. But always think twice when putting your eggs in a basket that is held together by multiple companies. If something is wrong, one single company isn't likely to be able to fix the basket on their own. So there are risks involved. You and your developers must try to evaluate your perceived vulnerability level, and what vulnerability level you can afford.
Per Westermark - you made me think about about this problem in a much more pragmatic approach than just simply "I can't stand this". I think that I may have been looking at the problem from the wrong point of view. There's a lot of really good suggestions in the replies, and it doesn't seem like I'm the only one who has gone through this , from time to time. I've been missing some critical steps, I think, in the approach that I've been taking. I'm not using Classic Mode; I'm using the CubeMX method of defining the parameters for my device, which has some unique challenges. I looked back at my previous support tickets, and it would appear as such that I'm going through the same things again, so I think that it's just been long enough that I've needed to go back.
Thank you everyone for having given me the encouragement to continue onward. For now.
I second what was mentioned about CubeMX: This should certainly _not_ be your tool of choice to create production-grade firmware (a statement made to a colleague by ST personnel...). If you are into ST, better to use their firmware libraries.