I kind of got it working. The "Screen fill" stage worked (on the graphicstest example). But nothing else seemed to although I did get the full console output
Self Diagnostic: 0x0
Benchmark Time (microseconds)
Screen fill 3661076
Horiz/Vert Lines 416258
Rectangles (outline) 393861
Rectangles (filled) 7629132
Circles (filled) 16010071
Circles (outline) 13419138
Triangles (outline) 9729282
Triangles (filled) 6902670
Rounded rects (outline) 4202870
Rounded rects (filled) 10165051
FYI - I uploaded a few minor fixes to this to my Adafruit_ILI9341 github project I mentioned above. Again only on the Edison branch, but put in a fix that allows reading of data back from the display.
Note: I have found at times the display might stop displaying stuff, like mentioned above, also I was having issues where the Edison would reset and sometimes would continue to reset. These both appear to be improved by using external power. In my case I plugged in a 12v 5amp wallwart that I use to test stuff using AX-12 servos.
Also I have started experimenting building my code base native under linux. I have now have versions of the Adafruit_ILI9341/GCC converted over to using some of MRAA library as well as some of my own libraries. I also have the Adafruit GraphicTest program converted over to run under this. These appear to be crawling along now. Had/have issues with mraa. As part of this I have also converted the Adafruit_STMPE library over, which builds, but I have not tested yet, will probably port the touch paint over into my test directory as well.
Again all of this is built using some of my own Arduino porting libraries and the like, that I started off when I first experimented with the Raspberry Pi, then BeagleBone Black, Odroid U3/2...
I uploaded my WIP up to my Raspberry_Pi project up on github (KurtE/Raspberry_Pi · GitHub)
I just thought I would mention, that made a few more performance fixes with my Linux version (KurtE/Raspberry_Pi · GitHub).
Mainly I sped up the drawing of text when both FG/BG colors are definged. I used some of the inspiration of the ili9341_t3 (Library for Teensy 3/3.1), where I use my writeRect function to output more than one pixel at a time. I generate several rows of data of the character per output.
I updated the graphic test program to have a 2nd draw text test, this one I set the BG color to black. The timings I see are:
Display Power Mode: 0x9C
MADCTL Mode: 0x48
Pixel Format: 0x5
Image Format: 0x9C
Self Diagnostic: 0x0
Benchmark Time (microseconds)
Screen fill 2769952
Text 2 385937
So as you can see the version where you set the fg and bg color is considerably faster! I have not done this with the actual Arduino library version as I modified the GFX library to make the drawChar be virtual and so far my Arduino version does not change the actual interface.
Edit: made some changes to drawChar when in transparent text mode. Not as fast as other but:
Text 1365127 Text 2 386748
KurtE, Since your plowing forward with SPI, and though you might find this interesting.
I have the Arietta G25. It would be cool to get the Linux framebuffer to work on the Edison. I thought i read here somewhere that the graphics processor was disabled in the edison, not sure though.
I have all but given up for faster SPI. There is just something broken with it on the Edison. ioctl just does not work right on it for passing multiple bytes.
I have tried the same code on 4 other boards, and it works just fine on them including the slower Arietta G25. I'm not a heavy linux guy so i am limited on what i can do.
For the most part I think I have the display running fast enough for most things I want to do. My main reason for working with the Edison is because Trossen Robotics with Intel and others have stated that they will be using one in their new humanoid project, which I am interested in. But they will be shipping it with their own adapter board, so I will probably need to adapt. Would still like to learn more about how spidev works here and see if there are enhancements we can do in order to speed things up. Maybe there are other ways to try to speed it up, like can you do writes to the device versus the IOCTL? I am also not a heavy linux guy, but I am just stumbling along.
FYI - yesterday my Galileo V2 arrived. was just curious about them. My Arduino IDE version of the driver appears to run on it, but even slower. Again I want to understand more, like different ways to drive the IO pins faster pinMode(9, OUTPUT_FAST) vs ... Also wondering if the faster methods also work on Edison? ... Lots to learn.
The Arietta G25 looks nice. Mostly recently I have been playing around with the Teensy 3.1 boards, which are a nice Arm Cortex M4 that I normally run at 96mhz. It runs completely using the Arduino 1.0.6 IDE (own hardware branch) and he has all most all Arduino libraries ported over to work with the hardware... As I have already mentioned his ILI9341_t3 library is an order of magnitude faster..
Sort of an FYI and question: For the fun of it I picked up a Galileo Gen 2 to see how will it performs. I plugged in the Adafruit 2.8" display using my updated driver and tried out the graphic test program and it works but it is quite a bit slower. I hooked up the Logic Analyzer and the SPI speed is no where near the 8mhz the program asked for.
I have the code setting the spi speed:
SPI.setClockDivider(SPI_CLOCK_DIV2); // 8 MHz (full! speed!)
I tried modifying the SPI library for Galileo to pass the speed: (msg.speed_hz) to see if that would help. So far nothing helps.
Suggestions? What is the max SPI speed of the Galileo?
Edit: I thought I updated the image with the image with the markers to show not just the pulse width but instead the time from clock to clock. When I show that one it shows something like 3.9us with a frequency of about 256khz
I bought one of those Galileo boards some time ago, I dont know if the Gen2 has changed anything since then. When i get a board the first think i do for a test is to try out the SIP port. WHen i tried this in the Galileo it was worthless to me. Digging into it further the CS, mosi, misom , & clk lines did not come out directly from the core but was routed to some other IC that mimicked SPI. It was because of them doing it this way caused the much slower SPI bus speeds. Maybe if the Gen2 has kept that silly same setup it is this causing the problems.
Did a quick update to Adafruit MRAA version of the display code to use the faster GPIO options. Also found current versions have the CS line under SPI when you init SPI, which broke the driver, so moved the CS init after the spI init which fixed it...
Anyway I do believe it is helping speed some, but still need to figure out why delays between SPI bytes
Hi I am currently working on my 8th grade science fair project and wanted to ask a few questions about how the pin outs work for PiTFT and how to connect it to the Edison through the breakout board.
Another question is for the touchscreen part of the screen is that also using SPI?
If so, should it go into the second SPI channel or does it use GPIO as the way of communicating ?
Thanks in advance