Epson and E-Ink developed advanced display controller

[searcher]

From the Seiko Epson press-release today:

Seiko Epson Corporation ("Epson"), a global supplier of semiconductor solutions, and its subsidiary, Epson Electronics America Inc., together with E Ink(R) Corporation, the leading developer and marketer of electronic paper display (EPD) technology, announced a jointly developed display controller IC delivering new capabilities for E Ink's Vizplex(TM)-enabled electronic paper displays. EPD's low-power-consumption screen technology is driving an emerging class of new mobile applications, such as e-books, e-newspapers, tablet PCs, laptop secondary displays, e-notebooks, and e-dictionaries.

The new EPD controller IC (part number S1D13521B) was developed by combining technologies from both Epson and E Ink. It will be offered in production quantities by Epson and as part of E Ink's upcoming AM300 Broadsheet prototype kit.

The Epson display controller will bring greater functionality to EPDs using E Ink technology by speeding up the user interface via seamless navigation, drop down/popup menus, responsive cursors, and real-time keyboard entry. The controller enables the display to perform up to 16 tasks in parallel, and supports smooth and responsive pen input devices for annotations and sketches.

"Epson developed the powerful S1D13521 with E Ink to support new e-paper applications such as electronic newspapers, portable Web browsers and industrial tablets," said Russ Wilcox, president and CEO of E Ink. "With the ability to address many screen regions simultaneously, future devices using this chip could offer a fast menu interface, simple animations, higher grayscale levels, and user input through typing and touch."

The AM300 will be shipping in June and is available online at http://www.eink.com/ for pre-order.

Link: http://www.earthtimes.org/articles/s...e,352446.shtml

Pictured here is the AM 300 prototype kit.

[igorsk]

Sounds nice. Something for PRS-510 maybe?

[Alexander Turcic]

Faster navigation, multitasking, and real-time pen/keyboard input. Wow!

[pilotbob]

But, we probably won't see devices that use this for a year or so.

BOb

[Adam B.]

I'm confused.... Other than a faster reflash, isn't all of that handled by the operating system?

[DaleDe]

Originally Posted by Adam B.

I'm confused.... Other than a faster reflash, isn't all of that handled by the operating system?

While software can be used to do those things, having hardware assistance can be a big help. Providing support for multiple things happening simultaneously in the controller can aid the OS as can providing specialized support for popup menus, for example partial page refreshes that are automatic. Hardware and software working together is always a good idea IMHO.

Dale

[msundman]

Originally Posted by Adam B.

Other than a faster reflash, isn't all of that handled by the operating system?

The OS is orthogonal to the issue. You probably meant to ask: "Isn't all of that done by software on more general purpose hardware?" That's a good question, and IMO that's what should have been done since the first prototypes. After the software is done and tested and devs have figured out which functions they need, and after profiling everything to see what takes most time when it matters most and what consumes most power in which usage scenarios, only then should you optimize your hardware. But epson probably thinks it's more important to create many revisions of those chips (for lots and lots of money, of course) than to help the devs working on them by making things better sooner.

[kacir]

Originally Posted by Adam B.

I'm confused.... Other than a faster reflash, isn't all of that handled by the operating system?

The softraew is supposed to render scenes in a modern 3D games. Look what can software do with some dedicated hardware accelerators - fancy graphic cards.

[seamusfp]

After the software is done and tested and devs have figured out which functions they need, and after profiling everything to see what takes most time when it matters most and what consumes most power in which usage scenarios, only then should you optimize your hardware.

What do you think E Ink has been doing since the development the Librie?

I've seen what Broadsheet can do, and when ebook developers utilize it fully this will allow for some spectacular interfaces.

[JSWolf]

I just fixed the image to show the AM300 and not the AM200.

[msundman]

Originally Posted by seamusfp

What do you think E Ink has been doing since the development the Librie?

I don't know what they have been doing, but AFAIK they have NOT released any software library with the functionality that was described above, but that, as I said, is what they SHOULD HAVE done.

If I interpret the implications of your non-statement above correctly and eink actually has released such software and gathered feedback from the devs then I guess all is good.

Originally Posted by seamusfp

when ebook developers utilize it fully this will allow for some spectacular interfaces.

That's how most new things are, only that a year or two down the road when devs actually have implemented the features they want they've learned how stupidly many details in the systems are designed. (Anyone remember the parhelia graphics chip(set) hype, and how a few details, that turned out to be bad in practice, caused it all to pretty much suck?)

[pilotbob]

Originally Posted by Adam B.

I'm confused.... Other than a faster reflash, isn't all of that handled by the operating system?

It possible can be with alot of code and also the performance is bad. It is like the difference between having a GPU in your PC, and not.

Once the stuff is moved into the firmware:

1. It works much better and faster.
2. Devs can just take advantage of it without writting low level code. They can focus on the features rather than the plumbing.

BOb

[msundman]

Originally Posted by pilotbob

It possible can be with alot of code and also the performance is bad. It is like the difference between having a GPU in your PC, and not.

It's most likely less code than the amount of hardware in the alternative, since the code is higher level than the hardware. It's true that the performance can be much better if implemented in hardware. OTOH, sometimes software is faster because of dynamic optimizations or what have you.

Originally Posted by pilotbob

Once the stuff is moved into the firmware:

1. It works much better and faster.
2. Devs can just take advantage of it without writting low level code. They can focus on the features rather than the plumbing.

1. Huh? It's definitely neither better nor faster to have code in the firmware than on some external medium. In fact, firmwares are often loaded from some external medium.
2. Nobody even hinted at suggesting application developers do the low level code. The alternatives are: provide an API to a software-only library, or provide an API to a hardware-accelerated library. The APIs of these alternatives could be identical, so the app devs wouldn't necessarily even know how much of what is done in hardware. (And again, whether the software is in the firmware or not is of no consequence (except that firmwares can be harder to upgrade, but can thus also be safer from being broken).)

[vivaldirules]

Hmm. Faster, huh? That would be good. I wonder if the screen will flash the way it does now when it redraws. Since they're just changing the display controller I would assume the answer is yes. That would be interesting to see but not necessarily pleasant.

[msundman]

Originally Posted by vivaldirules

Hmm. Faster, huh? That would be good. I wonder if the screen will flash the way it does now when it redraws. Since they're just changing the display controller I would assume the answer is yes. That would be interesting to see but not necessarily pleasant.

The flashing is to prevent ghosting in the display (and I'm sure it's the controller that does it, not the actual display), so it'll stay until eink creates better displays (although it might be optimized so that not the whole screen flashes, just the changing parts).

However, one thing that advanced low level functions should be able to support is to provide non-flashing, local drawing when ghosting isn't so important. E.g., who cares if the menus are a bit ghosted if they are 3 times faster that way? The same should go for other small, momentary stuff, such as pointers, scribblings, highlights, etc. That way you could still have it be somewhat responsive even if the anti-ghosted fullscreen refreshes are awfully slow.