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!