Some questions with SPI communication

[daviddwlee84]

I found some problem when running the "graphicsTest.cpp" code.

1. When I commented out "#define TFT_USE_SPI" (in line 51) and compiled it. It switched to use Adafruit_ILI9341 class, and the error came out because Adafruit_ILI9341 class doesn't contain "pushColors" function (in line 339). It only have "pushColor" function.
2. I comment back the "#define TFT_USE_SPI", try to use 8bit-mode. It can be compiled and installed. But it will break the connection with Intel Edison in the middle of process. I've tried to use independent power to power up TFT LCD to make sure it isn't cause by current shortage. But it seems not help actually. When I tried to plug out 8bit BUS, then the program back to work. Still confusing what is the main cause of these problem.
3. Last I want to ask is whether I can show the command line on the screen when I start the machine or not.

PS. I am using Intel's official Eclipse to compile. Thanks.

[llatta]

I didn't use SPI mode in a long time, as it's performance (at least with the Edison kernel a year ago) wasn't acceptable for driving a display at a reasonable frame rate. It shouldn't be hard to fix the compile errors though, if you want to try this first. Just comment out the portions of the graphicsTest.cpp needing code paths that are missing in SPI mode.

For 8-bit mode, I'm assuming you are using the wiring I'm describing in http://2ld.de/edidoom/ ? If so, I'd suggest first leaving out my "hacky" extra resistor. After the write up I learned that it could lead to pretty harmful currents (because the resistance value is so low, it's almost like shortening it out). I agree it sounds like you have some power issue. I'd try both simplifying the code and the wiring to the minimum. Like only try the reset of the display, and play with turning it on or off to see if any data gets through. There are also still some commented out/#ifdef'ed out portions in the code for slower data writing modes. You can also revert it to use pure mraa, without all my optimizations, in case there were incompatible changes to the edison internals since my version last ran about a year ago.

Regarding showing the command line on screen: You'd probably want to write a framebuffer kernel module to drive the display for that. I vaguely recall someone on the edison forums doing that for his own custom kernel. It doesn't seem crazily hard once the display connection is up and working, but I have not done that.

[inteliot]

Hi daviddwlee84, how did you get the package to compile on Eclipse? I try compiling and always get errors. Are you using a non-default toolchain? If so, which? Thank you.

[llatta]

These are the instructions on my above mentioned website to compile them:

The source code repositories below are projects for the Eclipse workspace of Intel's IoT Developer Kit. Just import (File/Import/General/Existing Projects into Workspace...) them into the examples workspace, create a new Debug configuration for the project using the Edison connection you've set up in the Remote System Explorer and run.

Since this was a year ago, it's possible that the IoT developer kit has changed enough to not compile them any more, but I doubt much needs to be changed. What errors do you get? Can you compile and run the samples in the IoT dev kit successfully?

[inteliot]

hi, thanks for quick reply. so i followed this thread b/c errors were the same (cannot find -lc Edison_Appliance C/C++ Problem...etc) https://communities.intel.com/thread/61564?start=0&tstart=0 and used File -> New -> Other... -> Intel(R) IoT Developper Kit -> Intel (R) IoT C/C++ project. to create a new project now i'm just getting nullptr not defined - I assume this is depending on some define that is not resolved? nullptr = NULL? Where do I make changes to GPIO pins assignment? Thank you.

[inteliot]

i spoke too soon...sorry. I see definitions in Adafruit_TFTLCD.cpp Am I correct? thank you

[llatta]

Yes, nullptr is a C++11 keyword equivalent to NULL or (void*)0 . Weird that your compiler version/options wouldn't know that keyword.

The pin assignment is at the top of Adafruit_TFTLCD.cpp. Note that you can't change the data and WR pins by much, as all 8 data pins need to map to 8 consecutive hardware pin IDs, so that the combined 8-bit writing works. So TFT_EDISON_DATA0/_WR are just the "hardware pin" numbers equivalent to the Arduino pin numbers in TFT_DATA/TFT_WR (see the hardware docs for a table mapping between the two id types).

[inteliot]

Thank you Lutz. when you say Hw pin numbers, this means sysfs or MRAA? (this may be helpful for what i'm talking about - 2/3rds down: http://www.i-programmer.info/programming/hardware/8744-exploring-edison-mraa-gpio.html) if data pins are not consecutive, I'm stuck with having to do bit by bit I assume? Thank you

[llatta]

It's bin a while, but I think the numbers I called hardware pin IDs, are what the article calls the sysfs numbers. They are bit offsets in the address range that is used to program the GPIO peripheral (via the PCI bus IIRC). If you don't use consecutive bits, you'll at the minimum have to do some bit shifting, and if your pins touch multiple groups of 32 pins (eg some pins between 0..31, and some 32..63) you will have to write to multiple 32-bit HW addresses, and write performance will decrease proportionally (eg half, if you need to update two 32-bit words). You'll have to change the code inside Adafruit_TFTLCD.cpp to do the bit shifting and possibly writing of multiple words per pixel.

[inteliot]

thanks again! So do all pins have to be in the same DW or jsut data? what i have is data in range from 31-48, and control are 0-20. I wish it was 32-48, but either way I have two groups of 32...this is still breaking what you were attempting to do, right? one more question, what is the intent of TFT_EDISON_DATA0 and TFT_EDISON_WR?

[llatta]

Ideally the data pins and WR are in the same 32 range, because for every data/pixel write you need to set all data bits to the target value and then flip WR on/off. So if that can be done together it's best.

[inteliot]

Got it working. Thanks for your help :)

[inteliot]

hi, sorry to bug you again. I'm trying to figure out if all of this still can be used with the config I have, and the pins there are not consecutive, and are not in the same DW. My thought is, I would need to rewrite most of it, and write bit by bit, instead of full DW. Note that I'm not concerned about performance. I also tried to use the base library from Adafruit, but that was written for Arduino, and I am not sure if I can add that to a C/C++program...I tried it, but seems like one header file after another one is "missing" (all arduino .h files) - any pointers are helpful. Thank you.

[andy-shev]

@llatta fbtft module works just fine with Intel Edison (vanilla kernel, v4.11-rc1).

[llatta]

Thanks Andy! By any chance do you have performance numbers from using the fbtft module? Back when I did this work, driving a 320x200 display with serial connection from the Edison was super slow. I think it was upwards of 200-300 milliseconds for refreshing the whole screen. That's why I had to go into all this squeezing cycles out of bit banging on parallel wires. I'm curious if the situation has improved over the years.

[andy-shev]

I didn't do that, but when I got v4.11-rc1 working (there is a problem with booting right now), I can do some tests. I'm using Buildroot, so, the only tools I got easily to run are from fb-test-app package.

And yes, I have big Adafruit 2.8" display (320x240).

[andy-shev]

As promised earlier

dmesg

... [ 59.575957] Console: switching to colour frame buffer device 30x40 [ 59.591599] graphics fb0: fb_ili9341 frame buffer, 240x320, 150 KiB video memory, 16 KiB buffer memory, fps=20, spi5.1 at 25 MHz

fb-test-perf 0 fb0.log

perf 1.1.0 (rosetta) sequential_horiz_singlepixel_read,811084800,4630823,175149168 sequential_horiz_singlepixel_write,546508800,10038890,54439166 sequential_vert_singlepixel_read,427392000,4966032,86063078 sequential_vert_singlepixel_write,240384000,10730430,22402084 sequential_line_read,3237734400,4732668,684124557 sequential_line_write,2123827200,7101122,299083327 nonsequential_singlepixel_write,15513600,5945083,2609484 nonsequential_singlepixel_read,30259200,4718213,6413275

uname -a

Linux buildroot 4.11.0-rc1-next-20170308+ #429 SMP Wed Mar 8 12:35:29 EET 2017 x86_64 GNU/Linux