MicroMod Beta Testing

Try using the sparkfun config by uncommenting the use_sparkfun at the begging of the sketch. Think I am using 4 in wires with no problem.

Ps. Sent about 30 images to the processing sketch from the teensy with no problems. Can’t seem to duplicate what you have.
 
Try using the sparkfun config by uncommenting the use_sparkfun at the begging of the sketch. Think I am using 4 in wires with no problem.

Ps. Sent about 30 images to the processing sketch from the teensy with no problems. Can’t seem to duplicate what you have.

That did it - it was set before ...

The PDE transfer works here in batches. Again maybe it is something about using this USB-C Computer port on a newer faster computer?

Had to restart PDE 3 times to get a sync's image - moving to std USB 3 cable port and the normal hub - many more failed starts than good until finally got one to work at all.

Put in a 1 sec wait between "P" repeat USB1 send. 1 Sec still too fast to transfer and display.
 
@KurtE - @defragster - @PaulStoffregen - @All
Decided to take a short break from the camera stuff and see if I could get the the ILI9341_t3n library working with the Sparkfun Display/Input board. So, I added the following
Code:
 #if defined(ARDUINO_TEENSY_MICROMOD) 
	writecommand_cont(ILI9341_INVON);
#endif
to begin in ILI9341_t3n.cpp and examples sketches are all running like on a regular ILI9341 with having install 3 more libraries.

EDIT: that won't work for the long haul since it is only applicable to the display board and we have no idea if its on that board.

EDIT2: Maybe we should add a setInversion function to the ILI9341 libraries to support the display carrier board. Too sleepy now to think about it.
 
That did it - it was set before ...

The PDE transfer works here in batches. Again maybe it is something about using this USB-C Computer port on a newer faster computer?

Had to restart PDE 3 times to get a sync's image - moving to std USB 3 cable port and the normal hub - many more failed starts than good until finally got one to work at all.

Put in a 1 sec wait between "P" repeat USB1 send. 1 Sec still too fast to transfer and display.

@defragster - getting ready for zzzz's but it has to be something on the PC side. I have it hooked up to my powered hub and its working no problem. I did notice that there is a noticable delay between when you hit 'p' and it displays on the PC side. Some of that is from the calcs it has to do before sending, some due to the fact that the PDE is set up to read the whole buffer first then display. Maybe something to do with the way Serial.write works with large buffers to USB1?
 
That is a big bunch of data - 300 consecutive 512 byte buffers. Though at 100-200 Mbs throughput that ~1.3M bits should be a blink. Though we've seen PC side using Java isn't a perfect conduit.

Also - something seen testing the Dual and tri Serial was IIRC :: it was slower overall than single Serial.

Gave that a quick thought about testing to UART serial for debug - but so few pins on the ML - and Rx/Tx are accounted for with the display.


Oh I did something FUN: When DMA was running I pushed Kurt's buffer over instead of having it read the camera - data format is different than the normal WORD to BYTE conversion - so it was the image but all weird and glowy like this from the PDE:
ProCam05.png
Boring pic of my overhead light - and desk stuff over keybaord
 
On a different note from the HB01B0 camera. Was looking at what @luni did and looking at the pins_arduino.h file and was wondering if it would worth it to add @luni's pinouts to the pins_arduino.h file like this:
Code:
#if defined(ARDUINO_TEENSY_MICROMOD)
    //GPIO ---------------------------------------
    constexpr uint8_t G0  = 40; // GPIO7-04--
    constexpr uint8_t G1  = 41; // GPIO7-05  |
    constexpr uint8_t G2  = 42; // GPIO7-06  |
    constexpr uint8_t G3  = 43; // GPIO7-07  | 8 bit bus G0-G7
    constexpr uint8_t G4  = 44; // GPIO7-08  |
    constexpr uint8_t G5  = 45; // GPIO7-09  |
    constexpr uint8_t G6  = 6;  // GPIO7-10  |
    constexpr uint8_t G7  = 9;  // GPIO7-11--
    constexpr uint8_t G8  = 26; // GPIO6-30
    constexpr uint8_t G9  = 32; // GPIO7-12  & CAM_HSYNC
    constexpr uint8_t G10 = 33; // GPIO9-07  & CAM_VSYNC
    constexpr uint8_t G11 = 27; // GPIO6-31  & A13

    constexpr uint8_t D0  = 4;  // GPIO9-06
    constexpr uint8_t D1  = 5;  // GPIO9-08


    // DAC / PWM ---------------------------------
    constexpr uint8_t PWM0 = 3;
    constexpr uint8_t PWM1 = 2;

    // UARTs -------------------------------------
    constexpr uint8_t TX1 = 1; // Serial 1
    constexpr uint8_t RX1 = 0;
    //constexpr uint8_t RTS1 = ?; // not in schematic
    //constexpr uint8_t CTS1 = ?; // not in schematic
    constexpr uint8_t TX2 = 17; // Serial 2
    constexpr uint8_t RX2 = 16;

    // I2C ---------------------------------------
    constexpr uint8_t I2CINT = 29;
    constexpr uint8_t SCL1   = A10;
    constexpr uint8_t SDA1   = A11;

    // SPI --------------------------------------
    constexpr uint8_t SCK  = 13;  // & LED_BUILTIN
    constexpr uint8_t CIPO = 12;
    constexpr uint8_t MISO = 12;
    constexpr uint8_t COPI = 11;
    constexpr uint8_t MOSI = 11;
    constexpr uint8_t CS   = 10;

    constexpr uint8_t SCK1  = 36;  // & SDIO_CLK
    constexpr uint8_t CIPO1 = 35;  // & SDIO_DATA0
    constexpr uint8_t MISO1 = 35;  // & SDIO_DATA0
    constexpr uint8_t COPI1 = 37;  // & SDIO_CMD
    constexpr uint8_t MOSI1 = 37;  // & SDIO_CMD
    constexpr uint8_t CS1   = 39;  // & SDIO_DATA3

    // SDI --------------------------------------
    constexpr uint8_t SDIO_CLK   = 36; // & SCK1
    constexpr uint8_t SDIO_CMD   = 37; // & COPI1 / MOSI1
    constexpr uint8_t SDIO_DATA0 = 35; // & CIPO1 / MISO1
    constexpr uint8_t SDIO_DATA1 = 34; 
    constexpr uint8_t SDIO_DATA2 = 38;
    constexpr uint8_t SDIO_DATA3 = 39;  // & SPI CS1

    // CAN --------------------------------------
    constexpr uint8_t CAN_TX = 31;
    constexpr uint8_t CAN_RX = 30;

    // CAMERA -----------------------------------
    constexpr uint8_t CAM_TRIG  = D1;
    constexpr uint8_t CAM_HSYNC = G9;
    constexpr uint8_t CAM_VSYNC = G10;
    constexpr uint8_t CAM_MCLK  = 7;
    constexpr uint8_t CAM_PCLK  = 8;

    // AUDIO -----------------------------------
    constexpr uint8_t AUD_MCLK = 23;        // & A9;
    constexpr uint8_t AUD_OUT   = CAM_MCLK;
    constexpr uint8_t AUD_IN    = CAM_PCLK;
    constexpr uint8_t AUD_LRCLK = A6;
    constexpr uint8_t AUD_BCLK  = A7;

    // Misc
    constexpr uint8_t BATT_VIN = A8;
#endif
 
Was testing a couple more things:
15s Restore: Works - tested both on the ATP and ML boards.

Quad Encoder Library: Finally got a chance to test change I made to the T4 Quad Encoder library that adds ARDUINO_TEENSY_MICROMOD on the ATP board. Tested just a couple of the pins and its working. I've updated the repository accordinly: https://github.com/mjs513/Teensy-4.x-Quad-Encoder-Library. So just a reminder that the next update needs to pull in the revision.
 
I started playing with FlexIO for the camera. So far it's unresponsive, but hope to have something soon...

Pulled in the latest QuadEncoder.
Good luck with FlexIO for the camera - assuming you mean the 4bit FlexIO? Are you trying it with the library or started it with your initial test sketch - going to assume your initial sketch? If the lib you may have a couple of gotcha's in there which I am sure you know.

Thanks for pulling in the changes to the encoder library, figured with all that you have going on would just make a note for you.
 
Morning all,

Looks like all are still having fun. Wondering with my DMA stuff, for the heck of it, I converted the one byte data into 565 format like @mjs513 code was doing external for single frame. Wondering if I should instead convert it (i.e. leave it alone) to one byte and send it through and then have the code displaying it then convert. That way if some of the other code like saving bitmap or sending or... the images should work the same... Will try that in a minute.

Paul - Will be interesting to see what you have on FlexIO. Right now I would be more tempted to try it out on the OV7670 as we can hook up to ATP board and do debugging.

On the Machine learning board, I assume someone has already played with the: ST LIS2DH12 3-axis accelerometer

With @luni definitions, I thought about doing something like that, but then though some of those defines were too generic and maybe will run into conflicts with other programs and the like:
Things like D0 and D1 or maybe more confusing like: TX2/RX2 which are actually Serial4... Could be wrong. Alternatively we could go complete different, and for example
On T-MM have Serial2 on those pins, but then again the normal T4 and 4.1 Serial2 and Serial3 pins are on the T-MM..

But first coffee
 
Morning all,
With @luni definitions, I thought about doing something like that, but then though some of those defines were too generic and maybe will run into conflicts with other programs and the like:
This is why (in my original file) they are in their own namespace :)
 
Morning @KurtE
On the Machine learning board, I assume someone has already played with the: ST LIS2DH12 3-axis accelerometer
Actually thought about it but forgot. Remember what they say about assume.

UPDATE: It works:
Code:
Acc [mg]: 21.0 x, -37.0 y, 1055.0 z, 27.5C
Acc [mg]: 21.0 x, -34.0 y, 1059.0 z, 27.3C
Acc [mg]: 21.0 x, -34.0 y, 1059.0 z, 27.3C
Acc [mg]: 22.0 x, -34.0 y, 1060.0 z, 27.5C
Acc [mg]: 18.0 x, -35.0 y, 1054.0 z, 27.5C
Acc [mg]: 17.0 x, -32.0 y, 1054.0 z, 27.0C
Acc [mg]: 16.0 x, -36.0 y, 1055.0 z, 27.3C
Acc [mg]: 16.0 x, -36.0 y, 1059.0 z, 27.3C
Acc [mg]: 18.0 x, -35.0 y, 1062.0 z, 27.8C
Acc [mg]: 18.0 x, -36.0 y, 1063.0 z, 27.8C
Acc [mg]: 18.0 x, -34.0 y, 1063.0 z, 27.3C
Acc [mg]: 20.0 x, -33.0 y, 1063.0 z, 27.0C
Acc [mg]: 15.0 x, -34.0 y, 1066.0 z, 27.8C

With @luni definitions, I thought about doing something like that, but then though some of those defines were too generic and maybe will run into conflicts with other programs and the like:
Things like D0 and D1 or maybe more confusing like: TX2/RX2 which are actually Serial4... Could be wrong. Alternatively we could go complete different, and for example
On T-MM have Serial2 on those pins, but then again the normal T4 and 4.1 Serial2 and Serial3 pins are on the T-MM..
Was 100% sure if there was going to be any conflict but looking at the .h I didn't think there would be - but then again don't know what I don't know that's why I threw it out there to see what smarter people than me with the core thought about it.
 
Last edited:
This is why (in my original file) they are in their own namespace :)

Was wondering why you set it up to have its own namespace. Is there anyway to do that with in the core. Reason asking it would be simpler than have to add the files to every library or sketch? Does that make sense?
 
Namespace makes sense... MMODPIN::D0 or whatever your namespace is called would make it convenient for C++.
There may still be issues for users like: Serial2 is actually on pins marked like I2S SDO I2S SDI...
 
Was wondering why you set it up to have its own namespace. Is there anyway to do that with in the core. Reason asking it would be simpler than have to add the files to every library or sketch? Does that make sense?

Defining things like 'D0' or 'TX2' without a dedicated namespace is screaming for trouble... However, I don't know if it make sense to do this in 'c++' in the core files since, AFAIK, they are supposed to work with old C-code as well?

Things like D0 and D1 or maybe more confusing like: TX2/RX2 which are actually Serial4... Could be wrong.
The defines I did, simply reflect the names as defined for the MM connector and are printed on the silk screen of the carriers. The idea of course was to be able to do something like digitalToggle(TX2) to access the pin named TX2 without having to look at a table to find out that this actually is Teensy Pin17. But, this of course is a matter of taste.
 
Good morning again,

Playing with sketch in new branch: dma_frame_8bit, where I removed the conversion from 8 bits to 565 in the DMA code and instead returned the 8 bit frame data, which to display you do the same conversion as with the s command...

Appears to work pretty good with sparkfun registers... Wondering what is different, so I added 'r' command to print out registers. Example run this is without sparkfun...
Code:
*** Camera Registers ***
MODEL_ID_H(0): 1(1)
MODEL_ID_L(1): 176(b0)
FRAME_COUNT(5): 129(81)
PIXEL_ORDER(6): 2(2)
MODE_SELECT(100): 1(1)
IMG_ORIENTATION(101): 0(0)
SW_RESET(103): 255(ff)
GRP_PARAM_HOLD(104): 0(0)
INTEGRATION_H(202): 1(1)
INTEGRATION_L(203): 2(2)
ANALOG_GAIN(205): 32(20)
DIGITAL_GAIN_H(20e): 1(1)
DIGITAL_GAIN_L(20f): 4(4)
FRAME_LEN_LINES_H(340): 1(1)
FRAME_LEN_LINES_L(341): 4(4)
LINE_LEN_PCK_H(342): 1(1)
LINE_LEN_PCK_L(343): 120(78)
READOUT_X(383): 1(1)
READOUT_Y(387): 1(1)
BINNING_MODE(390): 0(0)
TEST_PATTERN_MODE(601): 0(0)
BLC_CFG(1000): 67(43)
BLC_TGT(1003): 0(0)
BLI_EN(1006): 1(1)
BLC2_TGT(1007): 8(8)
DPC_CTRL(1008): 1(1)
SINGLE_THR_HOT(100b): 144(90)
SINGLE_THR_COLD(100c): 64(40)
VSYNC_HSYNC_PIXEL_SHIFT_EN(1012): 0(0)
AE_CTRL(2100): 1(1)
AE_TARGET_MEAN(2101): 100(64)
AE_MIN_MEAN(2102): 10(a)
CONVERGE_IN_TH(2103): 3(3)
CONVERGE_OUT_TH(2104): 5(5)
MAX_INTG_H(2105): 1(1)
MAX_INTG_L(2106): 2(2)
MIN_INTG(2107): 2(2)
MAX_AGAIN_FULL(2108): 2(2)
MAX_AGAIN_BIN2(2109): 2(2)
MIN_AGAIN(210a): 0(0)
MAX_DGAIN(210b): 192(c0)
MIN_DGAIN(210c): 64(40)
DAMPING_FACTOR(210d): 32(20)
FS_CTRL(210e): 0(0)
FS_60HZ_H(210f): 0(0)
FS_60HZ_L(2110): 60(3c)
FS_50HZ_H(2111): 0(0)
FS_50HZ_L(2112): 50(32)
FS_HYST_TH(2113): 102(66)
MD_CTRL(2150): 0(0)
I2C_CLEAR(2153): 255(ff)
WMEAN_DIFF_TH_H(2155): 125(7d)
WMEAN_DIFF_TH_M(2156): 75(4b)
WMEAN_DIFF_TH_L(2157): 5(5)
MD_THH(2158): 128(80)
MD_THM1(2159): 50(32)
MD_THM2(215a): 25(19)
MD_THL(215b): 3(3)
STATISTIC_CTRL(2000): 7(7)
MD_LROI_X_START_H(2011): 0(0)
MD_LROI_X_START_L(2012): 72(48)
MD_LROI_Y_START_H(2013): 0(0)
MD_LROI_Y_START_L(2014): 88(58)
MD_LROI_X_END_H(2015): 0(0)
MD_LROI_X_END_L(2016): 219(db)
MD_LROI_Y_END_H(2017): 0(0)
MD_LROI_Y_END_L(2018): 155(9b)
MD_INTERRUPT(2160): 1(1)
QVGA_WIN_EN(3010): 1(1)
SIX_BIT_MODE_EN(3011): 112(70)
PMU_AUTOSLEEP_FRAMECNT(3020): 1(1)
ADVANCE_VSYNC(3022): 1(1)
ADVANCE_HSYNC(3023): 2(2)
EARLY_GAIN(3035): 243(f3)
BIT_CONTROL(3059): 2(2)
OSC_CLK_DIV(3060): 42(2a)
ANA_Register_11(3061): 0(0)
IO_DRIVE_STR(3062): 0(0)
IO_DRIVE_STR2(3063): 0(0)
ANA_Register_14(3064): 0(0)
OUTPUT_PIN_STATUS_CONTROL(3065): 4(4)
ANA_Register_17(3067): 0(0)
PCLK_POLARITY(3068): 32(20)
And with it turned on:
Code:
*** Camera Registers ***
MODEL_ID_H(0): 1(1)
MODEL_ID_L(1): 176(b0)
FRAME_COUNT(5): 17(11)
PIXEL_ORDER(6): 3(3)
MODE_SELECT(100): 1(1)
IMG_ORIENTATION(101): 1(1)
SW_RESET(103): 255(ff)
GRP_PARAM_HOLD(104): 1(1)
INTEGRATION_H(202): 2(2)
INTEGRATION_L(203): 133(85)
ANALOG_GAIN(205): 0(0)
DIGITAL_GAIN_H(20e): 1(1)
DIGITAL_GAIN_L(20f): 0(0)
FRAME_LEN_LINES_H(340): 12(c)
FRAME_LEN_LINES_L(341): 122(7a)
LINE_LEN_PCK_H(342): 1(1)
LINE_LEN_PCK_L(343): 119(77)
READOUT_X(383): 1(1)
READOUT_Y(387): 1(1)
BINNING_MODE(390): 0(0)
TEST_PATTERN_MODE(601): 0(0)
BLC_CFG(1000): 67(43)
BLC_TGT(1003): 8(8)
BLI_EN(1006): 1(1)
BLC2_TGT(1007): 8(8)
DPC_CTRL(1008): 0(0)
SINGLE_THR_HOT(100b): 144(90)
SINGLE_THR_COLD(100c): 64(40)
VSYNC_HSYNC_PIXEL_SHIFT_EN(1012): 1(1)
AE_CTRL(2100): 1(1)
AE_TARGET_MEAN(2101): 100(64)
AE_MIN_MEAN(2102): 10(a)
CONVERGE_IN_TH(2103): 3(3)
CONVERGE_OUT_TH(2104): 7(7)
MAX_INTG_H(2105): 12(c)
MAX_INTG_L(2106): 120(78)
MIN_INTG(2107): 2(2)
MAX_AGAIN_FULL(2108): 2(2)
MAX_AGAIN_BIN2(2109): 2(2)
MIN_AGAIN(210a): 0(0)
MAX_DGAIN(210b): 128(80)
MIN_DGAIN(210c): 64(40)
DAMPING_FACTOR(210d): 32(20)
FS_CTRL(210e): 0(0)
FS_60HZ_H(210f): 0(0)
FS_60HZ_L(2110): 133(85)
FS_50HZ_H(2111): 0(0)
FS_50HZ_L(2112): 160(a0)
FS_HYST_TH(2113): 102(66)
MD_CTRL(2150): 3(3)
I2C_CLEAR(2153): 255(ff)
WMEAN_DIFF_TH_H(2155): 125(7d)
WMEAN_DIFF_TH_M(2156): 75(4b)
WMEAN_DIFF_TH_L(2157): 5(5)
MD_THH(2158): 128(80)
MD_THM1(2159): 50(32)
MD_THM2(215a): 25(19)
MD_THL(215b): 3(3)
STATISTIC_CTRL(2000): 7(7)
MD_LROI_X_START_H(2011): 0(0)
MD_LROI_X_START_L(2012): 72(48)
MD_LROI_Y_START_H(2013): 0(0)
MD_LROI_Y_START_L(2014): 88(58)
MD_LROI_X_END_H(2015): 0(0)
MD_LROI_X_END_L(2016): 219(db)
MD_LROI_Y_END_H(2017): 0(0)
MD_LROI_Y_END_L(2018): 155(9b)
MD_INTERRUPT(2160): 1(1)
QVGA_WIN_EN(3010): 1(1)
SIX_BIT_MODE_EN(3011): 112(70)
PMU_AUTOSLEEP_FRAMECNT(3020): 0(0)
ADVANCE_VSYNC(3022): 1(1)
ADVANCE_HSYNC(3023): 2(2)
EARLY_GAIN(3035): 243(f3)
BIT_CONTROL(3059): 2(2)
OSC_CLK_DIV(3060): 42(2a)
ANA_Register_11(3061): 0(0)
IO_DRIVE_STR(3062): 0(0)
IO_DRIVE_STR2(3063): 0(0)
ANA_Register_14(3064): 0(0)
OUTPUT_PIN_STATUS_CONTROL(3065): 4(4)
ANA_Register_17(3067): 0(0)
PCLK_POLARITY(3068): 32(20)
startReadFrameDMA called buffers 200295f8 20200000
*** Return from startReadFrameDMA ***
*** stopReadFrameDMA ***
*** return from stopReadFrameDMA ***
Next to see what registers are different and maybe localize down which one matter.

EDIT: Side by side ones that are different:
Code:
	Sparkfun	Default
FRAME_COUNT(5)	17(11)	129(81)
PIXEL_ORDER(6)	3(3)	2(2)
IMG_ORIENTATION(101)	1(1)	0(0)
GRP_PARAM_HOLD(104)	1(1)	0(0)
INTEGRATION_H(202)	2(2)	1(1)
INTEGRATION_L(203)	133(85)	2(2)
ANALOG_GAIN(205)	0(0)	32(20)
DIGITAL_GAIN_H(20e)	1(1)	1(1)
DIGITAL_GAIN_L(20f)	0(0)	4(4)
FRAME_LEN_LINES_H(340)	12(c)	1(1)
FRAME_LEN_LINES_L(341)	122(7a)	4(4)
LINE_LEN_PCK_L(343)	119(77)	120(78)
BLC_TGT(1003)	8(8)	0(0)
DPC_CTRL(1008)	0(0)	1(1)
VSYNC_HSYNC_PIXEL_SHIFT_EN(1012)	1(1)	0(0)
CONVERGE_OUT_TH(2104)	7(7)	5(5)
MAX_INTG_H(2105)	12(c)	1(1)
MAX_INTG_L(2106)	120(78)	2(2)
MAX_DGAIN(210b)	128(80)	192(c0)
FS_60HZ_L(2110)	133(85)	60(3c)
FS_50HZ_L(2112)	160(a0)	50(32)
MD_CTRL(2150)	3(3)	0(0)
PMU_AUTOSLEEP_FRAMECNT(3020)	0(0)	1(1)
 
Last edited:
Nice comparison @KurtE. From the lib I know what some of those settings are and some get changed with the function calls:
Code:
INTEGRATION_H(202)	2(2)	1(1)
INTEGRATION_L(203)	133(85)	2(2)
ANALOG_GAIN(205)	0(0)	32(20)
DIGITAL_GAIN_H(20e)	1(1)	1(1)
DIGITAL_GAIN_L(20f)	0(0)	4(4)
These are all associated with setting the sensors exposure gain which can get called from things :
Code:
	int set_auto_gain(int enable, float gain_db, float gain_db_ceiling);
	int set_auto_exposure(int enable, int exposure_us);
	uint8_t get_ae( ae_cfg_t *psAECfg);
	uint8_t cal_ae( uint8_t CalFrames, uint8_t* Buffer, uint32_t ui32BufferLen, ae_cfg_t* pAECfg);
Now I do call set_auto_gain in the body of the sketch:
Code:
  /* Gain Ceilling
   * GAINCEILING_1X
   * GAINCEILING_4X
   * GAINCEILING_8X
   * GAINCEILING_16X
   */
  hm01b0.set_gainceiling(GAINCEILING_4X);
  /* Brightness
   *  Can be 1, 2, or 3
   */
  //hm01b0.set_brightness(2);
  hm01b0.set_auto_exposure(true, 250);
  hm01b0.cmdUpdate();  //only need after changing auto exposure settings
In the default max_intg gets set based on the frame lenghts for QVGA (
Code:
    {MAX_INTG_H,           (HIMAX_FRAME_LENGTH_QVGA-2)>>8},          //Maximum INTG High Byte  [Def: 0x01]
    {MAX_INTG_L,           (HIMAX_FRAME_LENGTH_QVGA-2)&0xFF},
defined as #define HIMAX_FRAME_LENGTH_QVGA     0x104

Code:
GRP_PARAM_HOLD(104)	1(1)	0(0)
Really only gets used when I call cmdUpdate.

EDIT:
Code:
FRAME_COUNT(5)	17(11)	129(81)
PIXEL_ORDER(6)	3(3)	2(2)
IMG_ORIENTATION(101)	1(1)	0(0)
I really don't do anything with these Maybe something with the frame_count(s) - sparkfun alot smaller.
 
@mjs513 - I pushed the current stuff as a PR so you can play along also....

Also forgot to mention, made the build with SerialUSB1 optional, if you use the command that needs USB1 it will print an error message if not built with it.

Edit: My guess is frame count is probably nothing, probably just increments and wraps around, so your sketch can query to see how many frames have happened since your last check...
 
Sort of a random question/observation, not just tied to MM but all T4.x...
How best to put infrequently used tables with stings into flash memory so it does not eat up ITCM space....
I wanted a table of Register values and Register strings:

Code:
typedef struct {
  const char *reg_name;
  uint16_t reg;
} HM01B0_TO_NAME_t;
And if my table is something like:
Code:
static const HM01B0_TO_NAME_t hm01b0_reg_name_table[] PROGMEM {
    {"MODEL_ID_H", 0x0000},
    {"MODEL_ID_L", 0x0001},
    {"FRAME_COUNT", 0x0005},
...
I believe it leaves the table up in FLASH, but all of the strings are copied down to ITCM...
If I then try:
Code:
static const HM01B0_TO_NAME_t hm01b0_reg_name_table[] PROGMEM {
    {F("MODEL_ID_H"), 0x0000},
    {F("MODEL_ID_L"), 0x0001},
    {F("FRAME_COUNT"), 0x0005},
...
The compiler errors out that it can not convert the flash string to a const char *

I solved it by changing the typedef...
Code:
typedef struct {
  const __FlashStringHelper *reg_name;
  uint16_t reg;
} HM01B0_TO_NAME_t;
Which appears to work. Not sure if there are other side effects but the strings to works with Serial.printf with the %s...
Assuming this is a standard way for this, maybe need/want to mention it somewhere.

Now back to the regular channel
 
@mjs513 - I pushed the current stuff as a PR so you can play along also....

Also forgot to mention, made the build with SerialUSB1 optional, if you use the command that needs USB1 it will print an error message if not built with it.

Edit: My guess is frame count is probably nothing, probably just increments and wraps around, so your sketch can query to see how many frames have happened since your last check...

Was actually thinking about something like that last night but seems you beat me to it:)

Anyway's just did a quick experiment and think the MCLK clock has something to do with it. For the default_regs example I changed clock from 12Mhz down to 3Mhz:
Code:
	uint32_t OMV_XCLK_FREQUENCY	= 3000000;
which gives me:
Code:
OSC_CLK_DIV: 0x2A
Pixel Clock: 1500000
Camera Clock: 1500000
which looks pretty good for dma transfers. Running Sparfun with the 3Mhz example gives me the same clocks but fairly slow at 30 for a framerate. At 60fps with sparkfun:
Code:
SENSOR DETECTED :-) MODEL HM01B0
error writing to HM01B0
OSC_CLK_DIV: 0x2B
Pixel Clock: 1500000
Camera Clock: 1500000
Looks like the clock gets gated but DMA is haveing major problems - sometimes shows 4 images instead of a single image. Running it in 'c'ontinuous seems okay. Just DMA is having problems.

AT 12MHZ in SPARKFUN Mode
"
Code:
SENSOR DETECTED :-) MODEL HM01B0
OSC_CLK_DIV: 0x2A
Pixel Clock: 6000000
Camera Clock: 6000000
Default DMA and Continuous seems to be doing ok now. Not seeing any tearing. Running at a framerate of 30.

Now for default-registers @12Mhz
Code:
OSC_CLK_DIV: 0x2A
Pixel Clock: 6000000
Camera Clock: 6000000
ImageSize (w,h): 320, 240
Seeing the tearing in DMA mode as we discussed. Out of curiosity I changed the framerate to 15 and tried DMA again. It was a lot better. Still see some but not as much.
here it is at 15:
Code:
OSC_CLK_DIV: 0x29
Pixel Clock: 3000000
Camera Clock: 3000000
At 60fps:
Code:
OSC_CLK_DIV: 0x2B
Pixel Clock: 12000000
Camera Clock: 12000000
forget it the image is totally out synch and don't see anything. Continuous mode seems to be doing good at keeping up though.

Don't know if this helps any
 
@mjs513 - I pushed the current stuff as a PR so you can play along also....

Also forgot to mention, made the build with SerialUSB1 optional, if you use the command that needs USB1 it will print an error message if not built with it.

Edit: My guess is frame count is probably nothing, probably just increments and wraps around, so your sketch can query to see how many frames have happened since your last check...

Just merged your PR but looks like DMA mode got worse when not using Sparkfun registers.
 
@KurtE
Changed 2 settings in the default config and DMA seems to be working without using the Sparkfun:
Code:
    {FS_60HZ_L,            0x85},
    {FS_50HZ_L,            0xa0},
Give it a try and let me know if I am just seeing things.

EDIT:
Have to change the clock to 6Mhz in the .h file as well
Code:
	uint32_t OMV_XCLK_FREQUENCY	= 6000000;

NOTE: FrameRate of 15, 30 work no problem but at 60 vertical is off, bottom of pict is on top.
 
@mjs513 - Those values appear to work nicely. Wonder if it is the DMA or the update to the screen or???

That is can the ILI9341 display display 60 full frames per second?
That is assuming 0 overhead each frame sends about 320*240*2 + 11 bytes (again not taking time for DC/CS changes)
So about 153611bytes per screen * 60 = 9216660 bytes per second and if each byte takes about 9 bits of data (byte plus gap, maybe closet to 10
Would imply SPI speed > 90mhz...

And maybe with the camera running a lot faster than the display, may need to add a little logic in the code to decide when it can or should hand off the buffer to client.

Not sure if you want to push those up, or if I should see about changing the handshake.
 
@mjs513 - Those values appear to work nicely. Wonder if it is the DMA or the update to the screen or???

That is can the ILI9341 display display 60 full frames per second?
That is assuming 0 overhead each frame sends about 320*240*2 + 11 bytes (again not taking time for DC/CS changes)
So about 153611bytes per screen * 60 = 9216660 bytes per second and if each byte takes about 9 bits of data (byte plus gap, maybe closet to 10
Would imply SPI speed > 90mhz...

And maybe with the camera running a lot faster than the display, may need to add a little logic in the code to decide when it can or should hand off the buffer to client.

Not sure if you want to push those up, or if I should see about changing the handshake.

I'll go ahead and push the changes I have so we will in synch again. then you can change the handshake. You know never thought about about how fast the screen can update. Don't remember what SPI we defaulted to in the 9341_t3n library - wanted to check but forgot.

EDIT: Just pushed the changes.
 
@KurtE
Can't seem to push the SPI Clock over 30Mhz for the ILI9341 - just shows a white screen if I do. Just an FYI
 
Back
Top