Entries by Aki

The decision by Toshiba to drop HD DVD was just enough motivation for me to find out for myself which standard is ultimately better: HD DVD or Blueray (I'll name them HD and BD from now on for simplicity). I don't want to rehash the marketing glossies which overlook the entire mess of the implementation. In fact, I believe that the only useful pieces of information from the marketing slicks are the following:

1. HD stores about 15 GB per layer, and 30GB per side of a disc.


2. BD stores about 25 GB per layer, and 50GB per side of a disc.


3. HD uses "HDi", a combination of XML and JavaScript for interactivity, with the specification inspired by Microsoft.


4. BD uses a subset of Java for interactivity, with the specification inspired by Sony.

Continue reading "May the Best Hi Def Win" »

I'm not an Apple-agnostic person. A bit over two decades ago I owned and liked my Apple IIc with its wow-factor portable LCD display. Sometime later my desk was graced with the original Mac right alongside an Amiga and a PC. But with my usability and let-me-do-what-I-want requirements, the Apples were replaced by an almost endless succession of various PCs and portable devices.

Now I'm back to an Apple product, as I bought an iPhone. Frankly, I had not really planned to do so, but it was the culmination of circumstances that were perfectly aligned for that outcome. First, T-Mobile that I've used for many years has service at my house that for lack of a better term stinks. That combined with the declining firmware quality of Nokia phones (which is the brand that I've used almost exclusively because of their intuitive and task-centric user interface) gradually getting to the point of unacceptability. Finally, over the years I had already looked at several of the traditional Nokia competitors, such as Motorola, Samsung, NEC, and Sony-Ericsson, but found their firmware to be uniformly buggier than that of even the worst Nokias, and the user experience to be far from intuitive.tations.

Continue reading "What's Wrong with iPhone" »

By now you might have heard of the Amazon Kindle, the e-paper based reader, that allows wireless access to a vast library of electronic books from Amazon, and some selected blogs, newspapers, and such. There is even "experimental" access to the internet, though it's not very powerful, and is geared around static data only. I won't rehash more of the publicly available details on the unit, but give an inside peek at the guts of the unit.

One of the things that I noticed right away is the limited set of file formats that Kindle supports. Glaring omissions were the popular PDF format, and all forms of images, such as JPG and TIFF. Amazon provides a service that can be accessed for free and for fee, that converts image files to Kindle format. However, the service seems a bit slow, and requires the the file must be e-mailed to be converted.

To see what it can do, I used the service to convert several image files. The result was an image file that apparently had a maximum size and maximum resolution. An analysis of the files that were produced showed a header, followed by some HTML code, and then a binary image file. What appeared to be some closing bytes appeared at the end of the file.

With a hex file editor I cut&pasted the obvious header and footer, and placed them around some JPG files of my own. The resulting combinations did appear in Kindle as files, and were even partially viewable as images.

Kindle, however, seemed to refuse to display images above a certain size. While I did not determine the exact cut off point, it seemed to be somewhere around 64kB. An image larger than 64kB would only display correctly for information in the first 64kB. The remaining pixels were shown in a uniform pleasant gray.



I can't tell if the behavior is an intentional limitation in the Kindle software, a CPU-driven feature (e.g. 16-bit registers), or caused by memory constraints. I wanted to find out, hence I had no alternative to popping the covers on the unit.

The unit is relatively easy to open. There are 8 screws, all accessible without peeling labels. The corners of the plastic case have tabs with a very firm grip, but they will pop with an even pull on the side while pushing the top cover in the opposite direction. (Kids, if you have never done this before, or if you are worried about having a broken Kindle, don't try this at home.)



The interior of the unit was not exactly crowded. There is one main circuit board, with attachments for the keyboard, the displays, main power switches, scrolling mouse and the SD card adapter.



The AnyData DTEV-DUAL cellular modem is connected using a board-to-board connector, but its shell is permanently soldered to the main circuit board. It seems to have two antennas, one on the top, and one on the bottom right side of the unit.



The main microcontrollers are a Microchip PIC16LF874A, NXP ISP1761BF and Intel PXA255. The purpose of the PIC part is unknown, but a hunch based on its location is that it provides handling for the scroller and the keyboard. The NXP part is a USB-On-The-Go controller, which means that it can also function as a USB host, even though the Kindle only supports being a USB client device. The Intel part is an X-Scale ARM processor, which likely is the main processing unit for the Kindle.



Audio is handled by a Wolfson Microelectronics WM8971 Stereo codec that seems to be driven by another small PIC microcontroller marked "6282E/7270SH". The latter could also be memory or a voltage controller, but I had insufficient time to determine its type.



Memory on the unit is present in two Infineon 256 megabit Mobile-RAM parts, giving the PXA255 a total of 64 megabytes of RAM, accessible over a 32-bit bus. There are two Samsung K6F4016U6G chips that provide 1 megabyte of SRAM, accessible over a 32 bit bus, which are either working memory for the NXP part, or more likely video memory. Firmware is stored in a Spansion 512 megabyte boot-sector Flash, type S29AL004D90BFI01.



The display controller is the same as on the Sony electronic book series, a part marked "9322 571 0032 1 Apollo 1.18 T6TW8XBG-001".



The only part that remained a minor mystery is marked KFG2G16Q2M-DEB8 from Samsung. It is located next to two ADG3247 bus switches. It appears to be a 2 gigabit Flash part (256 megabytes). Its proximity to the bus switches might mean that these provide for sharing of the Flash between the NXP part when USB is connected to a PC, and the Intel PXA255 in the normal operating mode.



The last parts worthy of mention are a LM75A and a LTC3455. The LM75A measures temperature, and is likely used to avoid overheating the battery and the cellular modem. The LTC3455 provides battery power management, charging, and DC-DC conversion to change the variable voltage of the battery to a fixed voltage for the internal electronics.

Conclusions

Now that I know what's inside the unit, it's easier to say where limitations to functionality are intentional and where they are not.

First, there appears to be no good reason for this system to not handle large images. The CPU thinks in 32 bit, there is plenty of memory, and video output is not generated on the fly, but stored in SRAM. Hence, the limit is arbitrary.

This system should also easily be able to handle compressed and encrypted PDF files, making that limit arbitrary as well.

The USB-OTG controller is interesting, as it means that the unit might have future applications beyond what's apparent.

Hacking Opportunities

I'm not about to start hacking my Kindle, but it's apparent that serious hacking opportunities are present. The PXA255 is a common MCU, and its firmware comes from an external flash. The file system is likely on the other flash. And access to all is likely to be easy, since the board seems to have JTAG connectors and connection points for programming the various microcontrollers and memories. One of the connectors is even accessible while the case is closed, just by popping off a small access panel next to the battery.

If you end up hacking your Kindle, please let the world know what you find!

At PC-Doctor we've been busy with some hardware projects for some time now, and so we experienced the daily excitement that only Hardware Description Languages like Verilog can provide.

Working with Verilog provides a virtually endless stream of insights to someone who has mostly focused on software in the past. Where else is the parallelism of hardware execution so glaringly exposed and laid bare for unsuspecting programmers to trip up on?

For instance, I can, by omitting a single �<� character, change a previously happily humming expansion board to one that likes to eat motherboards for breakfast. Trust me, it's not a pretty sight when a motherboard starts popping capacitors in response to a bug in the firmware that was missed by the simulation test bench.

Some might say that VHDL is also an HDL and provides its users with the same capability for creating excitement, but I disagree. The formal definitions and verbose expression of VHDL hides the raw nature of the work. Reading VHDL gives me the same sort of creepies as ADA would to any honest C programmer (ADA, as in the programming language, not the disabilities act, diabetes association or dental association). It's possible to get in big trouble with VHDL, too, but it takes a lot more typing on the keyboard, just like it takes a lot of trying in ADA to cause the damage that a single careless pointer reference will do in C.

In case you didn't know, Verilog began its life as a language for simulating and modeling hardware designs. It was developed by Automated Integrated Design Systems in the early 80's. The company soon renamed itself to Gateway Design Automation, perhaps due to an obvious conflict with the initials of the company name. Gateway was later acquired by Cadence, who made Verilog an open standard in the mid 90's.

The cool part about Verilog is that it was intended to model and simulate hardware. This means that it makes twiddling bits and defining hardware features incredibly easy. Sort of what C did for software when it was introduced.

A major difference between software and hardware design is the difficulty of validating a hardware design. While a good software design always includes an associated test suite, it's possible to design quite extensive software projects based on manual execution and �debugging on error�. Needless to say, this is not a wise approach for hardware designs that can experience a wide range of problems, including self-destruction in the right circumstances.

A particular aspect of modern hardware design is the clocking that's used to synchronize events within the design. Clocks are forced on hardware designers due to difficulties in reliably predicting the switching characteristics of gates, transmission lines, etc., that make up an integrated circuit. Rather than trying to figure out switching times for every possible gate transition, and adding circuitry to make sure that outputs only change from one final state to the next, it's far easier to agree on a time limit within which every part of a design will respond to a change in the state of inputs, and allow outputs to toggle as they may in-between.

This is where the infamous @ (posedge clock) steps in. It is the command that forces a wait until the next positive edge of the agreed-upon synchronization method, the clock signal. A design without at least one instance of that magic phrase will often mean bad things for the implementation of the design. (Volumes have been published on this topic; just search for �Verilog� and you'll get more details if you want them.)

I used to not like the idea of the clock. Hardware switching is incredibly fast, yet clock synchronization forces an effectual wait-state on all but the very slowest logic-sequence. Why would I want to give up significant processing bandwidth to a synchronization scheme?

I was not alone in being unhappy about clocks. Just read http://www.eetimes.com/in_focus/embedded_systems/OEG20030606S0034 and http://www.eetimes.com/story/OEG20011025S0074.

To add to the allure of clock-less design, it is not difficult to write such designs in Verilog, requiring merely a switch to event-based flow instead of clock synchronization. Simulating clock-less designs is no different than simulating clocked ones.

Unfortunately the implementation on actual hardware is a can of worms. The designs that we create are implemented on CPLD and FPGA parts. These are essentially collections of logic gates with interconnections. The interconnections and the logic gate functions are programmable, which makes the whole chip do what we want. What I found out is that trying to synthesize a clock-less design will eat up a significantly higher number of chip resources than a clocked one, and will in many instances have bad timing characteristics.

The problem seems to originate with the switching and signal propagation delays inherent with all electronics, and the implications this has on clock signals. In order to minimize clock �skew� to a large number of gates, CPLD and FPGA vendors implement additional propagation circuitry for clock traces, and hence designate only a relatively small number of traces as clocks. Some parts have as few as 4 of them, others 60 or more, but these are always a relatively small proportion of the available traces.

The small number of low-skew clock traces becomes a problem in a clock-less design, where an implied clock is carried from one processing block to the next. Once the number of implied clocks exceeds the number of available low-skew clock traces, the design will incur significant bloat as synthesizing and fitting tools attempt to make the limited resources do what the designer wants.

Things are made worse with the difficulty of predicting behavior across clock domains, which means that fewer of the synthesizing tools' size and performance enhancing optimizers can be applied.

Perhaps things would be different if we were working on ASICs that allow the designer more freedom in stating what takes place where. Things would also be different if FPGA vendors were to introduce additional �local� or �mini� clocks, that could be used to implement a large number of implied clock domains.

But since we don't work on ASICs, and the FPGAs we work with don't have cool clock domain features, we are stuck with the clock. We just better love it, because hating it won't change a thing.

[display_podcast]

I just read about yet another Lithium ion battery spewing flames (http://www.wsbtv.com/news/14271878/detail.html). This one was from an iPod Nano, but it would be unfair to claim that it happened because it's an iPod. In the past we've all likely seen or heard of the Dell laptop that caught fire in Japan, and the ur-event itself, the first portable Mac that did the same. And how could one have missed the massive Li-ion battery recall of just a year ago, which affected pretty much every brand of laptop in the market. The latest is the Nokia recall of Li-ion batteries, specifically the BL-5C. See http://batteryreplacement.nokia.com.

The problem with Li-ion batteries is their ability to self-ignite under certain conditions. This is best described in an article all by itself, and here are two good links for it: http://computer.howstuffworks.com/dell-battery-fire.htm and http://en.wikipedia.org/wiki/Lithium_ion_battery.

Now it's obvious that there are many safeguards built into Li-ion batteries, and considering their massive use in most portable electronic devices, the number of failures is very small. But what's next?

I usually don't like to ring the caution bell, but the potential for trouble from Li-ion is significant. Had the Dell laptop fire occurred on-board an aircraft, instead of inside a meeting hall, it would have posed a whole new set of challenges. No, I don't believe a plane would catch fire or crash, but it would be a very unpleasant experience for many.

What I'm worried about is the aggregation of more Li-ion batteries to achieve with battery power what used to be done using other forms of energy storage. Mainly I'm thinking of electric cars, but this concern is not limited to the application itself.

On the upside, electric car batteries can employ additional safeguards that are difficult to implement in size- and weight-limited portable electronics applications. However, while portable electronics can expect the occasional drop, they don't have to undergo a 60-to-0 transition with significant plastic deformation of the containing frame (fancy words for a high speed crash).

I don't believe the question as to what happens to lithium ion batteries when they are violently deformed and short-circuited has been explained with sufficient clarity. Wishing or by calculation determining that there is no issue is akin to the thought process that left the Ford Pinto fuel tank the way it was.

Then again, if we were all worried about trying new things out, I would have taken a horse buggy to work today, and I'd be writing this out by hand, dipping my pen into a container of ink to recharge it every now and then.

Perhaps the middle ground is to be aware of the issue and look for better alternatives. Not too long ago I had an interesting conversation about the new breed of super capacitors coming out. The applications are endless, such as notebook battery recharges in seconds, but the repercussions of short circuiting one of those can be even more spectacular than with Li-ion. But that's a bit too far out for us to worry about for right now. Suffice to say that it's the consumers who decide what they buy or don't buy. Sadly, the car industry figured out the hard way that safety does not sell. Will it be the same for electronics?

[display_podcast]

One of the great things about working with diagnostic software is the great stories that for the most part go untold. I don't mean the obvious stuff about computer illiterate users trying to scan pages by holding them to computer screens, or using optical drive trays as cup holders. These are funny, but they can be found everywhere. Like airline passengers asking for window seats because they like to open the window for fresh air.

Nah. I'm talking about the good stuff. How about this one (it's real.) A computer user reported to technical support that flushing his toilet made his computer reboot. Now how would anyone figure that one out?

It turned out that this user was living in a rural area, and the water pump to the house would cause a brown-out, and that in turn would reboot the computer. Flushing the toilet would cause the water pump to turn on, and thus was a reliable mechanism for replicating the problem. Kudos to the unsung heroes of technical support for a major PC maker for figuring this one out.

Or how about the computer company that had a zero-tolerance policy for good hardware that was returned by technicians as bad. This reportedly was in response to a large portion of hardware returns by field-techs being no defect found (NDF) . Shortly after management instituted a charge-back for NDF returns, the rate dropped to near zero.

What prompted a review of the policy was the fact that the volume of parts being returned didn't change much, only now nearly all of them were truly broken. It turned out that prior to submitting �bad� hardware for return, techs would �assist� the parts to show obvious failures. I can only imagine field techs making a stop at the local 7-11 at the end of the day, and going to work on their return inventory with a stun gun.

And then, there was this (to go unnamed) audio card maker, whose card would fail our tests but pass theirs. For months the maker blamed our tests as faulty, and we checked and rechecked our code to look for what might be wrong.

Finally the PC maker in the middle trying to decide to use the cards or not was able to obtain a copy of the source code for the passing test from the audio card maker. The code was extensive, and should have done the job of testing the card very well had it not been #ifdef'd out and replaced by two print statements and a delay. Something like �print testing�, then a delay, and �print passed�.

There are more great stories, but the untold stuff is even better. These are the stories I can't tell you about (though I wish I could) unless you work for PC-Doctor. Anyway, there's the one that explains why a couple of years ago the entire PC industry went through a major hard drive crisis. Or a similar crisis relating to capacitors not much before that. Or why certain ground-breaking processors from a major manufacturer never really made it in the marketplace. Or the latest about a major software manufacturer situated in the Pacific Northwest. Or why I would never use PCs from certain makers.

But it's time to get to the point of my story. We are looking for more talent. If you have what it takes to work with us, why don't you join us. You'll also be able to hear the juicier stories that I can't tell you now, and be there to experience new ones, too.