Of course, after spending quite some time on Friday over the logical approach of a puzzle we were trying to crack, a bit of retrospect and lateral thinking brought us to a solution. It does have side effects, but was consistent and stable with respect to the problem we were trying to solve.
That made a good start to the weekend in general. Friday night was spent watching Television. The whole of Saturday did not turn out to be much too different.
I did watch a good movie, "Bug" which is on quite a difficult subject. The movie was given a "Horror-Movie" tag, while it really is more of a drama with a message that is slightly horrific. It deals with group psychosis, a strange thing that is usually not witnessed with such dramatic outlet as shown in the film. Ashley Judd has again proved herself in the movie in her role.
Further, I am working to find out what is really lacking for an opensource developer while creating embedded application development platforms (the entire Operating System underneath including a kernel, bootloader with the core utilities for a system.) There seems to be a considerable gap being addressed by very few projects like "emdebian" and "openembedded." It would be a good time to give these projects some competition.
Sunday, 30 December 2007
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.
Wednesday, 26 December 2007
A Good Christmas!
This Christmas, I chose to have a full holiday from Saturday all the way till Tuesday making it a really long weekend. Mom and Dad visited as planned, and we had a good time together. Bangalore, it seems wasn't as cold as Thanjavur at least for these days as a tropical cyclonic formation had rained cats and dogs there making it much colder. The temperature though with lesser humidity did make me feel quite cold.
Christmas was warm and we had food from a good friend. We all watched more than a fair share of Television as moving around Bangalore wasn't really the in-thing to do. On Christmas day we went over to St.Mark's for the service. It was unusually crowded and we were lucky to get seats in the second row to the left. I did enjoy the service, though earlier I was quite lazy to actually leave for church having coded for my pet-project till late night on christmas eve..
A good friend called and wished me and parents. Many relatives got in touch to wish us all a merry Christmas. Mom had brought two cakes made by a friend and that was really nice. I also had a longish phone conversation with my niece, and also wished my Sis and family. They had braved the Delhi cold for the watch-night service which ended shortly after midnight.
Today, Mom and Dad left for home, which due to bad roads and construction work on the way, took almost 10 hours. They left about 7:20am and reached about 5:15pm which was almost the same time they had taken on their trip to Bangalore. The only other person celebrating Christmas at office (people from Goa having returned to their homes) was Natarajan, D-Link's new Marketing head. My Boss was excited about a movie named "Welcome" and was encouraging us all to watch it.
Indeed, it was truly a merry Christmas! I loved it. It helps me prepare myself for my new-year resolutions which would hold quite strong this 2008, as my ever increasing commitment to new-year resolutions is at an all-time high.
Christmas was warm and we had food from a good friend. We all watched more than a fair share of Television as moving around Bangalore wasn't really the in-thing to do. On Christmas day we went over to St.Mark's for the service. It was unusually crowded and we were lucky to get seats in the second row to the left. I did enjoy the service, though earlier I was quite lazy to actually leave for church having coded for my pet-project till late night on christmas eve..
A good friend called and wished me and parents. Many relatives got in touch to wish us all a merry Christmas. Mom had brought two cakes made by a friend and that was really nice. I also had a longish phone conversation with my niece, and also wished my Sis and family. They had braved the Delhi cold for the watch-night service which ended shortly after midnight.
Today, Mom and Dad left for home, which due to bad roads and construction work on the way, took almost 10 hours. They left about 7:20am and reached about 5:15pm which was almost the same time they had taken on their trip to Bangalore. The only other person celebrating Christmas at office (people from Goa having returned to their homes) was Natarajan, D-Link's new Marketing head. My Boss was excited about a movie named "Welcome" and was encouraging us all to watch it.
Indeed, it was truly a merry Christmas! I loved it. It helps me prepare myself for my new-year resolutions which would hold quite strong this 2008, as my ever increasing commitment to new-year resolutions is at an all-time high.
Sunday, 23 December 2007
When Saturn Smiles
Saturday is usually a pretty gloomy day with not much plan on working things out. This Saturday thankfully was different with my parents at home. There was a lot of the usual conversation that goes on at home; the usual Christmas clothes and more of the Christmas spirit than the decorations which is a lone star in the house that ain't attributed to me.
Nothing else was done through the whole day. Parking arrangements were made where possible to accommodate the car over night. Plans of visiting friends are on schedule; except that most schedules haven't been synced.
Nothing else was done through the whole day. Parking arrangements were made where possible to accommodate the car over night. Plans of visiting friends are on schedule; except that most schedules haven't been synced.
Friday, 21 December 2007
Battling the Passe
My whole day was spent in trying to find the source of a many an issue, each of which, if eliminated would make the product I am working on look more polished. The more critical things having been addressed, these are what I term less critical, but necessary finishing touches.
Yet, when you are working on a product where the components are by and large passe and someone has already done it before, probably better; the only way out in software is sometimes fix the symptom of the problem before you find what really causes it. In most cases tracing aetiology of indeterministic and non-repeatable bugs happens by chance.
I believe that the chief architect of a product must anticipate and understand what is necessary rather than what is best. There must be an incentive for providing in short time the necessary ones before closing in on the best solution which would be an end-point. This requires a vision and imagination of a product long before one has even got to the drawing board. This is the one thing I see lacking in completeness.
Christmas season already having arrived, I would like to think of the pleasant things in life and rather cherish the time than crib about bad architects. One can spend hundreds of hours on a badly designed product and achieve nothing much, save wasting precious time. People justify why they "could not" have achieved better once the design imposes constraints that are hard to work around. Last Christmas a prototype of this product was made ready and had a problem no one anticipated, but the architect decided was good enough. The results were of course discontent remarks. The bridge between expectation and realisation wasn't built right. That would entirely be a PR exercise.
Despite the reasons, I am unhappy at being at the same level one year later. There are so many reasons one can attribute it to. Much could have been solved by stronger investment in testing equipment when there was known uncertainty with Silicon components and problems whose source was too difficult to identify with the limited debugging equipment. No one likes to take a risk that could pay off and get things solved. They'd rather waste time than money, as they have no idea that time in today's world is most of the times more precious than money.
If this product does fail in the market, it would be because of archaic architecture and management that is passe. The use of tools and debugging equipment that is not state of the art has added to the uncertainty. Expectation is a license that is free for all, but not by forcing people to slave longer.
Yet, when you are working on a product where the components are by and large passe and someone has already done it before, probably better; the only way out in software is sometimes fix the symptom of the problem before you find what really causes it. In most cases tracing aetiology of indeterministic and non-repeatable bugs happens by chance.
I believe that the chief architect of a product must anticipate and understand what is necessary rather than what is best. There must be an incentive for providing in short time the necessary ones before closing in on the best solution which would be an end-point. This requires a vision and imagination of a product long before one has even got to the drawing board. This is the one thing I see lacking in completeness.
Christmas season already having arrived, I would like to think of the pleasant things in life and rather cherish the time than crib about bad architects. One can spend hundreds of hours on a badly designed product and achieve nothing much, save wasting precious time. People justify why they "could not" have achieved better once the design imposes constraints that are hard to work around. Last Christmas a prototype of this product was made ready and had a problem no one anticipated, but the architect decided was good enough. The results were of course discontent remarks. The bridge between expectation and realisation wasn't built right. That would entirely be a PR exercise.
Despite the reasons, I am unhappy at being at the same level one year later. There are so many reasons one can attribute it to. Much could have been solved by stronger investment in testing equipment when there was known uncertainty with Silicon components and problems whose source was too difficult to identify with the limited debugging equipment. No one likes to take a risk that could pay off and get things solved. They'd rather waste time than money, as they have no idea that time in today's world is most of the times more precious than money.
If this product does fail in the market, it would be because of archaic architecture and management that is passe. The use of tools and debugging equipment that is not state of the art has added to the uncertainty. Expectation is a license that is free for all, but not by forcing people to slave longer.
Subscribe to:
Posts (Atom)