Forum Rule: Always post complete source code & details to reproduce any issue!
Page 11 of 36 FirstFirst ... 9 10 11 12 13 21 ... LastLast
Results 251 to 275 of 889

Thread: MicroMod Beta Testing

  1. #251
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    7,060
    Quote Originally Posted by defragster View Post
    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.

  2. #252
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    7,060
    Quote Originally Posted by defragster View Post
    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.

  3. #253
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    14,158
    Also seeing Continuous mode only snapping one pic? Using 9341_t3n

  4. #254
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    7,060
    Quote Originally Posted by defragster View Post
    Also seeing Continuous mode only snapping one pic? Using 9341_t3n
    Ok that sounds like something with the ILI9341. Not having any of those problems with the ST7789

  5. #255
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    14,158
    Quote Originally Posted by mjs513 View Post
    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?

  6. #256
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    14,158
    Quote Originally Posted by mjs513 View Post
    Ok that sounds like something with the ILI9341. Not having any of those problems with the ST7789
    Thought maybe it would point to a known change? IT was working when using the 9341 NOT_t3n

  7. #257
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    9,129
    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

  8. #258
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    14,158
    Switched back to 9341_t3 and still not getting continuous.

    Here are example processing displayed images I see:
    Click image for larger version. 

Name:	ProCam02.png 
Views:	8 
Size:	24.3 KB 
ID:	24390Click image for larger version. 

Name:	ProCam03.png 
Views:	12 
Size:	31.1 KB 
ID:	24391

    <edit> Next processing images has L<>R split again?
    Will go grab github version ...

  9. #259
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    7,060
    Quote Originally Posted by defragster View Post
    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 snapshot to PC on USB1");
    continuous mode goes to the display screen.

  10. #260
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    14,158
    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 ...

  11. #261
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    14,158
    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.

  12. #262
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    7,060
    Quote Originally Posted by defragster View Post
    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.

  13. #263
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    14,158
    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?

  14. #264
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    7,060
    @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.

  15. #265
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    14,158
    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.

  16. #266
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    9,129
    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...

  17. #267
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    14,158
    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 ...

  18. #268
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    24,261
    Quote Originally Posted by KurtE View Post
    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

  19. #269
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    9,129
    Quote Originally Posted by PaulStoffregen View Post
    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

    Quote Originally Posted by PaulStoffregen View Post
    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.

  20. #270
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    7,060
    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.

  21. #271
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    7,060
    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 by mjs513; 04-09-2021 at 03:26 PM.

  22. #272
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    9,129
    @mjs513 - Does SD.open take all of those flags? these days?

  23. #273
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    7,060
    Quote Originally Posted by KurtE View Post
    @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.

  24. #274
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    9,129
    @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...

  25. #275
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    7,060
    Quote Originally Posted by KurtE
    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.

Posting Permissions

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