MicroMod Beta Testing

@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
 
Good Morning all
Started work on mods to the lib. Created the following in the lib:
Code:
typedef enum {
	HM01B0_SPARKFUN_ML_CARRIER = 0,
	HM01B0_TEENSY_MICROMOD_GPIO_8BIT,
	HM01B0_TEENSY_MICROMOD_FLEXIO_8BIT,
	HM01B0_TEENSY_MICROMOD_FLEXIO_4BIT,
	HM01B0_TEENSY_MICROMOD_DMA_8BIT,
	HM01B0_TEENSY_41_GPIO_8BIT,
	HM01B0_TEENSY_40_FLEXIO_1BIT,
	HM01B0_TEENSY_41_FLEXIO_4BIT,
	HM01B0_TEENSY_41_CSI_8BIT,
} hw_config_t;
Not 100% sure why we need HM01B0_SPARKFUN_ML_CARRIER but its there.

Only modified example1 (FLEXIO) sketch but guess I decided to do it from the constructor:
Code:
HM01B0 hm01b0(HM01B0_TEENSY_MICROMOD_FLEXIO_8BIT);

Then in init I do something like this:
Code:
	if(_hw_config == HM01B0_SPARKFUN_ML_CARRIER || _hw_config == HM01B0_TEENSY_MICROMOD_GPIO_8BIT || _hw_config == HM01B0_TEENSY_MICROMOD_FLEXIO_8BIT) {
		VSYNC_PIN = 33;
		PCLK_PIN = 8;
		HSYNC_PIN = 32;
		MCLK_PIN = 7;
		EN_PIN = 2;
		G0 = 40; G1 = 41;  G2 = 42;	G3 = 43;
		G4 = 44; G5 = 45;  G6 = 6;
		G7 = 9;
	}

....
	if(_hw_config == HM01B0_TEENSY_MICROMOD_FLEXIO_8BIT ||  _hw_config == HM01B0_TEENSY_MICROMOD_FLEXIO_4BIT ) {
		flexio_configure();
	}
Note - just noticed - still have to adjust pin setups :)

then in flexio_configure:
Code:
	if(_hw_config == HM01B0_TEENSY_MICROMOD_FLEXIO_8BIT) {
		IOMUXC_SW_MUX_CTL_PAD_GPIO_B1_00 = 4; // B1_00 = FlexIO2:16 = PCLK
		IOMUXC_SW_MUX_CTL_PAD_GPIO_B0_04 = 4; // B0_04 = FlexIO2:4  = D0
		IOMUXC_SW_MUX_CTL_PAD_GPIO_B0_05 = 4; // B0_05 = FlexIO2:5  = D1
		IOMUXC_SW_MUX_CTL_PAD_GPIO_B0_06 = 4; // B0_06 = FlexIO2:6  = D2
		IOMUXC_SW_MUX_CTL_PAD_GPIO_B0_07 = 4; // B0_07 = FlexIO2:7  = D3
		IOMUXC_SW_MUX_CTL_PAD_GPIO_B0_08 = 4; // B0_08 = FlexIO2:8  = D4
		IOMUXC_SW_MUX_CTL_PAD_GPIO_B0_09 = 4; // B0_09 = FlexIO2:9  = D5
		IOMUXC_SW_MUX_CTL_PAD_GPIO_B0_10 = 4; // B0_10 = FlexIO2:10 = D6
		IOMUXC_SW_MUX_CTL_PAD_GPIO_B0_11 = 4; // B0_11 = FlexIO2:11 = D7
		IOMUXC_SW_MUX_CTL_PAD_GPIO_B0_12 = 4; // B0_12 = FlexIO2:12 = HSYNC

		// SHIFTCFG, page 2927
		//  PWIDTH: number of bits to be shifted on each Shift clock
		//          0 = 1 bit, 1-3 = 4 bit, 4-7 = 8 bit, 8-15 = 16 bit, 16-31 = 32 bit
		//  INSRC: Input Source, 0 = pin, 1 = Shifter N+1 Output
		//  SSTOP: Stop bit, 0 = disabled, 1 = match, 2 = use zero, 3 = use one
		//  SSTART: Start bit, 0 = disabled, 1 = disabled, 2 = use zero, 3 = use one
		FLEXIO2_SHIFTCFG3 = FLEXIO_SHIFTCFG_PWIDTH(7);

		// SHIFTCTL, page 2926
		//  TIMSEL: which Timer is used for controlling the logic/shift register
		//  TIMPOL: 0 = shift of positive edge, 1 = shift on negative edge
		//  PINCFG: 0 = output disabled, 1 = open drain, 2 = bidir, 3 = output
		//  PINSEL: which pin is used by the Shifter input or output
		//  PINPOL: 0 = active high, 1 = active low
		//  SMOD: 0 = disable, 1 = receive, 2 = transmit, 4 = match store,
		//        5 = match continuous, 6 = state machine, 7 = logic
		FLEXIO2_SHIFTCTL3 = FLEXIO_SHIFTCTL_TIMSEL(2) | FLEXIO_SHIFTCTL_SMOD(1)
			| FLEXIO_SHIFTCTL_PINSEL(4); // 4 = D0
	}

Also created 1 function for readFrame:
Code:
void HM01B0::readFrame(void* buffer, void* buffer2){
	set_mode(HIMAX_MODE_STREAMING_NFRAMES, 1);
	
	if(_hw_config == HM01B0_TEENSY_MICROMOD_GPIO_8BIT) readFrameGPIO(buffer);
	if(_hw_config == HM01B0_TEENSY_MICROMOD_FLEXIO_8BIT) readFrameFlexIO(buffer);
	
}
Now for the question - see next post....
 
Now for instance. For DMA I see that the function:
Code:
startReadFrameDMA(bool(*callback)(void *frame_buffer), uint8_t *fb1, uint8_t *fb2)
does setup framebuffers if fb1 and fb2 are not specified. So that leaves how to handle the callback for the frameBuffer.

So question is how to just have the function or say readFrame(void *Buffer) which would call startReadFrame just return the Buffer.

NOTE: Still need a lot more coffee.
 
Good morning all,

Sorry I have not given this enough thought and hard looking through the code to give a good answer about some of my wondering about API/Library setup for generic stuff, is how is it all configured?
How flexible is it?

In this post I will mainly discuss FlexIO.

Currently for The MicroMod 8 bit mode we are using:
Code:
	IOMUXC_SW_MUX_CTL_PAD_GPIO_B1_00 = 4; // B1_00 = FlexIO2:16 = PCLK
	IOMUXC_SW_MUX_CTL_PAD_GPIO_B0_04 = 4; // B0_04 = FlexIO2:4  = D0
	IOMUXC_SW_MUX_CTL_PAD_GPIO_B0_05 = 4; // B0_05 = FlexIO2:5  = D1
	IOMUXC_SW_MUX_CTL_PAD_GPIO_B0_06 = 4; // B0_06 = FlexIO2:6  = D2
	IOMUXC_SW_MUX_CTL_PAD_GPIO_B0_07 = 4; // B0_07 = FlexIO2:7  = D3
	IOMUXC_SW_MUX_CTL_PAD_GPIO_B0_08 = 4; // B0_08 = FlexIO2:8  = D4
	IOMUXC_SW_MUX_CTL_PAD_GPIO_B0_09 = 4; // B0_09 = FlexIO2:9  = D5
	IOMUXC_SW_MUX_CTL_PAD_GPIO_B0_10 = 4; // B0_10 = FlexIO2:10 = D6
	IOMUXC_SW_MUX_CTL_PAD_GPIO_B0_11 = 4; // B0_11 = FlexIO2:11 = D7
	IOMUXC_SW_MUX_CTL_PAD_GPIO_B0_12 = 4; // B0_12 = FlexIO2:12 = HSYNC
So it is using 10 FlexIO2 pins. This will only work on MicroMod:

Sort of extracted from my FlexIO library Readme the 3 t4.x have FlexIO ranges of:
Code:
T4:  
    Ranges: 4-8
    Ranges: 0-3, 10-12, 16-17
    Ranges: 0-3,6-11,14-17

T4.1:
    Ranges: 4-8,12-15
    Ranges 0-3, 10-12, 16-19, 28-29
    Ranges: 0-19, 28-29

MicroMod:
    Ranges: 4-8
    Ranges 0-12, 16-17
    Ranges: 0-3,6-11,14-17
Note: each line is one for FlexIO1, FlexIO2 and FlexIO3. If I remember correctly for 8 bit mode, the 8 data pins must be consecutive Flex IO pins.
So neither T4 nor T4.1 have 8 consecutive pins on FlexIO 1 nor FlexIO2.
T4.1 Does have 8 consecutive pins on FlexIO3... However FlexIO3 does not support DMA.

So questions come up, for example with MMod, I have 13 consecutive FlexIO pins, can I as an app user decide which range to use: currently that carrier is setup for 4-11?
Do we allow 8 bit mode on T4.1 without DMA?

For 4 bit mode, it looks like we have options on all three Teensy boards on all 3 FlexIO controllers. Do we allow this?
Obviously ditto for FlexIO in 1 bit mode...

@Paul - With the FlexIO stuff I was playing with earlier (FlexIO_T4) again I tried to table drive things, such that if you were going to switch Pin 7 into flexIO mode for FlexIO2 it knows to switch to:
mode 0x14, if however it want it for FlexIO3 it is 0x19... Side note, never has been been clear when we should or should not use the 0x10 bit when we set the mode....

Note: in my hacking of library you were mentioning that for example when I am doing FlexIO for a Serial object, I might simply ask for a Shifter( requestShifter) and it tries to find an unused one.
Other times you may have fixed ones you need to use, in this case I have method: claimShifter(shifter number0.
Dito for Timers.

Probably enough for one post.
 
@KurtE
Forgot about the table you have in the FlexIO library - was actually looking to create one - sort of.

Right now the way it looks is the DMA is used for both for DMA mode and FlexIO mode (works better). The pin configuration is hardcode for MicroMod8-bit only now when we do other configurations I was wondering similarly what pins we are going to be using as well for the T4 and T4.1. MM we know its going to have to be D0-D3 or G0-G3.

Going to 4-bit mode may be easier to configure for all boards as the common denominator.

A lot of good questions - at least giving us a chance to think about it now.
 
As a test I just pushed some more changes to the API_rework branch: https://github.com/mjs513/TMM-HB01B0-Camera/tree/API-Rework

I supports 3 cases for the Mircomod only:
Code:
/*
 *  HM01B0_TEENSY_MICROMOD_GPIO_8BIT,
 *  HM01B0_TEENSY_MICROMOD_FLEXIO_8BIT,
 *  HM01B0_TEENSY_MICROMOD_DMA_8BIT,
 */
HM01B0 hm01b0(HM01B0_TEENSY_MICROMOD_FLEXIO_8BIT);
Not 100% sure I like what I did.

Video in dma mode not working but I think there is a problem with the way I passed callback's back and forth....
 
Just a quick update. Been trying to figure it out most of the day. Found a couple errors but still no luck with video mode. So I bypassed my readframe's etc and used direct calls but no luck. Not sure if its something with my display or no not. Will try with a ILI9341 eventually.
 
That's no fun ... is github up to date - and the bypass example? I can get to try it here with ili9341 in a bit ...

... or ZIP your WIP and post here to avoid cluttering github ...

Just hit github - 11 minutes old ....
 
W/ili9341:

Says "F" - but using DMA? {if I saw that in the git DIFFS ?} - Single Frame good

the 'f' - took some time to get top bottom SYNC - Horizontal - then popped in and Horiz Stable but some verticle Jitter of a few pixels creeping side to side : though a decent movie otherwise.

Is that what you saw ? <edit> : "still no luck with video mode" not saying if you saw nothing or torn image?
 
Not sure which f or F I started with ? Meant 'F' but think I got 'f' ... Nope I was backwards "F" still continuous ...

Some more F and f and then :
Code:
startReadFrameDMA called buffers 20029e84 20238400
Hardfault.
Return Address: 0x75BA
Faulted from exception.
	(DACCVIOL) Data Access Violation
	(MMARVALID) Accessed Address: 0x18114E

Restarted and "F" is a continuous torn scroll for longer than before .... in Camera not Mirror mode

Timing is wrong - about third of the image is black when it should not be?

'f' single shot still working
 
Yep 'f' - single shot, 'F'-continuous (still not working if in DMA_8BIT mode but it does give you what you describe - what about 'V' ideo ? That's the one I am curious about.

NOTE: I haven't been getting any hardfaults - will have to retest - getting late for me here now.


EDIT: Forgot see post #531 to set up the different options that are currently available.
 
'f' single good, "F" iffy to bad

"V" - vid - Black screen ...

re p#531 - yes I saw that in sketch now

No VID going to "HM01B0_TEENSY_MICROMOD_FLEXIO_8BIT" - but "F" works at 10.23 Hz

And 'f' only in "HM01B0_TEENSY_MICROMOD_GPIO_8BIT"

ANd the input catches and indicates unsupported mode options nicely.
 
'f' single good, "F" iffy to bad

"V" - vid - Black screen ...

re p#531 - yes I saw that in sketch now

No VID going to "HM01B0_TEENSY_MICROMOD_FLEXIO_8BIT" - but "F" works at 10.23 Hz

And 'f' only in "HM01B0_TEENSY_MICROMOD_GPIO_8BIT"

ANd the input catches and indicates unsupported mode options nicely.

Thanks for checking - have to retest.

Yes 'f' only in GPIO-8bit for now - that's on the todo list to fix
Yep - VID only works in DMA mode as it did before but 'F' and 'f' works with FlexIO as before.

Have to try and figure out what I broke :)
 
Video CallBack needs to write to screen.

Picture is fully intact - but scrolling with each redraw

Some other minor edits - but my github wants to push direct to #mjs513 and cannot and I don't have option for PR as configured.

Code:
[ATTACH]24508._xfImport[/ATTACH]

Edit: Vid uses >> tft.updateScreenAsync(true);

so line #232 is not needed ??? :: // tft.updateScreenAsync();

With that change updates still display - and images still scrolling ...
 
Video CallBack needs to write to screen.

Picture is fully intact - but scrolling with each redraw

Some other minor edits - but my github wants to push direct to #mjs513 and cannot and I don't have option for PR as configured.

Code:
[ATTACH]24508[/ATTACH]

Edit: Vid uses >> tft.updateScreenAsync(true);

so line #232 is not needed ??? :: // tft.updateScreenAsync();

With that change updates still display - and images still scrolling ...

Thanks @defragster. Now that there is some life I think I may know what the problem may be.

EDIT: Nope what I thought may be wrong looks correct. But I did add my change to get GPIO 'F' working and pushed both sets of changes to the rework branch.
 
Last edited:
Morning all,

My Sparkfun package is at my PMB, which I will probalby pick up this morning. So may be able to more easily test on ATP board or other soon. But am also tempted to also try modifying for other camera. ;)
 
Morning all,

My Sparkfun package is at my PMB, which I will probalby pick up this morning. So may be able to more easily test on ATP board or other soon. But am also tempted to also try modifying for other camera. ;)

Morning @KurtE :)

Funny you should mention about CSI/OV7670 was just looking at that this morning. Great minds.

Anyway for now think I have gone about as far as I can go with mods - still don't know why "V" mode isn't working. @defragster got it to at least display.

EDIT: Forgot - my sparkfun package will arrive tomorrow and the other board on Thursday. My OV7670 without the adapter is still in transit from China :)
 
Good day! Glad I found the need to do the screen write in the callback - scanned the lib/src diffs and didn't see anything jumping out ... so went back to sketch and Voila ... callback getting called in good time but display blank ... maybe the display needs written now :cool:

Today will see: FedEx from SFun of two HiMax and USPS of new test board. Just found an OV7670 breakout on desk. Though have other tasks at hand that are due.

Have an ATP.MM here - also the AMZN 24pin Ribbon board ... and displays
 
Sorry, I've been preoccupied with business stuff for the last few days, so I haven't managed to keep up with this thread since the weekend. I'm also planning to work more on supporting encrypted firmware soon, which will also take my attention away to some degree.

But here's a couple really quick answers...


@Paul - With the FlexIO stuff I was playing with earlier (FlexIO_T4) again I tried to table drive things, such that if you were going to switch Pin 7 into flexIO mode for FlexIO2 it knows to switch to:
mode 0x14, if however it want it for FlexIO3 it is 0x19...

Yeah, it's unfortunate NXP couldn't keep all the FlexIO pin mux settings the same. I believe FlexIO3 was one of the features they added going from 1052 to 1062. My hunch is they probably had a big corporate customer who wanted to do something really fast on FlexIO which couldn't work with the lower clock speed, so for 1062 they tossed in another FlexIO on the faster bus and by that point no pins has ALT4 left over.


Side note, never has been been clear when we should or should not use the 0x10 bit when we set the mode....

You're talking about the force input path bit, right? I tried both ways and it didn't seem to be needed. No help I could find anywhere in NXP's documentation.


Going to 4-bit mode may be easier to configure for all boards as the common denominator.

My understanding is 4 bit mode offers everything 8 bits can, so when/if 4 bits is working keeping 8 bit support might be redundant.


Oh, also, it's perfectly fine to post photos of the new breakout board. Just cover or mask out the actual MicroMod board until Sparkfun puts photos on their public website.
 
Cool - Here's a pic of the bare breakout topside. Shows Qwiic's and SD socket. Evolved from post #349
PJRC_MModBreak.jpg

Noticed "T8" is repeated twice on silkscreen holes around the MMod unit - assume one is T9 { right of T5 or T4 }?
I see those noted in p#353 as:
That test board doesn't connect the video signals at all. They just route to those pads in the middle of the PCB. Only power and I2C are actually connected. All the Teensy 4.1 pins are also duplicated on another set of pads. The idea was to just solder or plug wires for experimenting with the video output signals.
 
Evening all.

Paul - not a problem. Didn't miss much except me playing with library to get a jump on reorganizing.

My understanding is 4 bit mode offers everything 8 bits can, so when/if 4 bits is working keeping 8 bit support might be redundant.
You are probably right about 8-bit being redundant but guess will see how 4-bit works compared to 8bit. Also - never worked with nibbles before should be interesting to see how that all works. Guess more to follow.

The board photo that @defragster posted looks really good by the way - mine should arrive tomorrow in the afternoon post. Camera's got here today.
 
Noticed "T8" is repeated twice on silkscreen holes around the MMod unit - assume one is T9

Opps. Indeed the pin between T5 & T2 is mislabeled. It is T9. The numbers match the test point numbers on Sparkfun's schematic.

If you want to get access to the 13 test points on the bottom of the MicroMod PCB, you will need Mill-Max part 0985-0-15-20-71-14-11-0, which you can buy at Digikey, part ED1122-ND. But these are quite difficult to solder, as the body of the pogo pin fits through the hole from the bottom side. Very careful soldering is needed to secure them in place without spilling extra solder into the pogo pin, and have it end up close enough to 90 degree angle from the PCB so it hits the tiny test point on the MicroMod bottom side.
 
My understanding is 4 bit mode offers everything 8 bits can, so when/if 4 bits is working keeping 8 bit support might be redundant.
It will be interesting, as I so far like the OV7670 cameras better than the ... And so far I don't see anything about them supporting a 4 bit mode. I am probably missing something.

I have also sort of been off doing some other stuff today.
 
Back
Top