Forum Rule: Always post complete source code & details to reproduce any issue!
Page 1 of 3 1 2 3 LastLast
Results 1 to 25 of 75

Thread: Teensy 3.0 - driving an SSD1289 with utft

  1. #1

    Teensy 3.0 - driving an SSD1289 with utft

    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 by Qumefox; 02-20-2013 at 05:00 AM.

  2. #2
    Senior Member ZTiK.nl's Avatar
    Join Date
    Dec 2012
    Location
    Amsterdam
    Posts
    179
    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 ;)

  3. #3
    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 by Qumefox; 02-07-2013 at 06:37 AM.

  4. #4
    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.

    Attached Thumbnails Attached Thumbnails Click image for larger version. 

Name:	IMG_0690.JPG 
Views:	1265 
Size:	197.5 KB 
ID:	229  

  5. #5
    Senior Member ZTiK.nl's Avatar
    Join Date
    Dec 2012
    Location
    Amsterdam
    Posts
    179
    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

  6. #6
    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.

  7. #7
    Senior Member ZTiK.nl's Avatar
    Join Date
    Dec 2012
    Location
    Amsterdam
    Posts
    179
    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?

  8. #8
    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.

  9. #9
    Senior Member
    Join Date
    Nov 2012
    Location
    Chipping Norton, UK
    Posts
    274
    Hi just ordered one of these, can you share the library?

  10. #10
    Member Dawnmist's Avatar
    Join Date
    Nov 2012
    Location
    Australia
    Posts
    51
    Dropping in here, I'm the person behind http://dawnmist.dreamwidth.org/ ... and I'm not a guy .

    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.h...d=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 by Dawnmist; 02-13-2013 at 02:07 AM.

  11. #11
    Senior Member
    Join Date
    Nov 2012
    Location
    Chipping Norton, UK
    Posts
    274
    Quote Originally Posted by Qumefox View Post
    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
    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.

  12. #12
    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

  13. #13
    Quote Originally Posted by Experimentalist View Post
    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'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.

  14. #14
    Senior Member
    Join Date
    Nov 2012
    Location
    Chipping Norton, UK
    Posts
    274
    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

  15. #15
    Senior Member ZTiK.nl's Avatar
    Join Date
    Dec 2012
    Location
    Amsterdam
    Posts
    179
    Quote Originally Posted by Qumefox View Post
    I think ZTiK.nl was the one using an 8-bit bus display with an ILI9325.. Not an SSD1289.. and also a different library.
    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 :)

  16. #16
    Senior Member
    Join Date
    Nov 2012
    Location
    Chipping Norton, UK
    Posts
    274
    Quote Originally Posted by Dawnmist View Post
    I'm the person behind http://dawnmist.dreamwidth.org/ ... and I'm not a guy
    Sorry, forgot to thank you for your post and assistance, very much appreciated

  17. #17
    Senior Member
    Join Date
    Nov 2012
    Location
    Chipping Norton, UK
    Posts
    274
    Quote Originally Posted by Dawnmist View Post
    it's available (with some details on what I'd done) here: [url]http://dawnmist.dreamwidth.org/549.html?thread=1573#cmt1573[/url
    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?

  18. #18
    Senior Member
    Join Date
    Nov 2012
    Location
    Chipping Norton, UK
    Posts
    274
    Quote Originally Posted by Qumefox View Post
    That's going to make things difficult for my particular project, since I'll require two SPI ports
    Thought I should point out that the SPI interface is a bus not a port as was previously pointed out to me:

    Quote Originally Posted by t3andy View Post
    SPI is a bus. To expand it, you just only need another chip select. Using SPI just only for your SD card and saying that SPI is already used is wrong.

  19. #19
    Quote Originally Posted by Experimentalist View Post
    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?
    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.

    Quote Originally Posted by Experimentalist View Post
    Thought I should point out that the SPI interface is a bus not a port as was previously pointed out to me:
    Arguing semantics. I was already aware SPI devices shared the bus, and only required different CS signals.

  20. #20
    Member Dawnmist's Avatar
    Join Date
    Nov 2012
    Location
    Australia
    Posts
    51
    Quote Originally Posted by Experimentalist View Post
    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?
    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/bc7igx5tdc...2009.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 by Dawnmist; 02-14-2013 at 06:09 AM.

  21. #21
    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!




    Last edited by Qumefox; 02-14-2013 at 04:09 AM.

  22. #22
    Senior Member ZTiK.nl's Avatar
    Join Date
    Dec 2012
    Location
    Amsterdam
    Posts
    179
    Quote Originally Posted by Dawnmist View Post
    I've got wires soldered to those pads underneath and brought out to pins that I've then breadboarded:
    https://www.dropbox.com/s/bc7igx5tdc...2009.17.56.jpg
    Thanks for that picture/the explanation!
    I had the same question, but wasn't sure if this was the 'right' way :)

  23. #23
    Senior Member ZTiK.nl's Avatar
    Join Date
    Dec 2012
    Location
    Amsterdam
    Posts
    179
    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 ?

  24. #24
    that's just a demo example that comes with the library. I didn't mess with it much beyond getting it working.

  25. #25
    Senior Member
    Join Date
    Nov 2012
    Location
    Chipping Norton, UK
    Posts
    274
    Quote Originally Posted by Qumefox View Post
    I was already aware SPI devices shared the bus, and only required different CS signals.
    not sure why you
    Quote Originally Posted by Qumefox View Post
    require two SPI ports
    then?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •