Forum Rule: Always post complete source code & details to reproduce any issue!
Page 12 of 36 FirstFirst ... 2 10 11 12 13 14 22 ... LastLast
Results 276 to 300 of 889

Thread: MicroMod Beta Testing

  1. #276
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    13,943
    Cloned the @mjs github for camera - not sure where the new code is evolving - have not read today's posts yet ...

    All seems well!
    >> Continuous seems FASTER? And it starts with "C"

    Running the PDE started a few times with bogus image shown.

    That runs on serialEvent() - wondered if that is triggering faster than all packets are buffered? Transfer is 300 packets of 512 bytes?
    > That routine enters on USB start - and does a while (bb.hasRemaining()) without any check on completed image transfer.

    Added a delay(3):
    Code:
    void serialEvent(Serial myPort) {
      delay(3);
    // read the saw bytes in
      myPort.readBytes(frameBuffer);
    //...
    Restarted a couple times and not seeing any garbage images with that?

    It may be this fancy new i7 running a tad faster? Code triggers before transfer is complete?

    Correction - restarted and SerMon showing this and the image from PDE is split Left to Right, But this is not the GARBAGE images I was seeing before:
    Code:
    Image Sent!
    Calibrating Auto Exposure...
    	not converged
    Versus:
    Code:
    Image Sent!
    Calibrating Auto Exposure...
    	converged!

  2. #277
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    6,973
    Quote Originally Posted by KurtE View Post
    @mjs513 - I was about to edit my response, and noticed you had edited yours.

    I was going to mention, that you might be able to use the other way, if you do something like SD.sdfs.open(...)
    I think you can then pass those flags directly to SDFS...

    This morning I figured out why one test I was doing was not working in my DMA buffer processing:

    Which I copied from readFrame:
    bool _grayscale = (pixformat == PIXFORMAT_GRAYSCALE);
    was returning false...

    But somehow working in readFrame.

    The issue is in the set_pixformat function: https://github.com/mjs513/TMM-HB01B0...M01B0.cpp#L509
    The parameter name to this method (pixformat) is the same name as your member variable, so the function more or less set the parameter (local variable) back to itself and not the member
    variable. When I changed the paramter to: pfmt (likewise the switch), the test in my function now works...
    @KurtE
    Was just playing with the fix and something hit me with readframe. The readFram function was designed to support the color version of the HB01B0 camera so once you fix the error with pixformat you wind up with 2 25% size pictures on the screen. Have to do the following in the code to fake it our:
    Code:
    	  //Change for Monodchrome only HB01b0
    	  _grayscale = false;
          if (!(j & 1) || !_grayscale) {
            *b++ = in;
          }

  3. #278
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    13,943
    Quick note - I put in an SD card on the MachL and saved a usable bitmap with 3 hr old github - now see it is fresh 32 minutes ago - lib.prop update

    Sounds like good progress on something ...

  4. #279
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    13,943
    Just restarted PDE - broken image again - the delay(3) not the fix
    Here is a Teensy card with light image out of H and V sync:
    Click image for larger version. 

Name:	ProCam04.png 
Views:	1 
Size:	81.5 KB 
ID:	24397
    > some of the images before this were worse with garbage
    <edit>
    > All sends are marked 'converged!'

    Oh - and nice '0' add to Blank display.

  5. #280
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    6,973
    Quote Originally Posted by defragster View Post
    Just restarted PDE - broken image again - the delay(3) not the fix
    Here is a Teensy card with light image out of H and V sync:


    Oh - and nice '0' add to Blank display.
    Not sure whats going on - on my machine it seems to be working no problem. After I finish play with the lib and sketch maybe will play with the processing code.

    Right now I am playing with the different functions in the lib. There isn't much to go on with the settings so I am doing a trial and error approach for now to see what happens to the image. So probably see another push today with changes to the sketch.

    Yes I did remember your comments about the lettering and adding a blank screen

  6. #281
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    13,943
    Just restarted PDE again and the back of the T_4.1 card came over perfectly.

    I have noticed if I stop and start the PDE 'too quickly' it seems I get : 'RuntimeException: Error opening serial port COM23: Port busy'
    So I Run again and all is well

    Just did that again and first image came over perfectly. So not seeing any Teensy issue - just something in the RAW send/Rcv with PDE gathering/presenting the bytes?

  7. #282
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    24,111
    A little breakout board to play with the signals on a Teensy 4.1 arrived last night from OSH Park. I build one this morning.

    Click image for larger version. 

Name:	cameratest.jpg 
Views:	14 
Size:	60.9 KB 
ID:	24398

    I'm running the camera completely on 3.3V. Haven't looked at the data yet, but it seems to be running correctly.

    Here are the clock outputs with the settings from test code of msg #120.

    Click image for larger version. 

Name:	file1.png 
Views:	4 
Size:	39.7 KB 
ID:	24400

    When I change the code to write 0x20 to register 0x3060, it does indeed change to PCLK gated by HSYNC.

    Code:
    	hm01b0_write(0x3060, 0x20); // slowest clock div
    Click image for larger version. 

Name:	file2.png 
Views:	4 
Size:	36.4 KB 
ID:	24401

    Here's a zoom in to the beginning of one of those HSYNC pulses.

    Click image for larger version. 

Name:	file3.png 
Views:	3 
Size:	32.7 KB 
ID:	24402

  8. #283
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    9,027
    @pretty cool, sure does look like it would make things easier to debug!

  9. #284
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    9,027
    Quote Originally Posted by mjs513 View Post
    @KurtE
    Was just playing with the fix and something hit me with readframe. The readFram function was designed to support the color version of the HB01B0 camera so once you fix the error with pixformat you wind up with 2 25% size pictures on the screen. Have to do the following in the code to fake it our:
    Code:
    	  //Change for Monodchrome only HB01b0
    	  _grayscale = false;
          if (!(j & 1) || !_grayscale) {
            *b++ = in;
          }
    Wonder if maybe there should be a different mode? And/Or simply remove the grayscale test?

  10. #285
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    6,973
    @Paul - agree with Kurt - pretty cool to see.

  11. #286
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    6,973
    Quote Originally Posted by KurtE View Post
    Wonder if maybe there should be a different mode? And/Or simply remove the grayscale test?
    Actually what I was thinking was to add a define:
    Code:
    #define SensorMonochrome 1
    to the .h and then wrap the test in a define. Probably will do that on the next update.

  12. #287
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    6,973
    Quote Originally Posted by defragster View Post
    Just restarted PDE again and the back of the T_4.1 card came over perfectly.

    I have noticed if I stop and start the PDE 'too quickly' it seems I get : 'RuntimeException: Error opening serial port COM23: Port busy'
    So I Run again and all is well

    Just did that again and first image came over perfectly. So not seeing any Teensy issue - just something in the RAW send/Rcv with PDE gathering/presenting the bytes?
    Almost sure its on the processing side. Had similar problems before with processing. Thought most of it would be resolved if we used USB1.

  13. #288
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    13,943
    Indeed that @Paul OSH board looks a good way to mount and debug.

    Quote Originally Posted by mjs513 View Post
    Almost sure its on the processing side. Had similar problems before with processing. Thought most of it would be resolved if we used USB1.
    It is intermittently and often perfect - except for some batches.

    Just restarted and sent 3 PERFECT images - first two Teensy said 'not converged'

    In PDE :: after myImage .updatePixels(); this println(i); and it is showing 76,800 on those images, and subsequent. Next broken image I'll see if there was anything odd in that number.

  14. #289
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    9,027
    I have a DMA version that is actually showing the images, Right now try to rebase, hopefully not totally screw up)... Made copy before trying.

    Note it builds again, I had several conflicts, but see several warnings, although I think most are still in the "main" branch

    Things like: in main sketch:
    Code:
    int filesize = 54 + 3*w*h;  //w is your image width, h is image height, both int
    
      // set fileSize (used in bmp header)
      int rowSize = 4 * ((3*w + 3)/4);      // how many bytes in the row (used to create padding)
      int fileSize = 54 + h*rowSize;        // headers (54 bytes) + pixel data
    Where at first I thought there were two duplicate defines. But case different, second one shows as unused variable.

    Signed/unsigned
    Unused...

    Actually now having linking issue due to running out of memory
    Code:
    teensy_size: Memory Usage on Teensy MicroMod:
    teensy_size:   FLASH: code:81864, data:10356, headers:7212   free for files:16415640
       RAM1: code:98304, variables:426816   free for local variables:-832
    teensy_size:    RAM2: variables:182848  free for malloc/new:341440
    Error program exceeds memory space
    I put my DMA buffers into main memory, and I moved my second buffer to DMAMEM, will try moving one or two of our others there as well...
    Last edited by KurtE; 04-09-2021 at 08:49 PM.

  15. #290
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    6,973
    @KurtE
    You are going to kill me just pushed up some minor changes:
    1. fixed pfmt,
    2. #define for monochrome sensor
    and
    3. Some tweaks to the sketch

    Can't wait to see what you did to it

  16. #291
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    6,973
    @defragster
    Just restarted and sent 3 PERFECT images - first two Teensy said 'not converged'
    That comment is from the auto calibration function that I extracted from the Sparkfun library. Just tweaked the sketch a bit more after playing with some of the functions and I am not getting that not converged message much, usually get that if its point in the direction of bright light.

  17. #292
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    13,943
    Number always coming up right - not getting a false trigger - but the buffer can start 'skewed' or go skewed

    Implemented "P" { upper case P } for :: g_continuous_pc_mode
    > quick hack - generally works for some time - then get the 'split screen' image skew
    > once it gets skew - it stays or worsens it seems.
    > The PDE sketch LAGS the ML.TMM image sending!
    Code:
          case 'P':
          {
            g_continuous_pc_mode = !g_continuous_pc_mode;
            break;
          }
    And outside that with other continuous:
    Code:
      if (g_continuous_pc_mode) {
          send_raw();
          Serial.println("Prior Image Sent! Took a new one.");
          calAE();
          memset((uint8_t*)frameBuffer, 0, sizeof(frameBuffer));
          hm01b0.set_mode(HIMAX_MODE_STREAMING_NFRAMES, 1);
          hm01b0.readFrame(frameBuffer);
          uint32_t idx = 0;
          for (int i = 0; i < FRAME_HEIGHT * FRAME_WIDTH; i++) {
            idx = i * 2;
            imageBuffer[i] = color565(frameBuffer[i], frameBuffer[i], frameBuffer[i]);
            sendImageBuf[idx + 1] = (imageBuffer[i] >> 0) & 0xFF;
            sendImageBuf[idx] = (imageBuffer[i] >> 8) & 0xFF;
          }
        }

  18. #293
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    6,973
    @defragster
    You could try changing the baud rate in the processing sketch to something much larger than 9600

  19. #294
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    13,943
    Quote Originally Posted by mjs513 View Post
    @defragster
    You could try changing the baud rate in the processing sketch to something much larger than 9600
    Okay, I assumed that was like Teensy and would use the net USB speed ...

    Changed to : myPort = new Serial(this, "COM23", 960000); // Windows

    Seems to be the same? Also with 9600000

  20. #295
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    6,973
    That was the only thing I could think off the top of my head. Will have to test it out again soon. Think for the most part I done with changes now time to have fun with Kurt’s smart stuff and the processing sketch

  21. #296
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    9,027
    OK I pushed up a PR to you. Still not 100% but at least it is showing signs of seeing full DMA image.

    We may still want to combine buffers. Like you have that new double one. I have double as well, although one of them is the previous one...

    Let me know what you think and/or if you think I totally screwed it up

  22. #297
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    24,111
    I finally got the display wired up and have it running here too, showing a super exciting view of my oscilloscope from the workbench.

    Click image for larger version. 

Name:	camera.jpg 
Views:	20 
Size:	111.2 KB 
ID:	24406

    Send another pull request, just minor stuff & compiler warnings.

  23. #298
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    24,111
    Running the DMA version now. Wow, frame rate is so smooth. Seeing some tearing & artifacts.

  24. #299
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    6,973
    Quote Originally Posted by PaulStoffregen View Post
    I finally got the display wired up and have it running here too, showing a super exciting view of my oscilloscope from the workbench.

    Click image for larger version. 

Name:	camera.jpg 
Views:	20 
Size:	111.2 KB 
ID:	24406

    Send another pull request, just minor stuff & compiler warnings.
    Very cool Paul that you got it wired up and its working I did incorporate the PR and Thanks for fixing that packed warning message - wasn't sure how to fix that one


    Quote Originally Posted by KurtE
    OK I pushed up a PR to you. Still not 100% but at least it is showing signs of seeing full DMA image.

    We may still want to combine buffers. Like you have that new double one. I have double as well, although one of them is the previous one...

    Let me know what you think and/or if you think I totally screwed it up
    Incorporated your PR with the DMA stuff as well. One thing I noticed was a lot of tearing using the default reg settings. However, pretty much disappears if you uncomment to the define to use the Sparkfun configurations settings. Everything else seems to be working with all the DMA changes.

  25. #300
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    13,943
    Got the DMA code and the screen goes crazy - seems my 4" Ribbon wires are too long for that speed and signal?

    Single and Continuous work well.

    It changes behavior when I touch and move the wire bundle - but doesn't get stable/good.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •