Teensyduino 1.54 Beta #12

Status
Not open for further replies.
For those that want to use this candidate in PlatformIO:
You can add this line to your platformio.ini:
Code:
platform_packages =
  framework-arduinoteensy@https://github.com/maxgerhardt/teensy-core-pio-package.git#1.54-beta12

Thanks to max Gerhardt for this service.

regards
Cor

That is very kind of you. I plan to do this, I haven't checked it yet but since you were so nice and posted this here randomly, now I know. Cheers!
 
@Paul - TD 1.54 finalizing soon or already ...

But if a sketch on a T_4.x/MM running with CrashReport that should run on a T_3.x - it won't build:
Code:
T:\tCode\Debug\TypicalUse\TypicalUse.ino: In function 'void setup()':
[B]T:\tCode\Debug\TypicalUse\TypicalUse.ino:8:18: error: 'CrashReport' was not declared in this scope[/B]
   if ( Serial && CrashReport ) { // Make sure Serial is alive and there is a CrashReport stored.

Can a NULL class be added to satisfy the build?

Also posted on LittleFS thread : should a T_3.5 that can do a LittleFS RAM drive also work for a PROG disk of suitable size? Seems this wasn't tested for T_3.5 Flash I/O? It fails .begin()
 
@Paul - TD 1.54 finalizing soon or already ...
......

Also posted on LittleFS thread : should a T_3.5 that can do a LittleFS RAM drive also work for a PROG disk of suitable size? Seems this wasn't tested for T_3.5 Flash I/O? It fails .begin()

@degragster

Tried PROGRAM on both a T3.5 and a T3.6. Both fail to start using PROGRAM. Probably because it is not defined for use with Teensy 3.x. From the LittleFS.cpp:
Code:
#if defined(__IMXRT1062__)

#if defined(ARDUINO_TEENSY40)
#define FLASH_SIZE  0x1F0000
#elif defined(ARDUINO_TEENSY41)
#define FLASH_SIZE  0x7C0000
#elif defined(ARDUINO_TEENSY_MICROMOD)
#define FLASH_SIZE  0xFC0000
#endif
only defined to work with T4.x/TMM. Paul designed these into the code so would be his call to add T3.x or we need to put a warning into the readme.
 
@PaulStoffregen

Quick question: do you need to bundle the HM01B0 and TinyML libraries with the 1.54 release or leave them as separate downloadable libraries?

EDIT: Forget I asked - just trying the examples and they need some major rework - need to simplify
 
Last edited:
@PaulStoffregen - @defragster - @KurtE

Did some rework on the HM01B0 examples. Basically move most of the sketches to a oldSketches folder and only 2 sketches are really valid for the library now. The CMSIS_NN sketch and a single example sketch. I tried to add a bunch more comments on configuration as well as removing the option for the Blue PJRC carrier board. Didn't want folks to start getting confused. I reran all the options with the camera and the ML board and its working. Did find out a few interest things.

So Paul your choice if you want to bundle it with 1.54

EDIT: almost forgot - at some point this week will probably put together maybe a tutorial and video of it actually working :) Or maybe a video first :)
 
You guys did some very good work with that HM01B0 !

Reading github.com/mjs513/TMM-HB01B0-Camera/blob/main/TMM-HM01B0/examples/HM01B0_ML_example/HM01B0_ML_example.ino looks good and familiar - just made coffee - will set the PJRC blue breakout off my desk and power up the SFUN_ML and give it a go.

Thanks we all had a hand in this one :) Oh I just pushed an update of some of the comments:
Code:
/*  Camera Configuration
 *  Two base configurations are used to initalize the camera.  The first is the Sparakfun configuration
 *  used in their library, the second is the configurations used by the OpenMV camera (modified) for the HM01B0
 *  If the define for USE_SPARKFUN is uncommented the sketch will use the Sparkfun configuration otherwise it will
 *  the OpenMV version which we modified slightly
 *  NOTE:
 *    1. If using 4 bit mode use set_framerate(60) with OpenMV config
 *    2. If using 8 bit/Sparkfun ML with the Sparkfun config use frameRate of 30. You do get flicker    
 *       using this combination.
 *    3. If using 8 bit/SparkfunML mode use set_framerate(60) with OpenMV config
 */
//#define USE_SPARKFUN 1
 
WORKING HERE ... Just had to change to ML here with this display :: #define TFT_ST7789 1
Did an 'f' then an d "F" so far without issue.

... have to sync - SD changed ...
 
Good work - SD problem FIXED with the .begin edit from the ML specific!

'b' and 'z' work and file name/## indexes properly!

Question - these at top are horrendous to start the example viewing - can they go in .H - or moved to bottom with:
Code:
// BMP config for saving to SD Card or PC display
#define BMPIMAGEOFFSET 66
extern const uint16_t mono_palette[256];
extern const char bmp_header[BMPIMAGEOFFSET];

And removed a static on the one PROGMEM:
Code:
const char bmp_header[BMPIMAGEOFFSET] PROGMEM =
{
  0x42, 0x4D, 0x36, 0x58, 0x02, 0x00, 0x00, 0x00, 0x00, 0x00, 0x42, 0x00, 0x00, 0x00, 0x28, 0x00,
  0x00, 0x00, 0x40, 0x01, 0x00, 0x00, 0xF0, 0x00, 0x00, 0x00, 0x01, 0x00, 0x10, 0x00, 0x03, 0x00,
  0x00, 0x00, 0x00, 0x58, 0x02, 0x00, 0xC4, 0x0E, 0x00, 0x00, 0xC4, 0x0E, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xF8, 0x00, 0x00, 0xE0, 0x07, 0x00, 0x00, 0x1F, 0x00,
  0x00, 0x00
};
const uint16_t mono_palette[256] PROGMEM = {
  MCP(0x00), MCP(0x01), MCP(0x02), MCP(0x03), MCP(0x04), MCP(0x05), MCP(0x06), MCP(0x07), MCP(0x08), MCP(0x09), MCP(0x0a), MCP(0x0b), MCP(0x0c), MCP(0x0d), MCP(0x0e), MCP(0x0f),
  MCP(0x10), MCP(0x11), MCP(0x12), MCP(0x13), MCP(0x14), MCP(0x15), MCP(0x16), MCP(0x17), MCP(0x18), MCP(0x19), MCP(0x1a), MCP(0x1b), MCP(0x1c), MCP(0x1d), MCP(0x1e), MCP(0x1f),
  MCP(0x20), MCP(0x21), MCP(0x22), MCP(0x23), MCP(0x24), MCP(0x25), MCP(0x26), MCP(0x27), MCP(0x28), MCP(0x29), MCP(0x2a), MCP(0x2b), MCP(0x2c), MCP(0x2d), MCP(0x2e), MCP(0x2f),
  MCP(0x30), MCP(0x31), MCP(0x32), MCP(0x33), MCP(0x34), MCP(0x35), MCP(0x36), MCP(0x37), MCP(0x38), MCP(0x39), MCP(0x3a), MCP(0x3b), MCP(0x3c), MCP(0x3d), MCP(0x3e), MCP(0x3f),
  MCP(0x40), MCP(0x41), MCP(0x42), MCP(0x43), MCP(0x44), MCP(0x45), MCP(0x46), MCP(0x47), MCP(0x48), MCP(0x49), MCP(0x4a), MCP(0x4b), MCP(0x4c), MCP(0x4d), MCP(0x4e), MCP(0x4f),
  MCP(0x50), MCP(0x51), MCP(0x52), MCP(0x53), MCP(0x54), MCP(0x55), MCP(0x56), MCP(0x57), MCP(0x58), MCP(0x59), MCP(0x5a), MCP(0x5b), MCP(0x5c), MCP(0x5d), MCP(0x5e), MCP(0x5f),
  MCP(0x60), MCP(0x61), MCP(0x62), MCP(0x63), MCP(0x64), MCP(0x65), MCP(0x66), MCP(0x67), MCP(0x68), MCP(0x69), MCP(0x6a), MCP(0x6b), MCP(0x6c), MCP(0x6d), MCP(0x6e), MCP(0x6f),
  MCP(0x70), MCP(0x71), MCP(0x72), MCP(0x73), MCP(0x74), MCP(0x75), MCP(0x76), MCP(0x77), MCP(0x78), MCP(0x79), MCP(0x7a), MCP(0x7b), MCP(0x7c), MCP(0x7d), MCP(0x7e), MCP(0x7f),
  MCP(0x80), MCP(0x81), MCP(0x82), MCP(0x83), MCP(0x84), MCP(0x85), MCP(0x86), MCP(0x87), MCP(0x88), MCP(0x89), MCP(0x8a), MCP(0x8b), MCP(0x8c), MCP(0x8d), MCP(0x8e), MCP(0x8f),
  MCP(0x90), MCP(0x91), MCP(0x92), MCP(0x93), MCP(0x94), MCP(0x95), MCP(0x96), MCP(0x97), MCP(0x98), MCP(0x99), MCP(0x9a), MCP(0x9b), MCP(0x9c), MCP(0x9d), MCP(0x9e), MCP(0x9f),
  MCP(0xa0), MCP(0xa1), MCP(0xa2), MCP(0xa3), MCP(0xa4), MCP(0xa5), MCP(0xa6), MCP(0xa7), MCP(0xa8), MCP(0xa9), MCP(0xaa), MCP(0xab), MCP(0xac), MCP(0xad), MCP(0xae), MCP(0xaf),
  MCP(0xb0), MCP(0xb1), MCP(0xb2), MCP(0xb3), MCP(0xb4), MCP(0xb5), MCP(0xb6), MCP(0xb7), MCP(0xb8), MCP(0xb9), MCP(0xba), MCP(0xbb), MCP(0xbc), MCP(0xbd), MCP(0xbe), MCP(0xbf),
  MCP(0xc0), MCP(0xc1), MCP(0xc2), MCP(0xc3), MCP(0xc4), MCP(0xc5), MCP(0xc6), MCP(0xc7), MCP(0xc8), MCP(0xc9), MCP(0xca), MCP(0xcb), MCP(0xcc), MCP(0xcd), MCP(0xce), MCP(0xcf),
  MCP(0xd0), MCP(0xd1), MCP(0xd2), MCP(0xd3), MCP(0xd4), MCP(0xd5), MCP(0xd6), MCP(0xd7), MCP(0xd8), MCP(0xd9), MCP(0xda), MCP(0xdb), MCP(0xdc), MCP(0xdd), MCP(0xde), MCP(0xdf),
  MCP(0xe0), MCP(0xe1), MCP(0xe2), MCP(0xe3), MCP(0xe4), MCP(0xe5), MCP(0xe6), MCP(0xe7), MCP(0xe8), MCP(0xe9), MCP(0xea), MCP(0xeb), MCP(0xec), MCP(0xed), MCP(0xee), MCP(0xef),
  MCP(0xf0), MCP(0xf1), MCP(0xf2), MCP(0xf3), MCP(0xf4), MCP(0xf5), MCP(0xf6), MCP(0xf7), MCP(0xf8), MCP(0xf9), MCP(0xfa), MCP(0xfb), MCP(0xfc), MCP(0xfd), MCP(0xfe), MCP(0xff)
};

<EDIT> : Did spelling PR : github.com/mjs513/TMM-HB01B0-Camera/pull/28
 
Left Camera run with "V" - DMA - no problem!

Did 'b' and CRASH restart after a bit of messed up display!

Got this:
Code:
Using SDCARD - Initializing
initialization done.
CrashReport:
  A problem occurred at (system time) 9:23:37
  Code was executing from address 0x4C58534E
  CFSR: 1
	(IACCVIOL) Instruction Access Violation
  Temperature inside the [B][COLOR="#B22222"]chip was ovf °C[/COLOR][/B]
  Startup CPU clock speed is 600MHz

After adding this in setup():
Code:
  while (!Serial) ;
[B]  if ( Serial && CrashReport ) { // Make sure Serial is alive and there is a CrashReport stored.
    Serial.print(CrashReport); // Once called any crash data is cleared
    // In this case USB Serial is used - but any Stream capable output will work : SD Card or other UART Serial
  }
[/B]  Serial.println("HM01B0 Camera Test");

I do NOT have current CORES - but not sure why 'OVF" on chip temp?

<EDIT>: Perhaps BMP should be disabled when it would conflict with DMA or other display?
 
Good work - SD problem FIXED with the .begin edit from the ML specific!

'b' and 'z' work and file name/## indexes properly!

Question - these at top are horrendous to start the example viewing - can they go in .H - or moved to bottom with:
Code:
// BMP config for saving to SD Card or PC display
#define BMPIMAGEOFFSET 66
extern const uint16_t mono_palette[256];
extern const char bmp_header[BMPIMAGEOFFSET];

And removed a static on the one PROGMEM:
Code:
const char bmp_header[BMPIMAGEOFFSET] PROGMEM =
{
  0x42, 0x4D, 0x36, 0x58, 0x02, 0x00, 0x00, 0x00, 0x00, 0x00, 0x42, 0x00, 0x00, 0x00, 0x28, 0x00,
  0x00, 0x00, 0x40, 0x01, 0x00, 0x00, 0xF0, 0x00, 0x00, 0x00, 0x01, 0x00, 0x10, 0x00, 0x03, 0x00,
  0x00, 0x00, 0x00, 0x58, 0x02, 0x00, 0xC4, 0x0E, 0x00, 0x00, 0xC4, 0x0E, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xF8, 0x00, 0x00, 0xE0, 0x07, 0x00, 0x00, 0x1F, 0x00,
  0x00, 0x00
};
const uint16_t mono_palette[256] PROGMEM = {
  MCP(0x00), MCP(0x01), MCP(0x02), MCP(0x03), MCP(0x04), MCP(0x05), MCP(0x06), MCP(0x07), MCP(0x08), MCP(0x09), MCP(0x0a), MCP(0x0b), MCP(0x0c), MCP(0x0d), MCP(0x0e), MCP(0x0f),
  MCP(0x10), MCP(0x11), MCP(0x12), MCP(0x13), MCP(0x14), MCP(0x15), MCP(0x16), MCP(0x17), MCP(0x18), MCP(0x19), MCP(0x1a), MCP(0x1b), MCP(0x1c), MCP(0x1d), MCP(0x1e), MCP(0x1f),
  MCP(0x20), MCP(0x21), MCP(0x22), MCP(0x23), MCP(0x24), MCP(0x25), MCP(0x26), MCP(0x27), MCP(0x28), MCP(0x29), MCP(0x2a), MCP(0x2b), MCP(0x2c), MCP(0x2d), MCP(0x2e), MCP(0x2f),
  MCP(0x30), MCP(0x31), MCP(0x32), MCP(0x33), MCP(0x34), MCP(0x35), MCP(0x36), MCP(0x37), MCP(0x38), MCP(0x39), MCP(0x3a), MCP(0x3b), MCP(0x3c), MCP(0x3d), MCP(0x3e), MCP(0x3f),
  MCP(0x40), MCP(0x41), MCP(0x42), MCP(0x43), MCP(0x44), MCP(0x45), MCP(0x46), MCP(0x47), MCP(0x48), MCP(0x49), MCP(0x4a), MCP(0x4b), MCP(0x4c), MCP(0x4d), MCP(0x4e), MCP(0x4f),
  MCP(0x50), MCP(0x51), MCP(0x52), MCP(0x53), MCP(0x54), MCP(0x55), MCP(0x56), MCP(0x57), MCP(0x58), MCP(0x59), MCP(0x5a), MCP(0x5b), MCP(0x5c), MCP(0x5d), MCP(0x5e), MCP(0x5f),
  MCP(0x60), MCP(0x61), MCP(0x62), MCP(0x63), MCP(0x64), MCP(0x65), MCP(0x66), MCP(0x67), MCP(0x68), MCP(0x69), MCP(0x6a), MCP(0x6b), MCP(0x6c), MCP(0x6d), MCP(0x6e), MCP(0x6f),
  MCP(0x70), MCP(0x71), MCP(0x72), MCP(0x73), MCP(0x74), MCP(0x75), MCP(0x76), MCP(0x77), MCP(0x78), MCP(0x79), MCP(0x7a), MCP(0x7b), MCP(0x7c), MCP(0x7d), MCP(0x7e), MCP(0x7f),
  MCP(0x80), MCP(0x81), MCP(0x82), MCP(0x83), MCP(0x84), MCP(0x85), MCP(0x86), MCP(0x87), MCP(0x88), MCP(0x89), MCP(0x8a), MCP(0x8b), MCP(0x8c), MCP(0x8d), MCP(0x8e), MCP(0x8f),
  MCP(0x90), MCP(0x91), MCP(0x92), MCP(0x93), MCP(0x94), MCP(0x95), MCP(0x96), MCP(0x97), MCP(0x98), MCP(0x99), MCP(0x9a), MCP(0x9b), MCP(0x9c), MCP(0x9d), MCP(0x9e), MCP(0x9f),
  MCP(0xa0), MCP(0xa1), MCP(0xa2), MCP(0xa3), MCP(0xa4), MCP(0xa5), MCP(0xa6), MCP(0xa7), MCP(0xa8), MCP(0xa9), MCP(0xaa), MCP(0xab), MCP(0xac), MCP(0xad), MCP(0xae), MCP(0xaf),
  MCP(0xb0), MCP(0xb1), MCP(0xb2), MCP(0xb3), MCP(0xb4), MCP(0xb5), MCP(0xb6), MCP(0xb7), MCP(0xb8), MCP(0xb9), MCP(0xba), MCP(0xbb), MCP(0xbc), MCP(0xbd), MCP(0xbe), MCP(0xbf),
  MCP(0xc0), MCP(0xc1), MCP(0xc2), MCP(0xc3), MCP(0xc4), MCP(0xc5), MCP(0xc6), MCP(0xc7), MCP(0xc8), MCP(0xc9), MCP(0xca), MCP(0xcb), MCP(0xcc), MCP(0xcd), MCP(0xce), MCP(0xcf),
  MCP(0xd0), MCP(0xd1), MCP(0xd2), MCP(0xd3), MCP(0xd4), MCP(0xd5), MCP(0xd6), MCP(0xd7), MCP(0xd8), MCP(0xd9), MCP(0xda), MCP(0xdb), MCP(0xdc), MCP(0xdd), MCP(0xde), MCP(0xdf),
  MCP(0xe0), MCP(0xe1), MCP(0xe2), MCP(0xe3), MCP(0xe4), MCP(0xe5), MCP(0xe6), MCP(0xe7), MCP(0xe8), MCP(0xe9), MCP(0xea), MCP(0xeb), MCP(0xec), MCP(0xed), MCP(0xee), MCP(0xef),
  MCP(0xf0), MCP(0xf1), MCP(0xf2), MCP(0xf3), MCP(0xf4), MCP(0xf5), MCP(0xf6), MCP(0xf7), MCP(0xf8), MCP(0xf9), MCP(0xfa), MCP(0xfb), MCP(0xfc), MCP(0xfd), MCP(0xfe), MCP(0xff)
};

<EDIT> : Did spelling PR : github.com/mjs513/TMM-HB01B0-Camera/pull/28

Realized about the SD failing and pushed that fix up as well when I did the comments.

Good idea put them in there own .h file and pushed up the change.
 
Left Camera run with "V" - DMA - no problem!

Did 'b' and CRASH restart after a bit of messed up display!

Got this:
Code:
Using SDCARD - Initializing
initialization done.
CrashReport:
  A problem occurred at (system time) 9:23:37
  Code was executing from address 0x4C58534E
  CFSR: 1
	(IACCVIOL) Instruction Access Violation
  Temperature inside the [B][COLOR="#B22222"]chip was ovf °C[/COLOR][/B]
  Startup CPU clock speed is 600MHz

After adding this in setup():
Code:
  while (!Serial) ;
[B]  if ( Serial && CrashReport ) { // Make sure Serial is alive and there is a CrashReport stored.
    Serial.print(CrashReport); // Once called any crash data is cleared
    // In this case USB Serial is used - but any Stream capable output will work : SD Card or other UART Serial
  }
[/B]  Serial.println("HM01B0 Camera Test");

I do NOT have current CORES - but not sure why 'OVF" on chip temp?

<EDIT>: Perhaps BMP should be disabled when it would conflict with DMA or other display?

Noticed that after you do 'V' certain things will not work anymore like '1' to clear display and 'f', 'F' etc. Thought had crossed my mind to move the 'V' - dma to its own sketch. Not sure why have problems or how to fix - maybe @KurtE has an idea.

EDIT: okay seems to work in 8bit mode and using OpenMV reg settings.
Code:
Reading frame
Finished reading frame
* continuous mode started
* continuous mode stopped
Before Set frame complete CB
Before UPdateScreen Async
* continuous mode (Video) started
* continuous mode stopped
Reading frame
Finished reading frame
Reading frame
Finished reading frame
Reading frame
Finished reading frame
Reading frame
Finished reading frame
Calibrating Auto Exposure...
	not converged
Writing BMP to SD CARD File: 9px_0000.bmp

No error thrown with Sparkfun Reg settings either:
Code:
Reading frame
Finished reading frame
* continuous mode started
* continuous mode stopped
Before Set frame complete CB
Before UPdateScreen Async
* continuous mode (Video) started
* continuous mode stopped
Calibrating Auto Exposure...
	not converged
Writing BMP to SD CARD File: 9px_0001.bmp
Done Writing BMP
Reading frame
Finished reading frame
but then again I am using a ILI9341 not a ST7789 not sure that should make a difference.
 
@defragster - just pushed another minor update to the example. I moved the code to turn on BL for the ILI9341 to under the ILI9341 #ifdef as long as I was in the example again and before I forgot.
 
Been some time ... but the prior HardFault code was seeing similar IIRC. - some conflict with DMA ???

'F" okay with 'b' and 'z' - 2nd sketch might be safest and cleaner without the SDcard.

With updated CORES and updated example - adding CrashReport - a "V" then 'b' gave this - TEMP now VALID:
Code:
[U]ST7789_t3::init mode: 0[/U]
Using SDCARD - Initializing
initialization done.
HM01B0 Camera Test
HM01B0 Camera Test
HM01B0_FLEXIO_CUSTOM_LIKE_8_BIT
------------------
SENSOR DETECTED :-) MODEL HM01B0
OSC_CLK_DIV: 0x2B
ImageSize (w,h): 324, 244
Send the 'f' character to read a frame using FlexIO (changes hardware setup!)
Send the 'F' to start/stop continuous using FlexIO (changes hardware setup!)
Send the 'V' character DMA to TFT async continuous  ...
Send the 'p' character to snapshot to PC on USB1
Send the 'b' character to save snapshot (BMP) to SD Card
Send the '1' character to blank the display
Send the 'z' character to send current screen BMP to SD

Before Set frame complete CB
Before UPdateScreen Async
* continuous mode (Video) started
Calibrating Auto Exposure...
[U]ST7789_t3::init mode: 0[/U]
Using SDCARD - Initializing
initialization done.
[B]CrashReport:
  A problem occurred at (system time) 9:42:33
  Code was executing from address 0x8420
  CFSR: 82
	(DACCVIOL) Data Access Violation
	(MMARVALID) Accessed Address: 0x1A2020A0
  Temperature inside the chip was 57.90 °C
  Startup CPU clock speed is 600MHz
  Reboot was caused by auto reboot after fault or bad interrupt detected
[/B]HM01B0 Camera Test
HM01B0 Camera Test
HM01B0_FLEXIO_CUSTOM_LIKE_8_BIT
------------------
SENSOR DETECTED :-) MODEL HM01B0
OSC_CLK_DIV: 0x2B
ImageSize (w,h): 324, 244
Send the 'f' character to read a frame using FlexIO (changes hardware setup!)
Send the 'F' to start/stop continuous using FlexIO (changes hardware setup!)
Send the 'V' character DMA to TFT async continuous  ...
Send the 'p' character to snapshot to PC on USB1
Send the 'b' character to save snapshot (BMP) to SD Card
Send the '1' character to blank the display
Send the 'z' character to send current screen BMP to SD
I see Frank B caught some corrections in display when printf was removed - that probably relates to the "OVF" display above.
 
@defragster - just pushed another minor update to the example. I moved the code to turn on BL for the ILI9341 to under the ILI9341 #ifdef as long as I was in the example again and before I forgot.

Also brought back :: "continueous"

while( !Serial ) is gone ...

Should the CrashReport test be added for fun?
Code:
  if ( Serial && CrashReport ) { // Make sure Serial is alive and there is a CrashReport stored.
    Serial.print(CrashReport); // Once called any crash data is cleared
  }
 
Also noticed going back to :; //#define USE_SPARKFUN 1
Display is brighter? Last update enabled it and display was a couple shades darker ( too dark?)

After I changed to not USE_SPARKFUN the "F" was torn - did a power off restart and it came up clean and bright.

Is there any known case where 'POWER OFF/CYCLE' is needed for changes to work? Seems there were times reprogramming needed a power cycle?
 
All I can think of is the cam refs get corrupted so you have todo a restart. Always had a problem. Be honest the cam doesn’t impress me. You can adjust brightness etc in the sketch.
 
Just went back and forth USE_SPARKFUN or NOT. Power cycle not always need ... got torn TFT_ST7789 "F" once going !SFUN then next time going to SFUN.

May be window light in background diff in Exposure. SFUN DIMS to see detail in bright window and !SFUN just whites out the window (all the way to ceiling light) - except for dual displays on the desk behind me.

I noticed again One continuous is 'Selfie Mode' and the other is 'Camera' mode, i.e. 'left to right' is mirrored w/SFUN "left to right" and the other !SFUN is "right to left"

With "F" not seeing any 'finger wiggle issues' except at mid screen where frame is halved? {using TFT_ST7789 }

Was going to swap to ILI9341 - but ML doesn't make that as easy as on other board

<offline a bit>
 
Have to say as setup - that is a good example - only issue would be DMA "V" versus "F" might call for second "V" non SD example?

Not sure if either "V" or "F" is expected to be better? Both seem to have mid frame update line. "V" update seems to show more finger wiggle - maybe faster updates and DMA driven less CPU resources? But no loop count to confirm.
 
Have to say as setup - that is a good example - only issue would be DMA "V" versus "F" might call for second "V" non SD example?

Not sure if either "V" or "F" is expected to be better? Both seem to have mid frame update line. "V" update seems to show more finger wiggle - maybe faster updates and DMA driven less CPU resources? But no loop count to confirm.

Ok got back on the computer.

Think you are bringing up things that we already identified. Yes a lot of light seems to be an issue even if I point it directly at the screen. Haven't seen any issue with the ILI9341 think I ran into that as well.

With 'V' the dma transfers, believe it is a lot faster. The old example2 sketch with the SSD1306 is still there just in the old examples folder.

Again I haven't seen any issue with the options with the SD card? Not sure we need to break it out.

EDIT: ok pushed the fix for the spelling error.
 
Ok got back on the computer.

Think you are bringing up things that we already identified. Yes a lot of light seems to be an issue even if I point it directly at the screen. Haven't seen any issue with the ILI9341 think I ran into that as well.

With 'V' the dma transfers, believe it is a lot faster. The old example2 sketch with the SSD1306 is still there just in the old examples folder.

Again I haven't seen any issue with the options with the SD card? Not sure we need to break it out.

EDIT: ok pushed the fix for the spelling error.

Okay, maybe SD hang/Crash is just an issue with TFT_ST7789 in DMA?

- certainly a good example ...

Indeed lighting and reverse image not NEW - just pointing out alternate behavior madr apparent because SFUN went off/on between git updates ... like that typo ")
 
@Paul - update to makefile for Teensy_MicroMod :: TEENSY_MICROMOD

And CMDline tool?

...

This page seems to ref cmdline though T_4.1 ... though nothing yet for Teensy MicroMod that was announced days ago ")

pjrc.com/teensy/loader_cli.html

Installed with TeensyInstaller is :: {local install}\hardware\teensy\avr\cores\teensy4\Makefile

Code:
...

# Use these lines for Teensy 4.0
MCU = IMXRT1062
MCU_LD = imxrt1062.ld
MCU_DEF = ARDUINO_TEENSY40

# Use these lines for Teensy 4.1
#MCU = IMXRT1062
#MCU_LD = imxrt1062_t41.ld
#MCU_DEF = ARDUINO_TEENSY41


...
 
Status
Not open for further replies.
Back
Top