E-ink on PICAXE, see it now !

Buzby

Buzby

Senior Member
Last edited:
Buzby

Buzby

Senior Member
The Seedstudio board has links missing from the 6 pin ISP at the end to pins 11,12,13 at the side.

This means it only works on a baseboard with matching ISP pins, such as the UNO.

The AXE401 does not have the ISP, but it will work with a properly compatible shield which has 11,12,13 connected.

The fault is on the Seeedstudio board, not the AXE401.

I later found it had been spotted before : http://www.seeedstudio.com/forum/viewtopic.php?p=16432#p16432
 
hippy

hippy

Technical Support
Staff member
Interesting. In the DisplayChar routine you seem to be sending a unicode character, reading some data, manipulating that, and writing it out again.

I'm guessing that's a two step process because the e-ink display is bit-mapped and there's a separate chip which returns the bitmap tile for the character which is then written to the display ?

I must admit I can't get my head around the X=0-17 and how that maps to vertical pixels of the display but I haven't really read the documentation.

Well done for figuring it out and getting something on the display.
 
Buzby

Buzby

Senior Member
Hi hippy,

The board basically consists of two active chips. One is a ROM which holds 175 different character sets, including Chinese. The other is the silver bar shaped object at the left of the screen. This is the Eink controller. Both chips are on SPI, with a separate CS for each.

The original code was too complex, it handled Chinese and two-dimensional barcode generation intermingled with 'ordinary' text, all specified in Unicode characters.

I stripped it down to just the basics. It inits the system, then for each char reads the pattern from the ROM, twiddles it a lot, then writes it to the display.

The initialistion stuff I copied byte for byte, so I don't really know what it does.

The transformation from ROM to display is weird.
The first job is to duplicate the bits, because the Eink uses 2 bits per pixel. It has 4 grey scale levels.
Then the bytes are re-arranged to fit the display.
None of this was easily gleaned from the code or the datasheets. It took lots of trial and error, and some very peculiar display patterns.

This all seems too complex, there seems to be some kind of 'window' generated for each character, and I'm not sure it needs this, but the display is not easy to understand.

My real aim is to get a big Eink display, I have a use for that. ( Anybody got an old Kindle ? )
 
D

DamonHD

Senior Member
Yes, very good! Would definitely like to consider this tech for my project. Lower power than LCD, ie 0! How long does the display last without power: hours, days, longer?

Rgds

Damon
 
Buzby

Buzby

Senior Member
DamonHD said:
How long does the display last without power: hours, days, longer?
Click to expand...
My wife has a Kindle, and that holds the last display for weeks at least. I've never seen it 'go off' at any time, even when the battery is so flat it won't switch on.

The E-ink technology has it's pros and cons. It's no good for quickly updating, but it's visible in just about any lighting, and really good outdoors.

Trying to get hold of a bigger screen is proving difficult. I'm talking to Densitron, but they want big money for a 5" development kit.

Now I've seen how this driver chip works, I'd be willing to try hacking an old Kindle or similar. ( Brian, thanks for the offer, but I think your Ereader is TFT. )

Cheers,

Buzby
 
W

westaust55

Moderator
Buzby said:
Hi hippy,

The board basically consists of two active chips. One is a ROM which holds 175 different character sets, including Chinese. The other is the silver bar shaped object at the left of the screen. This is the Eink controller. Both chips are on SPI, with a separate CS for each.


The initialistion stuff I copied byte for byte, so I don't really know what it does.

The transformation from ROM to display is weird.
The first job is to duplicate the bits, because the Eink uses 2 bits per pixel. It has 4 grey scale levels.
Then the bytes are re-arranged to fit the display.
None of this was easily gleaned from the code or the datasheets. It took lots of trial and error, and some very peculiar display patterns.

This all seems too complex, there seems to be some kind of 'window' generated for each character, and I'm not sure it needs this, but the display is not easy to understand.
)
Click to expand...
The Nokia 6610 and similar 128/132 x 128/132 colour gLCD displays also use a "box"/area function to fill a space whether with text or a block of colour. Can be faster as it just stalls around rather than needing to keep sending new address/location data.
These displays also have a silver/grey oblong controller chips.
For my past work on the Nokia display see here:
http://www.picaxeforum.co.uk/showthread.php?20181-Using-the-Nokia-128x128-4096-colour-gLCD-with-PICAXE-chips
 
S

srnet

Senior Member
Well the display does look real nice, and having it remember what last powered, is definitely a great power saving feature.

Wonder if the price will come down though, the Eink modules dont come cheap ?

There is a requirement for a low power and small display for many projects where the normal 16x2 line LCD is either just too big or uses too much power.

The Nokia 5110 LCDs displays are certainly cheap (£2) and low power (power direct from a PICAXE pin) but the 14 character x 6 line is a bit limiting.
 
Buzby

Buzby

Senior Member
srnet said:
... the Eink modules dont come cheap ? ...
Click to expand...
Very true !.

This project has cost me an arm and a leg, what with having to buy an Arduino and an AXE401 on top of the rather high cost of the Eink board.

Anyway, now I've got an Eink display and some knowledge on how to drive it, an AXE401 which I'm very pleased with, and an Arduino UNO which is going in the bits box.

I think I have determined that driving a small Eink from PICAXE is a 'sensible' idea, i.e. it doesn't use up too much code or take too long.

Next step is a 5" display, when I can find one at an acceptable price. ( I don't think my wife will let me dismantle her Ereader. )
 
hippy

hippy

Technical Support
Staff member
Buzby said:
The first job is to duplicate the bits, because the Eink uses 2 bits per pixel. It has 4 grey scale levels.
Click to expand...
Ah, yes; forgot about that. That makes sense.

It might be worth comparing how bit-banged SPI out and processing on the fly compares in speed with pre-processing and using HSPI. You could unfold the loops if you have the program space so HSPI would be the best way to go.

It would be nice to know if Kindles etc also have a display driver which is as easy to interface to.

The fairly high cost is the limiting factor for now. The 'txtr' looked interesting. That is an 'e-ink digital picture frame' which shows images of each page of a book rather than doing the rendering itself. It was meant to be very cheap (£10/$13) when bought as part of a phone contract renewal so keep an eye on friends renewing phones.

For the Seeedstudio module, I suppose the X axis (0-17) is best thought of as line number or part line number on which to put text. You could bit bang your own font as is done with the Nokia LCD's. Have you managed to work out the maximum lines / characters using a 7x5 font ? With 172 W pixels that's about 28 chars, though Y axis (0-171) could also be character or part-character position too.
 
W

westaust55

Moderator
srnet said:
There is a requirement for a low power and small display for many projects where the normal 16x2 line LCD is either just too big or uses too much power.

The Nokia 5110 LCDs displays are certainly cheap (£2) and low power (power direct from a PICAXE pin) but the 14 character x 6 line is a bit limiting.
Click to expand...
The Nokia 1100 and 2280 displays at 95 x 65 (instead of 84 x 48) offer a slighlty greater character resolution with ~17 chars x 7 lines.
I developed a pseudo proportional width font scheme a few years back when using th Siemens A55 (102 x 65 pixel) display so that characters such as "i" occupied a slightly narrower space to squeeze in an extra character or two.
 
Buzby

Buzby

Senior Member
Hi hippy,

I'm already using HSPI.

The original code used MSBfirst for one chip and LSBfirst for the other.
I faffed about with bit-banged SPI, then remembered the REV instruction !.

Even that is not needed now, due to your clever EEPROM table, just pre-populated with the bits reversed.
( Next step is to invert the EEPROM patterns, the Eink uses '0' to turn a pixel on. Then I can get rid if the inv in @ptr = inv b0 )

It's the uncertainty about the Kindle's etc. driver that is putting me off spending £45 on a display.

What's this 'txtr' thing ?. I've not seen it.

The mapping of the Eink screen is something I've not investigated closely yet, I just got it going using the settings that the Arduino code used.

One of the biggest problems with these modern displays is how to physically connect to them.
This unit has a tiny 24 pin connector for the ribbon on the display. There is no way to put this on a bit of stripboard !.

If I get time over the next few days I'll investigate the mapping.

Latest code attached.

Cheers,

Buzby

View attachment Eink_8.bas
 
hippy

hippy

Technical Support
Staff member
Buzby said:
What's this 'txtr' thing ?. I've not seen it.
Click to expand...
Google's your best bet. One review pulled at random ...

http://www.guardian.co.uk/technology/2012/nov/08/beagle-e-reader-review

Not sure if it's available in the UK yet. The idea was to sell it alongside a phone package and cross-subsidise it that way and through selling content, so just a one off payment of a tenner when renewing a contract. The standalone cost looks to be more like £60+ going by American prices which rather destroys its USP ( unique selling point ) which was incredibly low hardware cost.

If the market were flooded with £10 e-ink readers the hackers would undoubtedly have been all over it which is why it was notable.
 
hippy

hippy

Technical Support
Staff member
Code: 
for i = 0 to 7
	   ptr = i
	   b0 = @ptr
		b1 = b0 | $0F : Read b1, b1
		b0 = b0 | $F0 : Read b0, b0
	   ptr = i + 16 : @ptr = inv b0
	   ptr = i + 24 : @ptr = inv b1
    next i
You can invert the bits in the EEPROM data as well as having reversed them to save on the INV. There are also tricks you can play with 'ptr' to speed things up. Untested ...

Code: 
for ptr = 0 to 7
  b1 = @ptr | $0F
  b0 = @ptr | $F0
  ptr = ptr + 16 : Read b1, @ptr
  ptr = ptr +  8 : Read b0, @ptr
  ptr = ptr - 24
next
And with a more subtle tweak; "16" takes up an extra 4-bits than "15" does, so probably takes longer to process -

Code: 
for ptr = 0 to 7
  b1 = @ptr    | $0F
  b0 = @ptr[b]Inc[/b] | $F0
  ptr = ptr + [b]15[/b] : Read b1, @ptr
  ptr = ptr +  8 : Read b0, @ptr
  ptr = ptr - 24
next
I'm sure you can fold the three FOR-NEXT into one or two so you don't need to store and then have a loop to send the data out. The less you do the faster it should be.
 
Buzby

Buzby

Senior Member
There is another technology that holds the display after power off, it's called 'reflective cholesteric liquid crystal'.

There is only one manufacturer I've found, Kent Displays.

Worse than that, I've only found one supplier, and they are down to their last unit : http://proto-pic.co.uk/kent-display-240x160x2-9/

( And it's more expensive than E-ink ! )
 
You must log in or register to reply here.
Top