I ran into this same problem with a refurbished notebook that I bought last month. The refurbisher had installed a clean version of Windows 7 Professional. Not only could I not get any O/S updates, I couldn't update Internet Explorer or Windows Defender either. I thought I had just bought a totally insecure and crippled system. Before packing it up and sending it back, I did a web search and found a forum post with the answer.

Apparently, the latest Windows Update Server is not backwards compatible with the old version of the Windows Update client service that is part of the clean install. So to get around this problem, I had to manually download just the update for the Windows Update client and manually install it. Once I did that, Windows Update immediately found 100's of updates totaling 750 MB and installed them without a hitch. And now I love my new notebook. Unfortunately, I didn't save the link to the download site for the Windows Update patch, but I am sure it would be easy to find.

The patch I downloaded was a typical Microsoft update with a name in the form KBnnnnnnnn (where nnnnnnnn is a number). I downloaded it directly from Microsoft by going to their page that gave the details for this particular patch.

In issue 312 of TEM, reader Bob Snyder lamented about the painful process of applying all Windows 7 updates into a clean install. I suffered thru that also but found a way to get around it. Microsoft published a single file 'rollup' that installs all windows 7 updates (up to a very recent point). I followed the directions on how-to-geek (link below), downloaded all the files necessary to a thumb drive beforehand and had a clean, fully updated install of Windows 7 up and running in a few hours instead of days. Of course, even after this rollup, there was still a few updates to download and apply, but they were few. You should also locate and download IE11 for Win7 from Microsoft. Even after all the updates are applied, IE remains outdated (I think at v9) and doesn't work with the Microsoft website.

Note: I was not able to download the necessary files from the Microsoft website using the current version of Firefox. I had to use another computer with a compatible version of IE.

http://www.howtogeek.com/255435/how-to-update-windows-7-all-at-once-with-microsofts-convenience-rollup/

The last two months or so, I've been burning some null cycles trying to ponder what makes for well designed vs poorly designed software body, and it is very challenging to get a handle on any objective measures.

Over the last 36+ years - including some time tutoring CS at university and many years as a consultant, I've seen a lot of code. Some has been well designed and some terribly designed. Unfortunately the terrible is vastly more common than the beautiful.

But that assessment has been rather subjective - even very difficult to articulate.

Software is very abstract. From the outside you cannot see software duct tape. Nor can you see a an over-engineered monstrosity that is equivalent to a car built out of I-beams and craft glue.

With enough effort, even the most awfully designed software can be made to run - even reliably, so working or not working is not a good measure.

So far my pondering has only given me two measurements:

1) How long it takes to fix a bug once clear symptoms are known, Does it take a few minutes? Does it take days? Poorly designed code has convoluted code paths which make it very difficult to nail down where something is going wrong. Both well designed and poorly designed code have bugs, but poorly designed code is harder to fix, meaning the bugs live longer and take more effort to kill.

In the 1980s IBM tried developing some quality metrics. One they used was bugs tracked on a module by module basis. What they found was that bugs were not randomly scattered around. Some modules would tend to have more bugs than others. Certainly some modules are more difficult to design than others, but some must surely be attributed to good vs poor design.

2) Code complexity for the job at hand. When there's an order of magnitude more files and code than there should be then the chances are that the code body is poorly designed. The "code effectiveness" is very low and there's a lot of "lazy" code coming along for the ride.

That "lazy code" is often a result of trying to band-aid over corner cases where the main code path fails, or code duplication. Both are signs of poor design.

Neither of these are very satisfactory measures.

I just got around to reading this issue of the muse. I like Andreas Hagele's idea for instrumenting the idle timer, but don't really like the approach with the timer. In particular, he's using 50 timer ISR calls to execute what could be done in 2. IOW, if he dynamically sets the timer's counter value each time, he could save 96-98% of the processing that is associated with this. I.e:

 interrupt void timer_irq(void)
     {
         if(off_duty < SAMPLE_INTERVAL) {
             DEBUG_IO_ON();
             // LED on for some period of time to complete 100ms period
             set_timer_count(SAMPLE_INTERVAL - off_duty);
             off_duty = SAMPLE_INTERVAL;
         } else {
             DEBUG_IO_OFF();
             if(loop_count < IDLE_COUNT) {
                 off_duty = loop_count * SAMPLE_INTERVAL / IDLE_COUNT;
             } else {
                 off_duty = SAMPLE_INTERVAL;
             }
             // LED off for off_duty * 2ms ticks
             set_timer_count(off_duty);
             loop_count = 0;
         }
     } 

Of course, there's more optimization to be done here, but I think this is a good first step.

100ms period for this sort of PWM might will have flicker.... if he's OK using a timer tick every 2ms, I'd opt for a period closer to 20ms total (still only 10 interrupts per 100ms) to reduce noticeable flicker.