MicroMod Beta Testing

@KurtE
Yep it would be fun at some point - I was actually thinking of stereo vision :)

But think maybe we need to finish the base version first - going to go ahead and push what I have to the branch :) But first want to try it again with audio :)
 
@KurtE
Yep it would be fun at some point - I was actually thinking of stereo vision :)

But think maybe we need to finish the base version first - going to go ahead and push what I have to the branch :) But first want to try it again with audio :)

Sounds like a good idea.

As you mentioned, at some point it might also be good to extract the GPIO/DMA stuff and optionally keep or not in own source file(s). Maybe also the FlexIO stuff to it's own file(s). Maybe at some date CSI?
And then maybe all of the camera specific stuff to it's own... Then somehow glue them all to each other. Maybe as a way to also try out a lot of the same code base for different cameras.

But again .... Maybe later!
 
Lots of clean up left to do I think. Getting cross eyed :)

Agree have to figure out a better way to handle the different options in conjunction with the HW options (CSI, Flex, GPIO, and DMA) for those of us that like to thinker with the T4's vs the MM's.

Oh forgot test the new audio shield with the male headers (no jumpers) and it works. Since I am using threads for the camera stuff the camera thread hangs after a few frames. May have to use set slice on the thread but it works fine for 'f' - haven't tried anything much else.

The most important thing - I just pushed the changes I made in the last zip to the carrier_branch along with the zelda example :)
 
Cool, see about updating and giving it a look. Is there a T_4.1 pinout for camera noted somewhere - from that AMZN adapter?
 
Cool, see about updating and giving it a look. Is there a T_4.1 pinout for camera noted somewhere - from that AMZN adapter?

While mentioned don't @KurtE or me have tried it yet or even seen about hooking it up with the adapter yet. So far only tested on the MM carriers :)

@All.
Just pushed up the updated the CMSIS-NeuralNetwork CIFAR-10 picture classifier. Still needs a bit of work :) But it does run.
 
Got latest mjs513 and KurtE/FlexIO_t4 - couple edits for local setup and HM01B0_example1.ino is working on 8 bit PJRC.BB camera { _DC==4, _hmConfig==2 }
Good > f and F and Dual Serial to ArduCam { images not always in registration }
>> First run had DMA fail - okay after a few seconds power off.
 
Did a PR #21 for an intervalTimer to do some busy work added as :: TMM-HM01B0/examples/HM01B0_example2/HM01B0_example2.ino
>> opps - I checked in the line #139 as //isrPrime_it.priority(255); - just changed - that line is the one to comment to see FLEX Cont issue

It uses 54% of the clock cycles and reduces cont refresh - but doesn't cause other trouble except - when at default #128 PRI instead of lower #255 until then - on FLEX Continuous it leads to a Fault seen in 12 to 45 seconds it seems and makes the display unstable. { using ili9341 )

Results in 22K interrupts/sec - each finding the next prime number after the last - and reporting @1Hz and restarting the search prime.
 
Morning all
Did a few updates this morning.
1. Fixed a bit of a bug in the lib.
2. Fixed Neural Network example
3. Tweaked the Zelda-HM01B0 example
4. Cleaned up sketches so DMA is associated with anything anymore just FlexIO

All changes pushed to the carrier branch of the library. Figure everyone can play a bit more then will incorporate into the master after cleanup of all the serial prints.
 
Looks like you have been busy will try to play some later.

I would say go for it and back to master.
 
Sync'd to Main - Master! { Finally figured out the gitDesktop - adjust 'Repository settings ...' to defragster to update my fork - then PR knows what to do on WEB - and back to mjs513 for the latest version }

Doing CodeCompare of "...\HM01B0_example2.ino" and "...\HM01B0_example1.ino" - only diff is addition of 't'? Not seeing any change to "Example1 sketch - removed redundant code so only flexio is involved...", and the issue is with FLEXio

Doing "F" still has the two modes of continuous and the second "F" going to 'g_continuous_flex_mode' when line below commented in example2 leads to non-stable image and a Fault:
Code:
void setupPR() {
  Serial.println("\n" __FILE__ " " __DATE__ " " __TIME__);
  [B]//isrPrime_it.priority(255);[/B]

Started this post before an hour of phone calls ... The PJRC.mm.BB here restarted in TyComm about 17 times (no hardFault reports?) - and now not touchable - ??? - moved USB ports and finally got it to restart and show in TyComm ... seems time for a reboot as the ports not running right? Not even seeing Bootloader?
> Odd - on another port and uplaod and working now ...

That was on startup with no 't' - but the timer Pri was default - but not active?

BTW: for the value in this line with 't':
Cnt LP=4 Cnt Pri=22717 last Pri=53725879 ms=28629 ipCyc=0.54
> count of loops/sec
> count of _isr's per sec calc of next prime
> last prime found in the last second
> current millis() on printing - you can see it slip when 'F' enabled at low loop cnt
> ipCyc is the part os each 1 sec of F_CPU accounted for in the _isr code
 
Answering another post just now led me into :: ...\hardware\teensy\avr\cores\teensy4\IntervalTimer.cpp

Reading that code intervalTimer seems to put the priority value to a hard coded 255?
>> uint8_t IntervalTimer::nvic_priorites[4] = {255, 255, 255, 255};

Not sure why taking out the set to 255 changes that and causes trouble for Flexio case?
 
defragster said:
Doing CodeCompare of "...\HM01B0_example2.ino" and "...\HM01B0_example1.ino" - only diff is addition of 't'? Not seeing any change to "Example1 sketch - removed redundant code so only flexio is involved...", and the issue is with FLEXio
Should be seen g_continuous gone and the DMA callback gone. Maybe I forgot to update it? I will have to take a look. Having a problem with 8bit mode on the BB with message DMA Time out trying to figure it out.

EDIT: ok - found the problem Forgot to remove the audio shield :)
 
That Update must be a local change not on github.

I've seen some DMA timeouts - unplugging and waiting and other stuff ... wasn't sure if it was me or my selected options.

PJRC.BB on new USB port and fine since p#661 restarts? Moving back to the other port it now shows up? Something went odd ??? Not restarted machine ...
 
That Update must be a local change not on github.

I've seen some DMA timeouts - unplugging and waiting and other stuff ... wasn't sure if it was me or my selected options.

PJRC.BB on new USB port and fine since p#661 restarts? Moving back to the other port it now shows up? Something went odd ??? Not restarted machine ...

Just checked on the Master branch. Example1 has the changes I mentioned while Example2 does not. Are you sure you using Example1 from the repository?

Not sure you saw the previous post but the Timeouts were caused by leaving the audio board on the BB well in 8bit mode. Probably need to add a note to that effect someplace. Since just switching over to just FlexIO I haven't seen any timeouts that were caused by user error - that is my fat fingering :)

Weird the issue with the ports. Been leaving mine on the same port on the powered hub with no problem with restarts so far - well shouldn't say that - did have a restart but had wrong configuration set up which cause problems, once fixed no issue.
 
Mike - found the changed ex_1 in git folder. It needs to have that DMAMEM removed before send_image: you rewrote that days back to use buffered image data better so it isn't used.

Changing the 't' busy work timing to use DMA array - works much faster so base prime at 53,680,457 taking 54% of CPU had to go to 2,147,712,181 to get workload up to 45% and now instead of 22K/sec it is doing 36K.
> At prior 53M only taking 15% and that is doing 37K Primes/_isr's per sec, allows bumping _isr's (one new bigger prime each) to 100K/sec and still only 40% of cpu cycles, so tons of DMA reads for next divisor value

Good news is the many DMA RAM accesses in the _isr are not interfering with "F" - though FlexIO okay at 15% load - with PRI not 255 it tears and go HardFault at higher loads.

Will merge EX_2 w/'t' to EX_1 to fix the "F" option. Unless 't' enabled it only adds tiny bit of inactive code - not sure why it shouldn't replace EX_1 ?
 
Did Merge Ex1 >> Ex2 losing old DMA "F".

"F" is fine with _isr Pri(255) doing 43K primes/sec and using 75% of CPU for larger primes - 't' drops refresh to 5.11Hz from 15.34Hz. Put in explicit set option for Pri(128) and it scrambles and faults "F" Flexio.

That is with _hmConfig == 3 for 4bit camera using ili9341

Going to _hmConfig == 2 for 8 bit camera refresh is the same 15.34Hz - but turning on 't' drops refresh to 6.14 - so that gives a measure of the extra nibble processing overhead where the limit isn't set by screen refresh.
>> Doing 8 bit Flexio "F" and _isr Pri(128) seems to draw as bad/worse and Fault sooner.

Going to upload EX_2 PR running at 67K _isr's and 35% usage, if this uncommented Flexio won't run a full 10 seconds :: //isrPrime_it.priority(128);
with Pri(255) "F" FlexIO runs fine - Note changing the priority() does not allow any more _isr()'s - it just seems to interfere with Flexio priority operation to complete without Fault?:
Code:
redraw rate = 15.34 Hz
LP#=231011	Pri#=67682	last Pri=107510539	ms=20615	ipCyc%=35.36

Made TMM-HB01B0-Camera/pull/23 - saw it needed DMAMEM on the prime cache - works the same there or in RAM1 it seems.
 
Updated PR - integer request of intervalTimer freq was faulty asking for 200 or 220K/sec were way off.

These params work for 61% cpu use and all is well with FlexIO at _isr pri(255):
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 107361011 // Larger Primes takes longer :: 65537 // 53680457 // 107361011 // 107375183 // 2147503639 // 2147712181
giving stable good image and long run time with 't' output:
Code:
redraw rate = 7.67 Hz
LP#=685211	Pri#=117260	last Pri=107595517	ms=938968	ipCyc%=61.23

But changing to this { from 255 } is ugly and faults in under 10 secs:: isrPrime_it.priority(128);
Code:
LP#=884564	Pri#=117287	last Pri=107595583	ms=16228	ipCyc%=61.21
Hardfault.
Return Address: 0x8A87848C
Faulted from exception.
	(IACCVIOL) Instruction Access Violation
 
Good morning all
Realized something interesting this morning while looking at Zelda-HM01B0 example. As @defragster pointed out IntervalTimer seems to be conflicting with FlexIO. Now I mentioned that in continuous mode with Zelda and the camera the thread would hang for some reason. Well just noticed that Zelda uses 3 interval timers wondering if this is causing the camera to hang while in continuous mode.

Any thoughts.

NO not it - commented out the interval timer and still hung back to the drawing board.
 
Last edited:
Morning all,

Any thoughts? - Occasionally ;) :D

Sorry have been distracted with some other stuff...

I know I should read the stuff to figure it out, but what do I need to setup to do Zelda? i.e. does it need extra hardware... Again probably can figure that out,

but sort of going a bit slow today and only had a few sips of coffee
 
Morning all,

Any thoughts? - Occasionally ;) :D

Sorry have been distracted with some other stuff...

I know I should read the stuff to figure it out, but what do I need to setup to do Zelda? i.e. does it need extra hardware... Again probably can figure that out,

but sort of going a bit slow today and only had a few sips of coffee

Yeah going to feel a bit slow for about 2-3 days depending....

Actually to run Zelda all you need is the audio shield a speaker and sketch :)

EDIT: Heres a picture of my setup:
unnamed.png
For once no mess of jumper wires :)
 
Last edited:
@all
Just pushed a update to the lib - just turned off debug in the lib.

I also added a v2 of the Zelda sketch that works - just reads single frame at a time. Not sure why continuous is not working. In case anyone wants to play will leave original up there for a while.

Not sure where to go from here with the lib - maybe test on a T4 standalone? Oh - just got my OV7670 camera so maybe at some point will play with that :)
 
Sounds good. I found a T4 Audio board... I know I have several, but first one I found had female pins... Found new one with no pins, so will solder later.
Also will solder up pins to the ribbon breakout cable so can try different pins with it.

One thing I noticed with my DMA stuff sort of removed :( is that I don't believe we are doing any of the continuous updates mode like my 'V' command before. Where it was setup to receive an image and update the top half and bottom half depending on which part of the screen is being refreshed.

Wonder how it would work with the FlexIO stuff?
 
I set my Rev D Audio's aside somewhere I couldn't find - except a female bottom header - so I pushed male pins into the pjrc.bb - heard zelda music - but no image as tried at the time - with pin 10 conflict it was iffy. Will have to try again.

About the Ex_2 't' :: interval time issue with Pri(128) - did a quick test showing ::
Code:
new FlexIO data
redraw rate = 30.69 Hz
with removal of display code:
Code:
    if (g_new_flexio_data) {
      Serial.println("new FlexIO data");
[B][COLOR="#FF0000"]      if (0) {
      tft.setOrigin(-2, -2);
      tft.writeRect8BPP(0, 0, FRAME_WIDTH, FRAME_HEIGHT, (uint8_t *)g_new_flexio_data, mono_palette);
      tft.setOrigin(0, 0);
      tft.updateScreenAsync();
    }
[/COLOR][/B]

So:
#1 :: The camera reads 30 FPS - and display update cuts that in half.
#2 :: isrPrime_it.priority(128); Still faults without any display operations!
#3 :: runs fine with pri(255)

it isn't a display code conflict - and the HBcam_Flexio only has a Fault issue when the PRI 128

Setting :: isrPrime_it.priority(146);
Seems to be fine. My supposition is that Flexio needs a priority bump - or it needs some detection/correction where it may get late interrupt service and then proceeding is using a bad pointer?

The Average/Default _isr priority is #128 - so using any other device could easily cause this conflict? Serial?/SPI?/i2c?/SDIO?

This RUN : pri(128) >> 't', 'F' - restarted with NO fault ( like I saw 18 times yesterday ? )
Code:
new FlexIO data
LP#=3014046	Pri#=117287	last Pri=107595583	ms=18158	ipCyc%=61.19
new FlexIO data
new FlexIO data
new FlexIO data
new FlexIO data
LP#=926826841	Pri#=22259	last Pri=976828735	ms=18349	ipCyc%=11.68
[B]HM01B0 Camera Test
HM01B0_FLEXIO_CUSTOM_LIKE_8_BIT
[/B]------------------
SENSOR DETECTED :-) MODEL HM01B0
OSC_CLK_DIV: 0x2A
ImageSize (w,h): 324, 244
START Fill Cache :: 3221
END Fill Cache :: 	Last is 82813	 @ 3268

Then a run again : 't', 'F'
Code:
[B]Return Address: 0x2025BE00[/B]
Faulted from exception.
	(IACCVIOL) Instruction Access Violation
Custom - Flexio is 8 bit mode
8Bit FlexIO
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 :: 13333
END Fill Cache :: 	Last is 82813	 @ 13380

Then the next:
Code:
Hardfault.
[B]Return Address: 0x46484D4A[/B]
Faulted from exception.
...
[B]// And these[/B]
Return Address: 0x4545433E
Return Address: 0x494C4744
Return Address: 0x42404044
Return Address: 0x76787674
...
	(IACCVIOL) Instruction Access Violation
 
Add to p#674.

Ex_2 w/"tF" : Also faults with :: isrPrime_it.priority(129);

That #129 should be one level below and #128 should get processed?

<edit> and this runs okay :: isrPrime_it.priority(144);
 
Back
Top