This is what I've been saying all along; it could have easily been caused by some lazy programmer who didn't check a return value, overlooked integer overflow, or made an inappropriate type cast.

On the other hand, I do agree that there is a large chance that it could be due to 'ground bounce' or other EM noise. However, the electrical & computer systems on automobiles should really be considered one in the same. They are the left and right hands of an entity and need to communicate effectively with each other. If there is electrical interference, then the signal processing system should take that into consideration and filter it out. If there is too much electrical interference, then the electronics should be re-designed!

Wouldn't it be hilarious if you were pedestering in some urban center, and you notice two guys with the same 'sun glasses'. Then those two guys notice eachother, and then a virtual light-saber battle ensues?

Then somebody takes out their Nexus One to instantly upload a video of that event to youtube, and by the time you pedester to your destination, you could backtrack on Google Maps and find a link to an augmented video of the entire event. Wouldn't that be cool?

Yeah, it would be pretty cool. Of course, I would never engage in a virtual battle like that personally because that is waaaay beyond my geek tolerance, but it would be entertaining as a spectator ;-)

I think Yahoo has actually been slashdotted :o

This could actually be somewhat useful.

( 0 - 1 ) mod 8 = 255 mod 8 ? Could also be some lazy ass not properly checking the sign of a return value (-1 often usually means error), and then passing it to another function as an unsigned value. Funny that people often think that dsp / computer engineers have less pressure to be legally responsible for the breakages caused by their broken code. If a wall fell over and killed someone because the engineer messed up the decimal point, then there would definitely be some legal action.

JTAG is intentionally excluded from my argument

First of all, it's important to distinguish that RS-232 is just a signalling convention. RS-232 requires an RS-232 transceiver, exactly the same way that USB requires a USB transceiver. Both of these technologies are for serial communication. Both of these technologies can be backed by a UART (see Catsoulis) but USB often skips the UART backend, opting for direct access instead. What you're really talking about is replacing the traditional RS-232 transceiver with a USB transceiver on devices. Sure, why not?

Reason 1) a UART is absolutely crucial for OS debugging, boot loader debugging, and recovery from corrupt nand, because it's cheap, simple, and sufficient. Often (especially when reverse engineering a device) a UART can be the only way to interact with the OS during the porting phase.

Reason 2) Although most (decent) OS have a USB stack that will work in both host and device mode simultaneously, often there is some external hardware preventing direct usage of an OTG or USB-device port (e.g. VBUS sensing). Interfacing with a UART requires no knowledge of external circuitry aside from pin configuration.

Reason 3) Lower-level 'operating systems' that run on microcontrollers or DSP often do not have such a sophisticated USB stack. UARTs are just simpler.

So now that we know complete replacement is unlikely... I can tell you that the USB console you're asking for is already here (with varying protocols). The protocol is determined by the device in question (either statically or at runtime) and will typically be one of i) CDC Ethernet / RNDIS, or ii) CDC Modem, but custom protocols are also possible.

CDC Ethernet is essentially what you're looking for in terms of 'auto-negotiating' baud rates, but you still need to configure the Ethernet / IP layers. Drivers exist for most decent host operating systems, and even Windows!

The device in question needs to have an OTG or USB-device port, neither of which you're likely to see on x86 or x86_64 chips without external hardware (AFAIK manufacturers assume that x86 chips are always the host in a USB transaction). On the other hand, most ARM SoC have had an OTG or USB-device port for years already.

+1, again

+1

I completely agree with this statement. Having personally hacked android on to 3 devices that it was never intended to run on, I can say that the Android platform is even more consistent than windows mobile, or the iPhone OS. In fact, its even more consistent than a standard desktop Linux like Ubuntu. Furthermore, Linux (which is of course the pivotally important part of Android) runs on more platforms than any other operating system in existence. Linux itself does more than provide a 'consistent' API, it provides a POSIXly correct API, which is fathoms more than any other mobile OS can say.

As for variations between hardware (e.g. some device supporting multi-touch, some not) - the same API is running on all of them - there are no differences, Android uses what the Linux kernel provides.

Lastly, with respect to different UI features provided by various companies (HTC Sense, MotoBlur, etc), developers target their apps according to a common API. The presentation (the look and feel of the UI) is also done according to a certain API.

This topic really is a non-issue, whoever even brought it up likely forgot to eat their wheaties this morning.

Chuck Norris doesn't even need to attack them, they just submit because they know he could fry their CPU with a single packet!