Dave,
Any chance Jack Smith's SED 1335 Module will make it into an official SF module? I am looking at a project for these lcd's and this good be very handy. I contacted Jack and he seemed open to the idea but wanted to talk with you first.
Swordfish SED 1335 Module
Moderators: David Barker, Jerry Messina
-
David Barker
- Swordfish Developer
- Posts: 1214
- Joined: Tue Oct 03, 2006 7:01 pm
- Location: Saltburn by the Sea, UK
- Contact:
Jacks module does not currently hook into the default Swordfish GLCD library. He wrote it before the main Swordfish GLCD module was conceived, so it is very much a stand alone implementation (which works very well). However, because it does not hook into the main GLCD module, you don't get features such as variable width fonts etc.
I'm certainly looking towards adding more GLCD driver support - this is one of many benefits of using Swordfish, it is really quite easy to hook in a new driver to the main GLCD library.
I bought two GLCD modules some time ago, based around the S1D13700. This is a replacement for the older SED1335. There are a few minor differences, but if you are looking at a new design then you should consider using the S1D13700 rather than the SED1335.
Many companies have switched over to the new driver. For example, Jack bought his original 320x240 display from Crystalfonz (www.crystalfontz.com) in early 2006. This was based around the SED1335. If you take a look at their stock now (late 2006) they are all based around the S1D13700.
Also, if I understand correctly (and I may be wrong) the SED1335 is not RoHS compliant, but the new S1D13700 is. I don't know what part of the world you are based, but if it is in Europe or you plan to ship a unit into the EU then you will need to go with the S1D13700.
In summary
(1) I do plan a 320x240 GLCD driver, but it will be based around the S1D13700
(2) Jacks module will drive the SED1335, but not via the Swordfish GLCD library. I think it would be a fairly easy task to hook it into the Swordfish GLCD module though. Even so, you should seriously consider using the S1D13700 rather than the older SED1335.
I'm certainly looking towards adding more GLCD driver support - this is one of many benefits of using Swordfish, it is really quite easy to hook in a new driver to the main GLCD library.
I bought two GLCD modules some time ago, based around the S1D13700. This is a replacement for the older SED1335. There are a few minor differences, but if you are looking at a new design then you should consider using the S1D13700 rather than the SED1335.
Many companies have switched over to the new driver. For example, Jack bought his original 320x240 display from Crystalfonz (www.crystalfontz.com) in early 2006. This was based around the SED1335. If you take a look at their stock now (late 2006) they are all based around the S1D13700.
Also, if I understand correctly (and I may be wrong) the SED1335 is not RoHS compliant, but the new S1D13700 is. I don't know what part of the world you are based, but if it is in Europe or you plan to ship a unit into the EU then you will need to go with the S1D13700.
In summary
(1) I do plan a 320x240 GLCD driver, but it will be based around the S1D13700
(2) Jacks module will drive the SED1335, but not via the Swordfish GLCD library. I think it would be a fairly easy task to hook it into the Swordfish GLCD module though. Even so, you should seriously consider using the S1D13700 rather than the older SED1335.
Last edited by David Barker on Sat Nov 11, 2006 8:48 pm, edited 1 time in total.
Dave & Ryan:
I've posted the module code to my web page at http://www.cliftonlaboratories.com/GLCD_Page.htm.
I've placed an order with Crystalfontz for a quantity of the new S1D13700-based displays on September 20th, and was told they would be shipped around October 14th. When received, I will immediately test them for compatibility with my current code, as these are to go into Z90 Panadapters that I wish to ship the first week in November (supposed to be when the last long lead time parts arrive). I will surely post a note on my update page to that effect, as it is a major milestone to completing the Z90 project and shipping kits.
When Dave gets an official 320x240 library ready to go, I'll port my code over to it. (I suspect that I will have a chance to test an advance copy as well.) Dave has a copy of my code for some months now and has provided very usefull suggestions during my work on it and is free to use any parts that might provide useful in the real library.
The GLCD module was my first Swordfish code and I would do things differently if I were starting over, but it works and has proven stable.
Jack
I've posted the module code to my web page at http://www.cliftonlaboratories.com/GLCD_Page.htm.
I've placed an order with Crystalfontz for a quantity of the new S1D13700-based displays on September 20th, and was told they would be shipped around October 14th. When received, I will immediately test them for compatibility with my current code, as these are to go into Z90 Panadapters that I wish to ship the first week in November (supposed to be when the last long lead time parts arrive). I will surely post a note on my update page to that effect, as it is a major milestone to completing the Z90 project and shipping kits.
When Dave gets an official 320x240 library ready to go, I'll port my code over to it. (I suspect that I will have a chance to test an advance copy as well.) Dave has a copy of my code for some months now and has provided very usefull suggestions during my work on it and is free to use any parts that might provide useful in the real library.
The GLCD module was my first Swordfish code and I would do things differently if I were starting over, but it works and has proven stable.
Jack
Jack, Clifton VA
Jack,
I have been using crystalfontz's 128x64 lcd's and have been wanting to stepup to those same modules that you have purchased but was hoping to avoid writing all the lcd routines myself. Thanks for posting your code and I am very interested to see how things go with the displays you have ordered.
I have been using crystalfontz's 128x64 lcd's and have been wanting to stepup to those same modules that you have purchased but was hoping to avoid writing all the lcd routines myself. Thanks for posting your code and I am very interested to see how things go with the displays you have ordered.
Good news on the display.
As I understand the story from my conversations with a Crystalfontz engineer, there are now two versions of the display and controller board; CFAG320240C0-FMI-T and a CFAG320240CX-FMI-T.
The "X" unit employs the SS1D13700 Controller and the "0" unit uses an RA8835 "fully compatible solution" replacement for the S1D13305. http://www.mitsutech.com/RA8835.html
Brian, the engineer, said that the "X" versions are supposed to be compatible with code written for the S1D3305 (SED1335), which is in the units I've been using for development. But, he said, it is important that pins 19 and 20 of the "X" interface board be left floating and not be grounded. Of course, when I designed the Z90 PCB, those two pins were unused and I followed good practice and grounded them. He said some some customers have reported timing issues with the "X" versions, perhaps related to these pins.
The "0" unit, he said, is supposed to be 100% compatible with the the old S1D3305 (SED1335) based controller.
I received one "0" sample and one "X" sample today and started by hooking up the "0" unit. It plays perfectly with my existing Swordfish code and hardware. At that point, I decided not to even open the "X" sample package will return it to Crystalfontz.
So, I can say that my library will function with the CFAG320240C0-FMI-T display and other Crystalfontz variants that use the RA8835 controller.
As I understand the story from my conversations with a Crystalfontz engineer, there are now two versions of the display and controller board; CFAG320240C0-FMI-T and a CFAG320240CX-FMI-T.
The "X" unit employs the SS1D13700 Controller and the "0" unit uses an RA8835 "fully compatible solution" replacement for the S1D13305. http://www.mitsutech.com/RA8835.html
Brian, the engineer, said that the "X" versions are supposed to be compatible with code written for the S1D3305 (SED1335), which is in the units I've been using for development. But, he said, it is important that pins 19 and 20 of the "X" interface board be left floating and not be grounded. Of course, when I designed the Z90 PCB, those two pins were unused and I followed good practice and grounded them. He said some some customers have reported timing issues with the "X" versions, perhaps related to these pins.
The "0" unit, he said, is supposed to be 100% compatible with the the old S1D3305 (SED1335) based controller.
I received one "0" sample and one "X" sample today and started by hooking up the "0" unit. It plays perfectly with my existing Swordfish code and hardware. At that point, I decided not to even open the "X" sample package will return it to Crystalfontz.
So, I can say that my library will function with the CFAG320240C0-FMI-T display and other Crystalfontz variants that use the RA8835 controller.
Jack, Clifton VA
I received two "X" version (uses an SS1D13700 Controller) 320x240 displays today and plugged one into my Z90 test unit to see how compatible it is with the code for an S1D3305/SED1335 controller.
Not good ... nothing on the display. As per the "X" series data sheet, I left the controller board pins 19 and 20 floating.
There are some timing differences between the old and new controller and I need to sort out those changes.
Not much chance of that happening for a while as I am still deep into getting the Z90 kits ready to ship. And, I was thrown backwards today when it turned out that the random sample front panel I looked at three days ago when unpacking the boxes was a fluke -- one of the few decent looking paint jobs. So I am now dealing with 85% of the panels having unacceptable paint jobs and my supplier saying that the replacements will take 50 days or so. Ugh!
Jack
Not good ... nothing on the display. As per the "X" series data sheet, I left the controller board pins 19 and 20 floating.
There are some timing differences between the old and new controller and I need to sort out those changes.
Not much chance of that happening for a while as I am still deep into getting the Z90 kits ready to ship. And, I was thrown backwards today when it turned out that the random sample front panel I looked at three days ago when unpacking the boxes was a fluke -- one of the few decent looking paint jobs. So I am now dealing with 85% of the panels having unacceptable paint jobs and my supplier saying that the replacements will take 50 days or so. Ugh!
Jack
Jack, Clifton VA
Just to let everyone know, I've now started work on an official Swordfish driver for the S1D3700 based display. Thanks Jack for posting your code some time ago - I intend to make heavy use of this. Once I've completed the library, if anyone is interested in testing it before it is officially released, please let me know.
Kind regards,
Steven
Kind regards,
Steven
Last edited by Steven on Sat Nov 11, 2006 7:00 pm, edited 1 time in total.
If you have a Crystalfontz S1D3700-based display check the 8080/6800 mode jumper.
The data sheet says that the board is shipped with the jumper in 6800 mode, but in a telephone conversation with a Crystalfontz engineer today, I learned some early shipments were jumpered for 8080 mode.
It turns out that both of my displays are jumpered for 8080 mode. I quickly changed one to 6800 mode and plugged it into my Z90 test bed...still no display. (Pins 19 and 20 are NC during this test.) Although I expected that result, I still hoped to be pleasantly surprised.
Jack
The data sheet says that the board is shipped with the jumper in 6800 mode, but in a telephone conversation with a Crystalfontz engineer today, I learned some early shipments were jumpered for 8080 mode.
It turns out that both of my displays are jumpered for 8080 mode. I quickly changed one to 6800 mode and plugged it into my Z90 test bed...still no display. (Pins 19 and 20 are NC during this test.) Although I expected that result, I still hoped to be pleasantly surprised.
Jack
Jack, Clifton VA
Steven:
The controllers I have match the data sheet and the jumper is labeled J68-J80 with the legends showing where the zero-ohm jumper is to be placed.
I hope to have some time to tinker with the display in the next week or two. Reading the data sheet lead me to believe that the CX display would be a simple conversion from code running on the C (or C0) display, but that looks like it might not be the case.
Jack
The controllers I have match the data sheet and the jumper is labeled J68-J80 with the legends showing where the zero-ohm jumper is to be placed.
I hope to have some time to tinker with the display in the next week or two. Reading the data sheet lead me to believe that the CX display would be a simple conversion from code running on the C (or C0) display, but that looks like it might not be the case.
Jack
Jack, Clifton VA
Jack,
Thanks for the info. It turns out that the display that I am using is set to 8080 mode - it is not a CrystalFontz display. I have had some success - when I run the initialisation routine, the screen at least turns on now. I think that I must have the command and set data sequences correct for 8080 mode, as it responds appropriately to the command to turn the screen on at the end of the sequence. However, all I get on the display is a series of horizontal lines at random positions (these vary when I power down and up again). I do clear the contents of the buffer memory, but this does not clear the screen.
I suspect that the initialisation sequence is wrong, so I will check this carefully next, but if you have any further ideas, I would be grateful for any further help.
Regards,
Steven
P.S. I'm planning to make the library capable of running a display in 6800 mode or 8080 mode with a #option GLCD_MODE switch.
Thanks for the info. It turns out that the display that I am using is set to 8080 mode - it is not a CrystalFontz display. I have had some success - when I run the initialisation routine, the screen at least turns on now. I think that I must have the command and set data sequences correct for 8080 mode, as it responds appropriately to the command to turn the screen on at the end of the sequence. However, all I get on the display is a series of horizontal lines at random positions (these vary when I power down and up again). I do clear the contents of the buffer memory, but this does not clear the screen.
I suspect that the initialisation sequence is wrong, so I will check this carefully next, but if you have any further ideas, I would be grateful for any further help.
Regards,
Steven
P.S. I'm planning to make the library capable of running a display in 6800 mode or 8080 mode with a #option GLCD_MODE switch.
Success!!! I found a suggestion on the Microchip forums - a delay of 300us after the command before sending the parameters does the trick - this may only be needed during initialisation - I'll look into this.
I'll also have a look at the Wait line - it may be that I need to implement this - I've been lazy so far and tried to ignore this - this might have been my mistake!!
Steven
I'll also have a look at the Wait line - it may be that I need to implement this - I've been lazy so far and tried to ignore this - this might have been my mistake!!
Steven
Congratulations. Once you have the initialization working, the rest is not nearly so difficult.
Let me give you my take on the wait line ... the display memory is not dual ported, and hence the controller chip cannot simultaneously accept or send data to the PIC and also send refresh data to the LCD pixels.
The data sheet recommendation is thus to write and read the data bus only during "retrace" intervals, i.e., time when the controller is not refreshing the pixels. The percentage of time the LCD spends in the refresh period seems to be in the 15-20% range.
So, if you limit access to the retrace interval (when the wait line indicates OK to read or write data), your potential throughput is reduced by a factor of 5:1 or 6:1.
My Z90 code does not limit data access to the retrace interval as I cannot afford the throughput penalty. The consequence of this is that if you look closely at the display screen, you will see flashes of horizontal lines at random locations. These flashes are the pixels not staying in their proper values due to the controller being busy talking to the PIC over the data bus at the time those pixels need refreshing. Since the refresh rate is rather high, the duration of the artifacts is short and they are not noticeable unless you are looking for them.
In my case, as in others, I suspect, these artifacts are an acceptable price to pay for faster access. In other applications, the artifacts would be objectionable and hence data bus read/write should be restricted to the retrace interval. My recommendation is to give the user an option of retrace access or full time access.
The older controller does not have a wait line; instead the micro is supposed to poll the bus and wait until a go-ahead message is received, a far from efficient protocol, as it means your micro is tied up waiting for go ahead messages. Adding a separate wait status line is a major improvement, as it admits of an easily implemented interrupt-based write procedure.
Jack
Let me give you my take on the wait line ... the display memory is not dual ported, and hence the controller chip cannot simultaneously accept or send data to the PIC and also send refresh data to the LCD pixels.
The data sheet recommendation is thus to write and read the data bus only during "retrace" intervals, i.e., time when the controller is not refreshing the pixels. The percentage of time the LCD spends in the refresh period seems to be in the 15-20% range.
So, if you limit access to the retrace interval (when the wait line indicates OK to read or write data), your potential throughput is reduced by a factor of 5:1 or 6:1.
My Z90 code does not limit data access to the retrace interval as I cannot afford the throughput penalty. The consequence of this is that if you look closely at the display screen, you will see flashes of horizontal lines at random locations. These flashes are the pixels not staying in their proper values due to the controller being busy talking to the PIC over the data bus at the time those pixels need refreshing. Since the refresh rate is rather high, the duration of the artifacts is short and they are not noticeable unless you are looking for them.
In my case, as in others, I suspect, these artifacts are an acceptable price to pay for faster access. In other applications, the artifacts would be objectionable and hence data bus read/write should be restricted to the retrace interval. My recommendation is to give the user an option of retrace access or full time access.
The older controller does not have a wait line; instead the micro is supposed to poll the bus and wait until a go-ahead message is received, a far from efficient protocol, as it means your micro is tied up waiting for go ahead messages. Adding a separate wait status line is a major improvement, as it admits of an easily implemented interrupt-based write procedure.
Jack
Jack, Clifton VA
Jack,
Thanks for the detailed reply - that is helpful. I looked at connecting the wait line for the display I have, but found that the datasheet did not show a wait connection for the display, even though it is mentioned in the timing diagrams. There are four N/C pins, one of which I suspect is the wait line, but I'm yet to put a scope on these and take the plunge and connect a pin that the data sheet says should be left unconnected.
In addition, in 6800 mode, the S1D13700 datasheet suggests that the wait line is not used if I've read it correctly. I think that I will develop the library without the wait functionality initially, and add this at a later stage if possible. I am not seeing to many artefacts at the moment, although there are some.
So far I have the library hooked in to the GLCD library and the line, circle and rectangle commands work. I'm using three graphic layers and no text layer, limiting it to variable width fonts on a graphic layer. The text and image commands are not working yet - I've got to find a way of writing text into horizontal bytes.
When it comes to testing, I could email you the library and a modified GLCD library. Would you be able to run it in hardware with some sample code? If this is OK, which displays could you test it on - are they in 6800 or 8080 mode. I have not yet done the code for 6800 mode, but it is only a small change.
Many thanks,
Steven
Thanks for the detailed reply - that is helpful. I looked at connecting the wait line for the display I have, but found that the datasheet did not show a wait connection for the display, even though it is mentioned in the timing diagrams. There are four N/C pins, one of which I suspect is the wait line, but I'm yet to put a scope on these and take the plunge and connect a pin that the data sheet says should be left unconnected.
In addition, in 6800 mode, the S1D13700 datasheet suggests that the wait line is not used if I've read it correctly. I think that I will develop the library without the wait functionality initially, and add this at a later stage if possible. I am not seeing to many artefacts at the moment, although there are some.
So far I have the library hooked in to the GLCD library and the line, circle and rectangle commands work. I'm using three graphic layers and no text layer, limiting it to variable width fonts on a graphic layer. The text and image commands are not working yet - I've got to find a way of writing text into horizontal bytes.
When it comes to testing, I could email you the library and a modified GLCD library. Would you be able to run it in hardware with some sample code? If this is OK, which displays could you test it on - are they in 6800 or 8080 mode. I have not yet done the code for 6800 mode, but it is only a small change.
Many thanks,
Steven