@Clemens: Can you please shift your last posting frim IR ti this thread?
Hiwever, I do not understand the image write routine... You take each 8th byte only???
Yes, sorry I posted this too early and in the wrong thread. (I have removed it and will post it here as soon as it is more advanced...)
I took every 8th byte starting from byte 1 in the 8th line, starting from byte 2 in the 7th line, starting from byte 3 in the 6th line and so on.
So the first 8 bytes form the first column the second 8 bytes the second column and so on. (The image in the dat is thus displayed rotated by 90 degrees.)
It worked and I thought it is smart because I don't have to switch rows after each byte.
I guess I better think this over... ...just delete it, please.
The text-scrolling you posted does not work on my display. It just shows half of the "v" and the "a" of "deSilva" for a second and then turns to blank.
Did you change the "MPE_SPI_DOGM_005" since you last posted it?
Tis was extremely stupid of me... I exchanged two lines I don't know when and why...
Corect is:
gdogm.clearpage(page)
gdogm.write(posStr, 4, 0)
I corrected it above.
But during that debugging I found that you inititalize in your driver:
$A1 and $C0 as byte 2 and 3..
I had changed this to $A0 and $C8, and changing it with the "upsideDown" flag only inside the INIT routine, to $A1 and $C6... I must still see why it is $C6 rather than $C0...
Nevertheless I have no strong feelings about what's upside and what's down... We should do the same though... What is the standard orientation from the manufacturer?
Now it's working! Thank You. Very Nice indeed.
Actually wether to use it upside down or regular depends on the usage according to the manual. The angle from where I was taking the pictures is the "better" angle, the display is readable almost until you look flat across it. But I thing the overall readability is really good, so I don't mind either. But when I change the settings to upside down it cuts off the first 4 pixelcolumns and I havn't figured out why that is, yet. So much to learn. And another working day tomorrow...
I just noticed a little bug, that may not be visible on the 4-Line display. A new line is first displayed on the top line and then on the bottom line scrolling up. So the scrolling order is: "0,7,6,5,4,3,2,1" instead of "7,6,5,4,3,2,1,0"
I didn't notice at first because I was confused by the fast scrolling, but now that I made it slower, it is obvious.
(a) I shall look into it; it in fact is "hidden" in the invisible part of my half-display
(b) So I shall configure your angle as normal, and turn my display
(c) The display has 132 columns.. Maybe only 128 are useable when writing in the backwards direction... This might explain why they advertise only 128 pixels. The smaller display is advertised as "132 pixel" and does not have such an issue.. But I shall look into it next weekend
I've just got myself one of the DOGM128-6 displays and have been struggling to find any info on how to use it, so finding this thread is a great relief.
The small font from Clemens looks really nice. Is there a library of a slightly larger font too? Ideally I would like to have a few sizes at my disposal in order to be able to prioritise information on screen.
With larger fonts that run through more than one 'page' (i think this is how the rows are referred to) would it still be possible to scroll the text?
take a look at this thread: http://forums.parallax.com/showthread.php?p=708332
those fonts are generated by scaling down the internal rom font, so they don't look perfect but use up little memory.
At the moment I'm trying to learn assembler by making a driver with screen buffer for the dogm, so one can mix graphics and text.
I am new to assembler (and programming in general) so I guess it will take a long time till I'll have something worth posting.
I have attached another experimental version I made of DeSilva's driver that can display underlined negative bold and regular font.
But please note that this is far from beeing optimized...
Question on backlight control (since it is seperated from the display):
Does the DOG control the C1 and C2 (leds cathode connections) or does it need
to be controlled externally, eg. open collector switch to GND ?
The datasheet for the displays specifies No Connection on pins A1, C1, A2 and C2.
That's right, those pins are not connected to the actual Display electronically, they are just glued or melted onto the transparent plastic on top.
So there is no command to control the backlight, you have to sacrifice another pin like you suggested.
Hi Ray,
Just got a reply to an email to Electronic Assembly, because I wanted to know when the touchscreen sticker for the display (as shown in the datasheet) will be available. I also asked if they have a US-Distributor.
They say they are currently negotiating with Mouser and Allied Electronics. They also have a canadian distributor:
BIRDE Marketing Inc.
CA-Ontario
Phone +1-905-477-7722
Fax +1-905-477-7813
email: toronto@birde.ca
They didn't answer my first question though... :-( Never ask two questions in one email... :-D
I have a very badly programmed asm driver running now. The display accepts SPI at full asm speed. - So I think it is possible to get some greyscales...
My first post to your forum, as yours is the only one I have found with any info on the practical use of the Dog displays.
Am just building my own using the DogL 128x64 unit, using Pic assembler, - and after seeing Clemens excellent pictures - it just raised one question regarding the RST pin 39.
He has tied it to VDD, being the condition for normal operation, however the controller manual states that after power on the RST should be held low to complete a full Hardware Reset at power on.
Clemens display clearly works, but just wondered if any extra code was used when not doing a hardware reset ? or if in general use it has been found beneficial or necessary to do a hardware reset at power on ?
You're right, if you can spare one extra pin it's a good idea to use it to do a hardware reset on startup.
When I restart the propeller while the dogm is receiving data it sometime crashes and I have to turn the power off and on to reset it. This can be quite annoying because the dogm seems to get enough current from the usb-connection to not reset, so I have to disconnect the prop-plug too. It is only a problem while I am programming and debugging of course and no problem at runtime.
Good luck with your project,
As you say, your way is probably fine for testing etc. - hopefully a resistor and capacitor across the RST pin will act as the power on pulse generator rather than wasting an i/o line - will give it a try, when I have the software sorted.
Just another little point - don't know if you have seen it - the chip controller data sheet , page 54, says that you should Refresh the Dram 'regularly' but unable to find any specification as to how often that should be ?? - Do you 'refresh' the dram ?
Thought you might be interested in the link below showing my Dog unit - without using an i/o line for the Reset.
Although coded in Pic assembler, you might be able to make use the RS glcds, particularly the Black and White one, which is very good and clear in direct sunlight.
I'm designing a DOGM128 with touchscreen into a product although I am a little confused about some minor aspects of this product. I am considering using the display in a portrait mode which should be ok I guess (software!) but I'm not sure about the viewing angle. Also, is the touchscreen available for this yet and has anybody used it? I'm trying to figure out whether the screen contacts are on the bottom of the flex etc.
The touch-screen controller chip I'm thinking of using is the TSC2046PW which is readily available. The reason for portrait mode is it makes it easier to display a standard numeric keypad.
Clemens,
What is your overall impression of the display, is it good enough to use in a commercial product? Sure would help if EA had distributors here in Oz as well plus the only way to find out about price and availability is by contacting them.
@ Richard:
Conratulations for getting your driver done.
I never refreshed the Dram as far as I know ...
I have a dirty but working assembler driver for the display but still a lot of cleaning up to do.
I hope one day it will be good enough for the Object Exchange....
@Peter:
I havn't seen the touchpad for sale anywhere yet and Electronic Assembly seems to be interested in big business only :-(
For my current project I used some ordinary buttons, but I plan to get another dogm (hopefully with the touch pad) soon.
I'm very happy with the display. It is very well readable in the dark (with back light) and also in bright sunlight, which is important for me as I am using it on an automated panorama photography tripod head. I'm very satisfied with the viewing angle, but I cannot really supply any numbers in degrees.
I was not successful in producing grayscales however. You can feed the display fast enough (full asm speed) to get a very high framerate but if you try to do grayscales by toggling pixels they won't respond fast enough and tend to be darker next to black pixels, so I guess it is just not meant to be used that way.
It really depends on what you have in mind to judge if it is suitable for a commercial product. It cannot compete with mobile phoene displays in terms of resolution and colordepth, but it is much better readable in sunlight.
Do you thing the touch pad could be read directly with the propeller using Sigma Delta, or is this complete nonsense? I have no understanding of how these devices work (yet).
Re Peter and Clemens comments about touch screens for the EA DogL units - their official stick-on touch screen for the 128 x 64 DogL is a 4 wire Analogue unit, that will require some extra hardware and software.
However EAs 5x3-A touch screen is a 'Digital' switch type that can be fed into any micro port with just a pull up resisistor, and it will just fit onto a DogL unit with a bit of care.
It needs a smd 10 way connector but the pins are on 1mm spacing, so can be hand soldered with a fine point bit.
I purchased my touch screen for £8.50 net from MMSe here in the Uk, and having visited and chatted to the owner Marc, he already ships one off, small orders to diyers worldwide. http://www.mms-e.co.uk/
hm, the datasheet of the DogL states that the "official" touchscreen behaves just like two pots for horizontal and vertical position, so I was hoping I could read it with sigma-delta. http://www.electronic-assembly.de/deu/pdf/grafik/dogl128-6.pdf·(Sorry, German)
Still no way for me to find out yet because they don't sell it to unimportant people like me...
Quote - "Still no way for me to find out yet because they don't sell it to unimportant people like me.. "
Assume from the time you are somewhere in the Americas ?
Do contact Marc at MMSe here in the UK, he told me he does already export small orders to people like us - http://www.mms-e.co.uk/.
He does stock, both the DogL 4 wire X Y Analogue screens as well as the EA 5x3 'digital switch' matrix like the one I showed / purchased.
They are both about the same price. - make sure you purchase the matching little connector as well.
Forgot in the previous post to attach this touch screen pfd that Marc from MMSe sent me on the general use of the 4 wire screens.
Thats why I opted for the simpler 'digital switch' type ! - think trying to code for the 4 wire type in assember a bit beyond my abilities ! - perhaps easier for you ?
I just would liked to say: thank you for this thread! [noparse]:)[/noparse]
I bought one of this type of LCD and had some problems making it work.
This thread helped me a lot! So thanks to everybody who wrote anything in this thread. [noparse]:)[/noparse]
Guys, I understand Clemens and Desilva wrote a font for the 128x64? How do I make a font for the eadogm128x64?
Also, could someone explain the flowchart needed to put text on one line? If I can understand the principal, I can finish the rest of it. Thanks so much for the help.
Nick D
the display is logically arranged as 128 columns * 8 pages. So the first write, starting at 0,0 of the display writes 8 rows of pixels, then increments the column address.
Also note, it never increments the page address without sending it a command to do so, even if the column address exceeds 127.
Since you can't read the displays memory with spi, and you'll have to shift pixels up and down 2 pages in 8bit writes, it's a bit annoying to use.
I've attached a very basic driver I wrote, just to make the display usable for my purposes, it's a xor graphics driver, in spin, manual refresh, gobbling up 256longs of memory just to save the display state.
The font is clemens monospace, and the spiwrite and init routine is desilvas (neat trick putting a $00 string in the dat section by the way)
I'm using the EADOGM-128x64 display. Does anyone know of a command for clearing the display? I know there's one for the 162 and 163. Right now, I'm just using the space character to clear the display, but I would think there's a better way. It takes a while to run through the Ram address by using the space character.
Thanks.
As far as I know, no clearscreen command.
You could try the adc reverse or reset command. If I remember correctly display RAM is unaffected, so it probably won't work
You probably end up iterating through all 8 pages, and write "0" 128 times for each page.
desilvas driver has an example of this, take a look at the clearpage statement, and cleardogm in the dat section.
I am in desperate need of help.... I am using the PIC 32 with the EA DOGM128-6 display with the SPI. Right now I am having trouble configuring it to the SPI. I don't know if its an SPI interface problem or an initialization problem. I will show you my code if someone here has some expereince with it. Thanks.
Comments
' A DOGM Textreader v001 _clkmode = xtal1 + pll8x ' change! _xinfreq = 10_000_000 ' change! OBJ gdogm : "MPE_SPI_DOGM_005" font : "dogfont_1" PUB main|n, addr gdogm.init(0) REPEAT scrollAndSetLine(string("DOGM Textreader v01 by deSilva"),30) REPEAT 7 scrollAndSetLine(string("?"),0) waitcnt(cnt+clkfreq) addr := @theText REPEAT REPEAT N from 0 to 40 ' max characters IF byte[noparse][[/noparse]addr+N] == 13 or N == 30 scrollAndSetLine(addr, N) addr += N+1 QUIT PRI scrollAndSetLine(pos, bytes)| delimiter, posStr, page posStr := string($B0,$10,$FF,$40) page := (byte[noparse][[/noparse]posStr]+1)&7 byte[noparse][[/noparse]posStr] := page|$B0 ' scroll through pages byte[noparse][[/noparse]posStr+2] := 0 byte[noparse][[/noparse]posStr+3] := (byte[noparse][[/noparse]posStr+3]+8)&63|$40 ' scroll through pages gdogm.clearpage(page) gdogm.write(posStr, 4, 0) delimiter:= BYTE[noparse][[/noparse]pos+bytes] BYTE[noparse][[/noparse]pos+bytes] := 0 font.aString(pos) BYTE[noparse][[/noparse]pos+bytes] := delimiter waitcnt(CNT+clkfreq/4) DAT theText BYTE FILE "dogfont_1.spin"Edit:
Exchanged two lines!
Post Edited (deSilva) : 1/27/2008 10:41:10 PM GMT
Hiwever, I do not understand the image write routine... You take each 8th byte only???
I took every 8th byte starting from byte 1 in the 8th line, starting from byte 2 in the 7th line, starting from byte 3 in the 6th line and so on.
So the first 8 bytes form the first column the second 8 bytes the second column and so on. (The image in the dat is thus displayed rotated by 90 degrees.)
It worked and I thought it is smart because I don't have to switch rows after each byte.
I guess I better think this over... ...just delete it, please.
The text-scrolling you posted does not work on my display. It just shows half of the "v" and the "a" of "deSilva" for a second and then turns to blank.
Did you change the "MPE_SPI_DOGM_005" since you last posted it?
Sorry for the confusion.
Corect is:
gdogm.clearpage(page) gdogm.write(posStr, 4, 0)I corrected it above.
But during that debugging I found that you inititalize in your driver:
$A1 and $C0 as byte 2 and 3..
I had changed this to $A0 and $C8, and changing it with the "upsideDown" flag only inside the INIT routine, to $A1 and $C6... I must still see why it is $C6 rather than $C0...
Nevertheless I have no strong feelings about what's upside and what's down... We should do the same though... What is the standard orientation from the manufacturer?
Actually wether to use it upside down or regular depends on the usage according to the manual. The angle from where I was taking the pictures is the "better" angle, the display is readable almost until you look flat across it. But I thing the overall readability is really good, so I don't mind either. But when I change the settings to upside down it cuts off the first 4 pixelcolumns and I havn't figured out why that is, yet. So much to learn. And another working day tomorrow...
I didn't notice at first because I was confused by the fast scrolling, but now that I made it slower, it is obvious.
(b) So I shall configure your angle as normal, and turn my display
(c) The display has 132 columns.. Maybe only 128 are useable when writing in the backwards direction... This might explain why they advertise only 128 pixels. The smaller display is advertised as "132 pixel" and does not have such an issue.. But I shall look into it next weekend
I've just got myself one of the DOGM128-6 displays and have been struggling to find any info on how to use it, so finding this thread is a great relief.
The small font from Clemens looks really nice. Is there a library of a slightly larger font too? Ideally I would like to have a few sizes at my disposal in order to be able to prioritise information on screen.
With larger fonts that run through more than one 'page' (i think this is how the rows are referred to) would it still be possible to scroll the text?
Thanks
Oj
take a look at this thread: http://forums.parallax.com/showthread.php?p=708332
those fonts are generated by scaling down the internal rom font, so they don't look perfect but use up little memory.
At the moment I'm trying to learn assembler by making a driver with screen buffer for the dogm, so one can mix graphics and text.
I am new to assembler (and programming in general) so I guess it will take a long time till I'll have something worth posting.
I have attached another experimental version I made of DeSilva's driver that can display underlined negative bold and regular font.
But please note that this is far from beeing optimized...
Cheers,
Clemens
Does the DOG control the C1 and C2 (leds cathode connections) or does it need
to be controlled externally, eg. open collector switch to GND ?
The datasheet for the displays specifies No Connection on pins A1, C1, A2 and C2.
regards peter
So there is no command to control the backlight, you have to sacrifice another pin like you suggested.
Post Edited (Rayman) : 4/14/2008 5:16:25 PM GMT
Just got a reply to an email to Electronic Assembly, because I wanted to know when the touchscreen sticker for the display (as shown in the datasheet) will be available. I also asked if they have a US-Distributor.
They say they are currently negotiating with Mouser and Allied Electronics. They also have a canadian distributor:
BIRDE Marketing Inc.
CA-Ontario
Phone +1-905-477-7722
Fax +1-905-477-7813
email: toronto@birde.ca
They didn't answer my first question though... :-( Never ask two questions in one email... :-D
I have a very badly programmed asm driver running now. The display accepts SPI at full asm speed. - So I think it is possible to get some greyscales...
http://www.mmselectronics.co.uk/lcdgraphicdog.htm
http://www.soselectronic.com/?str=319&producer=ELECTRONIC%20ASSEMBLY
both have the spec sheet in english.
My first post to your forum, as yours is the only one I have found with any info on the practical use of the Dog displays.
Am just building my own using the DogL 128x64 unit, using Pic assembler, - and after seeing Clemens excellent pictures - it just raised one question regarding the RST pin 39.
He has tied it to VDD, being the condition for normal operation, however the controller manual states that after power on the RST should be held low to complete a full Hardware Reset at power on.
Clemens display clearly works, but just wondered if any extra code was used when not doing a hardware reset ? or if in general use it has been found beneficial or necessary to do a hardware reset at power on ?
thanks
Richard
You're right, if you can spare one extra pin it's a good idea to use it to do a hardware reset on startup.
When I restart the propeller while the dogm is receiving data it sometime crashes and I have to turn the power off and on to reset it. This can be quite annoying because the dogm seems to get enough current from the usb-connection to not reset, so I have to disconnect the prop-plug too. It is only a problem while I am programming and debugging of course and no problem at runtime.
Good luck with your project,
Clemens
Thanks for you quick and helpful reply.
As you say, your way is probably fine for testing etc. - hopefully a resistor and capacitor across the RST pin will act as the power on pulse generator rather than wasting an i/o line - will give it a try, when I have the software sorted.
Just another little point - don't know if you have seen it - the chip controller data sheet , page 54, says that you should Refresh the Dram 'regularly' but unable to find any specification as to how often that should be ?? - Do you 'refresh' the dram ?
thanks
Richard
Thought you might be interested in the link below showing my Dog unit - without using an i/o line for the Reset.
Although coded in Pic assembler, you might be able to make use the RS glcds, particularly the Black and White one, which is very good and clear in direct sunlight.
Richard
http://www.electro-tech-online.com/micro-controllers/40676-glcds-pic-18f-assembler.html
I'm designing a DOGM128 with touchscreen into a product although I am a little confused about some minor aspects of this product. I am considering using the display in a portrait mode which should be ok I guess (software!) but I'm not sure about the viewing angle. Also, is the touchscreen available for this yet and has anybody used it? I'm trying to figure out whether the screen contacts are on the bottom of the flex etc.
The touch-screen controller chip I'm thinking of using is the TSC2046PW which is readily available. The reason for portrait mode is it makes it easier to display a standard numeric keypad.
Clemens,
What is your overall impression of the display, is it good enough to use in a commercial product? Sure would help if EA had distributors here in Oz as well plus the only way to find out about price and availability is by contacting them.
*Peter*
Conratulations for getting your driver done.
I never refreshed the Dram as far as I know ...
I have a dirty but working assembler driver for the display but still a lot of cleaning up to do.
I hope one day it will be good enough for the Object Exchange....
@Peter:
I havn't seen the touchpad for sale anywhere yet and Electronic Assembly seems to be interested in big business only :-(
For my current project I used some ordinary buttons, but I plan to get another dogm (hopefully with the touch pad) soon.
I'm very happy with the display. It is very well readable in the dark (with back light) and also in bright sunlight, which is important for me as I am using it on an automated panorama photography tripod head. I'm very satisfied with the viewing angle, but I cannot really supply any numbers in degrees.
I was not successful in producing grayscales however. You can feed the display fast enough (full asm speed) to get a very high framerate but if you try to do grayscales by toggling pixels they won't respond fast enough and tend to be darker next to black pixels, so I guess it is just not meant to be used that way.
It really depends on what you have in mind to judge if it is suitable for a commercial product. It cannot compete with mobile phoene displays in terms of resolution and colordepth, but it is much better readable in sunlight.
Do you thing the touch pad could be read directly with the propeller using Sigma Delta, or is this complete nonsense? I have no understanding of how these devices work (yet).
Post Edited (Clemens) : 7/22/2008 11:11:03 PM GMT
Re Peter and Clemens comments about touch screens for the EA DogL units - their official stick-on touch screen for the 128 x 64 DogL is a 4 wire Analogue unit, that will require some extra hardware and software.
However EAs 5x3-A touch screen is a 'Digital' switch type that can be fed into any micro port with just a pull up resisistor, and it will just fit onto a DogL unit with a bit of care.
It needs a smd 10 way connector but the pins are on 1mm spacing, so can be hand soldered with a fine point bit.
I purchased my touch screen for £8.50 net from MMSe here in the Uk, and having visited and chatted to the owner Marc, he already ships one off, small orders to diyers worldwide. http://www.mms-e.co.uk/
hth
Richard
http://www.electronic-assembly.de/deu/pdf/grafik/dogl128-6.pdf·(Sorry, German)
Still no way for me to find out yet because they don't sell it to unimportant people like me...
Quote - "Still no way for me to find out yet because they don't sell it to unimportant people like me.. "
Assume from the time you are somewhere in the Americas ?
Do contact Marc at MMSe here in the UK, he told me he does already export small orders to people like us - http://www.mms-e.co.uk/.
He does stock, both the DogL 4 wire X Y Analogue screens as well as the EA 5x3 'digital switch' matrix like the one I showed / purchased.
They are both about the same price. - make sure you purchase the matching little connector as well.
You might find the following thread and code interesting - http://www.mikroe.com/forum/viewtopic.php?t=11953&highlight=touchscreen
- see also Circuit Ed - glcd / touch screens for similar info.
hth
Richard
Forgot in the previous post to attach this touch screen pfd that Marc from MMSe sent me on the general use of the 4 wire screens.
Thats why I opted for the simpler 'digital switch' type ! - think trying to code for the 4 wire type in assember a bit beyond my abilities ! - perhaps easier for you ?
Richard
I just would liked to say: thank you for this thread! [noparse]:)[/noparse]
I bought one of this type of LCD and had some problems making it work.
This thread helped me a lot! So thanks to everybody who wrote anything in this thread. [noparse]:)[/noparse]
Bye!
Also, could someone explain the flowchart needed to put text on one line? If I can understand the principal, I can finish the rest of it. Thanks so much for the help.
Nick D
Also note, it never increments the page address without sending it a command to do so, even if the column address exceeds 127.
Since you can't read the displays memory with spi, and you'll have to shift pixels up and down 2 pages in 8bit writes, it's a bit annoying to use.
I've attached a very basic driver I wrote, just to make the display usable for my purposes, it's a xor graphics driver, in spin, manual refresh, gobbling up 256longs of memory just to save the display state.
The font is clemens monospace, and the spiwrite and init routine is desilvas (neat trick putting a $00 string in the dat section by the way)
Thanks.
You could try the adc reverse or reset command. If I remember correctly display RAM is unaffected, so it probably won't work
You probably end up iterating through all 8 pages, and write "0" 128 times for each page.
desilvas driver has an example of this, take a look at the clearpage statement, and cleardogm in the dat section.