Closed chaunnt closed 3 years ago
I got linux kernel from https://github.com/WaRP7/linux-fslc/tree/4.1-1.0.x-imx/Documentation/devicetree/bindings
I 've checked SPI in menuconfig, spidev.ko was built and installed. I 've also modified imx7s-warp.dts => change ecspi1-2-3-4 from "Disabled" to "Okay"
spi_busnum_to_master(0) returned NULL
This means that spi bus number 0 (zero) is not available when you load the module (spidev is not used).
actually, I search alot but I do not know how to enable SPI or spidev in my WARP7 board :( Sorry but I 've never worked in linux (embedded) before.
&ecspi1 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_ecspi1>; status = "okay"; };
&ecspi2 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_ecspi1>; status = "okay"; };
&iomuxc { pinctrl-names = "default"; ecspi3 { pinctrl_ecspi3: ecspi3grp { fsl,pins = < MX7D_PAD_ECSPI2_SCLKMKBUS_ESPI3_SCLK 0x80000000 MX7D_PAD_ECSPI2_MOSI__MKBUS_ESPI3_MOSI 0x80000000 MX7D_PAD_ECSPI2_MISOMKBUS_ESPI3_MISO 0x80000000 MX7D_PAD_ECSPI2_SS0__MKBUS_ESPI3_SS0_B 0x80000000
; }; imx7d-sdb { ................. ................. pinctrl_ecspi1: ecspi1grp { fsl,pins = < MX7D_PAD_ECSPI1_SCLKMKBUS_UART5_TXD 0x80000000 MX7D_PAD_ECSPI1_MOSIMKBUS_UART5_RXD 0x80000000 ; }; pinctrl_ecspi2: ecspi2grp { fsl,pins = < MX7D_PAD_ECSPI2_SCLKMKBUS_ESPI3_SCLK 0x80000000 MX7D_PAD_ECSPI2_MOSIMKBUS_ESPI3_MOSI 0x80000000 MX7D_PAD_ECSPI2_MISO__MKBUS_ESPI3_MISO 0x80000000 MX7D_PAD_ECSPI2_SS0__MKBUS_ESPI3_SS0_B 0x80000000 ; }; ..... };
But error occured when I build imx7s-warp.dtb file. Error: arch/arm/boot/dts/imx7s-warp.dts:388.5-6 syntax error FATAL ERROR: Unable to parse input tree make[1]: [arch/arm/boot/dts/imx7s-warp.dtb] Error 1 make: [imx7s-warp.dtb] Error 2
I correct it. === Now DTS file is ..... &iomuxc { pinctrl-names = "default"; ecspi3 { pinctrl_ecspi3: ecspi3grp { fsl,pins = < MX7D_PAD_ECSPI2_SCLKGPIO4_IO20 0x80000000 MX7D_PAD_ECSPI2_MOSIGPIO4_IO21 0x80000000 MX7D_PAD_ECSPI2_MISOGPIO4_IO22 0x80000000 MX7D_PAD_ECSPI2_SS0GPIO4_IO23 0x80000000 / NOT SURE /
; }; }; imx7d-sdb { ...... pinctrl_ecspi2: ecspi2grp { fsl,pins = < MX7D_PAD_ECSPI2_SCLKGPIO4_IO20 0x80000000 MX7D_PAD_ECSPI2_MOSIGPIO4_IO21 0x80000000 MX7D_PAD_ECSPI2_MISOGPIO4_IO22 0x80000000 MX7D_PAD_ECSPI2_SS0GPIO4_IO23 0x80000000 / NOT SURE / ; }; pinctrl_i2c1: i2c1grp { fsl,pins = < MX7D_PAD_I2C1_SDAI2C1_SDA 0x4000007f MX7D_PAD_I2C1_SCLI2C1_SCL 0x4000007f ; };
Next error is: Reference to non-existent node or label "pinctrl_spi1" I can not find pinctrl_spi1 usage or definition anywhere
This question is better asked in a forum with knowledge about the board.
Thank you notro. we will modify it and back again
Hi notro After I modify my dts file. I'm now can enable spidev. I have folder /dev/spidev1.0 I run to test some command.
dmesg | grep spi => OK spi_imx 30830000.ecspi: registered master spi1 spi spi1.0: spi_imx_setup: mode 4, 8 bpw, 20000000 hz spi spi1.0: setup mode 0, cs_high, 8 bits/w, 20000000 Hz max --> 0 spi_imx 30830000.ecspi: registered child spi1.0 spi_imx 30830000.ecspi: probed
modprobe fbtft => OK
modprobe fb_ssd1351 => OK (My OLED display is Oled C Click and it is using SSD1351 controller)
modprobe fbtft_devices name=pioled debug=3 => Still this error spi_busnum_to_master(0) returned NULL
.display = {
.buswidth = 8,
},
.bgr = true,
.gpios = (const struct fbtft_gpio []) {
{ "reset", 24 },
{ "dc", 25 },
{},
},
.gamma = "0 2 2 2 2 2 2 2 " \
"2 2 2 2 2 2 2 2 " \
"2 2 2 2 2 2 2 2 " \
"2 2 2 2 2 2 2 3 " \
"3 3 3 3 3 3 3 3 " \
"3 3 3 3 3 3 3 3 " \
"3 3 3 4 4 4 4 4 " \
"4 4 4 4 4 4 4"
==
is gamma needed for OLED display ? I use OLED C Click (MikroBus standard)
Not to make it work, but you might need to change the default to get the best colors.
where can i get number "24", "25"
These are the gpio numbers you connect to. These numbers differ among boards and there can be multiple gpio controllers. Here's the ones available on a Pi running the mainline kernel:
$ ls -l /sys/class/gpio/
total 0
-rwxrwx--- 1 root gpio 4096 Jun 1 22:03 export
lrwxrwxrwx 1 root gpio 0 Jun 1 22:03 gpiochip458 -> ../../devices/platform/soc/20200000.gpio/gpio/gpiochip458
-rwxrwx--- 1 root gpio 4096 Jun 1 22:03 unexport
$ cat /sys/class/gpio/gpiochip458/{base,ngpio}
458
54
$ sudo cat /sys/kernel/debug/gpio
gpiochip0: GPIOs 458-511, parent: platform/20200000.gpio, pinctrl-bcm2835:
gpio-458 (SDA0 )
gpio-459 (SCL0 )
gpio-460 (SDA1 )
gpio-461 (SCL1 )
gpio-462 (GPIO_GCLK )
gpio-463 (GPIO5 )
gpio-464 (GPIO6 )
gpio-465 (SPI_CE1_N )
gpio-466 (SPI_CE0_N )
gpio-467 (SPI_MISO )
gpio-468 (SPI_MOSI )
gpio-469 (SPI_SCLK )
gpio-470 (GPIO12 )
gpio-471 (GPIO13 )
gpio-472 (TXD0 )
gpio-473 (RXD0 |discharge ) out lo
gpio-474 (GPIO16 )
gpio-475 (GPIO17 )
gpio-476 (GPIO18 )
gpio-477 (GPIO19 )
gpio-478 (GPIO20 )
gpio-479 (GPIO21 )
gpio-480 (GPIO22 )
gpio-481 (GPIO23 |panel-on ) out lo
gpio-482 (GPIO24 |reset ) out lo
gpio-483 (GPIO25 |busy ) in lo
gpio-484 (GPIO26 )
gpio-485 (GPIO27 )
gpio-486 (SDA0 )
gpio-487 (SCL0 )
gpio-488 (NC )
gpio-489 (LAN_RUN )
gpio-490 (CAM_GPIO1 )
gpio-491 (NC )
gpio-492 (NC )
gpio-493 (PWR_LOW_N |PWR ) out lo
gpio-494 (NC )
gpio-495 (NC )
gpio-496 (USB_LIMIT )
gpio-497 (NC )
gpio-498 (PWM0_OUT )
gpio-499 (CAM_GPIO0 )
gpio-500 (NC )
gpio-501 (NC )
gpio-502 (ETHCLK )
gpio-503 (PWM1_OUT )
gpio-504 (HDMI_HPD_N )
gpio-505 (STATUS_LED |ACT ) out lo
gpio-506 (SD_CLK_R )
gpio-507 (SD_CMD_R )
gpio-508 (SD_DATA0_R )
gpio-509 (SD_DATA1_R )
gpio-510 (SD_DATA2_R )
gpio-511 (SD_DATA3_R )
do i need to define more than "reset","dc" gpio ? "AN", "INT", "PWM","RST"
Those seems the be microbus signal names. AN is mapped to R/W which seems to be on the controller. INT to EN which is controlling power? PWM to D/C on the controller (dc) RST is reset
Hi Notro
Thank for your kindly support
root@imx7s-warp:~# cat /sys/kernel/debug/gpio GPIOs 0-31, platform/30200000.gpio, 30200000.gpio: gpio-24 (fb_ssd1351 ) out lo
gpio-25 (fb_ssd1351 ) out loGPIOs 32-63, platform/30210000.gpio, 30210000.gpio:
GPIOs 64-95, platform/30220000.gpio, 30220000.gpio:
GPIOs 96-127, platform/30230000.gpio, 30230000.gpio: gpio-119 (spi_imx ) out lo
GPIOs 128-159, platform/30240000.gpio, 30240000.gpio: gpio-138 (brcm_reg ) out lo
gpio-145 (bt_reg ) out loGPIOs 160-191, platform/30250000.gpio, 30250000.gpio:
GPIOs 192-223, platform/30260000.gpio, 30260000.gpio: gpio-193 (Back ) in lo
And when I run command "ls -l /sys/class/gpio/"
root@imx7s-warp:~# ls -l /sys/class/gpio/ --w------- 1 root root 4096 May 24 12:10 export lrwxrwxrwx 1 root root 0 May 24 12:10 gpiochip0 -> ../../devices/platform/soc/30000000.aips-bus/30200000.gpio/gpio/gpiochip0 lrwxrwxrwx 1 root root 0 May 24 12:10 gpiochip128 -> ../../devices/platform/soc/30000000.aips-bus/30240000.gpio/gpio/gpiochip128 lrwxrwxrwx 1 root root 0 May 24 12:10 gpiochip160 -> ../../devices/platform/soc/30000000.aips-bus/30250000.gpio/gpio/gpiochip160 lrwxrwxrwx 1 root root 0 May 24 12:10 gpiochip192 -> ../../devices/platform/soc/30000000.aips-bus/30260000.gpio/gpio/gpiochip192 lrwxrwxrwx 1 root root 0 May 24 12:10 gpiochip32 -> ../../devices/platform/soc/30000000.aips-bus/30210000.gpio/gpio/gpiochip32 lrwxrwxrwx 1 root root 0 May 24 12:10 gpiochip64 -> ../../devices/platform/soc/30000000.aips-bus/30220000.gpio/gpio/gpiochip64 lrwxrwxrwx 1 root root 0 May 24 12:10 gpiochip96 -> ../../devices/platform/soc/30000000.aips-bus/30230000.gpio/gpio/gpiochip96 --w------- 1 root root 4096 May 24 12:10 unexport
But when I use "echo" command
root@imx7s-warp:~# cd /sys/class/gpio root@imx7s-warp:/sys/class/gpio# for i in
seq 1 224
do echo "connect PIN GPIO$i"
export pin to use
echo $i > export
set PIN signal direction (IN or OUT)
echo out >gpio$i/direction
set PIN signal value (0: Off (Low), 1: On (High))
echo 1 > gpio$i/value
sleep for 1 second
sleep 1
done
I can get GPIO number of PIN (I echo 1/0 for each gpio and check it with LED light) as below
RST = GPIO 198
PWM = GPIO 200
INT = GPIO 199
AN = ?
3.3V = ?
CS = GPIO 119
SCK = GPIO 116
MISO = GPIO 118
MOSI = GPIO 117
About "pin name", I checked with many document and found out: here in "Document" section of this link (below Image) https://shop.mikroe.com/click/display/oled-c
After I run my custom device I got this
root@imx7s-warp:~# modprobe fbtft_device name=oledc busnum=1 debug=3 fbtft_device: module is from the staging directory, the quality is unknown, you have been warned. fbtft_device: SPI devices registered: fbtft_device: spidev spi1.0 20000kHz 8 bits mode=0x04 fbtft_device: 'fb' Platform devices registered: fbtft_device: Deleting spi1.0 fb_ssd1351 spi1.0: fbtft_gamma_parse_str() str= fb_ssd1351 spi1.0: 0 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 4 4 4 4 4 4 4 4 4 4 4 4 fb_ssd1351 spi1.0: fbtft_request_gpios: 'dc' = GPIO16 fb_ssd1351 spi1.0: fbtft_verify_gpios() fb_ssd1351 spi1.0: init_display() fb_ssd1351 spi1.0: set_var() fb_ssd1351 spi1.0: Display update: 1074 kB/s (29.766 ms), fps=0 (0.000 ms) fb_ssd1351 spi1.0: set_gamma() Console: switching to colour frame buffer device 16x16 graphics fb0: fb_ssd1351 frame buffer, 128x128, 32 KiB video memory, 4 KiB DMA buffer memory, fps=20, spi1.0 at 20 MHz fbtft_device: GPIOS used by 'oledc': fbtft_device: 'AN' = GPIO1 fbtft_device: 'RST' = GPIO2 fbtft_device: 'en' = GPIO15 fbtft_device: 'dc' = GPIO16 fbtft_device: SPI devices registered: fbtft_device: fb_ssd1351 spi1.0 20000kHz 8 bits mode=0x02
Next, i run "dmesg -c" command and get this
mx51_ecspi_clkdiv: fin: 60000000, fspi: 20000000, post: 0, pre: 2 mx51_ecspi_clkdiv: fin: 60000000, fspi: 20000000, post: 0, pre: 2 mx51_ecspi_clkdiv: fin: 60000000, fspi: 20000000, post: 0, pre: 2 mx51_ecspi_clkdiv: fin: 60000000, fspi: 20000000, post: 0, pre: 2 mx51_ecspi_clkdiv: fin: 60000000, fspi: 20000000, post: 0, pre: 2 mx51_ecspi_clkdiv: fin: 60000000, fspi: 20000000, post: 0, pre: 2 mx51_ecspi_clkdiv: fin: 60000000, fspi: 20000000, post: 0, pre: 2 mx51_ecspi_clkdiv: fin: 60000000, fspi: 20000000, post: 0, pre: 2 mx51_ecspi_clkdiv: fin: 60000000, fspi: 20000000, post: 0, pre: 2 root@imx7s-warp:~# fb_ssd1351 spi1.0: blank(blank=true)
But my screen is still black :(
fb_ssd1351 spi1.0: fbtft_request_gpios: 'dc' = GPIO16
...
fbtft_device: 'AN' = GPIO1
fbtft_device: 'RST' = GPIO2
fbtft_device: 'en' = GPIO15
fbtft_device: 'dc' = GPIO16
fbtft only understands 'reset' and 'dc'. reset is used when the driver loads to reset the controller, and dc is used on every transfer to distinguish between control bytes and data/pixel bytes.
Thank you. I will modify it
I modified it
.name = "oledc", .spi = &(struct spi_board_info) { .modalias = "fb_ssd1351", .max_speed_hz = 20000000, .mode = SPI_MODE_2, .platform_data = &(struct fbtft_platform_data) { .display = { .buswidth = 8, }, .bgr = true, .gpios = (const struct fbtft_gpio []) { { "reset", 198 }, { "en", 199 }, { "dc", 200 }, {}, }, .gamma = "0 2 2 2 2 2 2 2 " \ "2 2 2 2 2 2 2 2 " \ "2 2 2 2 2 2 2 2 " \ "2 2 2 2 2 2 2 3 " \ "3 3 3 3 3 3 3 3 " \ "3 3 3 3 3 3 3 3 " \ "3 3 3 4 4 4 4 4 " \ "4 4 4 4 4 4 4" } }
I use 198, 199, 200 because when I use "echo 1 > gpioXXX/value" I see that led light will be ON when I run for GPIO198, 199, 200 But display is still black :( I run as below:
But result keep displaying many texts on console .......
mx51_ecspi_clkdiv: fin: 60000000, fspi: 20000000, post: 0, pre: 2 mx51_ecspi_clkdiv: fin: 60000000, fspi: 20000000, post: 0, pre: 2 mx51_ecspi_clkdiv: fin: 60000000, fspi: 20000000, post: 0, pre: 2 mx51_ecspi_clkdiv: fin: 60000000, fspi: 20000000, post: 0, pre: 2 mx51_ecspi_clkdiv: fin: 60000000, fspi: 20000000, post: 0, pre: 2 mx51_ecspi_clkdiv: fin: 60000000, fspi: 20000000, post: 0, pre: 2 mx51_ecspi_clkdiv: fin: 60000000, fspi: 20000000, post: 0, pre: 2 mx51_ecspi_clkdiv: fin: 60000000, fspi: 20000000, post: 0, pre: 2 mx51_ecspi_clkdiv: fin: 60000000, fspi: 20000000, post: 0, pre: 2 mx51_ecspi_clkdiv: fin: 60000000, fspi: 20000000, post: 0, pre: 2 mx51_ecspi_clkdiv: fin: 60000000, fspi: 20000000, post: 0, pre: 2 mx51_ecspi_clkdiv: fin: 60000000, fspi: 20000000, post: 0, pre: 2 mx51_ecspi_clkdiv: fin: 60000000, fspi: 20000000, post: 0, pre: 2 mx51_ecspi_clkdiv: fin: 60000000, fspi: 20000000, post: 0, pre: 2 ...........
I also tried
cp /dev/urandom /dev/fb0 cp: write error: No space left on device
But screen is no hope
.mode = SPI_MODE_2,
Why mode 2? The 2 other ssd1351 displays in fbtft_device use mode 0. This sets MOSI/CLK signal inversion.
{ "en", 199 },
fbtft doesn't support 'en'. If this is backlight, you could use 'led' or '_led' if it is inverted.
You need to overrride the default width/height:
.display = {
.buswidth = 8,
.width = 98,
.height = 98,
},
mx51_ecspi_clkdiv: fin: 60000000, fspi: 20000000, post: 0, pre: 2
That's debug output from the spi controller driver: http://elixir.free-electrons.com/linux/latest/source/drivers/spi/spi-imx.c#L309
Thank you notro. I modified it and run again but display is still black. As i investigated, i found that AN (EN) PIN is disabled by i.MX7. And I think it may affect display since display need AN PIN connected to read/write data. Now I will try to change read/write data to CS PIN. Don't know how to start but start to learn now :)
This is output at current status. (Now I plug lithium pin to board also)
root@imx7s-warp:~# modprobe fbtft fbtft: module is from the staging directory, the quality is unknown, you have been warned. root@imx7s-warp:~# modprobe fb_ssd1351 fb_ssd1351: module is from the staging directory, the quality is unknown, you have been warned. root@imx7s-warp:~# modprobe fbtft_device name=oledc debug=3 busnum=1 fbtft_device: module is from the staging directory, the quality is unknown, you have been warned. fbtft_device: SPI devices registered: fbtft_device: spidev spi1.0 20000kHz 8 bits mode=0x04 fbtft_device: 'fb' Platform devices registered: fbtft_device: Deleting spi1.0 fb_ssd1351 spi1.0: fbtft_gamma_parse_str() str= fb_ssd1351 spi1.0: 0 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 4 4 4 4 4 4 4 4 4 4 4 4 fb_ssd1351 spi1.0: fbtft_request_gpios: 'reset' = GPIO198 fb_ssd1351 spi1.0: fbtft_request_gpios: 'dc' = GPIO200 fb_ssd1351 spi1.0: fbtft_request_gpios: 'led' = GPIO199 fb_ssd1351 spi1.0: fbtft_verify_gpios() fb_ssd1351 spi1.0: init_display() fb_ssd1351 spi1.0: fbtft_reset() fb_ssd1351 spi1.0: set_var() fb_ssd1351 spi1.0: Display update: 978 kB/s (18.394 ms), fps=0 (0.000 ms) fb_ssd1351 spi1.0: set_gamma() Console: switching to colour frame buffer device 12x12 graphics fb0: fb_ssd1351 frame buffer, 96x96, 18 KiB video memory, 4 KiB DMA buffer memory, fps=20, spi1.0 at 20 MHz fbtft_device: GPIOS used by 'oledc': fbtft_device: 'reset' = GPIO198 fbtft_device: 'dc' = GPIO200 fbtft_device: 'led' = GPIO199 fbtft_device: SPI devices registered: fbtft_device: fb_ssd1351 spi1.0 20000kHz 8 bits mode=0x00
And after I run "dmesg -c" There are some strange line appeared ....
Bus freq set to 24000000 start... Bus freq set to 24000000 done! cpu=0 mx51_ecspi_clkdiv: fin: 60000000, fspi: 20000000, post: 0, pre: 2 mx51_ecspi_clkdiv: fin: 60000000, fspi: 20000000, post: 0, pre: 2 ....
After that, it usually freeze my terminal (can not input anything)
If everything OK, I think display should enable & init display something when I run commands as below:
modprobe fbtft modprobe fb_ssd1351 modprobe fbtft_device...............
Is it right ?
When I run modprobe fbtft_device....... modprobe fbtft modprobe fb_ssd1351 it keep display no matter what i do stop or ctrl +C fb_ssd1351 spi1.0: fbtft_update_display(start_line=40, end_line=47) fb_ssd1351 spi1.0: fbtft_update_display(start_line=40, end_line=47) fb_ssd1351 spi1.0: fbtft_update_display(start_line=40, end_line=47) fb_ssd1351 spi1.0: fbtft_update_display(start_line=40, end_line=47) .......................
If everything OK, I think display should enable & init display something when I run commands as below:
This is an OLED so it will remain black when initialized since the initial framebuffer is zeroed.
graphics fb0: fb_ssd1351 frame buffer, 96x96, 18 KiB video memory, 4 KiB DMA buffer memory, fps=20, spi1.0 at 20 MHz
I use fbcon to put a console on the display when I do a quick test. My fbtft devices are on /dev/fb1 because hdmi takes fb0, but yours are fb0. I wonder if fbcon automatically connects to your display when it's loaded?
fb_ssd1351 spi1.0: fbtft_update_display(start_line=40, end_line=47)
If you get these on the console, it's because you have enabled them in fbtft with verbose= AND the console loglevel is set to print debug messages.
If I where to troubleshoot this I would:
This is an OLED so it will remain black when initialized since the initial framebuffer is zeroed.
I see.
I use fbcon to put a console on the display when I do a quick test. My fbtft devices are on /dev/fb1 because hdmi takes fb0, but yours are fb0. I wonder if fbcon automatically connects to your display when it's loaded?
I do not know fbcon is loaded & connected or not. So I rebuild imx7s-warp.dtb file with modules fbcon.ko. Then I run "modprobe fbcon". it return
root@imx7s-warp:~# modprobe fbcon Console: switching to colour frame buffer device 12x12
Next, I run "fbcon=map:0" ('0' is get from command "cat /proc/fb") and it do not return anything on terminal.
Current status: Screen is still BLACK
I'm trying to use con2fbmap (autoconf command is error, i'm investigating) it is in fbset package but Yocto can not use "apt-get" to get this package :( (It is strange that I can call "fbset" command but not con2fbmap)
There is an error when I tried to use fbset to run
~fbset mode "96x96-0"
D: 0.000 MHz, H: 0.000 kHz, V: 0.000 Hz
geometry 96 96 96 96 16 timings 0 0 0 0 0 0 0 accel false rgba 5/11,6/5,5/0,0/0 endmode ~cp /dev/urandom /dev/fb0 ~fbset -fb /dev/fb0 fbset: FBIOGET_VSCREENINFO: Inappropriate ioctl for device
when I read this link: https://github.com/notro/fbtft/wiki/Build-kernel-and-fbtft-drivers#configure-devices I see this section. But when i checked in menuconfig, there is nothing like this. I search in source code either but do not see anything ? Is it related to my problem "Screen is still Black" ? If yes, do you know which kernel version / repository has this source code ?
By default two console fonts is available: VGA8x8 and VGA8x16 To enable more fonts:
[] Select compiled-in fonts [ ] VGA 8x8 font (NEW) -- VGA 8x16 font [ ] Mac console 6x11 font (not supported by all drivers) (NEW) [ ] console 7x14 font (not supported by all drivers) (NEW) [ ] Pearl (old m68k) console 8x8 font (NEW) [ ] Acorn console 8x8 font (NEW) [ ] Mini 4x6 font (NEW) [ ] Sparc console 8x16 font (NEW) [ ] Sparc console 12x22 font (not supported by all drivers) (NEW) [ ] console 10x18 font (not supported by all drivers) (NEW)
About 'reset' & 'dc' pin.
fb_ssd1351 spi1.0: fbtft_request_gpios: 'reset' = GPIO198 fb_ssd1351 spi1.0: fbtft_request_gpios: 'dc' = GPIO200
is it equivalent to /sys/class/gpio198 & /sys/class/gpio200 ?
fbcon isn't necessary, I was just wondering if it connected to the device when it was probed. But if you're using yocto it might not be enabled at all.
Writing to /dev/fb0 should appear on the screen.
is it equivalent to /sys/class/gpio198 & /sys/class/gpio200 ?
Yes.
Writing to /dev/fb0 should appear on the screen.
I think so too. when I run "cp /dev/urandom /dev/fb0", screen should display something.
fbcon isn't necessary, I was just wondering if it connected to the device when it was probed. But if you're using yocto it might not be enabled at all.
I will check with NXP (producer)
~cp /dev/urandom /dev/fb0 ~fbset -fb /dev/fb0 fbset: FBIOGET_VSCREENINFO: Inappropriate ioctl for device
when i run fbset, it return this
I use my raspberrypi3 to test Oled display . I use "pioled" with different gpios because pioled has same controller ssd1351. I run step as below:
enable SPI in raspi-config sudo modprobe fbtft_device name=pioled debug=3 busnum=1 gpios=reset:20,dc:26 dmesg [ 77.151618] fbtft: module is from the staging directory, the quality is unknown, you have been warned. [ 77.156698] fbtft_device: module is from the staging directory, the quality is unknown, you have been warned. [ 77.157740] spidev spi0.0: spidev spi0.0 500kHz 8 bits mode=0x00 [ 77.157758] spidev spi0.1: spidev spi0.1 500kHz 8 bits mode=0x00 [ 77.157795] bcm2708_fb soc:fb: soc:fb id=-1 pdata? no [ 77.157844] spidev spi0.0: Deleting spi0.0 [ 77.158874] fbtft_device: GPIOS used by 'pioled': [ 77.158892] fbtft_device: 'reset' = GPIO20 [ 77.158908] fbtft_device: 'dc' = GPIO26 [ 77.158929] spidev spi0.1: spidev spi0.1 500kHz 8 bits mode=0x00 [ 77.158944] spi spi0.0: fb_ssd1351 spi0.0 20000kHz 8 bits mode=0x00 [ 77.170522] fb_ssd1351: module is from the staging directory, the quality is unknown, you have been warned. [ 77.171531] fb_ssd1351 spi0.0: fbtft_gamma_parse_str() str= [ 77.171555] fb_ssd1351 spi0.0: 0 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 4 4 4 4 4 4 4 4 4 4 4 4 [ 77.171634] fb_ssd1351 spi0.0: fbtft_request_gpios: 'reset' = GPIO20 [ 77.171658] fb_ssd1351 spi0.0: fbtft_request_gpios: 'dc' = GPIO26 [ 77.171673] fb_ssd1351 spi0.0: fbtft_verify_gpios() [ 77.171686] fb_ssd1351 spi0.0: fbtft_reset() [ 77.305640] fb_ssd1351 spi0.0: Display update: 2352 kB/s, fps=0 [ 77.306176] graphics fb1: fb_ssd1351 frame buffer, 128x128, 32 KiB video memory, 4 KiB DMA buffer memory, fps=20, spi0.0 at 20 MHz
After this
con2fbmap 1 1
=> Result is the same :( :( only LED Light is ON (3.3V) Note: I do not see any /dev/fb1 is generated. (after run fbset, there will be /dev/fb0 (my monitor) /dev/fb1 (my added OLED)
I also tried
cp /dev/urandom /dev/fb1 cp: error writing ‘/dev/fb1’: File too large cp: failed to extend ‘/dev/fb1’: File too large
I start thinking problem come from this OLED :) :) :) Not driver or WARP7 board
Based on this statement on the product page: It carries the PSP27801 OLED display, the same one that we have used on Hexiwear.
I have tracked down these files: https://developer.mbed.org/teams/Hexiwear/code/Hexi_OLED_SSD1351/file/ae5fad429790/OLED_info.h https://developer.mbed.org/teams/Hexiwear/code/Hexi_OLED_SSD1351/file/ae5fad429790/Hexi_OLED_SSD1351.cpp
Based on that, you should use this controller initialization:
write_reg(par, 0xfd, 0x12);
write_reg(par, 0xfd, 0xb1);
write_reg(par, 0xae);
write_reg(par, 0xb3, 0xf1);
write_reg(par, 0xca, 0x5f);
write_reg(par, 0xa0, 0x60);
write_reg(par, 0x15, 0x00, 0x5f);
write_reg(par, 0x75, 0x00, 0x5f);
write_reg(par, 0xa1, 0x80);
write_reg(par, 0xa2, 0x60);
write_reg(par, 0xb1, 0x32);
write_reg(par, 0xbe, 0x05);
write_reg(par, 0xa6);
write_reg(par, 0xc1, 0x8a, 0x51, 0x84);
write_reg(par, 0xc7, 0xcf);
write_reg(par, 0xb4, 0xa0, 0xb5, 0x55);
write_reg(par, 0xb6, 0x01);
write_reg(par, 0xaf);
Compare with this to see the difference from the default: http://elixir.free-electrons.com/linux/latest/source/drivers/staging/fbtft/fb_ssd1351.c#L36
Or as an fbtft_device argument:
init=-1,0xfd,0x12,-1,0xfd,0xb1,-1,0xae,-1,0xb3,0xf1,-1,0xca,0x5f,-1,0xa0,0x60,-1,0x15,0x00,0x5f,-1,0x75,0x00,0x5f,-1,0xa1,0x80,-1,0xa2,0x60,-1,0xb1,0x32,-1,0xbe,0x05,-1,0xa6,-1,xc1,0x8a,0x51,0x84,-1,0xc7,0xcf,-1,0xb4,0xa0,0xb5,0x55,-1,0xb6,0x01,-1,0xaf,-3
You can't use pioled straight up, because it is 128x128.
Based on this statement on the product page: It carries the PSP27801 OLED display, the same one that we have used on Hexiwear.
I checked init sequence of SSD1351 with sequence in Sample of Mikroe. It a bit different. Differences are order of signal in sequence & how it write command (Low DC & CS, then High again) We can found it in here: https://shop.mikroe.com/click/display/oled-c#heading1 => Download sample and open it with Mikroe Compiler or Package Manager
1 more thing that I should mention before. AN & 3.3V PIN has no signal when we are checking with Led light. (Power led light of Oled display is ON by using "echo 1 > gpio200/value" command) It may affect this display
The library in the download section only mentions the SEPS114A controller for the previous version of the display and not the ssd1351.
Thank you. I 've created 3 driver with 3 init sequence :) But it still failed. I will use them for further test after modification. Since the driver worked correctly as you suggested, I think problem may come from Hardware. (display or board). I will check it with producer. But 1 more thing, Display require 4 PIN: AN (GPIO??? - R/W), RST(GPIO198 - reset - RS), INT(GPIO199 - EN), PWM (GPIO200 - d/c) But in fbtft driver, we only defined "dc:200, reset:198". is it ok with just only 2 parameter ? Note: AN PIN is disabled by i.MX and they suggested me change to use CS PIN (GPIO119).
I have traced the signals to the datasheet descriptions:
AN -> R/W -> PSP27801:R/W#: This pin is read / write control input pin connecting to the MCU interface. RST -> RST -> PSP27801:RES#: This pin is reset signal input. PWM -> D/C -> PSP27801:D/C#: This pin is Data/Command control pin connecting to the MCU. INT -> EN -> TPS61041:EN: This is the enable pin of the device. Pulling this pin to ground forces the device into shutdown mode reducing the supply current to less than 1 μA. This pin should not be left floating and needs to be terminated.
What's AN and why is it broken out on the header?
I really don't understand why. This is what the ssd1351 datasheet has to say:
This pin is read / write control input pin connecting to the MCU interface. When 6800 interface mode is selected, this pin will be used as Read/Write (R/W#) selection input. Read mode will be carried out when this pin is pulled HIGH and write mode when LOW. When 8080 interface mode is selected, this pin will be the Write (WR#) input. Data write operation is initiated when this pin is pulled LOW and the chip is selected. When serial interface is selected, this pin R/W (WR#) must be connected to VSS
The display is wired for serial only, so why make it available... AFAIU the AN pin should be connected to GND.
So to summarise my understanding of this: AN -> GND RST -> fbtft:reset PWM -> fbtft:dc INT -> 3.3v
The TPS61041 generates 15V for the display from 3.3v.
So to summarise my understanding of this: AN -> GND RST -> fbtft:reset PWM -> fbtft:dc INT -> 3.3v
The TPS61041 generates 15V for the display from 3.3v.
I will try this first with my raspberryPi3. If this make display OK, then I will have to talk with NXP. I'm really confusing that they 've already designed WARP7 with mikroBus but when I plug it with other device (mikrobus), they need me to wire up with different PIN :) Then why should "mikrobus standard" be existed ? it is funny.
RST -> fbtft:reset PWM -> fbtft:dc INT -> 3.3v
In RaspberryPi3, display can enable by this, we using PIN as above, but the power up sequence may not right. we have to run as below:
it is default display, we can not monitor it. (we used command "con2fb")
AN -> GND
We think AN PIN have some problems. Then it can not read/write anything to display.
In WARP7, we are applying same method
About problem of 3.3V PIN in my board (WARP7). There may be hardware problem. I tried
echo 195 > /sys/class/gpio/export echo out > /sys/class/gpio/gpio195/direction # Set output echo 0 > /sys/class/gpio/gpio195/value # Output Low echo 1 > /sys/class/gpio/gpio195/value # Output High
But it can not enable.
I notice when I run echo command or do nasty thing with those PIN. some time, led light which connected to 3.3V PIN, can be ON. But led light went out right after that.
Bad luck :( I connect 3.3V & R/W PIN of display to others PIN (free PIN) of WARP7 but nothing happen. Screen do not enable like it did in Raspberry. I checked free PIN also has out signal. (I even tried with 5V PIN)
After a while trying manything. now I do not even display anything on Raspberry Currently, i do as below: PIN Plug
RASPBERRY <====> OLED C 3.3V -------------- 3.3V 3.3V -------------- EN GPIÔ26 ---------------- DC GPIO20 ---------------- RST GND ---------------- GND SPIMOSI --------------- SD1 SPIMISO --------------- SD0 SPISCK --------------- SCK GPIO06 --------------- CS (I think do not need) GND --------------- AN (R/W)
command run:
After a while trying manything. now I do not even display anything on Raspberry
@chaunnt were you able to get this working? I have sort of your same problem on the mikroBus.
not any clues :) I change to use LCD display, BTW in my case, mikroBus was customized by producer
This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days.
Can I use this driver with iMX-7S Board to enable & run OLED C Click display ?