Arduino + TFT LCD

I happened to find this 2.8 " TFT LCD on ebay here manufactured by a chinese company called ARMJISHU. The only way i came to know about this TFT was because of the fact that the manufacturers were generous enough to put their website url on the PCB silkscreen. If this detail would not have been there i would never have known what display driver chip it runs or what touchscreen driver it uses. If you head over to the ARMJISHU site it's all in chinese and i could not find this tft sold as a separate product. It was however sold as a part of their STM32 kit. It was in the CD for this kit (which was a whopping 1.2 GB download from the site) that i found the source code for all the peripherals used by the kit and in the tft example i found that the driver was a SSD1289 and a ADS7843 touch controller. 

Once you know the controller it is pretty easy to find the Arduino drivers for the same. I hooked up the tft to the Arduino MEGA and was able to run some sample code using the UTFT library. The touchscreen never worked with this library from elechouse. I am guessing it's damaged. I saw many posts on the internet about people not being able to use this TFT just because they could not find details about it. I hope this post serves as a reference, if they find this post ;)

 The connections for the ATMega 2560. The colored names are the pins on the TFT header. CS is actually named LCD_CS on the tft pcb. RD pin on the tft header has to be directly connected to 3.3V.

The output. Something does not seem right ? Can you guess the last number in the sequence ?

The hookup guide for the TFT using the Mega can be found in the UTFT pdf manual. The code i used is just the example available in the UTFT lib. One has to just uncomment the Arduino Mega API call and comment out the Uno one. The first parameter to the class variable declaration has to be set to the display model, in this case SSD1289.

Update

While using the ADS7843 library from the link mentioned above you might get some errors in ads7843.h like:

ads7843.h:34: error: ISO C++ forbids declaration of 'Pio' with no type

ads7843.h:34: error: expected ';' before '*' token

In order to fix this, open the ads7843.h file and comment out the line as shown below (the second line too

is of no use hence comment that as well)
 

Next, open ads7843.cpp file and disable the code shown below from the class constructor

The compilation should now be successful...

The CC3000 Wifi - Part I

I have been messing around with the CC3000 Wifi based breakout board and shield from Adafruit lately and have found a bunch of problems with that CC3000 from Texas Instruments. With a little research over the internet i found that i was not the only one with these problems and many people were facing similar problems with the TI wifi module. To keep things brief here are my findings on the CC3000.

Devices Used - Arduino UNO, Arduino Mega 2560, CC3000 Breakout, CC3000 Shield.
CC3000 Firmware - v1.24
Problems - Unknown hang-ups, Buffer Full.

1. CC3000 WiFi shield + Arduino

I implemented a small weather station a few days ago, details of which can be found here. This arduino sketch runs flawlessly on an Arduino Uno for hours and days without any hang-ups or inconsistencies in behavior. Very strange it might seem, perhaps it's got something to do with the 40 second delay created due to the use of println() function that sends data character by character giving enough time for the buffers in the CC3000 firmare to freeup...maybe...

2. CC3000 Breakout + Arduino Mega 2560

A similar approach to [1] above only that i send a single random number to the Xively site. On the Mega 2560, using the println() the CC3000 used to hand up frequently after 3 - 4 minutes of sending data. Then i switched to the fastrprintln() API where the hang-ups happened after quiet some time usually 20 - 30 minutes. There are two hang-ups that i have observed. One is in the HostFlowControlConsumeBuff returning an error of -3, i.e a timeout as there are no free buffers available on the CC3000. The other is an unknown hang-up that i have not been able to figure out, but i have a hunch that it is in the while(1) of the hci_event_handler function. #defining SEND_NON_BLOCKING has no effect, just making things worse, making HostFlowControlConsumeBuff return -2 frequently. 

The watchdog cannot be used on the MEGA 2560, since the WDTON fuse is set to 1 (unprogrammed). Even enabling and using it results in a continuous resets. I used the method shown below to take care of HostFlowControlConsumeBuff problems in simple_link_send. The SysReset is nothing but this - void (*SysReset)() = NULL. The unknown hangup remains unknown.

I had to modify the Adafruit CC3000 library and added an API for fastrprintln() that took a String object as an argument. 

The firmware of the CC3000 seems to be pretty buggy at the moment. So beware before you buy any product that uses this one. I will be updating soon some crude workarounds and stuff with the Teensy soon using the CC3000...

Update June 19th 2014 

To use the existing fastrprintln without having to add a new member function to the client class we can invoke it as follows

client.fastrprintln(data.c_str())

Where data is a String object and c_str() is the member function that returns the character buffer.

 

I came across this thread on the Texas Instruments community forum. Looking at this there seems to be no hope of getting the CC3000 to work properly. The last time the thread was active was on Feb 2014, since then, complete silence. Looks like the CC3000 firmware team at TI is either working hard or hardly working at all...and right now after almost 4 months i'd go with the latter...

http://e2e.ti.com/support/wireless_connectivity/f/851/t/312857.aspx