You might be interested in a chapter I wrote about FreeRTOS's internals for "The Architecture of Open Source Applications, Volume II", an open source book about open source software.

The chapter is free and available here.

And the book is also free.

The FreeRTOS chapter is about the guts of FreeRTOS; it is *not* about how to use FreeRTOS.

I worry a bit about the increasing "cloud-iness" of our data, some of which might be sensitive or even proprietary. I guess that's why I'm reluctant to share stuff via Google Docs, Amazon Cloud Drive, and maybe even Dropbox. But then again, I have a piece of password-management software (Roboform Everywhere) that encrypts my passwords and any other info that I want "safely" to the cloud, where I can easily get to it using any browser...

The apps I use most are: RealCalc (pretty decent scientific calculator with great conversions with data sizes being the most useful for me), TimeCalc, and Now and Then (basically "DateCalc"). I also use ColorNote to replace a short-term engineering notebook... I'm a poor writer (can't even read my ALL CAPS SCRIPT some days) so the swipe action is much more effective for me... talk about COOL technology: swipe! The sound meter has been useful a time or two as well, determining how loud a fan is... the app isn't good above 84dB (useless vs. my car stereo), but I suspect that to be a hardware problem. It is, however, good for lab-level fan noise. I'm in the radio business, so there are a few cell tower trackers and some GPS apps which are pretty interesting, if for nothing more than showing me the GPSs with which I integrate are of better quality than the ones in the phone.

I'm an Android user, and I've come across several helpful apps for electronics and embedded engineering. ElectroDroid is great for reference information on connector pinouts, wire size and ampacity, and the like. It includes a nice ASCII table and calculators for several common formulas. I find myself using it when I'm away from my desk or bench, such as answering questions on the factory floor or in meetings. It's available in a free ad-supported version.

Viewing CAD data on a phone is painful but it can be useful to view a Gerber or DWG that comes in as an email attachment in a pinch. There are many choices on the DWG side, but my favorite is GstarCAD MC. It loads quickly and scrolls nicely, even on a low-end phone.

There are many HP calculator emulators available. If I'm at my desk I still use a real HP35 but if I'm anywhere else I use my phone and Free42 by Thomas Okken. It's fast and has no annoying ads. I haven't found a 16c or 12c emulator that I like but they're out there.

Nuts & Bolts is an app that has data on just what it says. I've taped a tap chart on every drill press I use but they always fall off... now, I just look at my phone. (Not electronics per se, but the real world is still held together with threaded fasteners.)

Everything else I've used, from Wifi Analyzers, to Smith Chart Apps, to Audio Analyzers, is what I would call a novelty. They might be fun to play with, but it is hard to call them useful.

I fully agree, and as a software engineer it disheartens me that so much is done in software with such a great failure rate. We really should be doing better. Personally, I think it comes down to a matter of practicing software as a discipline instead of an art. No, that doesn't mean doing software in the way Carnegie Mellon defines "Software Engineering", which is simply not economically feasible for anyone but NASA; but it does mean:

1. Writing code with purpose, and knowing the purpose behind what you write.
2. Designing the code purposefully, not haphazardly.
3. Sticking to you guns about features and what will be done when (e.g. controlling feature creep).
4. Using a version control system so changes can be managed, even reverted when necessary.
5. Working together as a team, following the coding style of the team not your own.

Too often I run into programmers/software engineers/etc that look at programming entirely as an art. They want to do things their way and only their way. If the team has a coding standard that doesn't match their own, then they do their own - the team be damned.

Too often I run across projects that do version control by copying around directories of the software instead of using free tools like RCS, CVS, SVN, git let alone the many for purchase tools (TFS, PerForce, ClearCase, BitKeeper, etc).

With attitudes like these, and so much lack of control it's amazing that the projects that do succeed do. It's amazing companies like Microsoft have existed at all, let alone for so long. And it's amazing that the public at large (and companies in particular) allow projects to be so poor in delivery, and that companies are allowed to put things in their licensing saying they are not at fault for anything the software does (they should be when it doesn't work as advertised).

What is equally amazing is that the big open source projects that are successful share little on that list. Yes, they often share much of that list as they get going, but as they mature they quickly adopt version control systems (usually git or subversion), get their releases down to schedules, and make anyone contributing adhere to their coding standards (style, etc.). It's high time that companies started learning from projects like the Linux Kernel, QT, Subversion, Apache HTTPd, and many others.

And it's time that the software community as a whole learn to be more disciplined about what they do. There is no space for "Computer Science" in business - it's great in Academia and pure Research, but when it comes to delivering projects we really need to be doing Engineering and not Science; the big difference is practicing the art through a disciplined approach.

Of course, this will only be fixed if both software engineers push for it and follow through; and companies adopt the required practices to enable those environments as well. Without support from Management, companies have little hope of fixing these structural problems that plague the software industry.