Martin Cowen ⁽⁴⁵⁾

Everyone expects software to be soft. To be easily changeable. At least more easily changeable than hardware. But that is not always the case, sometimes it is easier to redesign the hardware than the software, but why and what do we mean when we say it is difficult to change software? Before the product has shipped, it should be easy to change both the hardware and the software as necessary to achieve the design. After the product has shipped, the hardware is fixed and you can only change the software. But there are often difficulties in changing software that mean it isn't as flexible as it might appear. What do we mean when we say it is difficult to change software? Let's start with what we don't mean. We don't mean that it's too much typing, or too many files,…

Reading data from Excel into a C# or VB.NET program using Interop.Excel.dll can be very slow because each read operation goes through a slow path in Windows (about 50ms), so instead of looping through each Range or Cell object to read one cell at a time, it is much better to read the entire Range (multiple cells) of interest in one go, and then do the looping on an array inside the program, without having to pull data in from Excel on each iteration. First get the dimensions of the sheet you wish to process. Here is a handy function to do that: ''' <summary> ''' Gets dimensions of Excel worksheet, assuming the first used cell is at (1,1). ''' </summary> ''' <param name="w">Worksheet object</param> ''' <param name="numrows">Returns the number of rows found to be used in the sheet</param> '''…

The type 'MainWindow' was not found. Verify that you are not missing an assembly reference and that all referenced assemblies have been built. Microsoft say this will be fixed in 16.3 Visual Studio 16.3 fixed this.

In all the companies I have worked, when the product development is finished it gets passed on to manufacturing and product support but the original developer retains ownership of the design. It's important that the product support department gets full training on how the product works, how to use it, how to diagnose problems in the field and on the bench, and what happens under misuse and failure conditions. But I have never seen a product support department really own the design to the extent that they could diagnose down to component level in the hardware or line of code in the software, which means that the last line of technical support comes back to the R & D engineer. Too often, that last line is perilously close to the first line, such as when the support team are understaffed…

Welcome to my blog, "Commented Out", where I tell stories of product development, finding bugs, solving electronics design problems and generally looking at embedded firmware development and deployment. I've gained experience across a few technologies in my career so far, but electronics and software is a fast growing field which can quickly leave you behind if you don't make an effort to keep up. So I am entering a period of retraining. I'm also going to be using this blog as a way of documenting my progress during my retraining period. I'll be learning a range of different technologies and keeping notes here which I hope will be helpful to others as they start out on the same path, or at least be something for me to look back on as I learn. In some posts, I'll cover subjects which are…