MicroMod Beta Testing

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) {
[B]  delay(3);
[/B]// 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...
	[B]not converged[/B]
Versus:
Code:
Image Sent!
Calibrating Auto Exposure...
	converged!
 
@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-Camera/blob/main/TMM-HM01B0/src/HM01B0.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
[B][COLOR="#FF0000"]	  _grayscale = false;
[/COLOR][/B]      if (!(j & 1) || !_grayscale) {
        *b++ = in;
      }
 
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 ...
 
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:
ProCam04.png
> some of the images before this were worse with garbage
<edit>
> All sends are marked 'converged!'

Oh - and nice '0' add to Blank display.
 
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 :)
 
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?
 
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.

cameratest.jpg

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.

file1.png

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

file2.png

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

file3.png
 
@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
[B][COLOR="#FF0000"]	  _grayscale = false;
[/COLOR][/B]      if (!(j & 1) || !_grayscale) {
        *b++ = in;
      }

Wonder if maybe there should be a different mode? And/Or simply remove the grayscale test?
 
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.
 
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.
 
Indeed that @Paul OSH board looks a good way to mount and debug.

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.
 
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:
@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 :)
 
@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.
 
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;
      }
    }
 
@defragster
You could try changing the baud rate in the processing sketch to something much larger than 9600
 
@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
 
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
 
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 ;)
 
I finally got the display wired up and have it running here too, showing a super exciting view of my oscilloscope from the workbench.

camera.jpg

Send another pull request, just minor stuff & compiler warnings.
 
I finally got the display wired up and have it running here too, showing a super exciting view of my oscilloscope from the workbench.

View attachment 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 :)


KurtE said:
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.
 
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.
 
Back
Top