This weekend was spent tinkering with a lot of code and updating systems. I also have a visitor at home for the weekend which is really nice (as I tend to be alone most of the time.) I have also taken up the task of getting FreeBSD installation CDs from the web. My only concern at present is which of my boxes is to be converted. Unlike my earlier days, I now have to take these decisions far more carefully because I have lots of data stored all over the place and would really miss them if I ended up formatting or slicing things again. I have decided to postpone the decision to the end of the week.
The other news is, after a lot of talking and contacting, the neighborhood demolition work is being done professionally. I haven't had to worry too much except about the dust plumes from the site. The coming week would be really important as there are a few of my teammates shifting; and therefore throwing parties out for the same.
Showing posts with label software. debugging. Show all posts
Showing posts with label software. debugging. Show all posts
Sunday, 20 January 2008
Thursday, 27 December 2007
On Cameras and Pictures
This day at work, my boss was down with fever and I was taking up the weekly status review in his stead. It took half the time which was well spent, attendance being thinner than usual. The rest of the day was spent in finding another (sigh!) anomaly with camera images on something we were working on. By the end of the day, we did find an answer to it, but we had created collateral restrictions working on it.
Another friend debunks from work to take a really long New year weekend vacation. That would leave me hunting down more bugs sitting by myself. I do like doing it, but sometimes it can grow to become quite a weight bearing down on oneself.
Coming back to the main thing, Camera's are odd devices - the modern digital video sensors. The CMOS Sensor Interface originally dismissed as a lower quality (and therefore low cost) alternative has gained popularity with much change in technology. Most sensor companies have decided to put a Application Specific Digital Signal Processor with their Sensors. This actually means that even if a CMOS Sensor is sensing video with less accuracy and sharpness than its cousin, the CCD, we could have "patches" or workarounds that "post-process" the captured image and show it to be of better quality in digital terms.
As these sensors are intended to be integrated in very small designs, they are generally low power consuming. That might seem like a feature to most people, however that means strict restrictions in communicating/programming a CMOS sensor. The major part of the problem that I've been tackling through the day has been on sequencing the program to the DSP paired with the CSI (CMOS Sensor Interface.)
Debugging it seems would occupy a major portion of the timeline of any product development. It is sometimes an interesting exercise if you would discount the human communication aspects at the time of facing a blocker and working through it. Mildly put whenever you encounter major problems in any product/service that on sale would fetch revenue, someone needs to be "accountable" for the "delay" (therefore loss of opportunity) in providing a consistent solution (even a workaround if it were reasonably secure and consistent.)
I do remember Alan Cox's speech on ratio of errors in hardware versus software on which I disagree entirely with his opinion that hardware is relatively much more bug free. I see that hardware is designed in a generic manner to send most of the complexity to "replaceable" and/or "upgradeable" software. This would mean that with higher complexity and offer of features over a generic platform, software would take the bane of being more buggy whenever engineered within strict time-frames with requirements changing along side (on the assumption that software can adapt and incorporate changes much easier than firmware/hardware.) Further, I see that a good number of hardware bugs (including the infamous pentium f00f bug) were worked around in "software."
So whenever a system as a total malfunctions, as most of its features rest in software, so do most of the errors (proportional to the features.) Unfortunately this relationship of software[features:errors] is not normally linear. I would assume that the mathematical non-linear relationship is statistically acceptable in any system that is operational with almost 0 probability of total failure and almost unity probability of being functionally useful for a predetermined set of tasks.
With reliability paradigms existing, like 5 nines or 7 nines, it is reasonable to assume that man-made system in an open environment has a 0 probability of failure (and therefore total perfection.) So engineering time spent in tilting the probability of failure towards 0 for any system grows in an asymptotic non-linear manner as you close in on the 0 but never reach it. That's a nice way of looking at "systems with embedded software" and their failure.
The unfortunate part is that I'm right now having to spend non-linear time in creating these shifts to close the probability towards 0. It does become exciting quite often as you crack the jigsaw puzzle a few pieces at a time.
Another friend debunks from work to take a really long New year weekend vacation. That would leave me hunting down more bugs sitting by myself. I do like doing it, but sometimes it can grow to become quite a weight bearing down on oneself.
Coming back to the main thing, Camera's are odd devices - the modern digital video sensors. The CMOS Sensor Interface originally dismissed as a lower quality (and therefore low cost) alternative has gained popularity with much change in technology. Most sensor companies have decided to put a Application Specific Digital Signal Processor with their Sensors. This actually means that even if a CMOS Sensor is sensing video with less accuracy and sharpness than its cousin, the CCD, we could have "patches" or workarounds that "post-process" the captured image and show it to be of better quality in digital terms.
As these sensors are intended to be integrated in very small designs, they are generally low power consuming. That might seem like a feature to most people, however that means strict restrictions in communicating/programming a CMOS sensor. The major part of the problem that I've been tackling through the day has been on sequencing the program to the DSP paired with the CSI (CMOS Sensor Interface.)
Debugging it seems would occupy a major portion of the timeline of any product development. It is sometimes an interesting exercise if you would discount the human communication aspects at the time of facing a blocker and working through it. Mildly put whenever you encounter major problems in any product/service that on sale would fetch revenue, someone needs to be "accountable" for the "delay" (therefore loss of opportunity) in providing a consistent solution (even a workaround if it were reasonably secure and consistent.)
I do remember Alan Cox's speech on ratio of errors in hardware versus software on which I disagree entirely with his opinion that hardware is relatively much more bug free. I see that hardware is designed in a generic manner to send most of the complexity to "replaceable" and/or "upgradeable" software. This would mean that with higher complexity and offer of features over a generic platform, software would take the bane of being more buggy whenever engineered within strict time-frames with requirements changing along side (on the assumption that software can adapt and incorporate changes much easier than firmware/hardware.) Further, I see that a good number of hardware bugs (including the infamous pentium f00f bug) were worked around in "software."
So whenever a system as a total malfunctions, as most of its features rest in software, so do most of the errors (proportional to the features.) Unfortunately this relationship of software[features:errors] is not normally linear. I would assume that the mathematical non-linear relationship is statistically acceptable in any system that is operational with almost 0 probability of total failure and almost unity probability of being functionally useful for a predetermined set of tasks.
With reliability paradigms existing, like 5 nines or 7 nines, it is reasonable to assume that man-made system in an open environment has a 0 probability of failure (and therefore total perfection.) So engineering time spent in tilting the probability of failure towards 0 for any system grows in an asymptotic non-linear manner as you close in on the 0 but never reach it. That's a nice way of looking at "systems with embedded software" and their failure.
The unfortunate part is that I'm right now having to spend non-linear time in creating these shifts to close the probability towards 0. It does become exciting quite often as you crack the jigsaw puzzle a few pieces at a time.
Subscribe to:
Comments (Atom)