In the case of JNI that has to be marshalled between native and managed code, and that’s where the sluggishness comes. The problem for these Java based IDEs is that to talk to the debuggers they have to use an inefficient interface to make multiple function calls with significant amounts of data. My complaint is that on-target debugging can be done slickly and well, as I found in uVision, and has been the case in the past before vendors jumped on the Eclipse and Netbeans bandwagon for IDEs. Please understand that I was brought up on this stuff in the 70s when on-target debugging was either non-existent or prohibitively expensive, so I’m well aware of, and still use, very many other techniques. Adding GPIO twiddles, high speed serial, printfs or other real time telemetry, for example, have their own pitfalls as well. There are many strings to your bow when debugging, I use the most appropriate at the time, which is often using the on-target debugging features. I’m not sure what you mean by “slow and cumbersome” when compared to other options, surely that depends on the what you’re trying to achieve. Why on earth should you avoid on-target debugging? It’s provided for a reason. It's at least ten times what I'd be willing to pay, and it's on an annual semi-subscription. So why won't I be using Keil going forward? One word, price. The debugging aspect alone shows why Java is a bad choice for cross platform IDEs, both Eclipse and Netbeans are evidence of this, it's slow, breaks a lot, and often takes some time to get working. I've not really got along with CCS for some time, the way library and directory structures are defined is complex and takes a while to understand, especially if you want to do things properly. Interestingly, I gave up trying to get the project to work on CCS. I repointed the project to the newer Tivaware I already had installed and the project I had worked right away. The exception was the TI board, where an older TI Tivaware library wasn't available for download, not even from TI: they don't seem to provide Tivaware archives, an important ommition in my view for supporting and maintaining old projects, the semi-TI official excuse being that "not much has changed so it's low risk". In all three cases, the project files I had been provided with downloaded all the appropriate support libraries. The automated pack loading feature is another area which other vendors should consider. Debugging and programming is really quick, with the exception being that single stepping didn't work on the STM32 board at first, although when I tried it again just now it works fine. Each board I was up and running in between five and fifteen minutes. (Interestingly enough, I gave up trying to get TI's CCS to work). This has not been the case with uVision, despite the three different dev boards, all using their own integrated debuggers. Typically when you start of on a new dev environment, you spend some time understanding its nuances, and most often you end up in a fight to get the hardware debugging to work reliably. 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. 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.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |