MicroMod Beta Testing

I just pushed up the changes. However it was in conflict as some of my earlier stuff was already merged... So I used github desktop to rebase to main, Then pushed that up, found a couple of merge issues, which I then resolved, plus removed the warning, then git rebase -i to get all back into one change... And issued PR...
SO you might want to check I did not screw it up :D
 
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' ...

As noted up the wire scanner picked the camera up on the PJRC.BB see one of the posts above :) Not sure why yours didn't
 
I just pushed up the changes. However it was in conflict as some of my earlier stuff was already merged... So I used github desktop to rebase to main, Then pushed that up, found a couple of merge issues, which I then resolved, plus removed the warning, then git rebase -i to get all back into one change... And issued PR...
SO you might want to check I did not screw it up :D

Will do in a little bit - having trouble with the new ML board and the ILI9341.

EDIT. Interesting my ILI9341 not working with the ML board now - tried a couple of 9341s and switching pins - oh using graphics test.
 
Last edited:
As noted up the wire scanner picked the camera up on the PJRC.BB see one of the posts above :) Not sure why yours didn't

Seems I saw another device show on PJRC.BB - but not on the ML ??? Interesting to know if your ML finds it when you get it 'untroubled'.

I'll go do some chores and look for LIB update a bit later.
 
Remember on the ML board, there is an enable pin that turns on the 1.8V regulator that supplies power to the camera. So if you don't enable that, the scanner will not find the camera.
 
Remember on the ML board, there is an enable pin that turns on the 1.8V regulator that supplies power to the camera. So if you don't enable that, the scanner will not find the camera.

That 'no 1.8V enable' would explain the scanner.INO not finding it
 
@KurtE
Going to be awhile I think - went back to the ML board and having major problems - keep getting waiting for DMA or camera not found using 8bit

ok - going to go through your changes and mine and see what is up. PS messing up github is usually my job :)
 
Github is Lame - only Kurt has it mastered. Though with No Permission to MJS513 - I think I found the key for switching base repository in 'Repository Settings' ... but merging is very unclear

When I went back to ML this time I went to 4 bit - seems I saw something odd in 8 bit ??? I was seeing DMA issues and thought it was ME - so went to 4 bit as that seemed the focus. I was having enough grief with the other .BB carrier messing with me.

Okay went back to #define _hmConfig 2 and no issue: "HM01B0_FLEXIO_CUSTOM_LIKE_8_BIT"
Code:
Reading frame
Finished reading frame
Reading frame
Finished reading frame
* continuous mode started
redraw rate = 0.09 Hz	 secs = 11		deg  C=55

Also working no issue as :: #define _hmConfig 0
Code:
HM01B0 Camera Test
HM01B0_SPARKFUN_ML_CARRIER
 
Remember on the ML board, there is an enable pin that turns on the 1.8V regulator that supplies power to the camera. So if you don't enable that, the scanner will not find the camera.

Think maybe I found it because I ran it right after I played with the camera so it may have been left on?
 
Yep tried a few different things with pin assignements etc. Will try again later.

Odd, I recall DMA grief - jumped to 4 bit and it worked - now going back both of those working without issue with last update git code.

About that SD card buffer - need top get back to trying malloc() temp buffer - maybe malloc for vid and use the same buff?

But "back then" when I pushed that static - malloc() alloc was causing FAULT in use.
 
Odd, I recall DMA grief - jumped to 4 bit and it worked - now going back both of those working without issue with last update git code.

About that SD card buffer - need top get back to trying malloc() temp buffer - maybe malloc for vid and use the same buff?

But "back then" when I pushed that static - malloc() alloc was causing FAULT in use.

Right now playing with the updated repository that I just merged. And going back to old sketches to make sure they still work etc.
 
Example2 works as it did for f, F, t

"V": now scrolls - still interrupts SSD box draw

it doesn't have the sketch edit for the callback buffer change?
 
Example2 works as it did for f, F, t

"V": now scrolls - still interrupts SSD box draw

it doesn't have the sketch edit for the callback buffer change?

Give me 5 minutes = just updated example sketches and changed default priorities to 102/192 in init. so if you want to change theme lower or higher :)
 
Wow, things are happening so fast anymore. Just noticed this thread (been living in a cave here). Can a Teensy 5.0 running 2.7-GHz be far behind, lol? Adafruit has a couple of her own hw/sw ecosystems, including CircuitPython. ML seems to be the big thing nowadays. I got one of her Edge Badges with TensorFlow, but not had a chance to play.

I moved the rest of my post to here:
https://forum.pjrc.com/threads/67075-My-Latest-2-GHz-Dual-Core-Project?p=278161#post278161
 
@Kurte - @defragster
Been running example sketch with:
Code:
  isrPrime_it.priority(122);
  hm01b0.setVSyncISRPriority(102);
  hm01b0.setDMACompleteISRPriority(102);

in 'V' ideo mode for about 1 hr . SSD1306: Nice smooth updates no jittering whatsoever. Video working - still have the banding in the lower half of the screen as we noted before. No hangs or loss of 1306 until I bumped the display and lost the connection but video is still work.

Running Example1 Video is rock solid no banding.
 
Tremendous Improvement in VIDEO!!!!
Code:
>> #define _hmConfig 2 // select mode string below
>> #define MMOD_ML 1
  isrPrime_it.priority(144);
  //isrPrime_it.priority(122);
  hm01b0.setVSyncISRPriority(102);
  hm01b0.setDMACompleteISRPriority(102);
> 'f' good
> "F" good then "F" off - these updates do have white area flash
> "V" Great :: Smooth no white popping/flash
>> SSD1306 BOXES are Smooth/NORMAL
LP#=35 Pisr#=96274 lastPR=107567729 ms=303726 ipCyc%=53.55 S5#=0 57C
>> Ooh - not seen temp that high :: 57C
> 96K _Prime _isr's , medium larger number not so fast, ITimer asking for 150K so some take more than alloted time interval
> Primes factor tested using some part of 32KB DMAMEM cache of primes
> No Serial5 in test on SFun.ML
All is running well near 11 minutes! Stopping to run Prime _isr at PRI(122).

Still :: HM01B0_FLEXIO_CUSTOM_LIKE_8_BIT
Only change :: isrPrime_it.priority(122);
>> All of the above repeated and look good / The Same

Doing a finger wiggle: Video shows scan line breakage mostly in the moving finger area, a waving hand does seem to break across whole scan line.
>> Not so much at distance - more with finger tip or hand 6" to a foot

BAD NOTE: Turned off room light, video went speckled - bad contrast
> Turned off "V" to do a 'f' and recalibrate brightness? :: End up Stopped ???? TyComm could do Bootloader and Reset.
SerMon shows this and then Quiet:
Code:
LP#=35	Pisr#=95125  lastPR=107565421  ms=391189  ipCyc%=53.93  S5#=0  57C
* continuous mode stopped
LP#=36	Pisr#=97408  lastPR=107569997  ms=392199  ipCyc%=52.90  S5#=0  57C
LP#=35	Pisr#=99825  lastPR=107574791  ms=393197  ipCyc%=52.07  S5#=0  57C
 
It hangs the code to stop "V" then do an 'f'.
Restarted "V" and waited this long to start 't':
* continuous mode (Video) started
LP#=61178 Pisr#=1 lastPR=0 ms=1672503 ipCyc%=0.00 S5#=0 57C
LP#=35 Pisr#=97167 lastPR=107569499 ms=1673498 ipCyc%=53.25 S5#=0 58C

>
Then let it run this long and stopped "V" - the hitting 'f' stopped SerMon and SSD1306 boxes
Code:
* continuous mode stopped
LP#=36	Pisr#=98806  lastPR=107572793  ms=2635503  ipCyc%=52.20  S5#=0  57C
LP#=36	Pisr#=99827  lastPR=107574791  ms=2636500  ipCyc%=52.07  S5#=0  57C
LP#=36	Pisr#=99823  lastPR=107574791  ms=2637498  ipCyc%=52.07  S5#=0  57C
LP#=35	Pisr#=99825  lastPR=107574791  ms=2638495  ipCyc%=52.07  S5#=0  57C
LP#=36	Pisr#=99824  lastPR=107574791  ms=2639492  ipCyc%=52.07  S5#=0  57C
LP#=37	Pisr#=99825  lastPR=107574791  ms=2640515  ipCyc%=52.07  S5#=0  57C
LP#=35	Pisr#=99828  lastPR=107574791  ms=2641512  ipCyc%=52.07  S5#=0  57C
LP#=36	Pisr#=99824  lastPR=107574791  ms=2642510  ipCyc%=52.07  S5#=0  57C

Until it stopped the SSD1306 boxes were good. Still at PRI(122)
It isn't HUNG or Faulted - just no loop() action - TyComm did a restart.

On restart 'f' good!
"F" - torn badly
"V" - out of sync scrolling 'static'

Turning of "V" did HANG - and TyComm no Reset

Seems the exit from "V" not doing the right thing with stopping auto update?

Good news is T.MM on ML carrier is working well and not restarting alone and is responsive to Program.

After Reset: "V" scrolling noise again - and "V" off then ... HUNG.
Seems I need a power off to clear the camera?

>> Back to normal after power off restart
 
Doing a finger wiggle: Video shows scan line breakage mostly in the moving finger area, a waving hand does seem to break across whole scan line.
>> Not so much at distance - more with finger tip or hand 6" to a foot

BAD NOTE: Turned off room light, video went speckled - bad contrast
> Turned off "V" to do a 'f' and recalibrate brightness? :: End up Stopped ???? TyComm could do Bootloader and Reset.
SerMon shows this and then Quiet:
Can confirm for example2 sketch that when you stop 'V' can't seem to do anything else with the camera. Seems to just hang. I am not seeing any flashes of white doing an 'F'.

Also if I restart I am not seeing the issues with 'F' or 'V' being torn or out of synch on restart. I did turn the light off but didn't see any speckling and when I turned it back on came back to what it was. PS camera in autoExposure mode so no need to do a calAE.

However, doing the same thing with Example1 it is not an issue. Went back and forth several times between "V' and 'F' and 'f' without a problem --- note I am working with the IDE and 4bit mode.

With Zelda sketch seems I can go back and forth several times then you see the same as for Example2. Restarted and tried again - this time it happened after 1 cycle.

With that said the challenge is get 'V' to work with interrupts in certain modes. 'F' seems not to be affected as much since it behaves differently - not really trying to read continually. Don't really remember if I have ever really seen 'V' working with any other cameras. Even with Arducam it tells the camera to load the FIFO then outputs then does again. So its probably more like an 'F' mode.
 
The noted 'white area flash' is just a pulsing of the bright white of the overhead light and bright area on the "F" frame changes. Not at all like that in "V" mode.

Ran fine a long time as "V" with 't' - using:
Code:
const int PrPS=1000 * 150; // 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
LP#=34 Pisr#=96971 lastPR=107569109 ms=6092049 ipCyc%=53.06 S5#=0 57C

Noted below it seems after some "V" runs it takes power off - if "F" or "V" starts bad it seems - some restarts are fine?
Video is very smooth - except moving fingers - and they are worse on the bottom of the image - top have not as pronounced. Is that image buffer timing?

Reprogrammed to fewer longer Prime _isr's
Code:
const int PrPS=1000 * 90; // pick number 30K to 120K, 220K or more net completed depends on priRestart val and tableSize
#define priRestart [B]2147712181 [/B]// Larger Primes takes longer :: 65537 // 53680457 // 107361011 // 107375183 // 2147503639 // 2147712181
LP#=25 Pisr#=35181 lastPR=2147782537 ms=53015 ipCyc%=70.40 S5#=0 55C

SSD1306 is good - but Video is Jittery - but the "F" was awful before doing "V" - going to power off
Okay 'f' and "F" good - but "V" was icky.

Another power off - maybe longer - and all is well as above.
Same thing - restart after "V" doesn't like to do "F" - something needs reset if camera not flushed?

So longer power off then reprogram all Good with - asking for 300K with tiny primes to get next working:
Code:
const int PrPS=1000 * 300; // pick number 30K to 120K, 220K or more net completed depends on priRestart val and tableSize
#define priRestart [B]65537 [/B]// Larger Primes takes longer :: 65537 // 53680457 // 107361011 // 107375183 // 2147503639 // 2147712181
LP#=36 Pisr#=293052 lastPR=651617 ms=237505 ipCyc%=23.76 S5#=0 57C

And this gets most of 500K too while running okay { still at PRI(122) }
const int PrPS=1000 * 500; // pick number 30K to 120K, 220K or more net completed depends on priRestart val and tableSize
LP#=36 Pisr#=432739 lastPR=931013 ms=332857 ipCyc%=43.58 S5#=0 57C

Starting prime at 521 gets 503KK of requested:
Code:
const int PrPS=1000 * 600; // pick number 30K to 120K, 220K or more net completed depends on priRestart val and tableSize
#define priRestart 521 // Larger Primes takes longer :: 521 // 65537 // 53680457 // 107361011 // 107375183 // 2147503639 // 2147712181
LP#=35 Pisr#=503957 lastPR=1008433 ms=3905844 ipCyc%=44.56 S5#=0 58C
 
Just did the lights ON>OFF a couple times and the image I saw must have been a one time 'odd mode'. Through now just ceiling light - earlier the window behind me was outside daylight as well and it didn't go off :)

Just did a code compare Ex_1 and Ex_2 are the same - except for 't' support, and 't' does nothing ( except set higher priorities ) until the 't' is turned ON. And I usually don't turn on 't' until trying the f/F/V startup, then 't' when they look right.

It seems Stopping "V" while 't' is on may be the trouble? Though that only worked once.

Repowering the ML then f,F gave jittery "F". Did a Reset and then f, F worked and "V" and "V" worked once to start stop without 't', but another "V" started and stopped - then Hung and won't TyComm Reset.
 
Morning all
Got the ML board working again using the ST7789 so ran a few tests:
ML Board:
Test 1. Example1 using hmconfig = 0 (8bit), ST7789:
1. 'f', 'F', 'V' all good.
2. No flashing seen.
3. Cycled through f, F, V several times with no hangs
4. 'V' images good with no banding noted on the ST7789

Test 2. Example1 using hmconfig = 3 (4bit), ST7789:
1. 'f', 'F', 'V' all good.
2. No flashing seen.
3. Cycled through f, F, V several times with no hangs
4. 'V' images good with no banding noted on the ST7789

---------------------------------------------------------------------
Test 3. Example2 using hmconfig = 0 (8bit), ST7789:
1. 'f' and 'F' images good no banding or flashing
2. 'V' banding seen in lower half of the screen when image changes (fingers moving or camera moved)
3. 'V' hangs sketch after stopping.
4. test done without 'f' turned on.

Test 4. Example2 using hmconfig = 0 (8bit), ST7789:
1. Turned 't' on and just running 'V'
2. Image stability degradated: Image is jumpy - kindof shifts to right and left periodically
3. Alot of flashing of screen when light is reflected off my hand as I wave it in front of the camera if <6 inches away otherwise no flashing.
4. Banding is there as noted before.
5. SSD1306 cycling smoothly
6. Didn't see any resets
Code:
LP#=35	Pisr#=97158  lastPR=107569493  ms=807749  ipCyc%=53.34  S5#=0  57C
LP#=34	Pisr#=97163  lastPR=107569499  ms=808732  ipCyc%=52.89  S5#=0  57C
LP#=35	Pisr#=97235  lastPR=107569571  ms=809743  ipCyc%=53.22  S5#=0  57C
Stopped here


Test 5. Example2 using hmconfig = 3 (4bit), ST7789:
1. Turned 't' on and just running 'V'
2. Stopped test after a few seconds - way too much flashing. Think this camera does not like direct light or floresenct light.


Note; Seems like the ML board is not as tolerant of example2. Wondering if it might have to do with the voltage applied to one of the camera pins - forgot which one - 1.8v vs 3.3v?
 
Back
Top