MicroMod Beta Testing

Yes, changed to 9341_t3n - not sure what that does differently.

The ON SCREEN 9341 is PERFECT - that screen shot is what Processing presented.

It seems to not use current buffer but Snap another Image - maybe it is getting it not drawn sync'd or ready for use?

That was the reason for using SerialUSB1. I make sure the sketch is running and the image window appears and then send the data from Arduino sketch with p command in main serial window. Did it a whole bunch of times with an issue. Not sure what the problem could be. May have to change writeRectangle to writeRectangle(CENTER, CENTER). But looks like the resolution that is getting sent is not 320x240 - should be filling the rectange.
 
Yes, changed to 9341_t3n - not sure what that does differently.

The ON SCREEN 9341 is PERFECT - that screen shot is what Processing presented.

It seems to not use current buffer but Snap another Image - maybe it is getting it not drawn sync'd or ready for use?

That was the reason for using SerialUSB1. I make sure the sketch is running and the image window appears and then send the data from Arduino sketch with p command in main serial window. Did it a whole bunch of times with an issue. Not sure what the problem could be. May have to change writeRectangle to writeRectangle(CENTER, CENTER). But looks like the resolution that is getting sent is not 320x240 - should be filling the rectange. Your are getting maybe a half a rectange.

Oh shoot - just remembered as I was writing the last line. In the processing sketch change you have to change the camera_width and camera_height to 320 and 240:
Code:
// must match resolution used in the sketch
final int cameraWidth = 320;
final int cameraHeight = 240;
Forgot to copy my version of the sketch to the folder.
 
That was the reason for using SerialUSB1. I make sure the sketch is running and the image window appears and then send the data from Arduino sketch with p command in main serial window. Did it a whole bunch of times with an issue. Not sure what the problem could be. May have to change writeRectangle to writeRectangle(CENTER, CENTER). But looks like the resolution that is getting sent is not 320x240 - should be filling the rectange. Your are getting maybe a half a rectange.

Oh shoot - just remembered as I was writing the last line. In the processing sketch change you have to change the camera_width and camera_height to 320 and 240:
Code:
// must match resolution used in the sketch
final int cameraWidth = 320;
final int cameraHeight = 240;
Forgot to copy my version of the sketch to the folder.

That fixed the Left to right drawing split.

But still bottom half black and it draws the top half twice?
 
Afternoon/evening all - Been playing some, @mjs513 I pushed up a DMA branch on a fork...

Not working yet, but it does get some stuff to screen. I know one issue is my current DMA code was setup for the other camera which I have configured for PCLK blanked when not in horizontal...
Not sure if this camera has that option or not. The code is setup to capture the state of HREF with each thing in DMA, so can try that as well.

But like the PCLK_PIN the HSYNC_PIN looks like it is also a XBAR pin, so now wondering if I can some XBAR stuff to do combing of signals before going to trigger the DMA? More reading
 
Switched back to 9341_t3 and still not getting continuous.

Here are example processing displayed images I see:
ProCam02.pngProCam03.png

<edit> Next processing images has L<>R split again?
Will go grab github version ...
 
Switched back to 9341_t3 and still not getting continuous.

Here are example processing displayed images I see:

Ok - video don't work very well with the Processing sketch which you are using. Only can send snapshot to the processing code. Also looks like you never change the image size in the processing sketch.

Code:
  Serial.println("Send the 'p' character to [COLOR="#FF0000"]snapshot [/COLOR]to PC on USB1");

continuous mode goes to the display screen.
 
Correct - 'p' sends a single image.

But 's' continuous to display is not doing that.

I did change the 320x240 layout - but somehow only grabbing and filling top half of frame - full width is accurate ( and usually aligned ) - but was seeing two top half frames and black empty bottom.

Just got from github ... will start over ...
 
Latest Github has fixes that work - using ILI9341_t3 ... NOT "N"
> again not sure what changes ... - but going to this also working :: #include "ILI9341_t3n.h"

's' - continuous works!

Also for processing:: the "final int cameraBytesPerPixel = 2;" was ONE before.
 
Latest Github has fixes that work - using ILI9341_t3 ... NOT "N"
> again not sure what changes ... - but going to this also working :: #include "ILI9341_t3n.h"

's' - continuous works!

Also for processing:: the "final int cameraBytesPerPixel = 2;" was ONE before.

I can confirm its not working with the t3n library. On the t3n it sends several frames to the display and then after that screen updates but its all white. On the t3 version it seems to work with an issue.
 
Something odd - as switching to the _t3n generally working here -

>> Always on the display : Single or Continuous { who picked those swapped input letters :) }

>> Iffy on Processing starting up - restarting it can sync and work
> it seems that sometimes the PDE may get half/part of a buffer and then the next SEND confuses it with another half?

---> had to restart the PDE after sitting it was ignoring and doing nothing?
> First few sends busted/ugly
> Then it got usable display but bottom edge held something not horiz sync'd with the upper half
> Then changed the hand sign from open hand to 2 fingers - and repeat SEND and it showed the whole hand
--> Next P send then displayed the 'two finger' image.

Then STOP'd PDE and RUN again:
> 'p' images sent fingers 1, then 2,3,4 all came over perfectly on PC display.

So it seems the Teensy and PC SYNC on image buffer across USB not always lossless in some fashion leaving PDE confused/waiting?
 
@defragster
Something weird. I just responded to this but maybe forgot to hit post. I just retested with stock ili9431 library and am sending frames to the Processing sketch without an issue. Not seeing the same thing that you are experiencing.
 
It has something in the USB COMM SYNC it seems - as noted I restarted and got garbled images - restarted again and counted four finger images perfect from the first.

Just did a STOP and RUN restart of the PDE and got 20 of 20 prefect images and using the:: ILI9341_t3n tft

And continuous runs fine as well.
 
Often times if the display works sometimes and not others and/or different libraries, I would be tempted to see what SPI speed they are outputting at. And then maybe lower the speed a bit and see if that helps.

Right now on DMA I am going to go through the first path and check state of HSYNC... Don't see any way to route XBar InOut pins through XBARB, only XBARA and To use AOC you have to route signals through XBARB or XBARC to AOC to combine (ADD, OR, INVERT) to then feed into XBARA... Maybe I am missing something...
 
2.8" PJRC w/ILI9341_t3n Display not showing any issues with latest github release Single or Continuous

>>- Just the PDE over USB data sync to display image data it seems can get part buffer it holds until the next image arrives.

This time after sitting ~35 minutes PDE was ready and able to pick up more images without issue. Often it seems to want to be restarted after time away ...

The sketch should have a Blank to black button to prevent screen burn in ... maybe on a time from last image and even pause continuous if left alone ...
 
one issue is my current DMA code was setup for the other camera which I have configured for PCLK blanked when not in horizontal...
Not sure if this camera has that option or not.

I believe the Himax HM01B0 camera does support HSYNC gated PCLK. Try setting bit 5 (mask 0x20) in the OSC_CLK_DIV register (address 0x3060).

Maybe change this line in HM01B0.cpp

Code:
    {OSC_CLK_DIV,          0x0B},

to this

Code:
    {OSC_CLK_DIV,          0x2B},


But like the PCLK_PIN the HSYNC_PIN looks like it is also a XBAR pin, so now wondering if I can some XBAR stuff to do combing of signals before going to trigger the DMA? More reading

I'm sad to say I don't see a way to do this with XBAR & AOI. Looks like AOI can only access signals connected to the inputs of XBAR2 & XBAR3, but the I/O pins only route to XBAR1.

Also don't see a way with FlexIO, at least with the pins as they are connected on the ML carrier board. The logic mode (page 2889 in the ref manual) needs 5 consecutive FlexIO pins, and the output is only to an external pin
 
I believe the Himax HM01B0 camera does support HSYNC gated PCLK. Try setting bit 5 (mask 0x20) in the OSC_CLK_DIV register (address 0x3060).

Maybe change this line in HM01B0.cpp

Code:
    {OSC_CLK_DIV,          0x0B},

to this

Code:
    {OSC_CLK_DIV,          0x2B},
Thanks,

I have been playing with this, and it does shrink down the number of stuff going into dma. I still am getting a few at start and the like that do not have the HSYNC bit set. Sort of had this with OV7670 and had code to figure out which ones to skip and the like.

Note: I have not updated the table like you mentioned, instead I changed the set_framerate code and added it there as this one updated that register later.

My current non-working DMA version code is up in my DMA branch of @mjs513 library. It is showing some stuff now on the display, just not correct. Also code to detect if we are in GrayScale was not working so hard coded, will check to see, maybe I am overwriting something.

I also

I'm sad to say I don't see a way to do this with XBAR & AOI. Looks like AOI can only access signals connected to the inputs of XBAR2 & XBAR3, but the I/O pins only route to XBAR1.

Also don't see a way with FlexIO, at least with the pins as they are connected on the ML carrier board. The logic mode (page 2889 in the ref manual) needs 5 consecutive FlexIO pins, and the output is only to an external pin
I also did not find any direct way to get the XBAR pins through the AOI... I am not sure if there is not some convoluted way, like something like:
Use XBARA for both pins to direct to something like a timer or counter or FlexPWM... Then somehow configure that one such that it triggers something that can be input to XBARB2 or B3.... Then have thos trigger to AOC which finally gets you back to XBAR1... Just feels too convoluted to try.

Have not looked at trying the FlexIO yet. May take a look on the off chance maybe it can work.
 
Good morning all
Been at it again this morning with the camera library. Made some minor updates to the sketch and pushed them up to the repository.
1. New menu selections:
Code:
  Serial.println("Send the 's' character to read a frame ...");
  Serial.println("Send the 'c' character to start/stop continuous display mode");
  Serial.println("Send the 'p' character to snapshot to PC on USB1");
  Serial.println("Send the 'b' character to save snapshot (BMP) to SD Card");
  Serial.println("Send the '0' character to blank the display");
  Serial.println();

2. Can now save a Grayscale BMP to the SD card on CS = 10 (just a reminder).

Re-tested with the all the updates and it seems to now working with the ILI9341_t3n library as well - wonder if I had a loose wire. Sometimes I hate jumpers :) So in summary:
ST7789 (320x240) - single, continuous, and PDE seems to working without issue for me.
ILI9341 - - single, continuous, and PDE seems to working without issue for me.
ILI9341 - - single, continuous, and PDE seems to working without issue for me.

@defragster - still not sure why you are having problems with the PDE, I am not seeing what you are seeing.

@KurtE - sounds like you are making some progress.
 
Morning again
Running into a little problem. I the past (Buddabrot) I have used this code snippet to increment the file name if the file already existed on the SD card using the SD library:
Code:
 // if name exists, create new filename, SD.exists(filename)
    for (int i=0; i<10000; i++) {
      name[4] = (i/1000)%10 + '0';    // thousands place
      name[5] = (i/100)%10 + '0';     // hundreds
      name[6] = (i/10)%10 + '0';      // tens
      name[7] = i%10 + '0';           // ones
      file = SD.open(name, O_CREAT | O_EXCL | O_WRITE);
      if (file) {
        break;
      }
    }
trying to reuse it here but doesn't seem to be incrementing the file name. The initial file name is defined as:
Code:
char name[] = "9px_0000.bmp";       // filename convention (will auto-increment)
Any ideas?

UPDATE: Never mind - forgot we have to use FILE_WRITE now. New function:
Code:
    for (int i=0; i<10000; i++) {
      name[4] = (i/1000)%10 + '0';    // thousands place
      name[5] = (i/100)%10 + '0';     // hundreds
      name[6] = (i/10)%10 + '0';      // tens
      name[7] = i%10 + '0';           // ones
      if(!SD.exists(name)){
        Serial.println(name);
        file = SD.open(name, FILE_WRITE);
        break;
      }
    }
 
Last edited:
@mjs513 - Does SD.open take all of those flags? these days?

About 5minutes after I post the question I remembered that those flags are no longer in use with the SD library. Sometimes hard to remember all the changes :) See the update to the post. Thanks for reminding me. I pushed the fix up to the repository.
 
@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 said:
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...
Darn it. Fixed it for framesize but forgot to change it for pixformat. Going to fix it now.
 
Back
Top