MicroMod Beta Testing

Arghh - github wanted to merge from your tree when nothing changed here - had to remove and start over ...

Installed 'git' but that's foreign - dumping and restarting repositories is a regular thing it seems ...

Anyhow on T_4.1 the AMZN ST7789 running one eye of : uncannyEyes_async_st7789_240x240.ino

<edit> p#483 sketch doesn't compile? Not sure why the conflicts and inclusion of 9341?

No comment on git :)

Any I just compile the test sketch that you posted with the latest updates to the ST7735 library and got no errors. I tried 7789 only, 9341 only, and both uncommented still no compile issues. I did use the T4.1 for the compile though.
 
@KurtE
Ok I give up. Got be doing something wrong someplace and not sure where. What I am trying to duplicate is what we did in your CSI_41_main in the send_image function. But just can't seem to get it right. Here's my latest iteration of the function just in case you want to look at my wacky coding.

Anyway, tomorrow going to do some clean up of the library and do some simple sketches as examples. Also want to try you new library with other 7735 displays. Think I know where I put them.

Code:
DMAMEM unsigned char image[324*244];
void send_image() {
  uint32_t imagesize, fbc;
  imagesize = (320 * 240 * 2);
  
  memset((uint8_t*)frameBuffer, 0, sizeof(frameBuffer));
  hm01b0.set_mode(HIMAX_MODE_STREAMING_NFRAMES, 1);
  hm01b0.readFrame(frameBuffer);
  
  //first lets ditch the first and last 2 rows
  uint32_t idx = 0;
  uint32_t start_idx = FRAME_WIDTH * 2; 
  uint32_t end_idx = FRAME_HEIGHT*FRAME_WIDTH - FRAME_WIDTH*2;

  for (uint32_t i = start_idx; i < end_idx; i++) {
    idx = (i-start_idx) * 2;
    frameBuffer[i] = color565(frameBuffer[i], frameBuffer[i], frameBuffer[i]);
    image[idx] = (frameBuffer[i] >> 0) & 0xFF;
  }
  
  //ok now lets try and ditch the last 4 pixels in each row - yes i know 2 before and 2 after probably.
  idx = 0;
  for(uint16_t j = 0; j < 240; j++) {
    for(uint16_t i = 0; i < 324; i++) {
      if(i < 320) {
        idx += 1;
        frameBuffer[idx ] = image[ i + j*320];
        frameBuffer[i] = color565(frameBuffer[i], frameBuffer[i], frameBuffer[i]);
        //Serial.printf("idx: %d, image_idx: %d\n", idx, i + j*240);
      }
    }
  }

  idx = 0;
  for(uint32_t i = 0; i < 320*240; i++) {
    idx = i * 2;
    sendImageBuf[idx + 1] = (frameBuffer[i] >> 0) & 0xFF;
    sendImageBuf[idx] = (frameBuffer[i] >> 8) & 0xFF;
  }

  Serial.write(0xFF);
  Serial.write(0xAA);

  //for (int temp = 0; temp < BMPIMAGEOFFSET; temp++)
  //{
  //  Serial.write(pgm_read_byte(&bmp_header[temp]));
  //}
  Serial.write((const uint8_t *)&bmp_header, sizeof(bmp_header));

  Serial.write(sendImageBuf, imagesize);

  Serial.write(0xBB);
  Serial.write(0xCC);

  Serial.println(F("ACK CMD CAM Capture Done. END"));delay(50);

}
 
@KurtE
Think your latest rounds of updates to the 7735 lib broke something in the HM01b0 library:
Code:
C:\Users\Merli\AppData\Local\Temp\arduino_build_418531\libraries\ST7735_t3-t4x_dma_no_copy\ST7735_t3.cpp.o: In function `dumpDMA_TCD(DMABaseClass*)':
D:\Users\Merli\Documents\Arduino\libraries\ST7735_t3-t4x_dma_no_copy/ST7735_t3.cpp:4250: multiple definition of `dumpDMA_TCD(DMABaseClass*)'
C:\Users\Merli\AppData\Local\Temp\arduino_build_418531\libraries\TMM-HM01B0\HM01B0.cpp.o:D:\Users\Merli\Documents\Arduino\libraries\TMM-HM01B0\src/HM01B0.cpp:1371: first defined here
f:/arduino-1.8.13-beta6/hardware/tools/arm/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/bin/ld.exe: Disabling relaxation: it will not work with multiple definitions
collect2.exe: error: ld returned 1 exit status
 
I just pushed up change for one fix for 240x240...

I can start and stop, sometimes a few times, but sometimes it hangs, so I need to debug more of that.
 
@KurtE
Think your latest rounds of updates to the 7735 lib broke something in the HM01b0 library:
Code:
C:\Users\Merli\AppData\Local\Temp\arduino_build_418531\libraries\ST7735_t3-t4x_dma_no_copy\ST7735_t3.cpp.o: In function `dumpDMA_TCD(DMABaseClass*)':
D:\Users\Merli\Documents\Arduino\libraries\ST7735_t3-t4x_dma_no_copy/ST7735_t3.cpp:4250: multiple definition of `dumpDMA_TCD(DMABaseClass*)'
C:\Users\Merli\AppData\Local\Temp\arduino_build_418531\libraries\TMM-HM01B0\HM01B0.cpp.o:D:\Users\Merli\Documents\Arduino\libraries\TMM-HM01B0\src/HM01B0.cpp:1371: first defined here
f:/arduino-1.8.13-beta6/hardware/tools/arm/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/bin/ld.exe: Disabling relaxation: it will not work with multiple definitions
collect2.exe: error: ld returned 1 exit status

They both have the same debug code... My last push up turned of the DMA test code in the ST7735/89 code. Let me know if that fixes it for you. Works on mine.
 
@mjs513
Obviously untested, but I think it would be a lot easier to debug with a double loop - here's my guess at what you're doing.

Code:
DMAMEM unsigned char image[324*244];
void send_image() {
  uint32_t imagesize, fbc;
  imagesize = (320 * 240 * 2);
  
  memset(frameBuffer, 0, sizeof(frameBuffer));
  hm01b0.set_mode(HIMAX_MODE_STREAMING_NFRAMES, 1);
  hm01b0.readFrame(frameBuffer);
  
  uint32_t image_idx = 0;
  uint32_t frame_idx = 0;

  for (uint32_t row = 0; row < 240; row++) {
    for (uint32_t col = 0; col < 320; col++) {
      frame_idx = (324 * (row + 2)) + col + 2;
      uint16_t framePixel = color565(frameBuffer[frame_idx], frameBuffer[frame_idx], frameBuffer[frame_idx]);
      sendImageBuf[image_idx++] = (framePixel >> 8) & 0xFF;
      sendImageBuf[image_idx++] = (framePixel) & 0xFF;
    }
  }
  
  Serial.write(0xFF);
  Serial.write(0xAA);

  Serial.write((const uint8_t *)&bmp_header, sizeof(bmp_header));

  Serial.write(sendImageBuf, imagesize);

  Serial.write(0xBB);
  Serial.write(0xCC);

  Serial.println(F("ACK CMD CAM Capture Done. END"));delay(50);

}
 
Morning all
@KurtE - Just downloaded your updates from last night and yep resolved the compile issue. Did you sort out your compile issue?

@ecurtz
Your guess was pretty good. With a couple of tweaks it worked perfectly. See image
Capture.PNG

Thanks for the assist was driving me crazy.
 
Just pushed up I think fix for T4.x into the ST7735_t3 branch I mentioned... Not sure if anyone else wants to try it before I do the PR?

Just tested your latest changes on a T4.1 with a Adafruit 128x128 display. Starts up fine and display looks good however after I toggle updates off screen stops but I can't seem to toggle it back on. Seems to hang the T4.1.

I then tried it on a T3.6 and worked fine even with toggling on and off and back on.

T4.1 SerMon output - dies after this
Code:
D:\Users\Merli\Documents\Arduino\st7789_framebuffer_test\st7789_framebuffer_test.ino Apr 16 2021 07:19:33
Begin: CS:10, DC:7RST: 8
Starting up DMA Updates
==================================================

*** Commands ***
    t - Toggle display updates on or off
after endUpdateAsync

T3.6 output:
Code:
D:\Users\Merli\Documents\Arduino\st7789_framebuffer_test\st7789_framebuffer_test.ino Apr 16 2021 07:24:22
Begin: CS:10, DC:7RST: 8
Starting up DMA Updates
==================================================

*** Commands ***
    t - Toggle display updates on or off
after endUpdateAsync
after endUpdateAsync
after waitUpdateAsyncComplete
Finished test
Do normal update to see if data is there
Starting up DMA Updates
after endUpdateAsync
after endUpdateAsync
after waitUpdateAsyncComplete
Finished test
Do normal update to see if data is there
 
Morning @mjs513.... Yep I need to look more at the shutdown... It did not go all of the way through... Which is why I added all of those outputs, back in the ILI coding of it. Probably something subtle.
Will play some more.
 
Morning @mjs513.... Yep I need to look more at the shutdown... It did not go all of the way through... Which is why I added all of those outputs, back in the ILI coding of it. Probably something subtle.
Will play some more.

Not a problem, just wanted to let you know. Took a while to find a display that you didn't test with - saw you tested with the 240x240 and the 320x240.

One curious thing about the HM01B0. Was reading on the their forum that some sensors worked with their library (CalAE) and others didn't. One user said he bought 2 cameras - 1 worked 1 didn't. Their library is geared to B/W. Reading one of the Sparkfun comments when they asked about color Sparkfuns response was basically they only how to make it work in monochrome mode and the user would have to ask Himax. Know the marking is -A for color and -M for monochrome. So may eventually do a test to see if we can get it into color mode - just in case we missed something.
 
Sounds good, I am assuming that the two others I ordered from Sparkfun, scheduled to arrive Sat at our PMB, which usually means Monday... Will be Mono as well.

As for the hang, I am pretty sure it is timing related... Note the 128x128 was hanging at every one, but simple change to test sketch:
In the frame callback:
Code:
void frame_callback() {
  //Serial.printf("FCB: %d %d\n", tft.frameCount(), tft.subFrameCount());
  uint32_t frameCount = tft.frameCount();
  // See if end of test signalled.
  if (shutdown_cont_update_count == COUNT_SHUTDOWN_FRAMES) {
    uint8_t color_index = (frameCount >> 4) & 0x7;
    tft.setCursor(TCENTER, TCENTER);
    tft.setTextColor(our_pallet[(color_index + 3) & 7]);
  [COLOR="#FF0000"]  if (tft.width() > 240) tft.setFont(Arial_20_Bold);
    else if (tft.width() > 160 ) tft.setFont(Arial_14_Bold);
    else tft.setFont(Arial_10_Bold);[/COLOR]
    tft.println("Stop Signalled");
    shutdown_cont_update_count--;
    arm_dcache_flush(tft_frame_buffer, FRAME_BUFFER_SIZE);
  } else if (shutdown_cont_update_count == 0) {
To downsize the font used when smaller screens, and it ran through 4 iterations before it hung...
 
I just tried it with your change and saw the same thing but only if I changed the default size "Arial_10_Bold", otherwise it hung after only 1 cycle.
 
For the most part I think it is an issue with the way the test is doing stuff...

So I may not hold up stuff on this. I am going to change the test callback to only do stuff for shutting down only at start of frame not at half frame and see what that does.
 
For the most part I think it is an issue with the way the test is doing stuff...

So I may not hold up stuff on this. I am going to change the test callback to only do stuff for shutting down only at start of frame not at half frame and see what that does.

Got it. I wouldn't hold it up either. It does seem to be working.

@Paul - @defragster
I did just make a few changes in prep for final release. I add 3 defines (at least for now) in the HM01B01 file:
Code:
// Camera access modes
//#define Normal_Mode 1
//#define DMA_Mode 1
#define FlexIO_Mode 1
If all 3 are uncommented you can still run the kitchen sink example. But for now it defaults to the FlexIO mode. I did update the lib to only load what's requested. I also added a example1 to just use FlexIO.

Just pushed that change - still have to test a few things to be sure nothing else is needed.
 
@mjs513 - I hacked up the example, mainly just the callback:
Code:
void frame_callback() {
  //Serial.printf("FCB: %d %d\n", tft.frameCount(), tft.subFrameCount());
  uint32_t frameCount = tft.frameCount();
  bool start_of_frame = tft.subFrameCount() == 0;
  // See if end of test signalled.
  if (start_of_frame) {
    if (shutdown_cont_update_count == COUNT_SHUTDOWN_FRAMES) {
      uint8_t color_index = (frameCount >> 4) & 0x7;
      tft.setCursor(TCENTER, TCENTER);
      tft.setTextColor(our_pallet[(color_index + 3) & 7]);
      if (tft.width() > 240) tft.setFont(Arial_20_Bold);
      else if (tft.width() > 160 ) tft.setFont(Arial_14_Bold);
      else tft.setFont(Arial_10_Bold);
      tft.println("Stop Signalled");
      shutdown_cont_update_count--;
      arm_dcache_flush(tft_frame_buffer, FRAME_BUFFER_SIZE);
      return;
    } else if (shutdown_cont_update_count == 0) {
      tft.setCursor(TCENTER, tft.getCursorY());
      tft.println("endUpdateAsync");
      tft.endUpdateAsync();
      Serial.println("after endUpdateAsync");
      arm_dcache_flush(tft_frame_buffer, FRAME_BUFFER_SIZE);
      return;
    } else if (shutdown_cont_update_count < COUNT_SHUTDOWN_FRAMES) {
      shutdown_cont_update_count--;
    }
  }
#ifndef UPDATE_HALF_FRAME
  else return;
#endif  

#ifdef UPDATE_HALF_FRAME
  bool draw_frame = false;
  if (((frameCount & 0xf) == 0) && tft.subFrameCount()) {
    draw_frame = true;
    tft.setClipRect(0, 0, tft.width(), tft.height() / 2);
  } else if (((frameCount & 0xf) == 1) && !tft.subFrameCount()) {
    draw_frame = true;
    tft.setClipRect(0, tft.height() / 2, tft.width(), tft.height() / 2);
  }
  if (draw_frame)
#else
  if ((frameCount & 0xf) == 0)
#endif
  {
    // First pass ignore subframe...
    uint8_t color_index = (frameCount >> 4) & 0x7;
    tft.fillScreen(our_pallet[color_index]);
    tft.drawRect(5, 5, tft.width() - 10, tft.height() - 10, our_pallet[(color_index + 1) & 7]);
    tft.drawRect(25, 25, tft.width() - 50, tft.height() - 50, our_pallet[(color_index + 2) & 7]);

    static uint8_t display_other = 0;
    switch (display_other) {
      case 0:
        tft.fillRect(50, 50, tft.width() - 100, tft.height() - 100, our_pallet[(color_index + 1) & 7]);
        break;
      case 1:
        tft.fillCircle(tft.width() / 2, tft.height() / 2, 100, our_pallet[(color_index + 1) & 7]);
        break;
      case 2:
        tft.fillTriangle(50, 50, tft.width() - 50, 50, tft.width() / 2, tft.height() - 50, our_pallet[(color_index + 1) & 7]);
        break;
    }
    if (!tft.subFrameCount()) {
      display_other++;
      if (display_other > 2) display_other =  0 ;
    }

    arm_dcache_flush(tft_frame_buffer, FRAME_BUFFER_SIZE);
    tft.setClipRect();
  }

}
And it did not hang in 10 runs of the 128x128
 
Got it. I wouldn't hold it up either. It does seem to be working.

@Paul - @defragster
I did just make a few changes in prep for final release. I add 3 defines (at least for now) in the HM01B01 file:
Code:
// Camera access modes
//#define Normal_Mode 1
//#define DMA_Mode 1
#define FlexIO_Mode 1
If all 3 are uncommented you can still run the kitchen sink example. But for now it defaults to the FlexIO mode. I did update the lib to only load what's requested. I also added a example1 to just use FlexIO.

Just pushed that change - still have to test a few things to be sure nothing else is needed.

Boy just #ifdef out all my stuff :D ;)
Actually at some point if we really want to kitchen sink it, we should also for the T4.1 add the CSI mode stuff.
 
Boy just #ifdef out all my stuff :D ;)
Actually at some point if we really want to kitchen sink it, we should also for the T4.1 add the CSI mode stuff.

Actually not really. FlexIO is so intertwined with the DMA stuff that 98% of its still being called for flexIO dma. :) which I chose to leave in. That caused me some problems when doing that :)

Oh - just tried you new callback a whole bunch of times and no issues with hanging. Even caught it a few times between half screen updates so had half the screen one color and the other half a different color :) Looks like it works.

As for CSI mod - Argh!
 
@mjs513 - does this link the ArduCam viewer : arducam.com/arducam-host-application-demonstration/ ... there is a zip onder 'here' : precompiled execute program can be download from here

The test of a single uncanny eye ran until shutdown last night - on a 240x320 ST7789 - showing active 240x240 area and garage in the 'extra' area. Didn't resolve why the prior post failed to build.

Behind on chores here ...
 
@mjs513 - does this link the ArduCam viewer : arducam.com/arducam-host-application-demonstration/ ... there is a zip onder 'here' : precompiled execute program can be download from here

The test of a single uncanny eye ran until shutdown last night - on a 240x320 ST7789 - showing active 240x240 area and garage in the 'extra' area. Didn't resolve why the prior post failed to build.

Behind on chores here ...

No - you are going to be in trouble if you use that one. Down the version I am using from here: https://github.com/ArduCAM/Arduino/tree/master/ArduCAM/examples/host_app/ArduCAM_Host_V2.0_Windows
 
MM board tests in a DIY carrier (solder paste dispenser)

I tested the Teensy MM beta board in my DIY stepper motor carrier. This carrier is part of a solder paste dispenser project I'm working on since a couple of weeks. The T4 MM board finally motivated me to work on the long promised T4 port of TeensyStep. (Well, actually it was a complete rewrite but this is another story for another thread :) )

The T4 MM board worked without issues in the carrier board. I was afraid that I'll get problems with the USB lines since the carrier was originally designed for a T3.2 MM board and I therefore didn't pay much attention to the routing of the USB lines. Anyway, it doesn't seem to be that critical since the carrier works without issues with the T4 MM board as well. Here a quickly assembled video showing the MM board controlling the thing (dry tests only, solder paste tests come next...)


Since you all make such great progress with the cameras I thought it might be a good idea to add one to the design and stream the video to the controlling PC, or use it to automatically calibrate the board position which currently is done manually... Lots of stuff to play with :)
 
@luni
Nice toy. Must be nice to have room for things like that :)

Guess I will have to see about about sending a continuous stream to the PC :)
 
@luni
Nice toy. Must be nice to have room for things like that :)
Actually it is quite, say, teensy :)

Guess I will have to see about about sending a continuous stream to the PC :)

Thought of encoding to jpeg before sending to reduce the data to transfer. Maybe something like this: https://github.com/noritsuna/JPEGEncoder4Cortex-M. Of course, this only makes sense if encoding is faster than sending the raw data. Ordered a few of those super cheap OV7670 boards for experimenting...
 
Actually it is quite, say, teensy :)

Thought of encoding to jpeg before sending to reduce the data to transfer. Maybe something like this: https://github.com/noritsuna/JPEGEncoder4Cortex-M. Of course, this only makes sense if encoding is faster than sending the raw data. Ordered a few of those super cheap OV7670 boards for experimenting...

Actually yes, on and off thought about but something always distracted me. Just took another look and found this one as well: https://create.stephan-brumme.com/toojpeg/ == it has some good references.
 
Does also look good and super easy to use but it seems to be targeted at larger machines? The one I linked is explicitly done for Cortex M processors. Don't know if it makes a difference though. Need to wait for my modules before I can do any experiments.
 
Back
Top