MicroMod Beta Testing

@defragster - incorporated the the PR this morning over coffee :) Very cool that it seems to all be working.


@KurtE - made a change to the stopReadDMA - saw on stop it had GPR27 for TMM and GPR26 for T4's but in the startReadDMA didn't have the #ifdef so I added this:
Code: 
#if defined (ARDUINO_TEENSY_MICROMOD)
  // Need to switch the IO pins back to GPI1 from GPIO6
  _save_IOMUXC_GPR_GPR27 = IOMUXC_GPR_GPR27;  // save away the configuration before we change...
  IOMUXC_GPR_GPR27 &= ~(0x0ff0u);

  // lets also un map the _hrefPin to GPIO1
  IOMUXC_GPR_GPR27 &= ~_hrefMask; //
#else
  // Need to switch the IO pins back to GPI1 from GPIO6
  _save_IOMUXC_GPR_GPR26 = IOMUXC_GPR_GPR26;  // save away the configuration before we change...
  IOMUXC_GPR_GPR26 &= ~(0x0ff0u);

  // lets also un map the _hrefPin to GPIO1
  IOMUXC_GPR_GPR26 &= ~_hrefMask; //
#endif

  // Need to switch the IO pins back to GPI1 from GPIO6
  //_save_IOMUXC_GPR_GPR27 = IOMUXC_GPR_GPR27;  // save away the configuration before we change...
  //IOMUXC_GPR_GPR27 &= ~(0x0ff0u);

  // lets also un map the _hrefPin to GPIO1
  //IOMUXC_GPR_GPR27 &= ~_hrefMask; //
Not sure its right.
 
Last edited:
Morning all,

mjs513 said:
Good very early morning all

Well FlexIO4bit is actually working. Got up and turned the TMM on and voila image was perfect for FlexIO4bit. Haven't seen it in such a long time I forgot. But if you get an image like shown in previous post on the screen turn the TMM off. Let sit for a few minutes unpowered and turn back on. 90% of the time that cures the image problem.

Has nothing to do with nibble swap or any other change except form TIMCMP=15 for 4bit mode. BTW seems SHIFTNSBUFx was talked about before: https://forum.pjrc.com/threads/62362-VGA-out-for-Teensy-4-0-4-1.

I just pushed a minor change to the lib to take into the different setting for TIMCMP. That just leaves DMA4bit mode :)

Not sure what we need to do for the other suggested modes:
Code: 
HM01B0_SPARKFUN_ML_CARRIER = 0,
	HM01B0_TEENSY_41_GPIO_8BIT,
	HM01B0_TEENSY_40_FLEXIO_1BIT,
	HM01B0_TEENSY_41_FLEXIO_4BIT,
Guess for T4 and T41 have the option to set different pins but that starts getting complicated - argh :(
Click to expand...
Actually all of these boards can and maybe should have options ;) :D

Except maybe the camera on the MicroMod machine learning:

For example for MicroMod just on FlexIO2 it has FlexIO pins 0-12 and 16 and 17,
So even for 8 bit flexIO, your only requirement of which pins, is that your D0-D7 are 8 consecutive... The other signals can be on any free ones.

I believe for 4 bit, we need 6 FlexIO... So again even more options ;)
T4 FlexIO1 (NO only 5 pins), FlexIO2 (yes 0-3 for data, and 2 of 10-12,16,17) FlexIO 3 maybe have pins NO DMA

Teensy 4.1 more options on all 3 FlexIO objects.

MicroMod - Like T4 plus more options on FlexIO2...

As for GPIO... The sky is the limit ;)

For T4.1, .. There is also CSI, but those are mostly fixed: the main data pins D2-D9 are fixed, likewise MCLK, and HSYNC. But you have 2 options for both
PIXCLK and VSYNC
 
mjs513 said:
@defragster - incorporated the the PR this morning over coffee :) Very cool that it seems to all be working.


@KurtE - made a change to the stopReadDMA - saw on stop it had GPR27 for TMM and GPR26 for T4's but in the startReadDMA didn't have the #ifdef so I added this:
Code: 
#if defined (ARDUINO_TEENSY_MICROMOD)
  // Need to switch the IO pins back to GPI1 from GPIO6
  _save_IOMUXC_GPR_GPR27 = IOMUXC_GPR_GPR27;  // save away the configuration before we change...
  IOMUXC_GPR_GPR27 &= ~(0x0ff0u);

  // lets also un map the _hrefPin to GPIO1
  IOMUXC_GPR_GPR27 &= ~_hrefMask; //
#else
  // Need to switch the IO pins back to GPI1 from GPIO6
  _save_IOMUXC_GPR_GPR26 = IOMUXC_GPR_GPR26;  // save away the configuration before we change...
  IOMUXC_GPR_GPR26 &= ~(0x0ff0u);

  // lets also un map the _hrefPin to GPIO1
  IOMUXC_GPR_GPR26 &= ~_hrefMask; //
#endif

  // Need to switch the IO pins back to GPI1 from GPIO6
  //_save_IOMUXC_GPR_GPR27 = IOMUXC_GPR_GPR27;  // save away the configuration before we change...
  //IOMUXC_GPR_GPR27 &= ~(0x0ff0u);

  // lets also un map the _hrefPin to GPIO1
  //IOMUXC_GPR_GPR27 &= ~_hrefMask; //
Not sure its right.
Click to expand...

Yep - should probably be as you mentioned, I missed it... Surprised it would build without the change as the variable names changed.
 
KurtE said:
Yep - should probably be as you mentioned, I missed it... Surprised it would build without the change as the variable names changed.
Click to expand...

Only picked it up because I compiled for T4.0 instead of TMM. Otherwise it compiles fine.
 
KurtE said:
Morning all,


Actually all of these boards can and maybe should have options ;) :D

Except maybe the camera on the MicroMod machine learning:

For example for MicroMod just on FlexIO2 it has FlexIO pins 0-12 and 16 and 17,
So even for 8 bit flexIO, your only requirement of which pins, is that your D0-D7 are 8 consecutive... The other signals can be on any free ones.

I believe for 4 bit, we need 6 FlexIO... So again even more options ;)
T4 FlexIO1 (NO only 5 pins), FlexIO2 (yes 0-3 for data, and 2 of 10-12,16,17) FlexIO 3 maybe have pins NO DMA

Teensy 4.1 more options on all 3 FlexIO objects.

MicroMod - Like T4 plus more options on FlexIO2...

As for GPIO... The sky is the limit ;)

For T4.1, .. There is also CSI, but those are mostly fixed: the main data pins D2-D9 are fixed, likewise MCLK, and HSYNC. But you have 2 options for both
PIXCLK and VSYNC
Click to expand...

Yeah but here's the 64 dollar question. Do we want to have that many options available for the HM01B0 camera..... Understand for the OVs but.....
 
Ok here we go with some more technical questions on FlexIO. I moved the camera over to the 4 pin camera connector on the breakout board and changed pins to:
Code: 
		VSYNC_PIN = 32;		//33
		PCLK_PIN = 44;		//8
		HSYNC_PIN = 45;		//32
		MCLK_PIN = 33;		//7
		EN_PIN = 28;		//2
		G0 = 40; G1 = 41;  G2 = 42;	G3 = 43;
Confirmed they are good using GPIO4Bit mode.
Now trying to convert to the new pins for FlexIO:
1st have to change a couple of things with the IOMUX settings:
Code: 
		[COLOR="#FF0000"]IOMUXC_SW_MUX_CTL_PAD_GPIO_B0_08 = 4; // B0_08 = FlexIO2:8 = PCLK (44)[/COLOR]
		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
		[COLOR="#FF0000"]IOMUXC_SW_MUX_CTL_PAD_GPIO_B0_09 = 4; // B0_09 = FlexIO2:9 = HSYNC (45)[/COLOR]
Then found have to change TIMCTL:
Code: 
	// TIMCTL, page 2933
	//  TRGSEL: Trigger Select ....
	//          4*N - Pin 2*N input
	//          4*N+1 - Shifter N status flag
	//          4*N+2 - Pin 2*N+1 input
	//          4*N+3 - Timer N trigger output
	//  TRGPOL: 0 = active high, 1 = active low
	//  TRGSRC: 0 = external, 1 = internal
	//  PINCFG: timer pin, 0 = disable, 1 = open drain, 2 = bidir, 3 = output
	//  PINSEL: which pin is used by the Timer input or output
	//  PINPOL: 0 = active high, 1 = active low
	//  TIMOD: mode, 0 = disable, 1 = 8 bit baud rate, 2 = 8 bit PWM, 3 = 16 bit
	FLEXIO2_TIMCTL2 = FLEXIO_TIMCTL_TIMOD(3)
[COLOR="#FF0000"]		| FLEXIO_TIMCTL_PINSEL(8) // "Pin" is 16 = PCLK (original was D16, new is D08
[/COLOR]		| [COLOR="#FF0000"]FLEXIO_TIMCTL_TRGSEL(4 * (12/2)) // "Trigger" is 12 = HSYNC[/COLOR]
		| FLEXIO_TIMCTL_TRGSRC;
Now I am stuck on TRGSel. Understand the 4 but not the 12/2? compared to the definition?

EDIT: for the heck of it I changed TRGSRC to 9/2 and it worked but don't know why
 
Last edited:
mjs513 said:
Yeah but here's the 64 dollar question. Do we want to have that many options available for the HM01B0 camera..... Understand for the OVs but.....
Click to expand...

Hopefully later today I will play with a version that maybe has a constructor, that looks something like:
Code: 
    HM01B0(int8_t vsync, int8_t hsync, int8_t  mclk, int8_t pckl,  TwoWire &wire=Wire, 
        int8_t d0, nt8_t d1,int8_t d2,nt8_t d3, int8_t d4=-1, int8_t d5=-1,nt8_t d6=-1,int8_t d7=-1);
Where you can define the whole setup and have it configure all of the pieces for you... Assuming this works,
then the other constructor can simply map to this :D

No promises!
 
KurtE said:
Hopefully later today I will play with a version that maybe has a constructor, that looks something like:
Code: 
    HM01B0(int8_t vsync, int8_t hsync, int8_t  mclk, int8_t pckl,  TwoWire &wire=Wire, 
        int8_t d0, nt8_t d1,int8_t d2,nt8_t d3, int8_t d4=-1, int8_t d5=-1,nt8_t d6=-1,int8_t d7=-1);
Where you can define the whole setup and have it configure all of the pieces for you... Assuming this works,
then the other constructor can simply map to this :D

No promises!
Click to expand...
Yeah - I saw that in the OV7670 CSI sketch and was thinking about it but kept looking at other things :)
 
Ok just pushed the updated lib to 4bit Modes (GPIO and FLEXIO) on the 4bit camera connector only.

@Paul - not sure if you want to support it both ways on the 4bit and 8bit connectors :)
 
I just pushed up a new branch based off the rewire, that added the constructor I mentioned (with edits)...

Now to start playing through this, to see how hard to get the FlexIO to be able to use it :D
 
Good progress!

Best T_4.1 hookup? :: another HiMax on the AMZN cable to pins adapter. So that could be setup on a T_4.1 - like the PJRC Tri-Sockets memory breakout board. Then an ST7789 or ili9341 wired up.

Offline a bit ...
 
PaulStoffregen said:
I'm not sure either.

With FlexIO, is there ever a reason to use all 8 bits?
Click to expand...

I don't see a reason too. I am setting up some changes for at least now to support both boards for at least testing..
Code: 
#define _hmConfig 4 // select mode string below
#define _hmCarrier 0 

PROGMEM const char hmCarrier[][48] = {
 "HM01B0_SPARKFUN_ML_CARRIER",
 "HM01B0_PJRC_CARRIER_4BIT",
 "HM01B0_PJRC_CARRIER_8BIT"};
PROGMEM const char hmConfig[][48] = {
 "HM01B0_TEENSY_MICROMOD_GPIO_8BIT",
 "HM01B0_TEENSY_MICROMOD_FLEXIO_8BIT",
 "HM01B0_TEENSY_MICROMOD_DMA_8BIT",
 "HM01B0_TEENSY_MICROMOD_GPIO_4BIT",
 "HM01B0_TEENSY_MICROMOD_FLEXIO_4BIT"};
 

HM01B0 hm01b0(HM01B0_PJRC_CARRIER_4BIT, HM01B0_TEENSY_MICROMOD_FLEXIO_4BIT);
So far everything works except
Code: 
HM01B0 hm01b0(HM01B0_PJRC_CARRIER_4BIT, HM01B0_TEENSY_MICROMOD_FLEXIO_4BIT);
Trying to trace it now but not having any luck - so not sure what I did since I thought I had it working - Argh....
 
PaulStoffregen said:
I'm not sure either.

With FlexIO, is there ever a reason to use all 8 bits?
Click to expand...

Given the fewer pins used and allowing sound and other uses on those pins - given the clock rate doubles the read rate is unchanged - some hopefully minor overhead incurred grabbing 2x4bits and to de-nibblize.
 
defragster said:
Given the fewer pins used and allowing sound and other uses on those pins - given the clock rate doubles the read rate is unchanged - some hopefully minor overhead incurred grabbing 2x4bits and to de-nibblize.
Click to expand...

However if we are going to extend this to apply to other cameras we may want to have the option for 8 bits as I know that at least some of them use 8
 
KurtE said:
However if we are going to extend this to apply to other cameras we may want to have the option for 8 bits as I know that at least some of them use 8
Click to expand...

Indeed - meant to add that note - the other color cam was noted as not yet seeing it had a 4 bit mode - or on others suitable cameras. But you guys make it 'seem' like given the pins it is trivial to change it 4<>8 :).
 
KurtE said:
However if we are going to extend this to apply to other cameras we may want to have the option for 8 bits as I know that at least some of them use 8
Click to expand...

Reading over this - I am rambling about my thoughts (yes they are all over the place) :) Guess just throwing it out there and see what .. resonates.

Kind of looking at from the point of view that for this camera (sensor) what what's the support requirement:
1. For Micromod carrier board maybe just use 4-bit GPIO/4 bit FlexIO with their defines for pins. Kind of torn to just leave 8-bit for ML carrier and the adjust for item 2. Reason the ML only breaks out a subset of pins of what available.
2. For other MM carrier boards what is the configuration and where are the pins routed - if there is another carrier board that just has the pins as selected by Paul for his breakout board then we have to deal with that config - again would just say 4bit GPIO and/or 4bit FLEXIO, at least for the TMM's. Say a board like the ATP but with a camera attachment and a display connector (basically Paul's breakout board).
3. Now if we extend it other sensors I would think they would have their own set of API's for either GPIO/FLEXIO/CSI etc. Not sure you really want to a generic API to have several options accessing the the sensor - think it would get more confusing on which to select unless you are experimenter/tinkerer/etc.
4. Think the option/options selected would depend on the sensor/MCU combo but It could be done from a common setup like with did for the ST7735/ST7789 displays.

Right now looking at what we are doing as a pathfinder where that we can export to other sensors.

Question - is CSI the best approach for the OV7670 or would FlexIO be better - I don't know but just curious since I really only have an inkling on how the both work as you can see by questions :)

I am going to push something up that I was working on to support multiple carriers and multiple configs - getting crazy but not too crazy yet. Implemented with my warped coding practice.
 
Ok just pushed what I was working on to a new branch: https://github.com/mjs513/TMM-HB01B0-Camera/tree/API-Rework+Carrier-board-selection

basically you select the carrier board and the method in the constructor. Not sure this is the best way but was an experiment.
Code: 
#define _hmConfig 4 // select mode string below
#define _hmCarrier 1 

PROGMEM const char hmCarrier[][48] = {
 "HM01B0_SPARKFUN_ML_CARRIER",
 "HM01B0_PJRC_CARRIER_4BIT",
 "HM01B0_PJRC_CARRIER_8BIT"};
PROGMEM const char hmConfig[][48] = {
 "HM01B0_TEENSY_MICROMOD_GPIO_8BIT",
 "HM01B0_TEENSY_MICROMOD_FLEXIO_8BIT",
 "HM01B0_TEENSY_MICROMOD_DMA_8BIT",
 "HM01B0_TEENSY_MICROMOD_GPIO_4BIT",
 "HM01B0_TEENSY_MICROMOD_FLEXIO_4BIT"};
 
HM01B0 hm01b0(HM01B0_PJRC_CARRIER_4BIT, HM01B0_TEENSY_MICROMOD_GPIO_4BIT);
BTW option combo selected is the only option that is not working and can't figure out what I did. Could be something with pin conflict that I didn't spot or something I mentioned in an earlier post about the pin config for flexio. But HM01B0_TEENSY_MICROMOD_GPIO_4BIT works with HM01B0_PJRC_CARRIER_4BIT.

Not sure this is the best approach but its an approach.
 
Stuck again. Not seeing any data using the case of 4Bit Breakout + 4Bit Flex. Data is all zero's. Still not sure this is 100% correct:
Code: 
	if( _hw_carrier == HM01B0_PJRC_CARRIER_4BIT && _hw_config == HM01B0_TEENSY_MICROMOD_FLEXIO_4BIT) {
		Serial.println("Setting config for 4x4 configuration");
		IOMUXC_SW_MUX_CTL_PAD_GPIO_B0_08 = 4; // B0_08 = FlexIO2:8 = PCLK (44)
		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_09 = 4; // B0_09 = FlexIO2:9 = HSYNC (45)
		
		
		// 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(3);
		
		// Timer model, pages 2891-2893
		// TIMCMP, page 2937
		FLEXIO2_TIMCMP2 = 15;
		
		// TIMCTL, page 2933
		//  TRGSEL: Trigger Select ....
		//          4*N - Pin 2*N input
		//          4*N+1 - Shifter N status flag
		//          4*N+2 - Pin 2*N+1 input
		//          4*N+3 - Timer N trigger output
		//  TRGPOL: 0 = active high, 1 = active low
		//  TRGSRC: 0 = external, 1 = internal
		//  PINCFG: timer pin, 0 = disable, 1 = open drain, 2 = bidir, 3 = output
		//  PINSEL: which pin is used by the Timer input or output
		//  PINPOL: 0 = active high, 1 = active low
		//  TIMOD: mode, 0 = disable, 1 = 8 bit baud rate, 2 = 8 bit PWM, 3 = 16 bit
		FLEXIO2_TIMCTL2 = FLEXIO_TIMCTL_TIMOD(3)
			| FLEXIO_TIMCTL_PINSEL(8) // "Pin" is D08= PCLK
			| FLEXIO_TIMCTL_TRGSEL(4 * (9/2)) // "Trigger" is D09= HSYNC
			| FLEXIO_TIMCTL_TRGSRC;

	}
or if there is something else that needs to change for this case. As I mentioned 4bit breakout + 4bit GPIO is working.

EDIT: Think going to have to hook up an LA tomorrow. UPDATE: OK couldn't wait:
Capture.jpg zoomed in
Capture1.jpg so it looks like the pin configs are correct and I am seeing data (NOTE: have to figure out standby mode.) But readframeflexIO is returning zeros for the buffer which makes me think the trigger isn't correct.

EDIT: think I sorted out the trigsel:
Code: 
		//  TRGSEL: Trigger Select ....
		//          4*N - Pin 2*N input (this one is used)
for pins its 2*9 for the vsynch - the 4*(9/2) didn't register until now. Still no data but at least got it sorted out - I think. Forgot triggersrc should be 0 as well - Hope I read the RM right.
 
Last edited:
Evening all: I will take a look tomorrow as well. Hopefully by then will have breakout board.

Been spending time trying to build in part of the constructor and Flex IO Config method that take more arbitrary pins and the like:

I pushed up a new configure function: bool HM01B0::flexio_configure_manual_settings()
In my branch. There are still some things I need to understand like:

I believe that we can use Shifter 3 and maybe Shifter 7? So I have:
// Needs Shifter 3 (maybe 7 would work as well?)
Code: 
    uint8_t fshifter = 3;
    if (!pflex->claimShifter(3)) {
        Serial.println("HM01B0 Flex IO: Could not claim Shifter 3");
        return false;
    }
Once this is working I may try 7 as well... Although I don't think Shifter 7 has DMA?

Note: The FlexIO structure in imxrt.h for 8 timers and shifters instead of assumed 4...

I also still have hard coded Shifter 2 as well, but not sure if that is necessary or not?
Code: 
    // Now lets try to claim all of the pieces
    // Special Timer needed? first pass lets assume Timer 2:
    uint8_t ftimer = 2;
    if (!pflex->claimTimer(2)) {
        Serial.println("HM01B0 Flex IO: Could not claim Timer 2");
        return false;
    }
Again if this works, may try switching to asking for a Timer...
For the fun of it I may have uint8_t ftimer = pflex->requestTimers();

More to work through!
 
Besides the update in my previous post just noticed that DMA is timing out:
Code: 
HM01B0_TEENSY_MICROMOD_FLEXIO_4BIT
------------------
PJRC_CARRIER_4BIT
4pins initialized
FlexIO Configure
 CCM_CSCMR2 = 13192F06
 div1 = 2, div2 = 2
 FlexIO2 Frequency = 120.00 MHz
 CCM_CCGR3 = F00FF303
 FLEXIO2_CTRL = 00000000
 FlexIO2 Config, param=02200808
Setting config for 4x4 configuration
 FLEXIO2_SHIFTCFG3 = 00030000
 FLEXIO2_SHIFTCTL3 = 02000401
 FLEXIO2_TIMCMP2 = 0000000F
 FLEXIO2_TIMCFG2 = 01206600
 FLEXIO2_TIMCTL2 = 0C400803
SENSOR DETECTED :-) MODEL HM01B0
OSC_CLK_DIV: 0x29
ImageSize (w,h): 324, 244
Send the 'f' character to read a frame using FlexIO (changes hardware setup!)

Reading frame
[COLOR="#FF0000"]Reading FlexIO frame.......................................
Timeout waiting for DMA[/COLOR]
 DMA channel #0
 DMAMUX = 80000041
 FLEXIO2_SHIFTSDEN = 08
 TCD CITER = 19764
 TCD CSR = 00000008
Ok now back for some more zzz's
 
Ok - 4x4 mode works now... think I had put in standby mode by accident ? but it started working - weird.
 
KurtE said:
Evening all: I will take a look tomorrow as well. Hopefully by then will have breakout board.

Been spending time trying to build in part of the constructor and Flex IO Config method that take more arbitrary pins and the like:

I pushed up a new configure function: bool HM01B0::flexio_configure_manual_settings()
In my branch. There are still some things I need to understand like:

I believe that we can use Shifter 3 and maybe Shifter 7? So I have:
// Needs Shifter 3 (maybe 7 would work as well?)
Code: 
    uint8_t fshifter = 3;
    if (!pflex->claimShifter(3)) {
        Serial.println("HM01B0 Flex IO: Could not claim Shifter 3");
        return false;
    }
Once this is working I may try 7 as well... Although I don't think Shifter 7 has DMA?

Note: The FlexIO structure in imxrt.h for 8 timers and shifters instead of assumed 4...

I also still have hard coded Shifter 2 as well, but not sure if that is necessary or not?
Code: 
    // Now lets try to claim all of the pieces
    // Special Timer needed? first pass lets assume Timer 2:
    uint8_t ftimer = 2;
    if (!pflex->claimTimer(2)) {
        Serial.println("HM01B0 Flex IO: Could not claim Timer 2");
        return false;
    }
Again if this works, may try switching to asking for a Timer...
For the fun of it I may have uint8_t ftimer = pflex->requestTimers();

More to work through!
Click to expand...

Morning @KurtE
Was looking at what you have so far in your branch and its looking good :)
 
Hope your Z's are doing good!

I am just starting the coffee infusion :D

Timeout: will try to take a look later. In the mean time you might try adding calls in to fully dump the DMA structure, like I do in the DMA code:
Code: 
#ifdef DEBUG_CAMERA
  dumpDMA_TCD(&_dmachannel);
  dumpDMA_TCD(&_dmasettings[0]);
  dumpDMA_TCD(&_dmasettings[1]);
  Serial.printf("pclk pin: %d config:%lx control:%lx\n", PCLK_PIN, *(portConfigRegister(PCLK_PIN)), *(portControlRegister(PCLK_PIN)));
  Serial.printf("IOMUXC_GPR_GPR26-29:%lx %lx %lx %lx\n", IOMUXC_GPR_GPR26, IOMUXC_GPR_GPR27, IOMUXC_GPR_GPR28, IOMUXC_GPR_GPR29);
  Serial.printf("GPIO1: %lx %lx, GPIO6: %lx %lx\n", GPIO1_DR, GPIO1_PSR, GPIO6_DR, GPIO6_PSR);
  Serial.printf("XBAR CTRL0:%x CTRL1:%x\n\n", XBARA1_CTRL0, XBARA1_CTRL1);
#endif
Note at some point if this will be a released library we should probably cleanup some. If for example we are not going to support multiple ways of reading a frame in one class at the same run, we should for example setup to only have one copy of DMAChannel... Right now we have _dmachannel and dma_flexIO ...

Starting to look at putting in more of the pieces now for allowing the FlexIO to be configured to available pins. Hopefully later today will be able to tell it long hand to use the default 8 pin camera connection and see if it works... Likewise for 4 pin.
 
Morning @KurtE
Had 1 cup so far but have to go out to do some errands.

As for the timeout - no longer there. Not sure what happened - I know I removed putting it standby but seems to be working now with an issue. Just pushed what I had up.

Note at some point if this will be a released library we should probably cleanup some. If for example we are not going to support multiple ways of reading a frame in one class at the same run, we should for example setup to only have one copy of DMAChannel... Right now we have _dmachannel and dma_flexIO ...
Click to expand...
yeah as well as readGPIO etc. but maybe wait until you have your stuff done.

Think maybe since FlexIO is using DMA as well that we hold off and delete it all and go with your version of FlexIO support it would provide flexibility to support the carrier boards and T4's where we could put the camera on a different pins.

Was thinking could have 2 constructors: (1) for user controlled pins and (2) to select the carrier board which would then set the pin configures - maybe? Make any sense.
 
You must log in or register to reply here.
Back
Top