Created Sat, 23 Nov 2013 04:56:08 +0000 by Endevor
Sat, 23 Nov 2013 04:56:08 +0000
So I have this:
I got it planning on using it on my old arduino mega, but now that I have a max32, I want to be able to use it with it. I'm trying to use the UTFT libraries, but having a hard time running the test programs. I think it has something to do with declaring the GLCD at the beginning. Anyone have and simple display code that works that I can test?
Thanks,
Sat, 23 Nov 2013 11:03:22 +0000
I have three of those TFT screens on my desk here. One of them is what I used in my DSO (see the projects forum).
I use my own TFT library, which is a very complex library supporting many many different displays, with framebuffers, backing stores, and all.
[url]https://github.com/majenkotech/chipKIT-TFT[/url]
At the moment I only use those screens directly connected to the Parallel Master Port of the PIC32MX695F512L chip, so I don't know how they would be connected to a MAX32 - I guess you have the carrier board pictured? (I don't - just the raw screens) In that case you should be able to get it going with the SSD1289 driver, but there isn't a 16-bit parallel interface at the moment. If you fancy cloning the 8-bit interface and creating a 16-bit one that'd be a great contribution.
Documentation is rather scant for the library though - it's one of my main failing. I know how it works, why should I spend time telling others? ;) But here's some bits of code adapted from my DSO project using the PMP driver:
#include <DSPI.h>
#include <TFT.h>
TFTPMP pmp; // Parallel Master Port driver
SSD1289 tft(&pmp); // TFT Driver
DSPI0 spi;
TFTDSPI tpSPI(&spi, PIN_DSPI0_SS, 255, 100000); // DSPI driver
XPT2046 tp(&tpSPI, 240, 320); // Touch screen driver
uint8_t buffer[SSD1289::Width * SSD1289::Height]; // Backing store for the frame buffer
SRAM ram(buffer, SSD1289::Width * SSD1289::Height); // Backing store manager - internal SRAM
Framebuffer332 fb(SSD1289::Width, SSD1289::Height, &ram); // 332 Framebuffer
void setup() {
fb.initializeDevice();
tft.initializeDevice();
tp.initializeDevice();
fb.setRotation(1);
fb.fillScreen(Color::Black);
tft.fillScreen(Color::Black);
fb.setTextWrap(false);
}
void loop() {
fb.fillScreen(Color::Black);
fb.setFont(Fonts::Topaz);
fb.setCursor(40, 40);
fb.setTextColor(Color::Red);
fb.print(millis());
tft.update(&fb);
}
There's functions to do everything you can think of as regards drawing, lots of fonts, a library of colours, etc. But it takes a bit of mind bending to get your head around how everything fits together. There's a lot of passing of objects to other objects to create a hierarchy of devices that fits together into a very very powerful display system.
Still, you might be able to pull some bits out of it to get yourself going.
Sun, 24 Nov 2013 18:28:13 +0000
Thanks, I'll definitely look into what you've done and see if I can adapt it here and there. Yea, the pic is with the carrier making it more like two shields than just one... Probably the last time I'll be buying anything from sainsmart. This thing was a pain trying to get it to work with the Arduino, much less the chipkit. I have a break from school coming up in a few days, I'll see what I can knock out and let ya know
Sun, 24 Nov 2013 18:30:07 +0000
The screens themselves are gorgeous things. I buy mine from eBay from China: [url]http://www.ebay.co.uk/itm/370905270095[/url]
Wed, 27 Nov 2013 18:41:34 +0000
So I ran into a wall with that shield and carrier. The developer of the UTFT library refused to help me with his code due to the fact my equipment is cheap and he didn't want to. Oh well. He had a little bit of a point though as I attempted to do it myself and found that I indeed had faulty hardware. I switched back to an arduino board to make sure it worked and for the short while the screen was on, it wouldn't register a touch.
So now I'm in the market for another touch display. I stumbled upon this: http://www.robotshop.com/en/3-2-tft-lcd-touch-shield-arduino.html
I was curious if any of you had any experience with this before I waste more money.
Wed, 27 Nov 2013 18:59:55 +0000
I haven't used that one, no. The SainSmart one is the only 3.2" one I have used.
Same CoG as the SainSmart one though, but configured for 8-bit not 16-bit interface.
Wed, 27 Nov 2013 22:42:22 +0000
Probably should go for a 16 bit interface...
I figured I'd go to the itead source and found this: http://imall.iteadstudio.com/display/tft-lcm/itdb02-2-8.html
Along with a shield: http://imall.iteadstudio.com/im120417024.html
The display has a 16 bit interface. One size smaller than what I had before, but should still be fine for my application. I just can't get anything larger than the 3.2". My only concern is the shield. It looks like it sends the pins to the same locations as the shield from sainsmart. Will that still work with the ChipKIT? I'm concerned that that was my issue before, but then again I was dealing with faulty hardware.
As I'm typing this, my dad handed me one of these: http://www.impactcomputers.com/60h00029-00m.html
Said he bought it for an old axim and I guess never used it... Looks like it would be pretty cool to get this to work on the chipKIT though I've never dealt with these before and would have no idea how to plug it in. Thoughts?
Wed, 27 Nov 2013 23:20:04 +0000
I don't know the ILI9325 CoG, but my library supports the ILI9340, which I have that communicates with SPI. Works nicely.
The problem with a 16-bit interface is how to drive it. While it's nice having a parallel interface, if you can't connect it up efficiently it's not hugely better than a nice fast SPI interface. If you're setting each bit of the interface as an individual operation with digitalWrite() it can be quite sluggish.
I don't have a MAX32, and I am not familiar with its pinout, but if it were possible to use the PMP to drive it, as I do with my 16-bit interface screens, then you can get some blisteringly quick graphics.
Of course, it all depends what you actually want to do with it.
At the end of the day, it shouldn't matter what pins it connects to if you're driving them manually. The only caveat is the touch screen will be an SPI connection,and if they don't route to an SPI port on the board then you'll have trouble using it, though you could theoretically use bit-banged software SPI.
I would also say you don't need the carrier shield, as the MAX32 is 3.3V and the screen is 3.3v, so you don't need any level shifting (unless you want to use it on your Mega). I use an old 40-pin IDE cable (not one of the newer 80-wire UDMA cables, but an old 40-wire one) and cut one end off.
Wed, 27 Nov 2013 23:46:21 +0000
My project is to create an aquarium controller. I had most of it working through the Arduino Mega, but needed some more I/Os for the components. I really don't need a high end display, it's just going to be used for a simple UI. Maybe a 8 bit interface would be fine. I would like to be able to access the SD card to store simple graphics and log data, register touch, and display parameters.
In all, I just want something simple and works. I think I may just go with an old ribbon cable like you did. That would allow me to put the display elsewhere and even make it bigger.
Thu, 28 Nov 2013 09:06:19 +0000
The developer of the UTFT library refused to help me with his code due to the fact my equipment is cheap...
This has nothing to do with it... I do not provide support for SainSmart products because they (SainSmart) have been using several of my libraries in violation of the license agreements. When confronted with this fact they were not cooperative at all.
It is also a known fact that there are (or at least were) a lot of hardware fault and issues with SainSmart products. This is also a contributing factor to me not providing support for these products.
/Henning
Thu, 28 Nov 2013 18:59:30 +0000
For the sake of not starting anything over the internet or stepping on any toes, I would like to apologize for that comment. I didn't really want to bad mouth UTFT, and I probably misunderstood the response I received from them. I do agree Sainsmart sells some pretty cheap stuff and in light of that, I bought another itead shield from the robotshop. Hopefully that will fix the issues I'm having, and if not, perhaps it'll be at least easier to troubleshoot. I look forward to seeing it the start of next week.
Anyway, sorry again for the ignorant comment, hope to be able to use your libraries in the future. Happy Thanksgiving!