Gary,
Thank you for your extensive and philosophic point of view. I just don’t understand how Nokia is related to the problem…
It is clear that at some point in time some bug has slipped into the TI SoC ADC kernel drivers or the touchscreen drivers that use these ADC drivers
If your talking about touchscreens interfaces and LCD screens, your very likely using code written by Nokia or one of the other major cell phone manufacturers. If there is a “bug” in the code it is likely that they wrote it. Because the code DOES work under a different version of Linux and works under versions of Android - it is not even fair to say the the driver has a bug in it. The driver works for the system it was written in. Why it doesn’t work in later versions of Linux may be because there was a true bug which only showed up when something else in the kernel changed. It may also be that there were changes to the api functions being used by those drivers which changed the way they work. The word bug tends to be taken negatively, as in the programmer of the code containing the bug made a mistake. In the case of changing API’s there was no “mistake”.
To understand why you have to understand how Linux itself is developed. There are thousands of drivers in the codebase for different items. For those drivers to get into the source tree they must compile AT THE TIME THEY ARE ADDED, they must follow Linux Coding Standards, they must work AT THE TIME THEY ARE ADDED, and they must be licensed under the GPL.
Once they are IN the codebase then when changes are made to any of the functions they use, the programmer making those changes MUST run an automatic program to find every single call to that function and fix them - hopefully the process will be automatic. Those changes have to follow the same rules as above PLUS every bit of code that they modified[all the drivers] must still compile successfully. Note: it doesn’t have to WORK, it just hast to compile. That is because it would cost millions of dollars to test every single bit of hardware[since you have to have access to every single bit] to ensure that the drivers still function. The best that can be reasonably expected is that they compile.
A better word to use is incompatibility - as you simply have no idea where the “bug” is so unless you specify each and every component that is being integrated then saying there is a bug in X companies code comes across as blaming the companies listed.
As for why I went into the long explanation, you were making comments about how TI expects “the community” to support their product for free - so I was giving you the true picture - how is a symbiotic relationship and how in this case your benefiting from work done by TI and Nokia - and that “the community” is expected to modify that work for their own usage if needed.
. What I am angry about is that CircuitCo (and 4D Systems) know about the problem. Besides the fact that they don’t do anything to fix it (although afaik they have good people working on Angstrom), they could at least post a notice on their product’s webpages so customers don’t have to chase where the bugs come from for weeks.
The comments in this thread indicated to me that they contributed to fixing the problem - in this case identifying where they think the problem lies and therefore cutting down on the time needed to debug code.
I will agree 100% that CircuitCo should update their product pages to include notices of compatibility issues as well as listing a known good software version compatibility matrix. I only agree about 60% that 4D Systems should be doing this as well.
The fact that they have still not done it makes me think that they want to keep their sales high. Again, the prices for the LCD boards are not low and we cannot talk about break even here.
We can’t? Consider the following:
SainSmart makes a similiar LCD module for Ardunio:
http://www.sainsmart.com/arduino-compatibles-1/lcd-module/sainsmart-3-2-tft-lcd-display-touch-panel-pcb-adapter-sd-slot-for-arduino-2560.html
It costs 16$. If you go to ebay you can find similiar products for 12$.
Compare this to CircuitCo’s 3" board:
http://www.mouser.com/ProductDetail/CircuitCo/BB-BONE-LCD3-01/?qs=2TuNuDMZFZ5UQcnBUi0fGw%3D%3D&gclid=CIy6vY7n67kCFUWd4AodLxkAqg
Which is 70$.
So what are the differences? Well, first of all, the pin layouts for the boards are completely different. BeagleBone capes have 2 rows of pins, while the Ardunio board has 1 row of pins. I know that pins seem like a nothing cost, but the truth is that every time you add big bulky items to a board - you increase production costs. So taking a stab in the dark, I’m going to guess that we added 4$ to the cost of the card(20$). In addition to this, a beaglebone cape needs an EEPROM on it which is programmed with the device tree configuration of the card[to allow the bone to automatically detect the card and configure itself]… So let’s call that another 5$ since while the chip may not cost much, we added another step to produce the board where the chip needs to be programmed and tested(25$). Lastly, the Ardunio is an extremely popular product - so for every 1 BeagleBone cape sold, let’s say 100 Ardunio capes could be sold. Production cost is directly related to how many you build, so I’ll guess that the cost is halved for making 100 of a product vs 1[or 100,000 vs 1000]. So that brings the comparable cost up to 50$.
50$ vs 70$… Yes the price seems high, but it is not twice my rough estimates, so I’m gonna give them the benefit of the doubt.
Keep in mind, due to this price difference I myself am planning on getting the Sainsmart module and seeing if I can get it to work…but then I also consider hacking away at it entertaining. So I am not the type of person to feel that the price difference is trivial. I just would not go around assuming that the pricing is inflated because I lack sufficient experience in pricing board production to make any sort of fair estimate. I know enough to know that there are lots of variables that affect cost - and I know enough to understand that all the numbers I come up with I am pulling out of my but.
You have one valid, in my opinion, complaint: CircuitCo and 4D should post more information regarding compatibility on their product pages. The problem is it is buried in so many other comments that I don’t consider reasonable that it is hard to differentiate.
Based on observation of your comments here, I can only assume your comments were written in the same manner when communicating with CircuitCo and others privately. This puts into question your interpretation of their response as a “lack of response”. I expect that they responded to the more serious seeming comments about “lack of support” and completely overlooked the “provide notice for future customers” part. Or that they stopped responding when you appeared to not accept their response and became repetitive.
I’m not trying to insult you and I apologize if it comes across that way. I’m trying to explain why some of your assumptions are incorrect - why many of your comments appear inflammatory - and how to go about things in a more productive manner.
The following phrases:
“We are not responsible for…”
“That is not our product…”
“Developers are expected to fix incompatible code…”
“We do not produce software…”
These are all, in my opinion, infuriating statements frequently made when discussing bugs. They appear to be shifting responsibility. In truth though they are stock phrases with a dual purpose:
-
When an employee of a company is trying to help you and going into detail about potential fixes. This opens them up to liability because “he said it would work if I did…”. So they often pepper their comments with these disclaimers to remind you that what they are doing is a FAVOR to you, not something they or their company is required to do.
-
When the comments they are responding to come across as extremely inflammatory - these stock phrases are a more professional way of saying “your acting like a complete jerk and upsetting my mental well-being”.
So you have to learn to not take those comments personally and note that they have been made and try to modify your phrasing to appear less confrontational.
