MicroMod Beta Testing

@mjs513 - I started testing some of my changes to flexIO and nothing is working in either 8 bit or 4 bit mode :D
And I am not using my own random configuration code (yet).

I then switched branch back to rework and still neither works:
8 bit mode looks scrambled.
4 bit mode it is black... Looks like a change in the last couple of days on 4 bit mode where the pin numbers all changed?
Is this for the other test board? Still using Machine learning board.
 
Is this for the other test board? Still using Machine learning board.
Try using this branch: https://github.com/mjs513/TMM-HB01B0-Camera/tree/API-Rework+Carrier-board-selection

It allows you to select the carrier board and the method:
Code:
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);
If using the ML Carrier use:
Code:
HM01B0 hm01b0(HM01B0_SPARKFUN_ML_CARRIER, HM01B0_TEENSY_MICROMOD_FLEXIO_4BIT);
Change the method accordingly - for the ML all the 8 and 4bit modes should work - at least they did this morning when I tried them :)

Oh example1 has been updated to use that constructor if you want to play :)
 
Afternoon all,

I just pushed up some changes for the FlexIO to use my FlexIO library.

I modified several of the methods like read a frame with FlexIO to use the FlexIO hardware structure with things like which timer and shifter which I added to the class.

I am showing stuff on ILI... display although not correct yet.

But if you are interested, you might take a look... Note Using older constructor including one where I specify all the pins, like:
Code:
//    HM01B0(uint8_t mclk_pin, uint8_t pclk_pin, uint8_t vsync_pin, uint8_t hsync_pin, en_pin,
//    uint8_t g0, uint8_t g1,uint8_t g2, uint8_t g3,
//    uint8_t g4=0xff, uint8_t g5=0xff,uint8_t g6=0xff,uint8_t g7=0xff, TwoWire &wire=Wire);
HM01B0 hm01b0(7, 8, 33, 32, 2, 40, 41, 42, 43, 44, 45, 6, 9);
 
Afternoon @KurtE
Just downloaded and gave it a try on ML board.
1, In 8 bit mode I am getting a blank screen and the dreaded DMA Timeout error.
2. In the 4 bit mode getting the same thing but you forgot to add option 6 to config to QVGA4 bit:
Code:
  if(_hmConfig == 3 || _hmConfig == 4 [COLOR="#FF0000"]|| _hmConfig ==6[/COLOR]){
    status = hm01b0.set_framesize(FRAMESIZE_QVGA4BIT);
  } else {
    status = hm01b0.set_framesize(FRAMESIZE_QVGA);
  }

EDIT: Take back what I just said.
8bit mode working perfectly using 'f' and "F"
4bit mode 'f' is working with no problem but "F" just send 1 frame. With one change to the readContinuous function "F" works fine.
Code:
bool HM01B0::readContinuous(bool(*callback)(void *frame_buffer), void *fb1, void *fb2) {
	set_mode(HIMAX_MODE_STREAMING_NFRAMES, 1);

	if(_hw_config == HM01B0_TEENSY_MICROMOD_FLEXIO_8BIT  [COLOR="#FF0000"]|| _hw_config == HM01B0_TEENSY_MICROMOD_FLEXIO_4BIT[/COLOR]) {
		return startReadFlexIO(callback, fb1, fb2);
	} else if(_hw_config == HM01B0_TEENSY_MICROMOD_DMA_8BIT) {
		return startReadFrameDMA(callback, (uint8_t*) fb1, (uint8_t*)fb2);
	} else {
		return -1;
	}
}
Attaching the zip to avoid confusion of the changes I made to the sketch and the lib. One note it display looks wacky after 1st load turn it off and leave off awhile and turn back on - odds are it will work fine after that.
 

Attachments

  • TMM-HM01B0.zip
    39 KB · Views: 75
Last edited:
@KurtE
Decided to test on the 4pin PJRC breakout board with this config with the ILI9341 display
Code:
#elif _hmConfig ==4  //PJRC Breakout board
//HM01B0 hm01b0(HM01B0_TEENSY_MICROMOD_FLEXIO_4BIT);
// We are doing manual settings: 
// this one should duplicate the 8 bit ML Carrier:
//    HM01B0(uint8_t mclk_pin, uint8_t pclk_pin, uint8_t vsync_pin, uint8_t hsync_pin, en_pin,
//    uint8_t g0, uint8_t g1,uint8_t g2, uint8_t g3,
//    uint8_t g4=0xff, uint8_t g5=0xff,uint8_t g6=0xff,uint8_t g7=0xff, TwoWire &wire=Wire);
HM01B0 hm01b0(33, 8, 44, 32, 45, 40, 41, 42, 43);
Work fine with "F" and 'f'

UPDATE: works on the 8-pin FPC connector as well with the _hmConfig ==5 :)

Think tomorrow will solder up a audio shield and see if it works on the extra headers that we haven't played with yet :)
 
Last edited:
Sounds great - I just pushed up your changes to my branch :D

Next thing to try may be to simply the other constructor simply save away the right pins and the like. and then in flexIO case at least it all folds back to one flexIO Init...

@Paul and others - The main issue with this, is it is currently using my flexIO_t4 library to do some of this. Mainly for the knowing that the pins are connected to a flexIO object, and do the mapping of the pins to the FlexIO pins and keeping track of which FlexIO resources that have been used, such that other thing can allocate others...

Probably need to clean it up some!.

Also one of the next steps will be to try it out to see if for example it works on T4.1 on FlexIO 1, and T4 on FlexIO 1 or 2... And if we should also allow it to be configured to work in non DMA mode?

Also I am guessing we probably need or should setup the FlexIO structure in imxrt.h to actually match what I think it is versus the documents
That is we currently have:
Code:
typedef struct {
        const   uint32_t VERID;                         // 0x00 (IMXRT_FLEXIO1.offset000)
        volatile uint32_t PARAM;                        // 0x04 // (IMXRT_FLEXIO1.offset004)
        volatile uint32_t CTRL;                         // 0x08(IMXRT_FLEXIO1.offset008)
        volatile uint32_t PIN;                          // 0x0c (IMXRT_FLEXIO1.offset00C)
        volatile uint32_t SHIFTSTAT;            // 0x10 (IMXRT_FLEXIO1.offset010)
        volatile uint32_t SHIFTERR;                     // 0x14(IMXRT_FLEXIO1.offset014)
        volatile uint32_t TIMSTAT;                      // 0x18 (IMXRT_FLEXIO1.offset018)
        const   uint32_t UNUSED0;                       // 0x1c
        volatile uint32_t SHIFTSIEN;            // 0x20 (IMXRT_FLEXIO1.offset020)
        volatile uint32_t SHIFTEIEN;            // 0x24 (IMXRT_FLEXIO1.offset024)
        volatile uint32_t TIMIEN;                       // 0x28 (IMXRT_FLEXIO1.offset028)
        const   uint32_t UNUSED1;                       // 0x2c
        volatile uint32_t SHIFTSDEN;            // 0x30 (IMXRT_FLEXIO1.offset030)
        const   uint32_t UNUSED2[3];            // 0x34 38 3C
        volatile uint32_t SHIFTSTATE;           // 0x40 (IMXRT_FLEXIO1.offset040)
        const   uint32_t UNUSED3[15];           // 0x44..  50... 60... 70...
[COLOR="#FF0000"]        volatile uint32_t SHIFTCTL[4];          // 0x80 84 88 8C
        const   uint32_t UNUSED4[28];           // 0x90 - 0xfc
[/COLOR]        volatile uint32_t SHIFTCFG[4];          // 0x100 104 108 10C (IMXRT_FLEXIO1.offset100)
        const   uint32_t UNUSED5[60];           // 0x110 - 0x1FC
        volatile uint32_t SHIFTBUF[4];          // 0x200 204 208 20c (IMXRT_FLEXIO1.offset200)
        const   uint32_t UNUSED6[28];           // 
        volatile uint32_t SHIFTBUFBIS[4];       // 0x280        // (IMXRT_FLEXIO1.offset280)
        const   uint32_t UNUSED7[28];           // 
        volatile uint32_t SHIFTBUFBYS[4];       // 0x300 (IMXRT_FLEXIO1.offset300)
        const   uint32_t UNUSED8[28];           // 
        volatile uint32_t SHIFTBUFBBS[4];       // 0x380 (IMXRT_FLEXIO1.offset380)
        const   uint32_t UNUSED9[28];           // 
        volatile uint32_t TIMCTL[4];            // 0x400 
        const   uint32_t UNUSED10[28];          // 
        volatile uint32_t TIMCFG[4];            // 0x480
        const   uint32_t UNUSED11[28];          // 
        volatile uint32_t TIMCMP[4];            // 0x500
        const   uint32_t UNUSED12[28+64];       // 
        volatile uint32_t SHIFTBUFNBS[4];       // 0x680
        const   uint32_t UNUSED13[28];          // 
        volatile uint32_t SHIFTBUFHWS[4];       // 0x700
        const   uint32_t UNUSED14[28];          // 
        volatile uint32_t SHIFTBUFNIS[4];       // 0x780
} IMXRT_FLEXIO_t;

Again the pdf talks about 4 timers and 4 shifters, in many different ways: Like on page 2913 (Memory map) It will show things like:
Shifter Control N (SHIFTCTL0 - SHIFTCLT3) but again I am assuming that it is actually through 7...
So for example in the structure above for this one the SHIFTCTL[4] should be 8 and the line below Should be decremented by 4 (56)...
Ditto for several of the others. Note functionally it probably does not matter but would get compiler warnings if one directly accessed the the 7th index...

Again I know the doc is wrong, example again PARAM should 4 for those two fields, yet if you run program that print them out they are 8...
And likewise section 50.3.4.1 Parallel Interface which we are using, mentions:For shifters supporting parallel receive (SHIFTER3, SHIFTER7),

So should I go ahead any update all of these.

Another question, that I don't think I can answer is on FlexIO2, there are only two DMA Mux Mappings one is for Timers 0,1 and the other for Timers 2,3
I am assuming that there is not another one that maps up to for example SHIFTER7? Lots to experiment with!
 
KurtE said:
Next thing to try may be to simply the other constructor simply save away the right pins and the like. and then in flexIO case at least it all folds back to one flexIO Init...
Funny you should say that. I was just looking at that a couple of minutes ago.

If it were me I would have 2 constructors:
Code:
HM01B0(set_Carrier)
where carrier would be ML carrier (think should default to 8pin) or PJRC carrier (4pin only allowed) so audio shield or prop shield or anyother shield that we come up with in the future :) This would then set the pins and call off flexio_configure_custom_pins (will probably rename in the future).

The second constructor would be what you have now for custom pins:
Code:
    HM01B0(uint8_t mclk_pin, uint8_t pclk_pin, uint8_t vsync_pin, uint8_t hsync_pin, uint8_t en_pin,
		uint8_t g0, uint8_t g1,uint8_t g2, uint8_t g3,
		uint8_t g4=0xff, uint8_t g5=0xff,uint8_t g6=0xff,uint8_t g7=0xff, TwoWire &wire=Wire);

@Paul and others - The main issue with this, is it is currently using my flexIO_t4 library to do some of this. Mainly for the knowing that the pins are connected to a flexIO object, and do the mapping of the pins to the FlexIO pins and keeping track of which FlexIO resources that have been used, such that other thing can allocate others...

Probably need to clean it up some!.
Yeah I noticed originally forgot to put the latest in the library folder. Guess you have some clean up to do so can go into Teensyduino as well I guess?

Also one of the next steps will be to try it out to see if for example it works on T4.1 on FlexIO 1, and T4 on FlexIO 1 or 2... And if we should also allow it to be configured to work in non DMA mode?
At some point guess we are going to have to.

Hopefully we can extend this to other camera's as well.
 
@All
First the Rev D Audio adapter works with the TMM - only tried tone sweep and zelda to test.

Now for the new problem. If I try to incorporate the camera sketch into zelda just to see if the 2 play nice together the sensor is not detected,
Code:
error reading HM01B0, address
SENSOR NOT DETECTED! :-(
Also out of curiosity I ran I2CScanner but no i2c devices were detected. It very late for me now so I am attaching the kludged together sketch if you want to play.

Oh forgot to mention I am using FlexIO 4bit with @KurtE's mod's. Probably should try it the other way as well.
 

Attachments

  • Zelda-HM01B0.zip
    271.1 KB · Views: 84
Morning all, just having first sip of coffee so have not looked yet at anything...

But at least with the ML board, you have to setup the enable pin to the camera, or Wire will fail to see the camera. Not sure yet with other board?
 
Morning all, just having first sip of coffee so have not looked yet at anything...

But at least with the ML board, you have to setup the enable pin to the camera, or Wire will fail to see the camera. Not sure yet with other board?

Just having my first sip of coffee as well.

Right after reading your message found my problem - forgot to move the cameera from the 8bit to the 4bit connector - guess it was way too late last night - have to try it now. :)
 
@KurtE - @Paul - @defragster

Ok after my silliness in forgetting to move the camera over to the 4bit connector, I did have to redo the constructor in @KurtE's updated lib.
1. The constructor has to be changed to, from what I previously posted:
Code:
#elif _hmConfig ==4  //PJRC Breakout board
//HM01B0 hm01b0(HM01B0_TEENSY_MICROMOD_FLEXIO_4BIT);
// We are doing manual settings: 
// this one should duplicate the 8 bit ML Carrier:
//    HM01B0(uint8_t mclk_pin, uint8_t pclk_pin, uint8_t vsync_pin, uint8_t hsync_pin, en_pin,
//    uint8_t g0, uint8_t g1,uint8_t g2, uint8_t g3,
//    uint8_t g4=0xff, uint8_t g5=0xff,uint8_t g6=0xff,uint8_t g7=0xff, TwoWire &wire=Wire);
HM01B0 hm01b0(33, 44, 32, 45, 28, 40, 41, 42, 43);
if you want to use the breakout with 4bit connector.

Also did a little bit of rearranging of the sketch to be able to play zelda while at the same time being able to take a snapshot. Remember this is just experimental test. Unfortunately there is alot of popping on the speaker and eventually just goes to high pitch. The popping is even if it just sitting and no pictures could be because I am using jumpers to the board.
unnamed.pngThe audio shield is under wire mess. I do have a new one coming today without headers to try. But it may also be a result of where I placed the code to that a picture.

There is one other potential conflict on the breakout - SD Card on the audio shield is same as that for the display - CS:10.

Here is the updated sketch if someone whats to try.
 

Attachments

  • Zelda-HM01B0.zip
    271.1 KB · Views: 45
Morning again all:

Quick FYI - I just updated the FlexIO_t4 library to be a more proper library, with an library.properties file and moved the sources into the src directory...

All of the moves where done using the git mv command, so you should just be able to sync up and the files should move.

Edit: I also issued a PR to cores to update the FlexIO structure in imxrt.h to have 8 timers and shifters instead of 4:
https://github.com/PaulStoffregen/cores/pull/557
 
Morning again all:

Quick FYI - I just updated the FlexIO_t4 library to be a more proper library, with an library.properties file and moved the sources into the src directory...

All of the moves where done using the git mv command, so you should just be able to sync up and the files should move.

Edit: I also issued a PR to cores to update the FlexIO structure in imxrt.h to have 8 timers and shifters instead of 4:
https://github.com/PaulStoffregen/cores/pull/557

Thanks @KurtE
Just updated my copies. Oh decided to have some fun. I put all the camera stuff in the zelda example in a thread and taking snapshots works. Only thing that's not working with threads is readcontinuous but that I think is a thread issue I have to work on.
 
@KurtE
Just made one more change to the example and the new FlexIO library. I added a second constructor so all you have to do is select the board:
Code:
PROGMEM const char hmConfig[][48] = {
 "HM01B0_TEENSY_MICROMOD_GPIO_8BIT",
 "HM01B0_TEENSY_MICROMOD_FLEXIO_8BIT",
 "HM01B0_TEENSY_MICROMOD_DMA_8BIT",
 "HM01B0_SPARKFUN_ML_CARRIER",
 "HM01B0_PJRC_CARRIER",
 "HM01B0_FLEXIO_CUSTOM_LIKE_8_BIT",
 "HM01B0_FLEXIO_CUSTOM_LIKE_4_BIT"
};
#if _hmConfig ==0
HM01B0 hm01b0(HM01B0_TEENSY_MICROMOD_GPIO_8BIT);
#elif _hmConfig ==1
HM01B0 hm01b0(HM01B0_TEENSY_MICROMOD_FLEXIO_8BIT);
#elif _hmConfig ==2
HM01B0 hm01b0(HM01B0_TEENSY_MICROMOD_DMA_8BIT);
#elif _hmConfig ==3
HM01B0 hm01b0(HM01B0_TEENSY_MICROMOD_GPIO_4BIT);
#elif _hmConfig ==4
HM01B0 hm01b0(HM01B0_PJRC_CARRIER);   //4 pin connector so you can use the audio shield on it as well
#elif _hmConfig ==5
// We are doing manual settings: 
// this one should duplicate the 8 bit ML Carrier:
//    HM01B0(uint8_t mclk_pin, uint8_t pclk_pin, uint8_t vsync_pin, uint8_t hsync_pin, en_pin,
//    uint8_t g0, uint8_t g1,uint8_t g2, uint8_t g3,
//    uint8_t g4=0xff, uint8_t g5=0xff,uint8_t g6=0xff,uint8_t g7=0xff, TwoWire &wire=Wire);
HM01B0 hm01b0(7, 8, 33, 32, 2, 40, 41, 42, 43, 44, 45, 6, 9);

#elif _hmConfig == 6
// We are doing manual settings: 
// this one should duplicate the 8 bit ML Carrier:
//    HM01B0(uint8_t mclk_pin, uint8_t pclk_pin, uint8_t vsync_pin, uint8_t hsync_pin, en_pin,
//    uint8_t g0, uint8_t g1,uint8_t g2, uint8_t g3,
//    uint8_t g4=0xff, uint8_t g5=0xff,uint8_t g6=0xff,uint8_t g7=0xff, TwoWire &wire=Wire);
HM01B0 hm01b0(7, 8, 33, 32, 2, 40, 41, 42, 43);
#endif
Only tested with the Breakout board not on the ML carrier.

Attaching the zip.
 

Attachments

  • TMM-HM01B0.zip
    39.1 KB · Views: 47
@mjs513 @Paul... Should have other breakout soon...

Question: Should maybe go ahead and merge in the newer flexIO version? Also should look at your new zip file to see if we can or you already have reworked the
constructors and the like and then can eliminate the other FlexIO configure function? or at minimum do basics to assign the pins and call the other...

Once I have the next setup, I want to try changing the code that is fixed on Timer2 to request a timer and see if that works or not ;)
 
@mjs513 @Paul... Should have other breakout soon...

Question: Should maybe go ahead and merge in the newer flexIO version? Also should look at your new zip file to see if we can or you already have reworked the
constructors and the like and then can eliminate the other FlexIO configure function? or at minimum do basics to assign the pins and call the other...

Once I have the next setup, I want to try changing the code that is fixed on Timer2 to request a timer and see if that works or not ;)

Morning again @KurtE
Yes you might say I reworked the constructor. I added a new constructor that just takes the board and sets wire and pins on the board selected so you don't have to specify the pins:
Code:
HM01B0::HM01B0(hw_carrier_t set_hw_carrier)
For the PJRC carrier its fixed at 4pin connector so you can use the audio shield or for that matter the propshield I guess but I didn't check. The pin constructor is still there so you can set pins if you are using the T4 or T4.1. Thats in the zip I attached along with a slightly modified exampl1 sketch. Yes no need for the other flexIO configure if we go to the new version. As a matter of fact all the pin assignments can get deleted in init as well.

Haven't tested on the ML carrier yet - need more coffee.

I would merge the new flexIO I stuff. Think you asked about keeping FlexIO/DMA - think we should. Somewhere in this thread we talked about that but cant remember where.
 
Kudos to all of those involved in this project - I am very much looking forward to using the MicroMod with the new FlexIO pins exposed :D

I see there has been a lot of development effort around supporting 4/8 bit parallel input for the cameras. I on the other hand find this perfect for driving a display over 8 bit 8080 - there are enough consecutive flexio pins and you guys are laying the grounds for the most part of it - very much appreciated!

One thing that interests me.. @paul is the pinout final?
 
Great! Tried it out on new carrier with 4 bit flexio... Works!

Will try a few things...

Already verified that I don't need any specific timer, will push up PR back to you, but now looking at commentsL
Code:
8 Data pins configured
Custom - Flexio is 4 bit mode
It still tries to configure all 8 unless one specific configuration mentioned... May instead change:
Code:
	if(_hw_config == HM01B0_TEENSY_MICROMOD_GPIO_4BIT || _hw_config == HM01B0_TEENSY_MICROMOD_FLEXIO_4BIT) {
		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;
[COLOR="#FF0000"]		G4 = 0xff;
[/COLOR]	}
And change:
Code:
if(_hw_config == HM01B0_TEENSY_MICROMOD_GPIO_4BIT) {
to
Code:
	if(G4 == 0xff) {

Actually I am thinking of moving most/all of the first part mentioned here could be moved to he constructor... And then remove the other flexIO init.

Not sure if that makes sense?

EDIT: Pushed up a PR for the first part (use any timer) and setting G4 to 0xff and test against it...
 
Afternoon @KurtE
What I would like to do is to baseline what we have and then revamp the whole lib and remove support for GPIO and DMA. GPIO relatively easy but DMA is so intertwined with Flexio that it gets me confused whats needed from it or not. What do you think.

Right now there are only 2 real options 8 or 4 bit mode.
 
@KurtE
Didn't push this yet wanted to see what you thought first. Basically did what you suggested.
1. replaced flexio_configure with what you had for _manual_settings.
2. moved init into the constructors - so no need to call it from the sketch anymore
3. Only 2 modes considered FlexIO4Bit and FlexIO8Bit.
4. in the sketch now we only have to deal with 4 possible configurations:
Code:
PROGMEM const char hmConfig[][48] = {
 "HM01B0_SPARKFUN_ML_CARRIER",
 "HM01B0_PJRC_CARRIER",
 "HM01B0_FLEXIO_CUSTOM_LIKE_8_BIT",
 "HM01B0_FLEXIO_CUSTOM_LIKE_4_BIT"
};
Since FlexIO is working so well not sure the need for the other modes (GPIO/DMA) especially since FlexIO uses DMA anyways

Let me know what you think - if ok will push to the branch.
 

Attachments

  • TMM-HM01B0.zip
    37.7 KB · Views: 53
Afternoon ...

Boy trying to tear out all of the fun stuff :D

And hear I was wondering if one could setup one T4.1 or MMOD and run two of these cameras ;) Not sure if we could do it just with FlexIO

Might be able to if we did not totally need DMA for one of them..
 
Afternoon ...

Boy trying to tear out all of the fun stuff :D

And hear I was wondering if one could setup one T4.1 or MMOD and run two of these cameras ;) Not sure if we could do it just with FlexIO

Might be able to if we did not totally need DMA for one of them..

Guess that's the problem with FlexIO. Probably the only way to run 2 camera's is to use GPIO. Didn't really delete anything except for the enum and test configs.

EDIT: Could set up constructors to take an option to select GPIO or FLEX.
 
I was sort-of kidding, but thought I would try a few things and see what happens with flexIO. Currently I don't have a total set of correction code in the flexIO stuff.

That is I request from the specified timer, which DMA source there is and don't check to see if that returns saying it does not have one...

I may need to add either a different constructor or some additional optional parameters to for example force it to use FlexIO3 or Timer7 on FlexIO2 Again lots of stuff I have not tried out yet.

Again my assumption is that timers 4-7 don't have a DMA source associated with them. FlexIO 1 and FlexIO 2 have 2 DMA Sources each where timers 0 and 1 share one and timers 2 and 3 share one.

But there are obviously two other options.

a) Polling - code was in there to start off with.
b) Interrupts - Looks like all 3 FlexIO objects have an interrupt each.
And you control which ones cause an interrupt with the SHIFTSIEN. Again this register only mentions bits 3-0 , but again guessing it is bits 7-0...
Might have to try it out :D We do have 14 FlexIO pins on FlexIO2 on MicroMod, so maybe can do :D
But of course some may be used up for other things!

Again sort of kidding, although might be fun to have cameras on both front and back...
 
Back
Top