recycling drivers...why not?

nicolad76

Hi....here I am again...
I do not want to re invent what everybody else has done already so I wold like to recycle some code...
Actually I am interested on all those nice routines implemented in VGA drivers.
Let me tell you what I have:
1·prop of course
1 EInk display (2 and 4 bits color)..currently working at 1 bit (for refresh reasons...)
Refresh is half seconds (so plenty of time to do all calculations) in 1bit, 1 sec in 2 bits
The display accepts only streams of bits....1 per pixel of course

Right now I am able to compose nwords by pulling out the bitmap of each char from an EEPROM and putting it on the right place.
It is very hard for me (very new to this level of programming) to write a graphic driver to draw circles, poligons etc.
I was thinking that all those drivers do that already so I could "intercept" their output (directly form the PINs???? - waste of pins probably) and translate it in b/w bitmap

What do you think...could it be done? Which would be the best way to do it?

I have gone trhough some "tile" driver but I do not quite understand how I can get the bitmap out of it since they produce a tile at the time (correct?) and the sequence I need is row by row.......
I am sure some of you can give me a good advice..besides quitting [noparse]:)[/noparse] [noparse]:)[/noparse] [noparse]:)[/noparse]

Thanks!!!!
Nicola
·

stevenmess2004

It should be fairly easy to use the graphics driver for drawing things and then write a driver (to essentially do the same as tv_text or vga_text) to use the tiles. I can help if you want.

The tiles are arranged back to front and are 2 bits/pixel which comes out to 16 pixels/long or one tile wide per long. The tiles are 16 pixels high.

To get a line out of the tiles you need to first locate the start of the row and then simply read in every 16th long.

To find the start of the line will be a little more difficult but not too hard. You have to divide the row by 16 and then multiply by the number of longs in the tile row and then add the row modulo 16... But its not too hard because you can do it all with some simple shifts and masks. Most of the code needed should be fairly easy to find in the graphics driver.

Is the 1 sec refresh time set by the display or your current driver?

nicolad76

Hi Steve,
thanks a lot for your help...I will certantly take advantage of your offert (to help me out [noparse]:)[/noparse] )

The 1 sec is a physical limit of EInk display that's why I want to work on 1 bit...at least refresh is half second (even less actually)....
I will read your replay carefully and try to get something out of it...right now i'm supposed to be working ... instead of surfing internet

I forgot to mention that display size is 800x600...it shouldn't be an issue for the driver right? I am not sure I have seen any VGA driver supporting that size....

stevenmess2004

800x600=60,000 bytes so we won't be able to store everything in a bitmap on the propeller unless you want to add some external memory. That basically means that none of the existing drivers will work although we may be able to modify the graphics driver to write directly to the display. However, that is going to depend on the driver chip for the display and what data we can get back from it. Do you have a spec sheet that you can post for the module?

nicolad76

I'll send it to you soon...anyway...the display driver accepts two kinds of input: full picture and partial picture. They are something like
full picture: send command $A0--> stream of bytes (60K or 120K according to color depth) -->$A1 (stop loading) --> $A2
partial picture: end command $E0-->x1,y1,x2,y2-->stream of bytes --> $A1 --> $E2 (show partial picture)

I have also 3Mbit eeprom working with the prop but I have alway sthought it was not a good idea to use it as video memory since it would take a few hours to reach the limit of 1.000.000 write cycles.

Right now I have no problem at all to display picture read from the eeprom but Iwould like to be able to generate them on the fly....I appreciate your help!!!

Thanks

stevenmess2004

It should be reasonably easy to fix up a copy of the xor_graphics driver to do this. All we need to do is change everywhere that it draws to the screen and replace it with a routine that outputs the data to the pins instead of the hub. We can use the partial picture mode for everything, pixel sprites should work very nicely for small areas of the screen that are in a bitmap form. Vertical and horizontal lines are a special case that can probably be handled fairly easily.

Is there a command to clear the whole display?

nicolad76

Yes, there is a command to clear to screen (it makes it either all white or all black).
How can I take a look to the xor_griphics driver (how does it work?) so I can start checking what I can do? Is it in objexch area?

stevenmess2004

Its right here obex.parallax.com/objects/310/

Its a bit of a monster. It takes up an entire cog and then some more. Its just a modified version Chips graphics driver.

What we need to do is to take out some stuff (probably the bit for drawing individual glyphs since we can do that different ways) so we can fit in more code. The extra code we need is simple something that puts the data out to the propeller pins in the right order (makes it 1 bit/pixel instead of 2 etc.). Than we just need change the 4 places (there is a pixel plot, wide pixel plot, fill code and somewhere else that I have to remember...) that draw to the tilemap in the hub to call the new function that we write. We can also get rid of some of the other stuff like the XOR mode since we probably can't use that. If you want we may even be able to change the vector font so that we can scale it the same as the vector sprites.

It will probably take up more space than if we coded something from scratch but 3/4 of the code already exists

nicolad76

That's great... I'll start taking a look to it. In the meantime I have sent you the specs to your eamil.....

stevenmess2004

Okay, I wonder what happens if we write directly to the sram? Does it update the display or does the change get wiped when you do a screen update?

The problem we are going to have with the partial picture is that we have to update the screen after each partial picture which looks like it may take the whole half second (not 100% sure as the data sheet isn't really all that clear).

Other options are to
1. store the image on the propeller as 400x300 and then make each pixel in the propeller equal to a 2x2 pixel block on the display (takes up 15k bytes of memory but will require a fair amount of change to the graphics driver to make it work in 1 bit/pixel instead of 2)
2. use text for most of the display and just have a small graphics window (that we can move around) or (should be fairly easy but may need two cogs)
3. have some kind of display list and calculate things line by line.

I think that there is a bitmap vga driver that we probably should checkout. I think that that does 1 bit/pixel but I can't remember.

nicolad76

Steve...If I am not wrong, double buffer is used to get a smoother animation...since the display can holds the picture (great quality of eink display) I imagine it is not needed....wuold it save more memory?

nicolad76

well...displaying a partial picture will take the entire 1/2 sec since it will not accpet commands until the previous one is finished. This is what the specs say.
What I am doing now is to use a 20K buffer where I build my string by taking each single char from an EEPROM and attacching them together, then I display a partial picture and I saw that in half a sec I can show more then 1 string where chars are an avarage of 50x40. The time the display takes to show the picture does not depend on the amount of data has to be shown...the most of time is spent turnind those microspheres the display is made of.....

So far my driver uses 1 cog + 1 for the application and I'll need 1 more for parsing the input and showing info on the screen....we would have 5 cogs to use....
I have downlaoded the driver and watched the example...If I could do that on my display it would be already a great result.

stevenmess2004

The buffer in the propeller is so that we can display the whole display at the same time. Otherwise, any change we make to the display will take half a second. So if we were going to draw a line pixel by pixel and the line was 50 pixels long, it would take 25 seconds.

The buffer in the propeller can be either a bitmap or a list of what to display on the screen. The list will be smaller but harder to program (good for mainly text displays). The bitmap is easier but a full bitmap won't fit in the propellers memory (better for graphics). We can also combine the two and have mot of the display using a list but have small areas used for graphics. This gives advantages of both by doing graphics well and actually fitting in the propeller. We could even use more than one graphics area if you wanted.

Is the info you want to display just text or do you want to include some graphics as well? If you do want graphics what do you want? Will the graphics all be in one area or all over the screen?

I think the best method is basically a sprite driver (uses a list) something like this in concept.
Everything you want to display has an x position, y position, x length, y length and a pointer to a bitmap of the stuff to draw. For characters this could point to the ROM characters and for graphics an area of memory where we can draw our bitmap.

To draw stuff we check all the items to check if they are in the current line using the y position and the y length. If any items are on the current line then we get the data for that line and put it in the right place on the line. Then we have a line that we can put out on the display. Then we just do it another 799 times and we have drawn the whole display.

nicolad76

I like the idea of sprite driver. The refresh is so slow that we have plenty of time to build the image.
My idea would be to be able to use graphic on a 600x600 area....I was thinking to get info from a gps and showing speed with a gauge in the center of the screen.
That would be the biggest picture to show but it would still require more than 40 KB.
Just a question....if I correctly understood the idea would be to have a list of objects to be displayed and then we build a line at the time according to the list of objects. Does it mean we can reach 600x800 with 1pixel per bit defintion?

I was looking at the driver and I thought that I will give it a try using 2 bit colors...if I can of course ....it would be interesting to see how the display will react.

Ok....where do we start from [noparse]:)[/noparse]

stevenmess2004

Can we cheat and use a bar graph for the speed display? That will use a lot less memory than a circular gauge.

First thing is to figure out a data format for the sprites. Something like

'object for sprites
VAR
word xStart
word yStart
word dataPointer ' pointer to 
byte wide
byte high
byte type 'allows for different things i.e. characters could come from propeller rom, your eeprom or a graphics bitmap

PUB init(x,y,width,height,data)
  
PUB getAddress

PUB setPosition(x,y)

Then we need to have some code to draw them onto the display.

'main object
OBJ
  sprites[noparse][[/noparse]numSprites] : "sprites"

PUB start
  repeat count from 0 to numSprites-1
    spriteBase[noparse][[/noparse]count]:=

DAT
'assy program to draw sprites
'start
'check y
'if on line then draw to line buffer
'go back to check y until all sprites done
'output line
'do next line

  word spriteBase[noparse][[/noparse]numSprites] ' wrong syntax...
  long line buffer

nicolad76

Probably I am little bit lost here...do we need all the object to be already present in memory as bitmap and then we send out a line at the time or each time the program considers one sprite, we first draw the sprite in a buffer and then we use it? next sprite would use same buffer.....

A while ago I was thinking of doing something like havig all objects codified by a bit sequence..let's say: chars, line, circle, arc etc...each object would have been saved along with x,y,and info depending on the object (let's say if the object is a line then the next bytes would be xx1,y1,x2,y2 and so on...)
When I codified all objects I can manage a list of objects where I can add and remove them.
I have already a 20 KB buffer which means I can virtually prepare 1/3 of the screen at the time. What I would have done is to draw all objects and catch only the pixel included in the first 200 rows. then I would shift up all objects by 200 pixel, redo the same drawing and send out the secnd third of info...then I would shift up again all objects by 200 pixel and draw again. At this point shift down 400 pixel and start over.
I believe that all this can be done in half sec if there arent thousands objects to show....

I hope it is clear enough...english is not my language and it is not easy to explain [noparse]:)[/noparse]

Do you think this would be too difficult? or it wouldn't work? or it is what the driver ou suggest is doing alread?

stevenmess2004

said...
Probably I am little bit lost here...do we need all the object to be already present in memory as bitmap and then we send out a line at the time or each time the program considers one sprite, we first draw the sprite in a buffer and then we use it? next sprite would use same buffer.....

Everything would need to be stored in memory as a bitmap. However, since many things could be used more than once and there is a lot of area on the screen that displays nothing it hopefully take up as much memory.

said...
A while ago I was thinking of doing something like havig all objects codified by a bit sequence..let's say: chars, line, circle, arc etc...each object would have been saved along with x,y,and info depending on the object (let's say if the object is a line then the next bytes would be xx1,y1,x2,y2 and so on...)
When I codified all objects I can manage a list of objects where I can add and remove them.
I have already a 20 KB buffer which means I can virtually prepare 1/3 of the screen at the time. What I would have done is to draw all objects and catch only the pixel included in the first 200 rows. then I would shift up all objects by 200 pixel, redo the same drawing and send out the secnd third of info...then I would shift up again all objects by 200 pixel and draw again. At this point shift down 400 pixel and start over.
I believe that all this can be done in half sec if there arent thousands objects to show....

Yep, we can do this and it shouldn't be too hard. If we divide the screen up into 4 buffers of 600x208 pixels than we will be using about 15.5kB for the buffer. The graphics driver will need modifying to work with just 1 bit/pixel instead of 2. I'll see what I can do tomorrow. It may even be better to break this buffer up into smaller parts and display one part while we are drawing the other part. The drawing will take longer but it will probably still be quicker than sending that amount of data.

Post Edited (stevenmess2004) : 6/20/2008 11:16:26 AM GMT

nicolad76

Hi Steve, I have started playing a llittle with my driver to adapt it to the new solution.
[noparse][[/noparse]quote]
It may even be better to break this buffer up into smaller parts and display one part while we are drawing the other part.

The display is a kind of bad guy...if you want to show a partial image you have to wait for it to be visible in order to draw the next piece. If, instead, we go with the option of using the "full picture" then it would work but the picture will show up only after the 60K have been sent to the driver.
I was adapting my driver to work this way by splitting the screen in blocks of 100 rows...which should take (800 / 8) *100 ~ 10KBytes.
In any case the display will give us about half second to draw all 6 pieces...I guess it is enough...do you think so?

stevenmess2004

Should be but it depends on how much stuff you want to display on the screen.

stevenmess2004

Okay, I think I've got a version of the graphics that will draw some stuff as 1 bit/pixel.

The tiles are arranged like this
1 4 7
2 5 8
3 6 9

If you've got a copy of your current driver I can put it in a demo for you to try.

Ale

Can we get some info on the Eink display, model, supplier, price

The refresh seems slow enough to use an external SRAM to the propeller. A 128 K would do. You can use 2 latches 573 for Addresses A1..A16 (or A2..A1& if you prefer), one or two more address lines, *Cs, *RD and *WE (with an OR gate you can build *CS using *RD or *WE) and 2 ALE signals, a grand total of 8+1+5 = 14 (that can be reduced to 13 using the OR gate). You can merge the 2 ALE signals probably using some more gates. Accessing this external SRAM is not rocket science, you may get a couple of MB/s .

stevenmess2004

The data transfer rate is actually limited by the controller in the display. It takes around 1/2 second to send a screen full of 1 bit/pixel data and 1 second for 2 bits/pixel. The extra memory would be easier to use though. However, the graphics driver will need more rewriting to work with the external memory (would probably have to take some stuff out of the cog)...

nicolad76

Hi Ale,
the display is a 6" and I can tell you that it cost about $80 which is not much compared to the driver you have to buy as interface between the display and your hw. The driver itself costs $200!!!! Do not ask me why I have bought it!!! [noparse]:)[/noparse]

Steve--> My driver (remeber this is my first project ever!!!) has to method to write to the scrren:

ShowPicture(@buffer)
ShowPartialPicture(@buffer,x1,x2,y1,y2)

Do I need to implement a new one to sync with the driver or the ShowPicture would be ok as it is?
Do you want me to send you a copy of the current driver? It should be used to replace to TV.spin of the demo.....

nicolad76

Hi just a note....
[noparse][[/noparse]quote]
It takes around 1/2 second to send a screen full
[noparse][[/noparse]\quote]

Actually the 1/2 sec delay is due to the "mechanic" part of the display (flipping microspheres) but transfering the image take much less...the bus supports 10MByte data transfer!!!! It means that while the display is busy refreshing itself...th eprop can prepare the next image....

stevenmess2004

Its probably not a bad idea to send me a copy. I'll just check that it will work (pointers are setup properly, etc.) and then send it back in a demo. Why on earth does the driver cost so much? It looks fairly simple to me. (just an sram chip and a fairly simple microcontroller and maybe a couple of buffers/mosfets)

nicolad76

Yea..actually if you want to build your own you need their driver (just the chip=$5), two sram+chip for temperature (the driver includes an automatic adjustment for temperature) and a ROM containing a sequenze (depending on the display) used to drive the display ...the one they have sent to me is quite complicated...