I am playing around with the GIGA with the display and a few of the different cameras.
I have a sketch that uses GFX to talk to the display and display what I read using the camera onto the display. And noticed that I am not getting very many frames per second...
example sketch up at: GitHub - KurtE/Arduino_GIGA-stuff: This is my GIGA test sketches and other like stuff for Arduino GIGA boards
currently using #define ARDUCAM_CAMERA_HM0360
And a few things not checked in yet. My main loop looks like:
void loop() {
// Grab frame and write to another framebuffer
digitalWrite(2, HIGH);
if (cam.grabFrame(fb, 3000) == 0) {
digitalWrite(2, LOW);
// We need to swap bytes.
uint16_t *pixels = (uint16_t *)fb.getBuffer();
digitalWrite(3, HIGH);
#if defined(ARDUCAM_CAMERA_HM01B0) || defined(ARDUCAM_CAMERA_HM0360)
writeRect8BPP(&display, (display.width() - CAMERA_WIDTH) / 2, (display.height() - CAMERA_HEIGHT) / 2, (uint8_t *)pixels, CAMERA_WIDTH, CAMERA_HEIGHT, palette);
#else
for (int i = 0; i < CAMERA_WIDTH * CAMERA_HEIGHT; i++) pixels[i] = HTONS(pixels[i]);
display.drawRGBBitmap((display.width() - CAMERA_WIDTH) / 2, (display.height() - CAMERA_HEIGHT) / 2, pixels, CAMERA_WIDTH, CAMERA_HEIGHT);
#endif
digitalWrite(3, LOW);
} else {
digitalWrite(2, LOW);
blinkLED(20);
}
}
And noticed with Logic analyzer I am not getting that many frame per second:
The calls to get the next fame is taking about a 1/5 of a second:
And the code to display it is taking about another 1/5th of a second:
At first I thought it was my calling to drawPixel to do the work so I hacked up a version of
the writeRect code that tried to minimize speed differences>
With this camera running in orientation 3:
void writeRect8BPP(GigaDisplay_GFX *pdisp, int16_t x, int16_t y, const uint8_t bitmap[],
int16_t w, int16_t h, const uint16_t *palette) {
int display_width = 480; // pdisp->WIDTH;
int display_height = 800; //pdisp->HEIGHT;
uint16_t *display_buffer = pdisp->getBuffer();
pdisp->startWrite();
// BUGBUG Assuming it will fit here and don't need to clip
#if CANVAS_ROTATION == 1
// y = xIn ; x = WIDTH - 1 - yIn
for (int16_t j = 0; j < h; j++, y++) {
uint16_t *p = display_buffer + (x * display_width) + display_width - 1 - y;
for (int16_t i = 0; i < w; i++) {
*p = palette[*bitmap++];
p += display_width;
}
}
#elif CANVAS_ROTATION == 3
// y = HEIGHT = 1 - xIn ; x = yIn
uint16_t *p_row = display_buffer + ((display_height - 1 - x) * display_width);
for (int16_t j = 0; j < h; j++, y++) {
uint16_t *p = p_row + y;
for (int16_t i = 0; i < w; i++) {
*p = palette[*bitmap++];
p -= display_width;
}
}
#else
for (int16_t j = 0; j < h; j++, y++) {
for (int16_t i = 0; i < w; i++) {
digitalWrite(4, HIGH);
pdisp->writePixel(x + i, y, palette[bitmap[j * w + i]]);
digitalWrite(4, LOW);
}
}
#endif
digitalWrite(4, HIGH);
pdisp->endWrite();
digitalWrite(4, LOW);
}
I thought maybe having the frame buffer in SDRAM was slowing it down, so I in this case just used normal malloc for the monochrome case and not that much of a difference.
And as a reference point, I printing out how long it takes fillScreen takes:
elapsedMicros em;
display.fillScreen(GC9A01A_BLUE);
Serial.println(em, DEC);
Before setRotation
Before fillscreen
20977end setup
Before camera start
Before setBuffer
Frame buffer: 0x2400ed80
Before setRotation
Before fillscreen
20968
end setup
So again 1/5th of a second.
Why is it so slow? Are there faster ways to update the screen?
Also wondering about the camera speed or setup. In this case I asked for 15 frames per second.
#if CAMERA_WIDTH == 640
if (!cam.begin(CAMERA_R640x480, IMAGE_MODE, 15)) {
blinkLED();
}
#else
if (!cam.begin(CAMERA_R320x240, IMAGE_MODE, 30)) {
blinkLED();
}
#endif
And as I mentioned, I am getting somewhere around 5 frames per second. I expected worst case about 7.5 frames if the frame had start just before we entered the API.
Also wondering if there is a way to put the camera into a continuous read mode maybe with two buffers and have some form of callback to let me know a new frame is available... But maybe different subject.
Note: the camera speed for the OV7675 in the 640x480 mode was similar
