War of IDEs and a curious observer

Long long time ago, I wrote on my blog, that I’ll be learning ARM architecture in the coming months and in last 10 months or so, I did quite a lot of coding for ARM Cortex M0 based SOCs. Today I thought, I’ll reflect, just a little on what I learned in those ten months and share my thoughts on rather a very important aspect of Commercial Embedded Systems development; IDE (Integrated Development Environment)

I had very little exposure to Embedded systems development before I joined my current place of work. I did worked as Firmware Verification Engineer for a Semiconductor Company, but the Firmware verification was done on a hosted environment and the target product was a very complex ASIC. I was verifying Firmware by writing user land applications in ‘C’ and quite infrequently (Since that was not my primary task), looked at the Firmware code  which was also written, mostly in C. Few years later, I ended up in a school, pursing Masters program in Computer Engineering and as part of the curriculum learned basic Embedded Systems programming (During bachelor’s study, I did assembly programming for 8051 Microcontroller, but, that was purely for learning Assembly language purposes) and enjoyed it and also struggled quite a lot, while working through the reference manual, data sheet, and code samples, etc. The code was written for bare metal without any abstraction (only bare minimal abstraction provided by the C language itself). Back then, I didn’t care the portability, reusability, modularity or any such “Software Engineering Jargon”, and  when I got to know that I’ll be working on Embedded Systems, I was getting excited and worried at the same time. I was excited because, I enjoyed programming those tiny hardware and was worried because, I assumed that once again, I’ll be doing this wiring by hand kind of coding, which is quite time consuming and frustrating at times (RCA of bugs in those programs is very difficult, if not toughest). However, I was taken by a little surprise, when I saw the actual commercial level code. It was much more readable and far easier to follow through than the simple code I wrote during the lab session in my college.

Now, After spending 10 months, I can’t stress enough the importance of “Software Engineering practices” in the world of Embedded systems. These two worlds are closer than we think they are. Unless there is really strict time constraint requirements, using abstraction is a better choice. Abstraction is very important for writing clean code. Designing good implementation and interfaces pays off very well in the long run. A commercial embedded solution is developed by many engineers and effort should be made to make the code as readable as possible. I was also surprised to see, how little assembly level coding I was doing. I was under the assumption, that I’ll have to learn the ARM ISA in detail, but So far, I had to refer the ISA only while debugging some code.

For example, I would almost never do even as trivial as setting a bunch of bits of some registers by accessing them directly in my application code.

FLASH_CR2 |= 1 << 2;
while (FLASH_STATUS_REG &= 1 << 3);

Or something as simple as translating some readings into a meaningful value as:

val = (264 * 32 ) / 24;

These above are dreadful and could be easily replaced by a much more meaningful looking code. The rant will go on and on, but I’ll save it for a future or rather on a series of future posts. Another thing that I want to talk is IDEs. IDE aka Integrated Development Environment for Embedded Systems are quite expensive and has a significant impact on time to market. The choice of IDE is even more important for Startups, since a typical startup will have to be frugal with it’s funds and be super fast in delivering product to the market, I believe, they should spend some time in narrowing down their requirements and do some kind of evaluation on plethora of options that are out in the market currently. IDE’s typically combine the cross compilers (I’ve a x86_64 bit machine on which I need to compile a code which will run on a ARM32 machine), and lot of other goodies such as flash programmer, debugger, code analysis tools etc. But those goodies come with a big price tag. Somewhat similar goal could be achieved with freebies (Long live FOSS) but that may require a steep learning curve and extra hours. So, when I found myself in the middle of IDE war, I prepared a list of few most famous IDEs for ARM development that I _know_ of. My requirement was to find a suitable development environment for STM32 and NRF51 based SOC solution. Good thing is that the part number that I’m using are both ARM Cortex M0 based MCU and hence it was comparatively easier for me.

The table below is one such comparison list of IDEs and in __my__ particular situation,  Keil comes as the winner. Using GNU Toolchain is very attractive (specially from the cost effective point of view), but since in real life, typically one works in a team, and choices are made for the entire team, rather than for a particular team member, GNU Toolchain (Shown in Yellow in the table below) came at spot number 2 on the most favored Embedded Systems development tool of our choice.

 

 

ARM n00b: Genesis

First and foremost, Why should I care to learn ARM architecture?

Well, the ARM aficionados may have million reasons, but for me the reason is that I might soon start working on developing some applications on ARM platform as part of my Internship. That’s all. I’m planning to keep my learning experience logged somewhere so that the future me can come back here for quick reference and maybe, just maybe these series of logs will turn into a good ARM resource for beginners like me. So here’s my ARM Odyssey!!!

P.S.

This and the future logs by no means are only technical. What do you expect from a n00b? Rather, it will be full of anecdotes with __some__ technical stuff.

I

I read about ARM processors and architecture in haphazard way for a day or two and then joined the ARM community portal. Looks like a good place to learn and discuss various topics surrounding ARM based Solutions(Sounds like a sales pitch, but I don’t know how else should I put it as there are various ARM implementations, however, it does sound cheeky to me). There are plethora of documents on Internet and on ARM website and I was starting to loose my mind (One should never loose his mind, never) and then my moment of enlightenment came; I checked the data sheet of the target board for my would be-could be project and that’s how I came to know that I should be focusing on ARM cortex M0. It is one of the entry level ARM core for low power application. So A note for myself and word of advise to others, Do check the datasheet of the target board for processor information before plunging into sea of datasheet, errata, manuals, application notes, Programmer’s guide(Yes I’m that stupid, I wasted one fine sleepless night).

Funny how life plays roller-coaster with one. Next day, I found out that I’ve access to the online library of Knovel (many thanks to TTU) and hence I can read “The Definitive Guide to the ARM Cortex-M0” online. Awesome 🙂

The next day went in online flipping few pages from this book and making strategy on how to best read this book and how to ramp up quickly.