The whole experience has been unexpectedly good, so good in fact that I'm way ahead of where I thought I'd be. For this evaluation, I used the 32KB limited version, so it was free. I wasn't looking forward to this, not least because the last time I used Keil was in 2005 on a Silabs 8051 project, and I remember gritting my teeth when handing over a substantial sum for the privilege then. It's also very cheap for hobbyists/students.I've been using uVision for the past three or four days on a small evaluation project using three different vendors' Cortex M4F boards, a Cypress FM4 board, a TI Launchpad and an STM Discovery board. Get segger system view and/or ozone, it is much more ergonomic, far faster, far more flexible, and works with effectively every chip under the sun. The built in debugger, it worked, sure, but there are so much better tools out there. You can easily tell your linker what linker script to use and I've never seen an arm based mcu that's avaliable on digikey/mouser/etc not have a publicly avaliable linker script. The comment about built in linker scripts, I don't understand. This makes it a pain for another dev to just "git clone" and use your project, and hard to keep track of what changes should or shouldn't be commited. It throws tons of files everywhere and has a tenancy to include absolute file paths instead of relative ones in its configuration files. Kiel is a massive pain to properly version control. If you use something like cmake, then open source larger tools like vscode and clion understand it right off the bat, and you can use a build server easily. You will be locked in if you use Kiel, meaning it uses its own proprietary (and needlessly much more complicated) build system which no other tools understand. Kiel has no proper night mode theme and is eclipse based (I have nothing good to say about eclipse relative to vscode or clion). If you use your own tooling, you can then just the infinitely more capable vscode built in one. The ide has "auto complete" which is actually non syntax aware string based comparisons and pales in comparison to clangd or even clion's auto complete. Kiel itself is a truly awful experience from my personal history. There's other reasons that are important for commercial use to use the licensed/closed source tools rather than the open source ones, but we're talking about 'community edition' vs. GCC, Keil won handily in all of the code density tests I did. Now, with Clang, these things might be closer, but when it was Keil (pre ARM) vs. They've optimized the code generation back end so it better than the open source version. Is the "Arm Compiler" a re-branded clang/llvm? There's also plugins for the RTOSes that will let you inspect all the OS objects and who's waiting on what, etc. I'm also regularly inspecting raw memory, loading and dumping it, which I believe you CAN do in GDB, it's just less friendly and not a normal thing. The keil/arm tool has peripheral definitions for most commercial parts (and you can roll your own if need be) that will show and let you edit the fields of the hardware registers. I found myself missing 'memory' windows, and register views.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |