Because of the Thanksgiving holiday in the U.S., TI E2E™ design support forum responses may be delayed from November 25 through December 2. Thank you for your patience.

  • State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 102 subscribers
  • Views 1554 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Linux/AM3352: Using 3-wire 9bit mode devices in McSPI

Richard McAleer
Expert 1485 points
Part Number: AM3352

Tool/software: Linux

Hi

I am working on a platform closely based on the beagle bone black.
One addition is a small screen that requires to be set up using SPI in a 9bit 3-WIRE mode.

It has been tracked to MOSI, SCLK and CS0 of SPI1 on our am3352zcz (balls H5, H16 and C12) there is nothing connected to the MISO of this SPI bus. 

MOSI has been connected to the SDA of the screen.

There appears to be a driver for the necessary chip (ilitek, 9340L) - the kernel version I am presently using is 4.4.19-gdb0b54cdad

From reading the TRM the hardware should be capable of this; looking at the code however it looks like it is not yet supported (from comments in spi-omap2-mcspi.c)

From the driver code it appears that it only transmits data - nothing is ever read from the display.

I am wondering what the path of least resistance would be to in get this screen to work?

  • Would I need to implement 3-WIRE support fully at the mcspi layer? (does anyone know of a patch?)
  • or is it possible to work with a normal 4-WIRE SPI mode in 9bits as all the (missing) received data is "dont' care"?
  • or is there some other option (pins as GPIO & bitbash?

Thanks for any advice, suggestions or warnings.

All the best,
Richard

  • 0
    TI__Guru**** 161600 points
    We're working on this. Feedback will be posted here.

    Best Regards,
    Yordan
  • 0 in reply to Yordan Kovachev
    Expert 1485 points

    Hi Yordan

    thanks for the reply.

    I believe that in this case I can just "pretend" that is is a 4-wire SPI because there is no attempt to read anything within the driver (fb_ili9340.c).

    The fbtft-core already looks to support supports 9bit transactions (using fbtft_write_reg8_bus9 if the buswidth is set to 9)

    From looking at the display datatsheet this screen is intended to be configured via SPI then operated via the lcd controller.

    I will have to work out how to convince my system to do this - but those questions probably belong in a different post.

    I would still be interested in knowing how extending the McSPI to support 3WIRE would be done; it looks like it could be useful to be able to peek registers within the display chip.

    Thanks for your help,

    All the best,

    Richard

  • 0 in reply to Richard McAleer
    TI__Genius 13485 points

    Hi Richard,

    This post might be interested for you, if you have not already come across it:

    https://www.element14.com/community/community/designcenter/single-board-computers/next-gen_beaglebone/blog/2015/11/24/bbb-fbtft-linux-44-kernel

    I think you're right - the fbtft driver should handle your SPI signaling.

    Are you using the TI Processor SDK, or the BeagleBoard.org Debian distribution?  I think the only thing that will change is whether or not you would need to manually modify your device tree (TI) or load a DT overlay (bb.org).

    Regards,
    Mike

  • 0 in reply to Michael Erdahl
    Expert 1485 points

    Thanks Mike

    that looks like it covers this driver pretty well; I had not seen that post

    - I've been working my way through the info in github.com/.../wiki 

    what confuses me at present is that the display we have is intended to be configured via SPI but updated via parallel interface

    I will need to check the configuration in the driver code to see what mode it leaves the display chip (these ilitek chips look to be very flexible - with a hefty datasheet to match!)

    Thanks for the pointer.

    All the best,

    Richard