Teensy 3.0 - driving an SSD1289 with utft

Status
Not open for further replies.
Q

Qumefox

Well-known member
Has anyone successfully ported this library to teensy 3.0 yet? And more importantly, been able to remap the D0-D15 16-bit interface IO pins to something other than the ones currently being written to by the library with direct port manipulation? Right now, just from having perused the documentation, and poking through the library code, of which, my understanding of is minimal at best, it seems like the pin mappings on the teensy 3.0 would equate to those used by the arduino uno, correct?

If so. That's going to make things difficult for my particular project, since I'll require two SPI ports, in addition to driving the display.

I've attempted to contact this person who has apparently already accomplished pretty much what I need to do, however i've yet to get a response from him.
 
Last edited:
I guess I'm the last person who should offer support to others, just got my feet wet with all this stuff, but I think I have a useful link for you.
This is a very useful guide into the pin/port mapping on T3 (GPIO PDIR/PDOR) and it has helped me out quite a bit.
It also contains a dandy handy list of which ports are linked to which pins.

I am using an 8bit display using the D0-D7 ports, and my pins are all over the place.
I still need to optimize this code to support my own combination of pin/port #'s, but for now it works quite well :)

Hope you get a completed lib though ;)
 
Thanks!.. And me personally rewriting the library to work with the teensy 3.0 is probably doable, once I learn enough to do it anyway. If someone else has done it already and is willing to share, it'd just speed up this particular project greatly though.

And actually on the library modification front.. Can anyone tell me if the teensy 3.0 has any kind of cpu define for itself, similar to __AVR_ATmega1280__, etc? I'd prefer to make the HW identification work properly, otherwise i'll just have to hack that section out and this will end up teensy 3.0 only. But I can't for the life of me figure out what cpu define the preprocessor is using.
 
Last edited:
Success!.. sort of. Though either I have a bad display, or the library is behaving in ways I have no idea how to troubleshoot. The bottom quarter of the screen is garbled.. Sometimes writes work there, sometimes they don't. and it's impossible to clear the area.

IMG_0690.JPG
 

Attachments

  • IMG_0690.JPG
    IMG_0690.JPG
    197.5 KB · Views: 1,406
Nice to see you made (some) progress here!

To identify Teensy 3.0, I have been using:
Code: 
#elif defined(__MK20DX128__)

I have too little experience troubleshooting displays, so I don't know the way forward in that area.
The fact that it does display on the bottom 'row' makes me think that either :
-the jumperwires are too long
-the jumperwires are not connected in right order
-the soldering doesnt connect as well as it should
 
Yeah thanks on the identification. But heh. I figured out why I was having problems initially. I had a typo in the define. :p

Regardless. The person I mentioned in the original post responded and I got a copy of his library, though it was an older version of utft. After porting his changes to the new version, and writing some new blocks in the HW specific code that the new library was looking for, I got the it to compile and init the display, with the above result. Though I tried his older library, which he had working on the teensy 3.0, with the same results as well. So I think it's even a wiring issue, or a bad display. I'll likely order another display anyway, since one can never have too many parts, and hopefully that will let me troubleshoot farther.
 
No problem, after reading 10k+ lines all characters start looking alike :)

When I first saw the pic of the display, it reminded me of a topic on adafruit forums where somebody had almost the exact same problem.
If I recall right (s)he did come up with the fix, but I haven't been able to find that topic yet.

In case you get a new/second display, are you getting the same one or going for a different type?
 
I'll probably get another similar display (SSD1289) but probably not from the same vendor as this one. Also ordering some proper breadboard compatible IDC connectors to clean up my wiring a little.
 
Dropping in here, I'm the person behind http://dawnmist.dreamwidth.org/ ... and I'm not a guy :p.

I've uploaded the library I was using to that post when Qumefox contacted me, so for anyone else interested in it it's available (with some details on what I'd done) here: http://dawnmist.dreamwidth.org/549.html?thread=1573#cmt1573. For the garbled display - have you tried doing a plain "set to one colour" type test first? My first step in getting it working was to get a simple "colour the screen and draw a box" sketch working, then progress from there (since that proved the screen itself was working). I haven't had a chance to do any further work on it since mid-November, but the last state I had it in was http://youtu.be/ElWEnGebk7I

You're obviously getting something through - otherwise there wouldn't be readable words, etc on the display. However, I was suspicious about timing issues in the screen write - I noticed myself that I'll get smeared bitmaps occasionally, and they tended to vanish if I added some delays to the write process (i.e. teensy was operating too fast for the screen to keep up - which was part of why I hadn't worried too much about using digitalWriteFast() yet). I haven't spent very much time yet looking into that (because I got sidetracked by a new NAS and putting my stuff into git and playing the computer game this was all intended to support instead *grins*) - but what I suspected was happening was the screen was still updating when the next write command got sent, resulting in overwriting/corruption of the on-board screen's RAM data before it had finished writing out to the tft and garbage being drawn on the screen. Given that bitmaps are written from the bottom row up the screen, that might account for the bottom section being readable with greater issues appearing higher up.

You also said earlier you were using an 8-bit data bus...which pins on the teensy/library did you end up using? Since I'd been using the 16-bit interface, I can't guarantee that the 8-bit one worked solo (though I knew it could work since it's part of the 16-bit one, and I'd followed the addressing standard used in the arduino pin examples so I thought it should work "in theory").

Those issues were why I hadn't submitted any changes upstream yet - it was still in very much an "experimental, mainly works for me" type state. ;)
 
Last edited:
Qumefox said:
After porting his changes to the new version, and writing some new blocks in the HW specific code that the new library was looking for, I got the it to compile and init the display
Click to expand...

Hi

As I said I have one on order, are you willing to share the updates to Dawnmist's code you refer to in the quote?

Did you see the new post suggesting your issue?

Thanks
Ex.
 
I think ZTiK.nl was the one using an 8-bit bus display with an ILI9325.. Not an SSD1289.. and also a different library.

AFAIK, the SSD1289's in the 3.2" LCD's we're using are hardwired to 16bit only, even though the SSD1289 supports other communication modes. these particular LCD's would just require being torn apart to change the mode, since the mode select pins aren't brought out anywhere where you can actually access them.

As far as the timing issues.. That actually makes sense. I wasn't kidding when I said I was a total noob at this stuff, and that never occurred to me. I might try to declock the teensy tonight and see if it helps, and that failing, try adding delays. At least if I get time/inclination to poke at it.. This project is fairly low priority for me. I've mostly been trying to get rid of 3/4 of the stuff I own in preparation for moving halfway across the country in a few months, and other than that or work, poking around fairly mindlessly in KSP, GW2 or WOT. :p
 
Experimentalist said:
Hi

As I said I have one on order, are you willing to share the updates to Dawnmist's code you refer to in the quote?

Did you see the new post suggesting your issue?

Thanks
Ex.
Click to expand...

I'll post a .RAR when I get home from work, but keep in mind I in no way claim to know what i'm doing. Most of the code I added was purely guesswork from looking at how the referenced code blocks were done for other hardware, with the majority of the changes originating from Dawnmist's code.
 
Hi

Don't worry, I, like you, and many others, am effectively making it up as I go along and just trying to learn from and share with others to save on the pain :)

I would greatly appreciate the .RAR and will PM you my email in case you have trouble posting here

Thanks
Ex.

p.s. Good luck with the move
 
Qumefox said:
I think ZTiK.nl was the one using an 8-bit bus display with an ILI9325.. Not an SSD1289.. and also a different library.
Click to expand...

Yeah thats 100% correct.
The only reason I joined in the conversation was (in case you had to rewrite a library) to point out a topic about GPIO mapping :)
 
Experimentalist said:
Hi

Looks like you are using the inner pins on the base (25 - 32), is that the case? They are hard to use on breadboard in my tiny enclosure is there another way you know of?
Click to expand...

On mine I was using the normal breadboard accessible pins. I'm not using the inner ones yet. The pin mappings are changeable for the teensy3 by modifying the HW specifics in the library currently. I'm sure it's possible to pass said pin definitions to the library from the calling program, but as it stands, I think that's likely low priority for all involved. Making it work properly is a bigger issue.

Experimentalist said:
Thought I should point out that the SPI interface is a bus not a port as was previously pointed out to me:
Click to expand...

Arguing semantics. I was already aware SPI devices shared the bus, and only required different CS signals.
 
Experimentalist said:
Hi

Looks like you are using the inner pins on the base (25 - 32), is that the case? They are hard to use on breadboard in my tiny enclosure is there another way you know of?
Click to expand...

Yes I am - it was the best way I could see to get all 16 pins + the control pins and still leave the SPI+a few SPI clock select lines free (plus it meant that I could use 2 sets of 8 contiguous pins for the data lines, which was easier to check that I'd wired up correctly). I've got wires soldered to those pads underneath and brought out to pins that I've then breadboarded:
https://www.dropbox.com/s/bc7igx5tdculnof/2012-11-15 09.17.56.jpg
In the image above, that bottom set of pads has been brought out on small red wires along the central channel of the breadboard to the pins on the right - and the data lines are the yellow wires from those pins.

I also needed to leave 4 pins free to hook up to my keyboard stuff (migrating from Teensy 2++ to Teensy 3), so there was no way I was going to manage without using the underside pins.
 
Last edited:
Not sure what changed. I went through and set the D0-D15 pins to 0-15 on the teensy3, and put the RS WR CS & reset on 20-23 just for simplicity sake before posting the library, and when I rewired the display to match the pinout, the damn thing worked right. lol. I most likely had some data pins reversed, or incorrectly assigned in the library before. I tried 24, 48, and 96 mhz clocks and it ran about the same on every one.

Anyway, here's the latest library, at least as of a week ago, with Dawnmist's changes plus my own.

UTFT.zip

Again, like I said above, the data pins are mapped to 0-15 on the teensy, in order.. D0 is pin 0, D1 is pin 1, etc. RS WR CS and reset can be mapped to anything left.

and pics!

IMG_0702.JPG

IMG_0703.JPG

IMG_0704.JPG

IMG_0705.JPG
 
Last edited:
The screen looks great Qumefox, congrats on getting it to work finally :)

I guess that this is the default 'display test' example to show some screen drawing functions, had a chance to load HQ images or anything like that yet ?
 
that's just a demo example that comes with the library. I didn't mess with it much beyond getting it working.
 
Status
Not open for further replies.
Back
Top