MicroMod Beta Testing

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!
 
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.
 
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:
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 ...
 
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
[B]LP#=3	Pisr#=67400  lastPR=107509979  ms=470330  ipCyc%=51.43  S5#=0  55C[/B]
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:
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.
 
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:
?? - 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.
 
Aargh :eek: - 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
[COLOR="#FF0000"]Failed call to useFrameBuffer[/COLOR]
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.
 
KurtE said:
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 :)
 
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.
 
I have a version I think that is working a lot better. up in the branch: https://github.com/KurtE/TMM-HB01B0-Camera/tree/video_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.
 
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()
 
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 :D 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...
 
<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
 
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
 
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
i2c with 1306.PNG

b. 't' and 'F' running
i2c with F and 1306.PNG

c. 't' and 'V' which causes the hang.
i2c with V and 1306.jpg

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.
 
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...
 
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 :)
 
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:
Capture.PNG 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
 
@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:
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).
 
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.
 
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' ...
 
Back
Top