Forum Rule: Always post complete source code & details to reproduce any issue!
Page 31 of 36 FirstFirst ... 21 29 30 31 32 33 ... LastLast
Results 751 to 775 of 889

Thread: MicroMod Beta Testing

  1. #751
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    9,129
    Quote Originally Posted by mjs513 View Post
    Hi all
    For the micromod board in twowire i just changed Wire1 and Wire2 like this:

    figure it would be easiest. Tried it with example2 sketch and seems to work - if anyone else want to test go for it. Going to go test on a T4 just to satisfy myself before doing a PR>

    EDIT: ok tested on the i2c board and it works. Yea
    It is sort of an interesting issue... Like I mentioned elsewhere.

    Is Currently Wire1 on all T4.x boards is on Teensy IO pins(16 and 17) and also have some alternates on other pins.
    and likewise Wire2 is on Teensy IO pins (24, 25) on all T4.x...

    But the MMod as labeled 24 and 25 as SDA1 and SCL1...

    Again I don't think there is a right answer here. And how far do you take it?

    That is for example then:
    pins 16 and 17 are listed as: TX1/A3 and RX1/A2
    However 16 and 17 are currently matches other T4.x boards and is Serial4
    Also on their Boards D0 and D1 are Teensy pin 4 and 5

    Again I am not sure what the right answer is here!

  2. #752
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    7,060
    Not 100% sure either that is why I did the way I did.
    Code:
    #if defined(ARDUINO_TEENSY_MICROMOD)
    	TwoWire Wire2(&IMXRT_LPI2C3, TwoWire::i2c3_hardware);
    	TwoWire Wire1(&IMXRT_LPI2C4, TwoWire::i2c4_hardware);
    #else
    	TwoWire Wire1(&IMXRT_LPI2C3, TwoWire::i2c3_hardware);
    	TwoWire Wire2(&IMXRT_LPI2C4, TwoWire::i2c4_hardware);
    #endif
    Isn't this just swapping Wire assignments vs pin assignments? So all pins remains the same except when you say wire1 you refering to pins24/25 on the micromod. That wouldn't affect TX1/A3 and RX1/A2 would it assuming you aren't trying to use both at the same time? That's why I didn't fiddle with pin assignments for Wire1 and Wire2. Again like you said not sure how far you want to take it. Going to put the PR in at least it will be a reminder for Paul to look at?

    I did test with the T4.1 on the I2C Master Controller and it worked and Scanner_all did identify correctly where each device was so at least the change should affect the T4's.

    EDIT: just issued the PR, https://github.com/PaulStoffregen/Wire/pull/31, and referred to your post as well.

  3. #753
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    14,158
    Quote Originally Posted by mjs513 View Post
    Comment out this line:
    Code:
    isrPrime_it.priority(122);
    Put it in init to set as a default. Right now with that line commented out V and F are both working fine at Framerate(30)
    ?? - just did the PR with that line commented as that as how it was run for last p#747.
    >> And 'V' went bad with 't' at PRI(144) - and never recovered ...

    Just started an Ex_2 with _isr PRI(122) and it is working okay - but the SSD1306 drawing JITTERING oddly like not seen before.
    't' showing LP#19 to 21 so assume that is the video update rate

    Over 7 minutes in and Video working and SSD running but drawing is jittery.
    Code:
    LP#=20	Pisr#=58291  lastPR=107491763  ms=437136  ipCyc%=58.88  S5#=1323  52C
    UPDATE <EDIT> :: It went wrong at this point and SSD1306 is wholly dead running 'V' with 't':
    >> As noted this is the same as p#747 where the Prime busy _isr was at PRI(144) - this is at PRI(122)

    Code:
    LP#=21	Pisr#=59273  lastPR=107493721  ms=684611  ipCyc%=59.41  S5#=1386  53C
    LP#=21	Pisr#=58296  lastPR=107491763  ms=685653  ipCyc%=46.74  S5#=1386  52C
    LP#=7	Pisr#=59275  lastPR=107493731  ms=687987  ipCyc%=63.44  S5#=504  52C
    LP#=1	Pisr#=58301  lastPR=107491763  ms=692233  ipCyc%=54.81  S5#=126  52C
    LP#=1	Pisr#=59275  lastPR=107493731  ms=696441  ipCyc%=55.34  S5#=126  52C
    LP#=1	Pisr#=59275  lastPR=107493731  ms=700687  ipCyc%=51.30  S5#=126  52C
    ...
    
    LP#=1	Pisr#=59275  lastPR=107493731  ms=1971865  ipCyc%=55.34  S5#=126  53C
    LP#=1	Pisr#=59275  lastPR=107493731  ms=1976072  ipCyc%=51.29  S5#=126  53C
    LP#=1	Pisr#=58301  lastPR=107491763  ms=1980319  ipCyc%=42.66  S5#=126  52C
    Video still running and the 't' update lines coming out - but you can see (ms values not 1,000 apart) they stopped being 1 second apart with loop running so slow
    Last edited by defragster; 04-29-2021 at 12:49 AM.

  4. #754
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    14,158
    TOO WIERD .... IT IS BACK ....
    Left it running as above ... then the computer is getting and losing something on USB ???
    Yep - the T.MM on PJRC.BB has started start and reboot????

    Code:
    LP#=1	Pisr#=59275  lastPR=107493731  ms=4079273  ipCyc%=51.30  S5#=126  52C
    LP#=1	Pisr#=59276  lastPR=107493731  ms=4085585  ipCyc%=43.20  S5#=126  52C
    LP#=1	Pisr#=58303  lastPR=107491763  ms=4089831  ipCyc%=54.81  S5#=126  52C
    LP#=1	Pisr#=59275  lastPR=107493731  ms=4094039  ipCyc%=59.39  S5#=126  52C
    LP#=1	Pisr#=58301  lastPR=107491763  ms=4098247  ipCyc%=54.81  S5#=126  52C
    LP#=1	Pisr#=59275  lastPR=107493731  ms=4102493  ipCyc%=55.34  S5#=126  52C
    LP#=1	Pisr#=59275  lastPR=107493731  ms=4106701  ipCyc%=47.25  S5#=126  52C
    LP#=1	Pisr#=58299  lastPR=107491763  ms=4110947  ipCyc%=54.81  S5#=126  52C
    LP#=1	Pisr#=59275  lastPR=107493731  ms=4115155  ipCyc%=51.30  S5#=126  52C
    LP#=1	Pisr#=59275  lastPR=107493731  ms=4121505  ipCyc%=47.25  S5#=126  52C
    LP#=1	Pisr#=58301  lastPR=107491763  ms=4125713  ipCyc%=54.81  S5#=126  52C
    HM01B0 Camera Test
    HM01B0_FLEXIO_CUSTOM_LIKE_8_BIT
    ------------------
    SENSOR DETECTED :-) MODEL HM01B0
    OSC_CLK_DIV: 0x2A
    ImageSize (w,h): 324, 244
    START Fill Cache :: 3221
    END Fill Cache :: 	Last is 82813	 @ 3268
    
    T:\tCode\libraries\HM01B0\examples\HM01B0_example2\HM01B0_example2.ino Apr 28 2021 17:13:39
    Send the 'f' character to read a frame using FlexIO (changes hardware setup!)
    Send the 'F' to start/stop continuous using FlexIO (changes hardware setup!)
    Send the 'V' character DMA to TFT async continueous  ...
    Send the 'p' character to snapshot to PC on USB1
    Send the 'b' character to save snapshot (BMP) to SD Card
    Send the '1' character to blank the display
    Send the 't' character to toggle intervalTimer
    Send the 'z' character to send current screen BMP to SD
    
    HM01B0 Camera Test
    HM01B0_FLEXIO_CUSTOM_LIKE_8_BIT
    ------------------
    SENSOR DETECTED :-) MODEL HM01B0
    OSC_CLK_DIV: 0x2A
    ImageSize (w,h): 324, 244
    START Fill Cache :: 3221
    END Fill Cache :: 	Last is 82813	 @ 3268
    
    T:\tCode\libraries\HM01B0\examples\HM01B0_example2\HM01B0_example2.ino Apr 28 2021 17:13:39
    Send the 'f' character to read a frame using FlexIO (changes hardware setup!)
    Send the 'F' to start/stop continuous using FlexIO (changes hardware setup!)
    Send the 'V' character DMA to TFT async continueous  ...
    Send the 'p' character to snapshot to PC on USB1
    Send the 'b' character to save snapshot (BMP) to SD Card
    Send the '1' character to blank the display
    Send the 't' character to toggle intervalTimer
    Send the 'z' character to send current screen BMP to SD
    
    HM01B0 Camera Test
    HM01B0_FLEXIO_CUSTOM_LIKE_8_BIT
    ------------------
    SENSOR DETECTED :-) MODEL HM01B0
    OSC_CLK_DIV: 0x2A
    ImageSize (w,h): 324, 244
    START Fill Cache :: 3221
    END Fill Cache :: 	Last is 82813	 @ 3268
    
    T:\tCode\libraries\HM01B0\examples\HM01B0_example2\HM01B0_example2.ino Apr 28 2021 17:13:39
    Send the 'f' character to read a frame using FlexIO (changes hardware setup!)
    Send the 'F' to start/stop continuous using FlexIO (changes hardware setup!)
    Send the 'V' character DMA to TFT async continueous  ...
    Send the 'p' character to snapshot to PC on USB1
    Send the 'b' character to save snapshot (BMP) to SD Card
    Send the '1' character to blank the display
    Send the 't' character to toggle intervalTimer
    Send the 'z' character to send current screen BMP to SD
    
    HM01B0 Camera Test
    HM01B0_FLEXIO_CUSTOM_LIKE_8_BIT
    ------------------
    SENSOR DETECTED :-) MODEL HM01B0
    OSC_CLK_DIV: 0x2A
    ImageSize (w,h): 324, 244
    START Fill Cache :: 3221
    END Fill Cache :: 	Last is 82813	 @ 3268
    
    T:\tCode\libraries\HM01B0\examples\HM01B0_example2\HM01B0_example2.ino Apr 28 2021 17:13:39
    Send the 'f' character to read a frame using FlexIO (changes hardware setup!)
    Send the 'F' to start/stop continuous using FlexIO (changes hardware setup!)
    Send the 'V' character DMA to TFT async continueous  ...
    Send the 'p' character to snapshot to PC on USB1
    Send the 'b' character to save snapshot (BMP) to SD Card
    Send the '1' character to blank the display
    Send the 't' character to toggle intervalTimer
    Send the 'z' character to send current screen BMP to SD
    
    HM01B0 Camera Test
    HM01B0_FLEXIO_CUSTOM_LIKE_8_BIT
    ------------------
    SENSOR DETECTED :-) MODEL HM01B0
    OSC_CLK_DIV: 0x2A
    ImageSize (w,h): 324, 244
    START Fill Cache :: 3221
    END Fill Cache :: 	Last is 82813	 @ 3268
    
    T:\tCode\libraries\HM01B0\examples\HM01B0_example2\HM01B0_example2.ino Apr 28 2021 17:13:39
    Send the 'f' character to read a frame using FlexIO (changes hardware setup!)
    Send the 'F' to start/stop continuous using FlexIO (changes hardware setup!)
    Send the 'V' character DMA to TFT async continueous  ...
    Send the 'p' character to snapshot to PC on USB1
    Send the 'b' character to save snapshot (BMP) to SD Card
    Send the '1' character to blank the display
    Send the 't' character to toggle intervalTimer
    Send the 'z' character to send current screen BMP to SD
    
    HM01B0 Camera Test
    HM01B0_FLEXIO_CUSTOM_LIKE_8_BIT
    ------------------
    SENSOR DETECTED :-) MODEL HM01B0
    OSC_CLK_DIV: 0x2A
    ImageSize (w,h): 324, 244
    START Fill Cache :: 3237
    END Fill Cache :: 	Last is 82813	 @ 3284
    
    T:\tCode\libraries\HM01B0\examples\HM01B0_example2\HM01B0_example2.ino Apr 28 2021 17:13:39
    Send the 'f' character to read a frame using FlexIO (changes hardware setup!)
    Send the 'F' to start/stop continuous using FlexIO (changes hardware setup!)
    Send the 'V' character DMA to TFT async continueous  ...
    Send the 'p' character to snapshot to PC on USB1
    Send the 'b' character to save snapshot (BMP) to SD Card
    Send the '1' character to blank the display
    Send the 't' character to toggle intervalTimer
    Send the 'z' character to send current screen BMP to SD
    So that is where I stopped it ...

    repowered and held the Button and then reset and this time is came up running SSD1306 boxes after TFT power up and help menu print ... ran that for a short time time and then stopped.

    As I typed the last line it restarted twice - and on second time SSD ran a bit and stopped ????

    Let me put the DMM on 3.3V again ... as it just restarted again ...

  5. #755
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    14,158
    Two DMM's on diff 3.3V & GND and neither jiggled at all ... self restarts and failed SSD boxes continued.
    Could not get a stable Button to do 15s Restore ...

    Moved the T.MM to SFun ML carrier - no reprogramming.
    Powered it up, the display and camera will be wrong - but it starts and running WIRE SSD1306 fine and stable

    In that unchanged state it is running over 50 minutes later with SSD1306 boxes and responsive SerMon where 't' shows micros() runtime.
    Code:
    LP#=36	Pisr#=99828  lastPR=107574791  ms=3012025  ipCyc%=52.05  S5#=0  55C
    So the T.MM module is fine - but wondering about the power coming from the PJRC.MM - dropping and giving a bad start?

    If the Ex_2 is run and an SSD1306 connected to work - nothing should stop it while loop() is running ... ???

    > This .BB anomoly shows that
    > Also the 'V' video code as it stands

    Update:
    Reprogrammed T.MM on ML for 4 bit Camera: "F" worked - then started "V" ... The SSD is showing disturbed drawing - but "V" clear/good at what seems to be ~24 fps if each loop::
    Code:
    LP#=18	Pisr#=99785  lastPR=107574721  ms=82520  ipCyc%=52.12  S5#=0  55C
    redraw rate = 5.08 Hz	 secs = 83		deg  C=55
    LP#=19	Pisr#=99778  lastPR=107574721  ms=83521  ipCyc%=52.10  S5#=0  55C
    ...
    LP#=19	Pisr#=99779  lastPR=107574721  ms=90599  ipCyc%=52.11  S5#=0  54C
    LP#=18	Pisr#=99793  lastPR=107574767  ms=91571  ipCyc%=52.12  S5#=0  54C
    * continuous mode stopped
    LP#=27	Pisr#=99805  lastPR=107574791  ms=92524  ipCyc%=52.08  S5#=0  55C
    LP#=36	Pisr#=99828  lastPR=107574791  ms=93522  ipCyc%=52.05  S5#=0  55C
    LP#=35	Pisr#=99829  lastPR=107574791  ms=94519  ipCyc%=52.05  S5#=0  54C
    LP#=36	Pisr#=99828  lastPR=107574791  ms=95516  ipCyc%=52.05  S5#=0  55C
    * continuous mode (Video) started
    LP#=29	Pisr#=83649  lastPR=107542447  ms=96518  ipCyc%=47.67  S5#=0  55C
    LP#=24	Pisr#=67401  lastPR=107509979  ms=97503  ipCyc%=55.48  S5#=0  54C
    ...
    LP#=24	Pisr#=67399  lastPR=107509979  ms=294588  ipCyc%=55.48  S5#=0  54C
    LP#=25	Pisr#=71288  lastPR=107517757  ms=295626  ipCyc%=65.58  S5#=0  55C
    LP#=26	Pisr#=71474  lastPR=107518097  ms=296664  ipCyc%=57.58  S5#=0  55C
    Video was running and SSD1306 stopped and the 't' counts show the time of loss when loop # drops to 1:
    Code:
    LP#=24	Pisr#=67401  lastPR=107509979  ms=462516  ipCyc%=51.43  S5#=0  55C
    LP#=24	Pisr#=67402  lastPR=107509979  ms=463527  ipCyc%=51.43  S5#=0  55C
    LP#=25	Pisr#=71290  lastPR=107517757  ms=464564  ipCyc%=45.34  S5#=0  55C
    LP#=26	Pisr#=71475  lastPR=107518097  ms=465600  ipCyc%=49.49  S5#=0  55C
    LP#=3	Pisr#=67400  lastPR=107509979  ms=470330  ipCyc%=51.43  S5#=0  55C
    LP#=1	Pisr#=67405  lastPR=107509991  ms=475023  ipCyc%=55.48  S5#=0  55C
    LP#=1	Pisr#=71475  lastPR=107518097  ms=479715  ipCyc%=53.53  S5#=0  55C
    LP#=1	Pisr#=67404  lastPR=107509979  ms=484408  ipCyc%=55.48  S5#=0  55C
    LP#=1	Pisr#=67404  lastPR=107509979  ms=489100  ipCyc%=51.43  S5#=0  55C
    Again no trouble - 2 hrs running - with the T.MM on the ML :: "_hmConfig == 3" 4 bit
    > 2 hrs of continued "FT" run with Prime _isr at PRI(122) - SSD1306 running smooth
    Code:
    LP#=20	Pisr#=99786  lastPR=107574721  ms=7252234  ipCyc%=52.08  S5#=0  55C
    redraw rate = 5.08 Hz	 secs = 7252		deg  C=54
    LP#=19	Pisr#=99793  lastPR=107574767  ms=7253216  ipCyc%=52.08  S5#=0  55C
    All well another couple of T.mm "F" and 't' of T.MM on the ML - have to restart machine ...
    Code:
    LP#=21	Pisr#=99793  lastPR=107574767  ms=16013345  ipCyc%=52.07  S5#=0  55C
    redraw rate = 5.06 Hz	 secs = 16014		deg  C=55
    LP#=19	Pisr#=99792  lastPR=107574721  ms=16014327  ipCyc%=52.08  S5#=0  55C
    Last edited by defragster; 04-29-2021 at 07:51 AM.

  6. #756
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    9,129
    Quote Originally Posted by mjs513 View Post
    Not 100% sure either that is why I did the way I did.
    Code:
    #if defined(ARDUINO_TEENSY_MICROMOD)
    	TwoWire Wire2(&IMXRT_LPI2C3, TwoWire::i2c3_hardware);
    	TwoWire Wire1(&IMXRT_LPI2C4, TwoWire::i2c4_hardware);
    #else
    	TwoWire Wire1(&IMXRT_LPI2C3, TwoWire::i2c3_hardware);
    	TwoWire Wire2(&IMXRT_LPI2C4, TwoWire::i2c4_hardware);
    #endif
    Isn't this just swapping Wire assignments vs pin assignments? So all pins remains the same except when you say wire1 you refering to pins24/25 on the micromod. That wouldn't affect TX1/A3 and RX1/A2 would it assuming you aren't trying to use both at the same time? That's why I didn't fiddle with pin assignments for Wire1 and Wire2. Again like you said not sure how far you want to take it. Going to put the PR in at least it will be a reminder for Paul to look at?

    I did test with the T4.1 on the I2C Master Controller and it worked and Scanner_all did identify correctly where each device was so at least the change should affect the T4's.

    EDIT: just issued the PR, https://github.com/PaulStoffregen/Wire/pull/31, and referred to your post as well.
    Sorry I probably was not clear.

    What I am wondering, is if we are renaming Wire2 to be Wire1 on TMOD to sort of match the MMOD name for the pins SCL1/SDA1

    And currently on the MMOD board like the one Paul has it show:
    16 RX1/A2 and 17 as TX1/A3 - Well with all of the T4.x boards 16 and 17 are A2 and A3, But they are Serial4 so Should we also update the core to swap SerialX's?
    Probably add comment to PR as well.

  7. #757
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    7,060
    Quote Originally Posted by KurtE View Post
    Sorry I probably was not clear.

    What I am wondering, is if we are renaming Wire2 to be Wire1 on TMOD to sort of match the MMOD name for the pins SCL1/SDA1

    And currently on the MMOD board like the one Paul has it show:
    16 RX1/A2 and 17 as TX1/A3 - Well with all of the T4.x boards 16 and 17 are A2 and A3, But they are Serial4 so Should we also update the core to swap SerialX's?
    Probably add comment to PR as well.
    Morning all - late start today.
    Ah - now I understand what you are asking. That is what I am assuming. Don't think A2 and A3 have to be renamed since there is no A2/A3 on the ATP board for instance. As for Serial????

    EDIT: Was just looking at the edge connectors on the PJRC BB:
    24/25 shows as SCL1/SDA1
    16/17 shows as RX1(A2)/TX1(A3)
    0/1 shows as RX0/TX0

    So I would assume (which usually gets me in trouble) that Serial pin names would probably have to change as well but A2/A3 wouldn't have to. Never really looked at Serial closely enough to know if it would be that easy?

    Guess you could do it from pins_arduino.h. This would have to get rearranged:
    Code:
    #define SERIAL_PORT_USBVIRTUAL		Serial
    #define SERIAL_PORT_HARDWARE		Serial1
    #define SERIAL_PORT_HARDWARE1		Serial2
    #define SERIAL_PORT_HARDWARE2		Serial3
    #define SERIAL_PORT_HARDWARE_OPEN	Serial1
    #define SERIAL_PORT_HARDWARE_OPEN1	Serial2
    #define SERIAL_PORT_HARDWARE_OPEN2	Serial3
    #define SERIAL_PORT_HARDWARE3		Serial4
    #define SERIAL_PORT_HARDWARE4		Serial5
    #define SERIAL_PORT_HARDWARE5		Serial6
    #define SERIAL_PORT_HARDWARE6		Serial7
    #define SERIAL_PORT_HARDWARE_OPEN3	Serial4
    #define SERIAL_PORT_HARDWARE_OPEN4	Serial5
    #define SERIAL_PORT_HARDWARE_OPEN5	Serial6
    #define SERIAL_PORT_HARDWARE_OPEN6	Serial7
    Last edited by mjs513; 04-29-2021 at 12:39 PM. Reason: update

  8. #758
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    7,060
    Quote Originally Posted by defragster View Post
    ?? - just did the PR with that line commented as that as how it was run for last p#747.
    >> And 'V' went bad with 't' at PRI(144) - and never recovered ...

    Just started an Ex_2 with _isr PRI(122) and it is working okay - but the SSD1306 drawing JITTERING oddly like not seen before.
    't' showing LP#19 to 21 so assume that is the video update rate

    Over 7 minutes in and Video working and SSD running but drawing is jittery.
    Code:
    LP#=20	Pisr#=58291  lastPR=107491763  ms=437136  ipCyc%=58.88  S5#=1323  52C
    UPDATE <EDIT> :: It went wrong at this point and SSD1306 is wholly dead running 'V' with 't':
    >> As noted this is the same as p#747 where the Prime busy _isr was at PRI(144) - this is at PRI(122)

    .....

    Video still running and the 't' update lines coming out - but you can see (ms values not 1,000 apart) they stopped being 1 second apart with loop running so slow
    Tim never really looked at I2C with a LA with the a LA so can't be 100% certain of what I am about to say. Wonder if comm with the SSD1306 is somehow getting overwhelmed with traffic to the camera? You can there switching so that the SSD is on a different Wire port.

  9. #759
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    9,129
    Aargh - Playing with Zelda with V and F... And noise and ...

    Sometimes it helps to go back and the basic stuff.

    Things like: Where in the code do we ever turn on using the frame Buffer? We don't in this version...
    Then try to add it, like:
    Code:
            if (!g_continuous_flex_mode) {
              if (hm01b0.readContinuous(&hm01b0_flexio_callback_video, frameBuffer, frameBuffer2)) {
    
                Serial.println("Before Set frame complete CB");
                if (!tft.useFrameBuffer(true)) Serial.println("Failed call to useFrameBuffer");
                tft.setFrameCompleteCB(&frame_complete_cb, true);
                Serial.println("Before UPdateScreen Async");
                tft.updateScreenAsync(true);
                Serial.println("* continuous mode (Video) started");
                g_flexio_capture_count = 0;
    And run it and you see:
    Code:
    Before Set frame complete CB
    Failed call to useFrameBuffer
    ILI9341_t3n::setFrameCompleteCB called
    Before UPdateScreen Async
    * continuous mode (Video) started
    Then look at build:
    Code:
    teensy_size: Memory Usage on Teensy MicroMod:
    teensy_size:   FLASH: code:98812, data:230896, headers:7212   free for files:16178152
    teensy_size:    RAM1: code:98304, variables:271040   free for local variables:154944
    teensy_size:    RAM2: variables:432608  free for malloc/new:91680
    Maybe not enough room for Frame buffer...
    Next attempt, maybe create frame buffer low and set it and see what happens.

  10. #760
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    7,060
    Quote Originally Posted by KurtE
    Maybe not enough room for Frame buffer...
    Next attempt, maybe create frame buffer low and set it and see what happens.
    This is getting fun isn't it But fustrating. Maybe should try another sketch to just play a file

  11. #761
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    7,060
    Ok all just tried to run WavFilePlayer example and all I am hearing is a high pitch continuous sound from the speaker. I did change the setup slightly:
    Code:
    #include <Audio.h>
    #include <SD.h>
    
    AudioPlaySdWav           playWav1;
    // Use one of these 3 output types: Digital I2S, Digital S/PDIF, or Analog DAC
    AudioOutputI2S           audioOutput;
    //AudioOutputSPDIF       audioOutput;
    //AudioOutputAnalog      audioOutput;
    //On Teensy LC, use this for the Teensy Audio Shield:
    //AudioOutputI2Sslave    audioOutput;
    
    AudioConnection          patchCord1(playWav1, 0, audioOutput, 0);
    AudioConnection          patchCord2(playWav1, 1, audioOutput, 1);
    AudioControlSGTL5000     sgtl5000_1;
    
    // Use these with the Teensy 3.5 & 3.6 SD card
    #define SDCARD_CS_PIN    BUILTIN_SDCARD
    
    
    void setup() {
      Serial.begin(9600);
    
      // Audio connections require memory to work.  For more
      // detailed information, see the MemoryAndCpuUsage example
      AudioMemory(8);
    
      // Comment these out if not using the audio adaptor board.
      // This may wait forever if the SDA & SCL pins lack
      // pullup resistors
      sgtl5000_1.enable();
      sgtl5000_1.volume(0.5);
    
      if (!(SD.begin(SDCARD_CS_PIN))) {
        // stop here, but print a message repetitively
        while (1) {
          Serial.println("Unable to access the SD card");
          delay(500);
        }
      }
    }
    If I change AudioOutput to i2s1 still get the high pitch sound. Serial monitor says it is playing the file so ??? not sure what's up.

  12. #762
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    9,129
    I have a version I think that is working a lot better. up in the branch: https://github.com/KurtE/TMM-HB01B0-...deo_mode_partb

    Not sure if I needed the part b, to move it to when the frame completed or not... But appears to be working better!

    We probably need to look at the different buffers used for different commands, like SD versus send RAW...

  13. #763
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    7,060
    Quote Originally Posted by KurtE View Post
    I have a version I think that is working a lot better. up in the branch: https://github.com/KurtE/TMM-HB01B0-...deo_mode_partb

    Not sure if I needed the part b, to move it to when the frame completed or not... But appears to be working better!

    We probably need to look at the different buffers used for different commands, like SD versus send RAW...
    Like do we need the extra buffers or can we reuse?

    UPDATE
    @KurtE - just downloaded and gave it a try - a lot better in terms of no more popping but am seeing a lot more tearing on the bottom half of the screen when I move the camera or wiggle my fingers in front of it But nice job on the sound. Have to go look at what you did.

  14. #764
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    14,158
    Quote Originally Posted by mjs513 View Post
    Tim never really looked at I2C with a LA with the a LA so can't be 100% certain of what I am about to say. Wonder if comm with the SSD1306 is somehow getting overwhelmed with traffic to the camera? You can there switching so that the SSD is on a different Wire port.
    <uninformed questions ahead ???>

    Does Camera use i2c? After startup - i.e. not like PJRC Audio Board just for setup - but more often during camera read?

    Though scanner on the SFun.ML shows this for default "Wire":
    Code:
    I2C Scanner
    Scanning...
    Device found at address 0x19  (LSM303,LIS331DLH)
    Device found at address 0x3C  (SSD1306,DigisparkOLED)
    So Camera isn't on Wire?
    Scanner does not find any SFun.ML i2c devices on Wire1 or Wire2? { using current CORES i2c setup }

    But Starting Ex_2 with "V" and NOT 't' shows the SSD1306 I/O to be jumpy and not smooth. So it is being affected - but not from common i2c bus I/O?
    Note: "F" does not show any SSD1306 draw issues - blocks repeat smooth and clean.

    ref: SSD1306 I/O is called from loop() -> loopPR()

  15. #765
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    9,129
    Quote Originally Posted by mjs513 View Post
    Like do we need the extra buffers or can we reuse?

    UPDATE
    @KurtE - just downloaded and gave it a try - a lot better in terms of no more popping but am seeing a lot more tearing on the bottom half of the screen when I move the camera or wiggle my fingers in front of it But nice job on the sound. Have to go look at what you did.
    I enabled the Frame buffer by freeing up memory. I think that some of the other functions should all share memory and/or they should maybe malloc/new memory and free it after the Raw or bitmap...

    I am seeing some banding, ... as part of the frame as you mentioned, not sure exactly the source right now, I can give a few different possibilities.

    a) Memory was in DMAMMEM and maybe not getting the data back from DMA of the frame if in DMAMEM... Likewise maybe my writes in continuous update modes are not getting through... So I have hacked up version two different ways so far:
    Code:
    #define UPDATE_ON_CAMERA_FRAMES
    
    uint8_t *pfb_last_frame_returned = nullptr;
    
    bool hm01b0_flexio_callback_video(void *pfb)
    {
      pfb_last_frame_returned = (uint8_t*)pfb;
    #ifdef UPDATE_ON_CAMERA_FRAMES
      tft.setOrigin(-2, -2);
      if ((uint32_t)pfb_last_frame_returned >= 0x20200000u)
        arm_dcache_delete(pfb_last_frame_returned, FRAME_WIDTH*FRAME_HEIGHT);
    
      tft.writeRect8BPP(0, 0, FRAME_WIDTH, FRAME_HEIGHT, (uint8_t*)pfb_last_frame_returned, mono_palette);
      pfb_last_frame_returned = nullptr;
      tft.setOrigin(0, 0);
      uint16_t *pframebuf = tft.getFrameBuffer();
      if ((uint32_t)pframebuf >= 0x20200000u) arm_dcache_flush(pframebuf, FRAME_WIDTH*FRAME_HEIGHT);
    #endif  
      //Serial.print("#");
      return true;
    }
    
    void frame_complete_cb() {
      //Serial.print("@");
    #ifndef UPDATE_ON_CAMERA_FRAMES
      if (!pfb_last_frame_returned) return;
      tft.setOrigin(-2, -2);
      if ((uint32_t)pfb_last_frame_returned >= 0x20200000u)
        arm_dcache_delete(pfb_last_frame_returned, FRAME_WIDTH*FRAME_HEIGHT);
    
      tft.writeRect8BPP(0, 0, FRAME_WIDTH, FRAME_HEIGHT, (uint8_t*)pfb_last_frame_returned, mono_palette);
      pfb_last_frame_returned = nullptr;
      tft.setOrigin(0, 0);
      uint16_t *pfb = tft.getFrameBuffer();
      if ((uint32_t)pfb >= 0x20200000u) arm_dcache_flush(pfb, FRAME_WIDTH*FRAME_HEIGHT);
    #endif
    }
    Both ways showing it.

    The way I have it now, on the Camera callback - implies that it will overwrite the whole frame buffer each time camera completes, so could get part of one frame and part of the next or next...

    Or could be with the update in the frame complete, that the camera has already cycled back and is starting to overwrite...

    Or maybe the camera itself does not respond fully correct from one frame to the next, like maybe it is readjusting the internal data or ???

    And I may try Step C) I mentioned where it only updates half the screen at a time, and holds onto buffer while it is doing the writes...

  16. #766
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    7,060
    Quote Originally Posted by defragster View Post
    <uninformed questions ahead ???>

    Does Camera use i2c? After startup - i.e. not like PJRC Audio Board just for setup - but more often during camera read?

    Though scanner on the SFun.ML shows this for default "Wire":
    Code:
    I2C Scanner
    Scanning...
    Device found at address 0x19  (LSM303,LIS331DLH)
    Device found at address 0x3C  (SSD1306,DigisparkOLED)
    So Camera isn't on Wire?
    Scanner does not find any SFun.ML i2c devices on Wire1 or Wire2? { using current CORES i2c setup }

    But Starting Ex_2 with "V" and NOT 't' shows the SSD1306 I/O to be jumpy and not smooth. So it is being affected - but not from common i2c bus I/O?
    Note: "F" does not show any SSD1306 draw issues - blocks repeat smooth and clean.

    ref: SSD1306 I/O is called from loop() -> loopPR()
    Just ran WireScanall that Kurt put together:
    Scanning(Wire)...
    Device found at address 0x24 (MCP23017,MCP23008,PCF8574)
    Device found at address 0x3C (SSD1306,DigisparkOLED)
    0x24 is the camera. Haven't tried it on the ML board.

    Yes camera uses i2c for setup and when you call calAE and setMode. Not sure what it does in between have to check soon

  17. #767
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    14,158
    If the VID mods don't end up with clean i2c to SSD ...

    Will be interesting to put LA on the i2c with SSD1306 and the _isr trigger lines for video.

    Left Ex_2 - no 't' - running "V" that showed tearing - and again it stopped SSD1306 function while video continues

  18. #768
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    7,060
    Quote Originally Posted by defragster View Post
    If the VID mods don't end up with clean i2c to SSD ...

    Will be interesting to put LA on the i2c with SSD1306 and the _isr trigger lines for video.

    Left Ex_2 - no 't' - running "V" that showed tearing - and again it stopped SSD1306 function while video continues
    Funny you should mention that caused I just checked with a LA

    1. After setup I2C is not involved with the Camera unless you do a single snapshot like with 'f' and call calAE.
    2. Running 't' and 'v' at the same time you see the i2c traffic going to the SSD1306. When the SSD1306 fails I2C traffic to the SSD display stops and you see the ISR drop to 1. Video and sketch are still operational.
    3. With that said 'V' and 'F' seem to interact with I2C - SDA and SCL both go high., top line SDA bottom line SCL. Scales are the same.
    a. LA with just 't' - interrupt running
    Click image for larger version. 

Name:	i2c with 1306.PNG 
Views:	7 
Size:	2.1 KB 
ID:	24653

    b. 't' and 'F' running
    Click image for larger version. 

Name:	i2c with F and 1306.PNG 
Views:	9 
Size:	4.1 KB 
ID:	24654

    c. 't' and 'V' which causes the hang.
    Click image for larger version. 

Name:	i2c with V and 1306.jpg 
Views:	8 
Size:	15.6 KB 
ID:	24655

    3. so not sure where the problem is = are you the busy1306 from within the ISR?


    NOTE: have 'V' running not for a while without 't' and both are running with out issue. Note I am running at ISR 122.

  19. #769
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    9,129
    Afternoon all,

    Question with the V command above, is that with or without my changes?

    If without:

    What was happening is we don't have a frame buffer, so when you get the callback from the camera,
    the code will stay in the Callback while it does the complete writeRect8BB to the screen...

    With my current stuff, it will simply copy the data to frame buffer...

  20. #770
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    7,060
    Quote Originally Posted by KurtE View Post
    Afternoon all,

    Question with the V command above, is that with or without my changes?

    If without:

    What was happening is we don't have a frame buffer, so when you get the callback from the camera,
    the code will stay in the Callback while it does the complete writeRect8BB to the screen...

    With my current stuff, it will simply copy the data to frame buffer...
    That's without your changes - was trying to duplicate what I thought was how Tim was testing. Was in the process of going to test on the ML board but just broke my camera connector on it - luckily I have a spare - just have to solder some headers on it to plug the display in

  21. #771
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    7,060
    Quote Originally Posted by KurtE View Post
    Afternoon all,

    Question with the V command above, is that with or without my changes?

    If without:

    What was happening is we don't have a frame buffer, so when you get the callback from the camera,
    the code will stay in the Callback while it does the complete writeRect8BB to the screen...

    With my current stuff, it will simply copy the data to frame buffer...
    Ok just dowloaded it again and set up Tim's sketch with IPR priority at 144 took a quick snap shot and looks a lot better:
    Click image for larger version. 

Name:	Capture.PNG 
Views:	7 
Size:	2.7 KB 
ID:	24656 Getting a good lesson her. Anyway at 144 the 1306 looks nice and smooth and no hangs so far. Going to rest to 122 and let the sketch run and report back

  22. #772
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    7,060
    @KurtE - @defragster

    Running the V-ideo updates in Kurt's library your test sketch with ISR priority of 122 has been running for about 25 minutes with no hangs or slow downs or no jittery 1306. Only issue is the banding when the camera sees movements. Going to let it keep running.

    UPDATE: 48 minutes and still good done for now going to try on the ML board now
    Last edited by mjs513; 04-29-2021 at 09:00 PM.

  23. #773
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    9,129
    Do you think I Should I PR my changes or wait until I try a few more things to see if we can get smoother video when things are moving?

    Looks like I will need to rebase my changes to the current stuff (i.e. it shows conflicts).

  24. #774
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    14,158
    Just back here - didn't get vid update - for any new testing yet today ...

    Kurt - The old stuff is a hazard - so any update would be a step forward for testing.

  25. #775
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    14,158
    Quote Originally Posted by mjs513 View Post
    Funny you should mention that caused I just checked with a LA
    ...

    3. so not sure where the problem is = are you the busy1306 from within the ISR?

    NOTE: have 'V' running not for a while without 't' and both are running with out issue. Note I am running at ISR 122.
    busy1306 only from loop - noted in p#764 : "ref: SSD1306 I/O is called from loop() -> loopPR()"
    > I considered trying it from the _isr() but that seemed to be asking for trouble.

    Thanks for the LA info - good you have that to look at. Nice to know the CAM i2c is just startup and single frame - but it seems to be not on same Wire as SSD1306? Though 'scanner.ino' didn't pick it up?

    The video making it breakup and fail isn't nice to see - hopefully that will resolve ... wanted to put something on and that little display seemed a good 'canary in the coal mine' ...

Posting Permissions

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