MicroMod Beta Testing

T.MM on SFun_ML 35 minutes and all is well doing : 't' and "F" - the SSD1306 is still running as it should. - don;t have active Serial5 pins exposed on ML - so that is a NOP.

>> 1 hours 20 minutes and multiple uploads and T.MM on the HL carrier is fine and healthy ....

There is something wrong with my PJRC.BB (image in email) - not sure what that is soldered side F_headers - nothing cut?

The change to (60) fps update was just to see the updated callback count when the TFT was 'if (0)'

The uploaded Ex_2 had LAME prime _isr() busy work rates only using 0.05% of cpu cycles.
Code:
redraw rate = 10.55 Hz	 secs = 2421		deg  C=55
LP#=20	Pri#=1001	last Pri=67537	ms=2422342	ipCyc%=0.05	deg  C=54

Code:
const int PrPS=1000 * 220; // pick number 30K to 120K, 220K or more net completed depends on priRestart val and tableSize
#define usPTimer 1000000.0/PrPS // intervalTimer us freq val
#define priRestart 65537 // Larger Primes takes longer :: 65537 // 53680457 // 107361011 // 107375183 // 2147503639 // 2147712181
One part is the PrPS value was 1000 * 1, bumping that back to * 220 gives that many more interrupts:
Code:
redraw rate = 9.71 Hz	 secs = 154		deg  C=55
LP#=18	Pri#=220118	last Pri=505763	ms=155310	ipCyc%=16.28	deg  C=54

That is a bit more load - but 'priRestart' is still a small number. Bumping that to '53680457' results in 57.3 load on the CPU cycles:
Code:
redraw rate = 7.58 Hz	 secs = 80		deg  C=54
LP#=14	Pri#=142801	last Pri=53966057	ms=80746	ipCyc%=57.32	deg  C=55

That dips the number of _isr()'s as finding some primes extends into the next timer _isr()

Playing with those two numbers can vary the load.

Bigger number holds the _isr even longer and now seeing so breaks in the continuous update - seems a single frame gets drawn out of sync ( one or more some seconds ) though it recovers.:
Code:
const int PrPS=1000 * 180; // pick number 30K to 120K, 220K or more net completed depends on priRestart val and tableSize
#define usPTimer 1000000.0/PrPS // intervalTimer us freq val
#define priRestart 107375183 // Larger Primes takes longer :: 65537 // 53680457 // 107361011 // 107375183 // 2147503639 // 2147712181

Fewer _isr's but display rate dropped:
Code:
redraw rate = 6.82 Hz	 secs = 101		deg  C=53
LP#=14	Pri#=110121	last Pri=107595413	ms=101267	ipCyc%=57.52	deg  C=54

Temp of 54C here is higher than before - it wasn't from that - not sure what is up with the breakoutBoard - it was fine for days - but what I was seeing there before is now fixed/HIDDEN with the Pri(102) updates to lib/src/.cpp
 
T.mm running fine 2.5 hours after the last time it was reprogrammed. Multiple time before that with no issues and no restarts or hangs. This is with CORES as durrent at last post.

THOUGH :: seeing this is using prior code with the altered priority .... time to restart ... See below - HANGS in NO TIME !!!!!

"F" image showing stable without the frame flickers noted 2 hrs ago - and SSD boxes drawing along at the 12 loops per second that remain.
Code:
redraw rate = 6.12 Hz	 secs = 9208		deg  C=54
LP#=12	Pri#=110007	last Pri=107595179	ms=9208367	ipCyc%=57.64	deg  C=54

110K _isr task plenty of interrupts/sec and using 57% of CPU cycles in the isr() plus entry and exit.
>> Works properly with prior priority updates Not Commented when Timer running at PRI(128)
Code:
//    NVIC_SET_PRIORITY(IRQ_GPIO6789, 102);
//    NVIC_SET_PRIORITY(dma_flexio.channel & 0xf, 102);

Using the current github - with the interrupts for GPIO and DMA_flexio it runs until Ex_2 turns on the 't' isr calcualting Prime numbers using the above prior settings.
>> with isrPrime_it.priority(128);
Code:
Reading frame
Finished reading frame
* continuous mode started
redraw rate = 1.58 Hz	 secs = 10		deg  C=54
redraw rate = 9.84 Hz	 secs = 20		deg  C=54
redraw rate = 9.90 Hz	 secs = 30		deg  C=54
[B]LP#=782	Pri#=1	last Pri=0	ms=35480	ipCyc%=0.00	deg  C=54  [COLOR="#FF0000"]<< This is the start of 't'  in a partial second : hung 3 secs later.[/COLOR][/B]
LP#=13	Pri#=110121	last Pri=107595413	ms=36486	ipCyc%=57.51	deg  C=54
LP#=17	Pri#=110124	last Pri=107595413	ms=37486	ipCyc%=57.51	deg  C=54
LP#=14	Pri#=110119	last Pri=107595413	ms=38513	ipCyc%=57.51	deg  C=54

>> Died first sec after start:
redraw rate = 9.89 Hz secs = 30 deg C=54
LP#=731 Pri#=1 last Pri=0 ms=32149 ipCyc%=0.00 deg C=54
>> Died 4th sec after start

To give it a chance 100 /sec short _isr's - it ran okay - but busy work is 0.01%
Code:
redraw rate = 10.05 Hz	 secs = 694		deg  C=53
LP#=21	Pri#=101	last Pri=65731	ms=695361	ipCyc%=0.01	deg  C=54

Changed to this and all is well {after Button to reProgram} :: isrPrime_it.priority(144);
>> Start : 'f', "F" - wait some 30 secs, 't' - enable the _isr
Code:
Reading frame
Finished reading frame
* continuous mode started
redraw rate = 0.89 Hz	 secs = 10		deg  C=51
redraw rate = 9.88 Hz	 secs = 20		deg  C=52
redraw rate = 9.83 Hz	 secs = 30		deg  C=53
LP#=820	Pri#=93931	last Pri=187861	ms=36793	ipCyc%=5.28	deg  C=53
LP#=13	Pri#=110019	last Pri=107595209	ms=37812	ipCyc%=57.58	deg  C=53
LP#=13	Pri#=110008	last Pri=107595197	ms=38831	ipCyc%=57.57	deg  C=52
LP#=12	Pri#=110013	last Pri=107595197	ms=39798	ipCyc%=57.57	deg  C=53
redraw rate = 8.28 Hz	 secs = 40		deg  C=53
LP#=12	Pri#=110020	last Pri=107595209	ms=40792	ipCyc%=57.58	deg  C=53
LP#=13	Pri#=110014	last Pri=107595209	ms=41813	ipCyc%=57.58	deg  C=53

Ended to restart at these times with PRI(144):
> redraw rate = 6.02 Hz secs = 212 deg C=54
> redraw rate = 6.06 Hz secs = 285 deg C=53
> redraw rate = 6.12 Hz secs = 496 deg C=54

With current CORES the HardFault Print is no longer here to say if it faulted ... it just hung needing Button to upload in seconds

Back to PRI(128) : 100 and 113 ran okay with shorter and middle busy time each - under 0.1% CPU load okay
Moving to TINY workload at 199,950/sec out of 200K requested it dies in 70 seconds, where 't' was only on for 37 sec at 13.26% of CPU where each _isr is then avg about 420 Cycles:
Code:
const int PrPS=1000 * 200; // pick number 30K to 120K, 220K or more net completed depends on priRestart val and tableSize
#define usPTimer 1000000.0/PrPS // intervalTimer us freq val
#define priRestart 13 // Larger Primes takes longer :: 65537 // 53680457 // 107361011 // 107375183 // 2147503639 // 2147712181
Last printed line before hang:
Code:
LP#=20	Pri#=199958	last Pri=399913	ms=70484	ipCyc%=13.26	deg  C=54

Above works to repro - or for a bit faster ( 16-40 sec after 't' with some display jitter ) use :: View attachment HM01B0_example2.ino
Code:
const int PrPS=[B]1000 * 120[/B]; // pick number 30K to 120K, 220K or more net completed depends on priRestart val and tableSize
#define usPTimer 1000000.0/PrPS // intervalTimer us freq val
#define priRestart [B]107375183[/B] // Larger Primes takes longer :: 65537 // 53680457 // 107361011 // 107375183 // 2147503639 // 2147712181
Last Line out :: LP#=16 Pri#=87952 last Pri=107551079 ms=51578 ipCyc%=45.96 deg C=53
 
Testing on the TMM.BB using the same setup as @defragster but on the 4bit with no changes to the current library version. Only elements changed were in the sketch and as noted in each test.

Test 1
---------
Code:
const int PrPS=1000 * 1; // 220; // pick number 30K to 120K, 220K or more net completed depends on priRestart val and tableSize
#define usPTimer 1000000.0/PrPS // intervalTimer us freq val
#define priRestart 65537 // Larger Primes takes longer :: 65537 // 53680457 // 107361011 // 107375183 // 2147503639 // 2147712181 

  //isrPrime_it.priority(144);
  //isrPrime_it.priority(128);
  //NVIC_SET_PRIORITY(IRQ_GPIO6789, 102);
Runtime - approximately
'F' continuous mode: SSD cycling happily and images displaying nicely - no tearing or split screen
Code:
LP#=15	Pri#=1001	last Pri=67537	ms=1282940	ipCyc%=0.06	deg  C=51
redraw rate = 14.05 Hz	 secs = 1283		deg  C=51
LP#=14	Pri#=1001	last Pri=67537	ms=1283921	ipCyc%=0.06	deg  C=51
LP#=15	Pri#=1001	last Pri=67537	ms=1284928	ipCyc%=0.05	deg  C=51

Stopped 'F' and put it in 'V'ideo mode sketch hung but no faults.
Restarted and put it in 'V' mode after the 't' and video working no issues.
Stopped 'V' and blanked the screen and start "F" continuous no isse with display quality good.
Stopped 'F' mode blanked the screen and start 'V' without an issue and display quality good.
Cycled between 'F' and 'V' without issue this time with no screen blanking.

Code:
LP#=19	Pri#=595	last Pri=66721	ms=489269	ipCyc%=0.03	deg  C=51
LP#=21	Pri#=605	last Pri=66739	ms=490269	ipCyc%=0.03	deg  C=52
LP#=21	Pri#=607	last Pri=66749	ms=491270	ipCyc%=0.03	deg  C=51


Test 2
------------------
Code:
const int PrPS=1000 * 180; // pick number 30K to 120K, 220K or more net completed depends on priRestart val and tableSize
#define usPTimer 1000000.0/PrPS // intervalTimer us freq val
#define priRestart 107375183 // Larger Primes takes longer :: 65537 // 53680457 // 107361011 // 107375183 // 2147503639 // 2147712181

  //isrPrime_it.priority(144);
  //isrPrime_it.priority(128);
  //NVIC_SET_PRIORITY(IRQ_GPIO6789, 102);
Code:
LP#=35	Pri#=110160	last Pri=107595491	ms=10746	ipCyc%=57.52	deg  C=51
LP#=34	Pri#=110157	last Pri=107595491	ms=11727	ipCyc%=57.52	deg  C=51
Mode Hardfaults only after a couple of seconds in 'F' mode, same thing happens in 'V' mode

Test 3
----------
same as test 2 except
Code:
 [COLOR="#FF0000"] isrPrime_it.priority(144); [/COLOR]

Ran 't' and 'F' for >45minutes and all was good with the SSD1306 updating and display was good quality with no tearing or splitting of image.
Code:
LP#=10	Pri#=110050	last Pri=107595281	ms=2888270	ipCyc%=57.53	deg  C=51
redraw rate = 8.00 Hz	 secs = 2888		deg  C=51
LP#=8	Pri#=110057	last Pri=107595287	ms=2889252	ipCyc%=57.53	deg  C=51

As for the 15s restore not seeing any issues on the PJRC Breakout board.
 
Morning all,

Looks like you have been having some fun.

I may play a little more with the 'V' stuff.

@Paul and others - I am no Audio expert. I have not done much of anything with this library...

But wondering about the music sounding bad in the Video mode, which currently each time the camera receives an image it transfers it to the Frame buffer, where each byte is looked up in the array to translate to 16 bit color.... So it is taking some time in this ISR...

Audio - I might be missing something but I only found one IRQ IRQ_SOFTWARE (70) which in the IMXRT manual shows up as grayed out Reserved...
It is used in AudioStream.cpp
Code:
bool AudioStream::update_setup(void)
{
	if (update_scheduled) return false;
	attachInterruptVector(IRQ_SOFTWARE, software_isr);
	NVIC_SET_PRIORITY(IRQ_SOFTWARE, 208); // 255 = lowest priority
	NVIC_ENABLE_IRQ(IRQ_SOFTWARE);
	update_scheduled = true;
	return true;
}
And it is set pending in Audiostream.h (static void update_all(void) { NVIC_SET_PENDING(IRQ_SOFTWARE); }
And enabled and disabled in Audio.h
Code:
#define AudioNoInterrupts() (NVIC_DISABLE_IRQ(IRQ_SOFTWARE))
#define AudioInterrupts()   (NVIC_ENABLE_IRQ(IRQ_SOFTWARE))
So I am assuming that our DMA interrupt at completion ISR is starving this ISR? So will will play some with how/when I transfer the image.
 
Morning all,

Looks like you have been having some fun.

I may play a little more with the 'V' stuff.

@Paul and others - I am no Audio expert. I have not done much of anything with this library...

But wondering about the music sounding bad in the Video mode, which currently each time the camera receives an image it transfers it to the Frame buffer, where each byte is looked up in the array to translate to 16 bit color.... So it is taking some time in this ISR...

Audio - I might be missing something but I only found one IRQ IRQ_SOFTWARE (70) which in the IMXRT manual shows up as grayed out Reserved...
It is used in AudioStream.cpp
Code:
bool AudioStream::update_setup(void)
{
	if (update_scheduled) return false;
	attachInterruptVector(IRQ_SOFTWARE, software_isr);
	NVIC_SET_PRIORITY(IRQ_SOFTWARE, 208); // 255 = lowest priority
	NVIC_ENABLE_IRQ(IRQ_SOFTWARE);
	update_scheduled = true;
	return true;
}
And it is set pending in Audiostream.h (static void update_all(void) { NVIC_SET_PENDING(IRQ_SOFTWARE); }
And enabled and disabled in Audio.h
Code:
#define AudioNoInterrupts() (NVIC_DISABLE_IRQ(IRQ_SOFTWARE))
#define AudioInterrupts()   (NVIC_ENABLE_IRQ(IRQ_SOFTWARE))
So I am assuming that our DMA interrupt at completion ISR is starving this ISR? So will will play some with how/when I transfer the image.

Good Morning @KurtE.
Knew there had to be some sort of interrupt associated with the audio. Nice find. Was a little distracted with the Example2 testing last night and this morning.

So I just did a grep on AudioNoInterrupts and found that in the PlaySynthMusic example they do this when playing a note:
Code:
  if(opcode == CMD_PLAYNOTE) {
    unsigned char note = *sp++;
    unsigned char velocity = *sp++;
    [COLOR="#FF0000"]AudioNoInterrupts();[/COLOR]
    waves[chan]->begin(AMPLITUDE * velocity2amplitude[velocity-1],
                       tune_frequencies2_PGM[note],
                       wave_type[chan]);
    envs[chan]->noteOn();
   [COLOR="#FF0000"] AudioInterrupts();[/COLOR]
    return;
  }
but I don't see that in playnote in the Zelda sketch - wonder if it would make a difference?
 
Good Morning @KurtE.
Knew there had to be some sort of interrupt associated with the audio. Nice find. Was a little distracted with the Example2 testing last night and this morning.

So I just did a grep on AudioNoInterrupts and found that in the PlaySynthMusic example they do this when playing a note:
Code:
  if(opcode == CMD_PLAYNOTE) {
    unsigned char note = *sp++;
    unsigned char velocity = *sp++;
    [COLOR="#FF0000"]AudioNoInterrupts();[/COLOR]
    waves[chan]->begin(AMPLITUDE * velocity2amplitude[velocity-1],
                       tune_frequencies2_PGM[note],
                       wave_type[chan]);
    envs[chan]->noteOn();
   [COLOR="#FF0000"] AudioInterrupts();[/COLOR]
    return;
  }
but I don't see that in playnote in the Zelda sketch - wonder if it would make a difference?

Not sure, my impression from: https://www.pjrc.com/teensy/td_libs_AudioProcessorUsage.html
Is the no interrupts calls is to allow you to setup multiple settings and not have them all take effect at the same time...
 
Sorry, havn't read all.
Is there an audio problem, i.e. distorted sound?
Or an other problem?

AudioNoInterrupts() just disables the very low priority software interrupt that generates new audio data.
It can be used to prevent change of settings during generation of a new block, and should be re-enabled as soon as possible.

An other reason for sound problems can be that the interrupt gets not called fast enough or cpu usage is too high - i.e. when other, higher priority interrupts need too much time.
Or, the I2S DMA interrupt is delayed too long.

Running an other DMA channel with higher priority too fast can be a reason, too.
 
Talking another look through the FlexIO DMA code we have now and what I was doing in the GPIO DMA code, to see if anything makes sense on differences.

There are some simple differences, like: I was/am using a chain of DMASettings and the FlexIO is just using one DMAChannel.

There are a couple of reasons why, but the main one is due to amount of data transferred. Also especially since the other code started from different camera.

That is: With this camera we are reading in a 324x244 image with one byte per pixel and we are reading it in 4 bytes at a time. That is the shift register will trigger the DMA operation after it completes shifting in 4 pixels...
So the main iteration counts are: 324*244/4 = 19764

Now suppose that OV7670 at 320*240 with 16 bit colors: 320*240/2 = 38400

Problem is that CITER/BITER are 15 bits so max is 32767

Another difference in code bases, which may not make much difference is, that: In the earlier DMA code, once I was in continuous mode and saw the VSYNC signal, I don't look again for VSYNC, but instead rely on the DMA transfers will only happen with the HREF signals are active which is only within the frame... Where the FlexIO version now, stops the dma operation at the end of a frame, and then only starts it again when it gets the next VREF... If this interrupt is not serviced quick enough, potentially the frame may have already started, and we may have missed part of it and would then walk into the next frame. But I also don't know what the VSYNC interrupt code would then do as it might trigger again while that DMA was still active... So not sure what would happen then...

More to figure out and play with.
 
Sorry, havn't read all.
Is there an audio problem, i.e. distorted sound?
Or an other problem?

AudioNoInterrupts() just disables the very low priority software interrupt that generates new audio data.
It can be used to prevent change of settings during generation of a new block, and should be re-enabled as soon as possible.

An other reason for sound problems can be that the interrupt gets not called fast enough or cpu usage is too high - i.e. when other, higher priority interrupts need too much time.
Or, the I2S DMA interrupt is delayed too long.

Running an other DMA channel with higher priority too fast can be a reason, too.

More of a popping sound when display is activated. Likely problem is for the reasons you cited on the interrupts. About half way through the attached recording you can hear the popping and then I stop the video it Zelda plays fine again.

Now if I tell the sketch just to read individual frames and display them as opposed to continuously read from the camera then it works without popping. So you are probably right in your assessment.
 

Attachments

  • 2021-04-28-10-30-09.zip
    145.8 KB · Views: 51
Mike p#728 Test #2 is the " problem discovered with 't' " - when user _isr PRI not set lower than (128==default) - i.e. (144)
> originally it was written at PRI(255) just to assure the camera code could deal with interruptions or busy user code : no problem here, just slower fps Hz
> then rewrite to use DMAMEM for busy code cache - assuming the slower access if the Camera code was using that might show an issue : no problem here

>> Noted before the DMA (non-Flexio ) had no trouble with this as it was before removal
>> But the Flexio transfer method with SAME higher PRI(128) user code gets delayed and then Faults the system arriving too late to handle the event it was expecting
Kurt RE p#734 :: This was fixed when GPIO PRI(102) put it above the User PRI(128) so the VSync response window was not missed

Raising the Flexio PRI above User code Hides the problem where slow response to the Flexio interrupt has a math/access issue from delayed response and Faults
> not sure there is a way to 'fix' missing the start window as noted the frame has started - perhaps if 'discoverable' as late - just skip the frame?

This PRI(#) conflict hasn't changed ... even though for some reason my PJRC.BB failed me here as a carrier for the T.MM. It works to exhibit the same on SFun MachLearn carrier
> though I no longer have the FB_HardFault code on hand to Restart and ID after a fault so I have to push Button after Hang with note as to why.
 
This morning I have done a little playing with IRQ priorities...

To help with that I added to the class: HM01B0.h:
Code:
	void setVSyncISRPriority(uint8_t priority) {NVIC_SET_PRIORITY(IRQ_GPIO6789, priority); }
	void setDMACompleteISRPriority(uint8_t priority) {NVIC_SET_PRIORITY(dma_flexio.channel & 0xf, priority); }

And then added to the Zelda...INO file.

Code:
 Serial.printf("ImageSize (w,h): %d, %d\n", FRAME_WIDTH, FRAME_HEIGHT);

  // Lets setup camera interrupt priorities:
  //hm01b0.setVSyncISRPriority(102); // higher priority than default
  hm01b0.setDMACompleteISRPriority(192); // lower than default
And was playing around with different numbers.

So far I have not fixed the sound issue. I also commented out the outputs of #s which I think did help some.

Next up to add some digitalWrites... To see if I get any overlaps of timings...

Also maybe in the VSync ISR maybe check to see if the DMA is still in operation and not do something...
 
This morning I have done a little playing with IRQ priorities...

To help with that I added to the class: HM01B0.h:
Code:
	void setVSyncISRPriority(uint8_t priority) {NVIC_SET_PRIORITY(IRQ_GPIO6789, priority); }
	void setDMACompleteISRPriority(uint8_t priority) {NVIC_SET_PRIORITY(dma_flexio.channel & 0xf, priority); }
...
Next up to add some digitalWrites... To see if I get any overlaps of timings...

Also maybe in the VSync ISR maybe check to see if the DMA is still in operation and not do something...

Have fun with digitalWrites.

Exposing the priority adjustment should make that available easily enough.

You mentioned pulling the needed GPIO from 6789 to the low speed individual interrupt? If that worked on the SLOW I/O mode - it would speed up the interrupt processing for the needed pin(s) without affecting all ports . Is that a worthy avenue?

Missing the VSync for start could explain the broken images displayed - but having it get to a fault is icky :( - don't suppose there is a way to arrive to VSync and tell that it happened 'too long ago' to start now.

Of course the 'Prime _isr Busy' work is contrived - but the Example code is otherwise in a vacuum of what a user sketch might be doing in a real use case. And again not sure what typical use of _isr might accompany camera usage - but if the loop() is busy 'processing' images and loop run time is slow - setting up interrupts to handle time critical things might be common.
 
@KurtE - @defragster
Just stopped going through my myriad of junk boxes and trying to get them organized and catching up now.

I did notice that you commented out the lines a little while after post #725:
Code:
//    NVIC_SET_PRIORITY(IRQ_GPIO6789, 102);
//    NVIC_SET_PRIORITY(dma_flexio.channel & 0xf, 102);

I uncommented those lines and reran Zelda in just the 'F' continuous mode and no popping sounds or distortion. Only thing is that the frame update rate goes way done. Haven't played with tweaking those settings.

>> But the Flexio transfer method with SAME higher PRI(128) user code gets delayed and then Faults the system arriving too late to handle the event it was expecting
Kurt RE p#734 :: This was fixed when GPIO PRI(102) put it above the User PRI(128) so the VSync response window was not missed
Agreed. That's why I commented about setting it to 144. At 128 it fails. But I am still not getting the issues you are except for the priority interrupts.

Serial.printf("ImageSize (w,h): %d, %d\n", FRAME_WIDTH, FRAME_HEIGHT);

// Lets setup camera interrupt priorities:
//hm01b0.setVSyncISRPriority(102); // higher priority than default
hm01b0.setDMACompleteISRPriority(192); // lower than default
Have you tried with just 'F' or is it with just 'V'?
 
As a follow-up to my previous post. Reran example2 with the high interrupt load.

with no isrPrime_it set 'F' runs but does get split screened if I wiggle my fingers around in front of the camera. Starts out fine but then slows way up:
Code:
redraw rate = 8.10 Hz	 secs = 109		deg  C=53
LP#=7	Pri#=110056	last Pri=107595287	ms=110509	ipCyc%=57.52	deg  C=53
LP#=8	Pri#=110053	last Pri=107595287	ms=111485	ipCyc%=57.54	deg  C=53
LP#=9	Pri#=110053	last Pri=107595287	ms=112515	ipCyc%=57.54	deg  C=53
LP#=9	Pri#=110054	last Pri=107595287	ms=113518	ipCyc%=57.53	deg  C=53
LP#=8	Pri#=110053	last Pri=107595287	ms=114429	ipCyc%=57.52	deg  C=53
LP#=8	Pri#=110052	last Pri=107595281	ms=115434	ipCyc%=57.54	deg  C=53
LP#=9	Pri#=110058	last Pri=107595287	ms=116442	ipCyc%=57.53	deg  C=53
LP#=8	Pri#=110053	last Pri=107595287	ms=117446	ipCyc%=57.53	deg  C=53
LP#=8	Pri#=110050	last Pri=107595281	ms=118426	ipCyc%=57.54	deg  C=53
LP#=8	Pri#=110057	last Pri=107595287	ms=119523	ipCyc%=57.53	deg  C=53
redraw rate = 8.01 Hz	 secs = 119		deg  C=53
LP#=8	Pri#=110053	last Pri=107595287	ms=120500	ipCyc%=57.54	deg  C=53
LP#=7	Pri#=110051	last Pri=107595281	ms=121477	ipCyc%=57.54	deg  C=53
LP#=8	Pri#=110053	last Pri=107595287	ms=122481	ipCyc%=57.55	deg  C=52
LP#=7	Pri#=110052	last Pri=107595281	ms=123434	ipCyc%=57.53	deg  C=53
LP#=8	Pri#=110059	last Pri=107595287	ms=124439	ipCyc%=57.52	deg  C=54
LP#=9	Pri#=110056	last Pri=107595287	ms=125445	ipCyc%=57.53	deg  C=54
LP#=7	Pri#=110060	last Pri=107595287	ms=126423	ipCyc%=57.53	deg  C=53
LP#=9	Pri#=110053	last Pri=107595287	ms=127520	ipCyc%=57.52	deg  C=53
LP#=8	Pri#=110058	last Pri=107595287	ms=128432	ipCyc%=57.52	deg  C=54
LP#=9	Pri#=110061	last Pri=107595287	ms=129554	ipCyc%=57.53	deg  C=53
redraw rate = 8.08 Hz	 secs = 129		deg  C=53
LP#=7	Pri#=110055	last Pri=107595287	ms=130504	ipCyc%=57.52	deg  C=53
LP#=8	Pri#=110053	last Pri=107595287	ms=131505	ipCyc%=57.53	deg  C=53
LP#=8	Pri#=110054	last Pri=107595287	ms=132481	ipCyc%=57.53	deg  C=53
LP#=8	Pri#=110057	last Pri=107595287	ms=133484	ipCyc%=57.52	deg  C=53
LP#=9	Pri#=110050	last Pri=107595281	ms=134490	ipCyc%=57.54	deg  C=53
LP#=9	Pri#=110053	last Pri=107595287	ms=135426	ipCyc%=57.53	deg  C=53
LP#=8	Pri#=110053	last Pri=107595287	ms=136430	ipCyc%=57.51	deg  C=53
LP#=9	Pri#=110051	last Pri=107595281	ms=137434	ipCyc%=57.54	deg  C=53
LP#=9	Pri#=110062	last Pri=107595287	ms=138465	ipCyc%=57.52	deg  C=53
LP#=9	Pri#=110053	last Pri=107595287	ms=139468	ipCyc%=57.53	deg  C=53
redraw rate = 7.93 Hz	 secs = 139		deg  C=53
LP#=9	Pri#=110053	last Pri=107595287	ms=140498	ipCyc%=57.52	deg  C=53
LP#=1	Pri#=110053	last Pri=107595287	ms=142043	ipCyc%=57.54	deg  C=54
LP#=1	Pri#=110062	last Pri=107595287	ms=145899	ipCyc%=57.52	deg  C=53
LP#=1	Pri#=110059	last Pri=107595287	ms=149758	ipCyc%=57.53	deg  C=54
redraw rate = 1.02 Hz	 secs = 151		deg  C=53
LP#=1	Pri#=110065	last Pri=107595287	ms=155450	ipCyc%=57.51	deg  C=54
LP#=1	Pri#=110059	last Pri=107595287	ms=159309	ipCyc%=57.51	deg  C=54
LP#=1	Pri#=110060	last Pri=107595287	ms=163165	ipCyc%=57.52	deg  C=54
redraw rate = 0.44 Hz	 secs = 163		deg  C=54
If I stopped 'F' and switch to 'V' seems to be working:
Code:
LP#=1	Pri#=64376	last Pri=107503933	ms=344531	ipCyc%=66.09	deg  C=53
LP#=1	Pri#=65489	last Pri=107506159	ms=348778	ipCyc%=66.66	deg  C=53
LP#=1	Pri#=65491	last Pri=107506159	ms=352985	ipCyc%=54.51	deg  C=54
LP#=1	Pri#=64376	last Pri=107503933	ms=359336	ipCyc%=66.09	deg  C=53
no tearing and no splits when wiggle fingers or move around.

if I now set it to 122 it still works about the same way as with no priority set.
Code:
LP#=3255	Pri#=110157	last Pri=107595491	ms=8578	ipCyc%=57.52	deg  C=54
LP#=1	Pri#=110155	last Pri=107595491	ms=12250	ipCyc%=57.52	deg  C=54
LP#=1	Pri#=110157	last Pri=107595491	ms=15922	ipCyc%=57.52	deg  C=54
LP#=1	Pri#=110154	last Pri=107595487	ms=19594	ipCyc%=57.52	deg  C=54
* continuous mode started
LP#=1	Pri#=110055	last Pri=107595287	ms=23280	ipCyc%=57.53	deg  C=54
redraw rate = 0.04 Hz	 secs = 23		deg  C=54
LP#=1	Pri#=110055	last Pri=107595287	ms=28973	ipCyc%=57.53	deg  C=54
LP#=1	Pri#=110050	last Pri=107595281	ms=32832	ipCyc%=57.55	deg  C=54
redraw rate = 0.44 Hz	 secs = 34		deg  C=54
LP#=1	Pri#=110053	last Pri=107595287	ms=36691	ipCyc%=57.53	deg  C=54
LP#=1	Pri#=110053	last Pri=107595287	ms=40547	ipCyc%=57.54	deg  C=54
LP#=1	Pri#=110061	last Pri=107595287	ms=44405	ipCyc%=57.51	deg  C=54
redraw rate = 0.52 Hz	 secs = 46		deg  C=54
LP#=1	Pri#=110056	last Pri=107595287	ms=48261	ipCyc%=57.51	deg  C=54
* continuous mode stopped
LP#=1	Pri#=110155	last Pri=107595491	ms=51933	ipCyc%=57.52	deg  C=54
LP#=1	Pri#=110155	last Pri=107595491	ms=55699	ipCyc%=57.52	deg  C=54
* continuous mode (Video) started
redraw rate = 0.08 Hz	 secs = 59		deg  C=54
LP#=1	Pri#=63598	last Pri=107502377	ms=61650	ipCyc%=57.60	deg  C=54
LP#=1	Pri#=65491	last Pri=107506159	ms=65858	ipCyc%=58.56	deg  C=54
LP#=1	Pri#=64376	last Pri=107503933	ms=70104	ipCyc%=58.00	deg  C=54
 
Results with Zelda:
1. 'F' updates screen but no popping sounds and no distortions.
2. 'V' still get the distortion

As a note even if I change the priorities in the lib (up or down) 'F' still works but 'V' will still give the distortion when updating the screen.

This is just a quick a dirty test.
 
@All
Good Morning.

Decided to play a bit more with the camera so I ported over the CMSIS NN example using CIFAR10 example that identifies several objects. Did have to reduce the size of the image down to 32x32 to make it work but luckily that was part of the example I ported. The CIFAR-10 dataset has 10 classes of images it can identify:
Code:
airplane
automobile
bird
cat
deer
dog
frog
horse
ship
truck

To use the example you will have to download CMSIS-NN lib. My copy that I am using is here: https://github.com/mjs513/CMSIS-NN--Neural-Network--for-Teensy-3.6

Past forum stuff: https:
https://forum.pjrc.com/threads/5380...-Now-Working-on-Teensy-3-6?highlight=cmsis-nn
https://forum.pjrc.com/threads/57433-Teensy-4-0-Image-Classification-w-CMSIS-NN?highlight=cmsis-nn

CMSIS-NN: https://community.arm.com/developer...ls-boost-efficiency-in-microcontrollers-by-5x
CIFAR-10/CIFAR-100 datasets: https://www.cs.toronto.edu/~kriz/cifar.html

Ran this - not sure if it saw my cat or not - cats are not easy to present to the camera:
Code:
airplane	0: 94	0: 84	0: 117	0: 40	0: 79	0: 0
automobile	1: 0	1: 0	1: 0	1: 1	1: 0	1: 0
bird	2: 2	2: 42	2: 3	2: 1	2: 1	2: 1
cat	3: 23	3: 1	3: 3	3: 81	3: 39	3: 0
deer	4: 5	4: 0	4: 0	4: 0	4: 2	4: 0
dog	5: 0	5: 0	5: 1	5: 1	5: 4	5: 0
frog	6: 0	6: 0	6: 0	6: 0	6: 0	6: 126
horse	7: 0	7: 0	7: 0	7: 0	7: 0	7: 0
ship	8: 0	8: 0	8: 0	8: 0	8: 0	8: 0
truck	9: 0	9: 0	9: 0	9: 1	9: 0	9: 0

Is that word order from post the same as the number list on SerMon as shown?

Did okay on a couple of web images on phone
 
@KurtE - @defragster
...
Agreed. That's why I commented about setting it to 144. At 128 it fails. But I am still not getting the issues you are except for the priority interrupts.
The only issue I see is that PRI(128) breaks w/screen Un-Sync and Faults ... not sure what others?
> ... [ignoring PJRC.BB for now] - looking close the camera ribbon is not perfectly square - wonder it is is cross connecting and shorting power?

It seems default is 128, as it acts the same - but I was setting explicitly to be sure either 128 or 144. Given all other 'default' interrupts are at 128 - those would be the ones a user might engage with, by default.

Have you tried with just 'F' or is it with just 'V'?

I don't have a sketch with 'V' in - Ex_1 or Ex_2 ??

I can merge it into Ex_2 if I see it ... <edit> I see 'V' in hm01b0_testv3.ino

NOTE: Returned to PJRC.BB - indeed reseating the camera connector straight and sure seems to have corrected the issue! I plugged in USB to bare PJRC carrier and saw some fluttering on the 3.3V power come and go 2.5V to 3.3V. So it was shifted enough to short it seems.
 
Last edited:
Afternoon all
Sorry crashed for a little bit so just catching up.

Is that word order from post the same as the number list on SerMon as shown?
Simple answer is yes :) The OV7670 did much better but I think the lens that they use is better.

I don't have a sketch with 'V' in - Ex_1 or Ex_2 ??
@KurtE added it to the Zelda sketch so I just copied it over.
 
Ok just updated the repository.

1. Added @KurtE set priorities to .h and call them from init to set both to 102.
2. Updated sketches to include 'V'
3. Uploaded my copy of Example2 which has 'V' included. Also updated Example1 and Zelda original version.

Cheers.
 
Hi all
For the micromod board in twowire i just changed Wire1 and Wire2 like this:
Code:
PROGMEM
constexpr TwoWire::I2C_Hardware_t TwoWire::i2c3_hardware = {
	CCM_CCGR2, CCM_CCGR2_LPI2C3(CCM_CCGR_ON),
#if defined(ARDUINO_TEENSY41)
		{{17, 1 | 0x10, &IOMUXC_LPI2C3_SDA_SELECT_INPUT, 2}, {44, 2 | 0x10, &IOMUXC_LPI2C3_SDA_SELECT_INPUT, 1}},
		{{16, 1 | 0x10, &IOMUXC_LPI2C3_SCL_SELECT_INPUT, 2}, {45, 2 | 0x10, &IOMUXC_LPI2C3_SCL_SELECT_INPUT, 1}},
#else  // T4 and ARDUINO_TEENSY_MICROMOD
		{{17, 1 | 0x10, &IOMUXC_LPI2C3_SDA_SELECT_INPUT, 2}, {36, 2 | 0x10, &IOMUXC_LPI2C3_SDA_SELECT_INPUT, 1}},
		{{16, 1 | 0x10, &IOMUXC_LPI2C3_SCL_SELECT_INPUT, 2}, {37, 2 | 0x10, &IOMUXC_LPI2C3_SCL_SELECT_INPUT, 1}},
#endif
	IRQ_LPI2C3
};
//TwoWire Wire1(&IMXRT_LPI2C3, TwoWire::i2c3_hardware);

PROGMEM
constexpr TwoWire::I2C_Hardware_t TwoWire::i2c4_hardware = {
	CCM_CCGR6, CCM_CCGR6_LPI2C4_SERIAL(CCM_CCGR_ON),
		{{25, 0 | 0x10, &IOMUXC_LPI2C4_SDA_SELECT_INPUT, 1}, {0xff, 0xff, nullptr, 0}},
		{{24, 0 | 0x10, &IOMUXC_LPI2C4_SCL_SELECT_INPUT, 1}, {0xff, 0xff, nullptr, 0}},
	IRQ_LPI2C4
};
//TwoWire Wire2(&IMXRT_LPI2C4, TwoWire::i2c4_hardware);

#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
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 :)
 
Last edited:
PRIOR run just stopped this long run with prior hardcoded PRI(102) in lib
>> redraw rate = 9.43 Hz secs = 10440 deg C=52

So PJRC.MM.Breakout is up and running with Camera connector properly seated :)

>> Will do a PR for edits made for some of the following.

Using :: example2.ino { w/ssd1306 on WIRE and Serial5 wired 20<>21 }
>> Just noticed all of the followed is using LOWER Priority for PRIME _isr :: isrPrime_it.priority(144);
Got the updated with VID - {'Vv' ... need to add to the prompt menu}
Added these to setupPR():
hm01b0.setVSyncISRPriority(102);
hm01b0.setDMACompleteISRPriority(102);
>> It runs "F" a bit - the display stops updating then the SSD stops and it is hung :( - needs a Button.

opps : this was still at (60) - that was a posted bad thing :: hm01b0.set_framerate(30); //15, 30, 60, 120

Got "V" video to display - ran fine 53 secs with 't' then loop Cnt dropped to 1 and SSD1306 update stopped and Serial5 loopback count dropped from "S5#=1134" to "S5#=125" ???
QUESTION: >> Is there another interrupt utilized in processing VIDEO ?
Code:
LP#=21	Pisr#=59273  lastPR=107493721  ms=77145  ipCyc%=71.56  S5#=1386  52C
LP#=20	Pisr#=58297  lastPR=107491763  ms=78121  ipCyc%=75.07  S5#=1323  52C
LP#=20	Pisr#=59270  lastPR=107493721  ms=79122  ipCyc%=71.56  S5#=1323  52C
LP#=21	Pisr#=59273  lastPR=107493721  ms=80125  ipCyc%=67.51  S5#=1386  52C
LP#=17	Pisr#=59275  lastPR=107493731  ms=83059  ipCyc%=71.54  S5#=1134  52C
[B]LP#=1	Pisr#=58306  lastPR=107491793  ms=87267  ipCyc%=71.00  S5#=126  52C[/B]
LP#=1	Pisr#=59275  lastPR=107493731  ms=91514  ipCyc%=71.54  S5#=126  52C
LP#=1	Pisr#=59275  lastPR=107493731  ms=97825  ipCyc%=71.54  S5#=126  51C
LP#=1	Pisr#=59280  lastPR=107493731  ms=102072  ipCyc%=71.54  S5#=126  52C
LP#=1	Pisr#=58306  lastPR=107491793  ms=106280  ipCyc%=71.01  S5#=126  52C
LP#=1	Pisr#=59280  lastPR=107493731  ms=110487  ipCyc%=71.54  S5#=126  52C
LP#=1	Pisr#=58299  lastPR=107491763  ms=114734  ipCyc%=75.05  S5#=126  52C

... // Stopped "V" and 't' count behavior persisted then did 'f' single frame  :: SSD1306 still DEAD !!!
LP#=1	Pisr#=99827  lastPR=107574791  ms=259977  ipCyc%=52.05  S5#=126  52C
LP#=1	Pisr#=99827  lastPR=107574791  ms=265485  ipCyc%=52.05  S5#=126  53C
Reading frame
error writing to HM01B0
Finished reading frame
LP#=1	Pisr#=99828  lastPR=107574791  ms=269436  ipCyc%=52.05  S5#=126  52C
LP#=1	Pisr#=99829  lastPR=107574791  ms=273108  ipCyc%=52.05  S5#=126  52C
LP#=1	Pisr#=99827  lastPR=107574791  ms=276780  ipCyc%=52.05  S5#=126  52C
Reading frame
error writing to HM01B0
Finished reading frame

... // Below restart "F" and it does update as noted ... SLOW
LP#=1	Pisr#=99828  lastPR=107574791  ms=359659  ipCyc%=52.05  S5#=126  52C
LP#=1	Pisr#=99828  lastPR=107574791  ms=363331  ipCyc%=52.05  S5#=126  52C
* continuous mode started
LP#=1	Pisr#=99743  lastPR=107574667  ms=367005  ipCyc%=52.10  S5#=126  52C
redraw rate = 0.00 Hz	 secs = 367		deg  C=53
LP#=1	Pisr#=99745  lastPR=107574671  ms=370841  ipCyc%=52.11  S5#=126  52C
LP#=1	Pisr#=99746  lastPR=107574671  ms=374677  ipCyc%=52.10  S5#=126  52C
LP#=1	Pisr#=99745  lastPR=107574671  ms=378514  ipCyc%=52.11  S5#=126  52C
redraw rate = 0.52 Hz	 secs = 378		deg  C=52
LP#=1	Pisr#=99743  lastPR=107574667  ms=382351  ipCyc%=52.10  S5#=126  51C
LP#=1	Pisr#=99745  lastPR=107574671  ms=386188  ipCyc%=52.11  S5#=126  52C
redraw rate = 0.44 Hz	 secs = 390		deg  C=53
 
hm01b0.setVSyncISRPriority(102);
hm01b0.setDMACompleteISRPriority(102);
Not really need as its in init but good to show usuage.

Yeah - 'V' has a problem still but believe @KurtE is working on it. Have to retest.

Warning: priority is set to 122 - never changed back
 
Not really need as its in init but good to show usuage.

Yeah - 'V' has a problem still but believe @KurtE is working on it. Have to retest.

Missed the add to init - yes, I see it. Assumed that was added for user discretion ... though obscure and hard to debug when it crashes :)

PR done - added "V", set framerate to (30) and (60) is a fail.

Put 't' output note for Serial5 chars looped - and reformatted to better fit screen line.

That VIDEO behavior is ODD!!! - has the CPU busy outside of loop somewhere - Prime _isr still ticking - but loop output is broke and the SSD1306 was KILLED
 
Missed the add to init - yes, I see it. Assumed that was added for user discretion ... though obscure and hard to debug when it crashes :)

PR done - added "V", set framerate to (30) and (60) is a fail.

Put 't' output note for Serial5 chars looped - and reformatted to better fit screen line.

That VIDEO behavior is ODD!!! - has the CPU busy outside of loop somewhere - Prime _isr still ticking - but loop output is broke and the SSD1306 was KILLED

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)
 
Back
Top