McKee

Members
  • Content Count

    3
  • Joined

  • Last visited

  1. 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
  2. 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
  3. 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