MTDS display on PSoC 6

[McKee]

I am considering the Digilent Pmod 2.8" MTDS display for a Cypress Pioneer CY8CKIT-062-BLE, which has a PSoC 6 MCU. The kit board includes a Pmod header.

One challenge is that I intend to generate a live image on the display as close to 20 Hz frame rate as I can get. Looks like I will need to modify the mtds library to handle the SPI connection to the PSoC 6 and also to create a function for high speed image data transfer instead of reading files from the display's SD card. (I will use the latter for a button UI also.) I am not sure the display's processor can handle the required SPI clock rate from the PSoC. It can run a 50+ MHz SPI clock, but I notice that the clock rate listed in  MtdsHal.h for a PIC32 is 3.5MHz, or 4 MHz for AVR. I calculate I need 25MHz or so: 320 x 240 x 16 x 20 bits per sec. Is there a display side limit?

Comments/ideas/collaborators welcome. Just exploring at this stage.

thanks, McKee

[jpeyron]

Hi @McKee,

 I am in the process of reaching out to more knowledge engineers about your clock rate question. 

thank you,

Jon

[JColvin]

Hi @McKee,

We learned the following from one of the engineers much more familiar with the MTDS library that the SPI clock speeds that are listed in the MtdsHal.h file were the calculated max speeds that were attainable with the implemented state machine in the MTDS firmware.

As a side note, a begin function does exist to let you choose an alternate SPI clock speed, but as stated in the MTDS Library Programmer's Reference Manual that comes with the library download, the board will begin to experience erratic behavior, especially if the touch functionality is being used.

Thank you,
JColvin

 

[McKee]

Thanks much, @JColvin and @jpeyron, for looking into it and replying.

Yes, I had seen that begin() function and wondered if the default clock frequency was max. So indeed it seems that 4 MHz would be the SPI maximum, else risk erratic display behavior. Thus a max update rate for an image area comprising most of the display would be about 4 Hz, or 8 Hz if just using 8 bit greyscale data going across the SPI. I will probably seek another display subsystem for my project.  But the MTDS library seems really nice ... sad to leave it behind. 

And I realized, doh, that while I might blithely add functionality to the host MTDS library, such as a new function MTDS::WriteBitmap(hbmp,data), there would be no primitives on the display side processor firmware to implement the necessary "receiving" functionality in its MCU, unless I were to get into that code also ... which is beyond the scope I can take on (or perhaps that Digilent would allow.)

But if your team decides to implement some form of MTDS::WriteBitmap() functionality, of course I would be interested, especially if the state machine you mentioned could be tweaked to accept a 12 MHz or 25 MHz SPI link, even for the special case of live image transfer. Seems unlikely.

So again, thanks for the help. I'll keep looking at other display options.

McKee

[JColvin]

Hello @McKee,

What sort of functionality are you looking for with this MTDS::WriteBitmap(hbmp,data) function were you looking for?

There seem to be a couple of functions that put an image onto the display with just the name (or handle) for the image and the desired upper left coordinate in the MyDisp Library Programmer Reference Manual with the overloaded MYDISP::drawImage function. Those functions eventually re-direct to calling the MTDS::DrawBitmap function which can be found on page 70 of the MTDS Library Programmer's Reference Manual.

As for the firmware on the display itself, I don't even have access to it, but perhaps calling some of these lower level functions as appropriate will be able to get you the speed increase you need.

Thanks,
JColvin

 

[McKee]

hi @JColvin --

I had looked through those functions, but perhaps not deeply enough.

Yes, DrawBitmap() is a fast low level MTDS function, but it just sends handles and coordinates over SPI to the shield. Creating the source bitmap in the shield from arbitrary data in the host the issue, as I understand it. The MyDisp library provides those two drawImage() overloads you mention, as well as another called loadImage(), but they are all constrained to essentially static data sources: two of them take a file name to read from the SD card file system (in the shield), and the other takes a handle for an existing bitmap, created previously in the shield. If not created by reading an SD file, then a bitmap can be created or modified or copied in the shield by sending drawing or rendering commands, etc., such as by the high level MyDisp::drawArc() function or the low level MTDS::Arc() primitive . An extremely slow way to create an arbitrary bitmap, such as my live image, would be to use MTDS::SetPixel() for each and every pixel. Each call results in a long execution of MTDS::MtdsProcessCmdWr(), with its handshakes and timeouts etc.

I would need to create the bitmap in the shield from an array of data that my algorithm will generate in the host, from scratch. A single array of unsigned 16, for instance, to set pixel states in an existing bitmap object. I could also pass coordinate boundaries or max array size or whatever is convenient to implement. But they key is a single transfer across SPI, one transaction, one call to MTDS::MtdsProcessCmdWr(). But there seems to be no firmware function that can accept such a data stream on the shield side.

In fact, looking at the low level communication functions and macros, it appears that the maximum single call payload would be 512 bytes, from ProtoDefs.h:

#define    cbDhdrDataOutMax    512            // maximum payload for data out packet

With that as max payload, it would take 150 calls to populate a full size bitmap on the shield with 8 bit pixel data. Clearly a new SPI transfer mechanism would need to be created, that can take a long data stream. My guess is that's why it does not already exist.

Intriguingly, some unfulfilled function prototypes suggest that bitmap loading might have been contemplated. In mtds.h:

    bool        SndBitmap(char * szName, uint8_t * pbmp);
    bool        RcvBitmap(char * szName, int cbMax, uint8_t * pbmp);

No sign of implementation of these functions in the MTDS library. 

Seems I am pushing for functionality a little beyond the intent of the hardware. I am in a sour spot -- I am generating a slow, live, coarse medical image (anatomy), akin to a slow movie, and then trying to display it on a very low power, small system. This Pmod display shield is close, but no cigar. 

Unless you see some mechanism I have not thought of.

Thanks again for looking at this!

McKee

 

 

[JColvin]

Hi @McKee,

Unfortunately I am in agreement with you; I don't think there is another method already available that will get you the transfer speed that you need. I'll definitely put this type of data transfer in as a customer request, but since I don't know how the internal firmware is set up, I'm not able to provide any sort of guess on the feasibility or timeframe for this to be implemented.

Good luck,
JColvin