Teensy 4.0 First Beta Test

Status
Not open for further replies.
Is anyone using the Linux ARM version?

Me not.
Enough T4 for today.. it's 18:00 here and a cold beer waits.
beer-gif-9105093

HAPPY NEW YEAR TO EVERYONE!
 
Follow up to previous post about virtual functions... Sort of weird in that looks like VTABLE not setup for my simple class, but is setup for Serial and Serial1...

Current code:
Code:
class TestSerial : public Stream {
  public:
    TestSerial() {state_ = 0;};
    virtual int available(void);
    virtual int peek(void);
    virtual void flush(void);
    virtual size_t write(uint8_t c);
    virtual int read(void);
    using Print::write;
    size_t nonVirtualfunc(uint8_t c);
    uint8_t state_;
};

int TestSerial::available(void) {return 0;}
int TestSerial::peek(void){return 0;}
void TestSerial::flush(void) {return;}

size_t TestSerial::write(uint8_t c) {
  digitalWrite(3, HIGH);
  state_ = state_? 0 : 1;
 digitalWrite(13, state_);
 digitalWrite(3, LOW);
 return 0;  
}

size_t TestSerial::nonVirtualfunc(uint8_t c) {
  digitalWrite(3, HIGH);
  state_ = state_? 0 : 1;
 digitalWrite(13, state_);
 delay(100);
 digitalWrite(3, LOW);
 return 0;  
}

int TestSerial::read(void){return 0;}

TestSerial ts;

void setup() {
  while ( !Serial && millis() < 600 ) {
    if ( 0 == ARM_DWT_CYCCNT &&  0 == ARM_DWT_CYCCNT ) {
      digitalWrite(LED_BUILTIN, HIGH);
  //    SOME_SERIAL.println( "   ARM_DEMCR_TRCENA done!" );
      ARM_DEMCR |= ARM_DEMCR_TRCENA;
      // ARM_DWT_CTRL |= ARM_DWT_CTRL_CYCCNTENA; // turn on cycle counter << THIS LINE NOT NEEDED
    }
  }
  Serial.println("\n" __FILE__ " " __DATE__ " " __TIME__);
  Serial.println("Test begun");
  uint16_t cb = sizeof(TestSerial);
  Serial.printf("Test Serial: %x Size:%d ", (uint32_t)&ts, cb);
  uint8_t *b = (uint8_t*)&ts;
  while (cb--)Serial.printf("%x ", *b++);
  Serial.println();

  // Now lets try Serial
  cb = sizeof(Serial);
  Serial.printf("Serial: %x Size:%d ", (uint32_t)&Serial, cb);
  b = (uint8_t*)&Serial;
  while (cb--)Serial.printf("%x ", *b++);
  Serial.println();

  // Now lets try Serial1
  cb = sizeof(Serial);
  Serial.printf("Serial1: %x Size:%d ", (uint32_t)&Serial1, cb);
  b = (uint8_t*)&Serial1;
  while (cb--)Serial.printf("%x ", *b++);
  Serial.println();

  
  // put your setup code here, to run once:
  pinMode(13, OUTPUT);
  pinMode(2, OUTPUT);
  pinMode(3, OUTPUT);
  pinMode(4, OUTPUT);

  for (uint8_t i=0; i< 5; i++) {
    digitalWrite(13, HIGH);
    delay(250);
    digitalWrite(13, LOW);
    delay(250);
  }
  
}
uint8_t buf[]={0,1};
void loop() {
  digitalWrite(2, HIGH);
  //ts.write((uint8_t)0x00);  // see if we call through the virtual function
  ts.write(buf, 1);
  //ts.nonVirtualfunc(0);
  digitalWrite(2, LOW);
  delay(500);
}

Test output:
Code:
/Users/kurt/Documents/Arduino/TestVirtualCall/TestVirtualCall.ino Dec 31 2018 09:23:57
Test begun
Test Serial: 20002000 Size:16 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
Serial: 20000a64 Size:16 14 5 0 20 0 0 0 0 e8 3 0 0 0 0 0 0 
Serial1: 200009a0 Size:16 b8 0 0 20 0 0 0 0 e8 3 0 0 0 0 0 0 
Print::write 20002000 2000099c 1
0 0 0 0 0 0
First 4 data bytes should be VTABLE, looks like Serial and Serial1 both have one, but my simple class does not... All 0s. Maybe as constructors are different...

Update: If I make the constructor: constexpr TestSerial() {}

VTable is now created and test runs...
 
Last edited:
Maybe it's all that C++ stuff I didn't put into the linker script yet?

Or could be the C++ constructor init stuff missing in setup.c?
 
Thanks Paul,

I think you are right. As I mentioned in update to previous message works now with constexpr TestSerial() {}

Ok well now back to Hardware Serial
 
I've uploaded version 1.46-beta4 to msg #2, with many fixes. This version will update your bootloader from 0.01 to 0.02, to (hopefully) fix all the cycle counter problems. Also included are fixes for USB serial printing at startup (before your PC ready), while (!Serial) should now work, Frank's IRQ priority patches are included, Wire scanner should be improved (may still have issues?), PWM on pins 0 & 1 fix included (untested), Tools > Optimize for Fastest and Debug should now work, and core libraries code should no longer interfere with pin 13.

Issues with digitalRead are unresolved. I couldn't reproduce problems with it changing a pin while in output mode, but it does appear to be unable to read the pin if the hardware is configured for output. It definitely does work when the pin is in INPUT_PULLUP mode.

C++ vtables & constructors are probably still broken for non-constexpr classes. Will get a fix for that into the next update.
 
Just loaded up the new version the it did indicate that the bootloader was being updated. Also verified:
1. while(!Serial); - is fixed! Put this in a couple of sketches i had open - testing i2c again
2. i2cScanner now works! Just hooked up a BME280 to the T4 and the scanner now shows:
Code:
Scanning...
Device found at address 0x77  (BMP085,BMA180,BMP280,MS5611,BME280)
done

Now for the bad news. I loaded up Adafruits BME280 library - compiled no issues but could not connect to the sensor. I had a scope on SCK and SDI and I did not see any signals. Maybe I did something wrong or there is something flaky with the library. After wire begin it does a read to get the sensor id as a connection check, this is the code it is using to read:
Code:
read8(byte reg) {
    uint8_t value;
    
    if (_cs == -1) {
        _wire -> beginTransmission((uint8_t)_i2caddr);
        _wire -> write((uint8_t)reg);
        _wire -> endTransmission();
        _wire -> requestFrom((uint8_t)_i2caddr, (byte)1);
        value = _wire -> read();
    } else {
        if (_sck == -1)
            SPI.beginTransaction(SPISettings(500000, MSBFIRST, SPI_MODE0));
        digitalWrite(_cs, LOW);
        spixfer(reg | 0x80); // read, bit 7 high
        value = spixfer(0);
        digitalWrite(_cs, HIGH);
        if (_sck == -1)
            SPI.endTransaction(); // release the SPI bus
    }
    return value;
Any suggestions. Going to play some more to make sure it still is getting there

EDIT: Think its the library - more to follow
 
Downloaded and installed: Good work.

CycleCounter Problem solved in the sketches I ran - CycleCounter was active coming into setup()!

<edit>: And the USB debug control of LED_BUILTIN is out so the LED BLINKS right!

I see that :: while ( !Serial && millis() < 1000 ); now leaves the loop for Serial==TRUE! at millis=543 ! Though BLINK stops when SerMon Closed until opened:
2009172 Micros=2008310
status = 000A0080
status = 00000000
2012399 Micros=2008310
status = 00070080 << closed here ?
status = 00070080
....


FYI Here are two log files is you want to see the Bootloader Update: View attachment BLupdate_log.txt View attachment BLupdate2_log.txt
{ had to button push in first - TyComm monitor on debug Teensy started active on Serial - then went normal }
 
Issues with digitalRead are unresolved. I couldn't reproduce problems with it changing a pin while in output mode, but it does appear to be unable to read the pin if the hardware is configured for output.

FWIW, the EVKB board can read a pin configured for OUTPUT, reads the GPIO DR register. (could it be a bit-band problem?)
 
Code:
19:54:13.821 (loader): Bootloader update: 63% of estimated 8 seconds, wait=50
19:54:13.857 (ports 5): WM_DEVICECHANGE DBT_DEVICEARRIVAL
19:54:13.863 (ports 5): found_usb_device, id=\\?\usb#vid_16c0&pid_0478#000186bd#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
19:54:13.863 (ports 5): found_usb_device, loc=usb:0/1D0000/0/1/6/3    Port_#0003.Hub_#0006
19:54:13.863 (ports 5): found_usb_device, hwid=USB\VID_16C0&PID_0478&REV_0002
19:54:13.863 (ports 5): found_usb_device, devinst=00000011
19:54:13.863 (ports 5): add: loc=usb:0/1D0000/0/1/6/3, class=HID, vid=16C0, pid=0478, ver=0002, serial=000186bd, dev=\\?\usb#vid_16c0&pid_0478#000186bd#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
19:54:13.863 (ports 5): hiddev_from_devinst_list: iface=0
19:54:13.863 (ports 5): found_usb_device complete
19:54:13.863 (ports 5): hid, found devinst=00000012
19:54:13.863 (ports 5): hid, path=\\?\hid#vid_16c0&pid_0478#8&365c6bdd&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}
19:54:13.864 (ports 5): hid,  opened handle
19:54:13.864 (ports 5):  devinst=00000012, location=usb:0/1D0000/0/1/6/3
19:54:13.864 (ports 5):  vid=16C0, pid=0478, ver=0002, usepage=FF9C, use=0023
19:54:13.864 (ports 5):  devpath=\\?\hid#vid_16c0&pid_0478#8&365c6bdd&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}
19:54:13.864 (ports 5): usb_add: usb:0/1D0000/0/1/6/3  hid#vid_16c0&pid_0478 (Teensy 4-Beta) Bootloader
19:54:13.962 (loader): Bootloader update: 64% of estimated 8 seconds, wait=51
19:54:13.962 (loader): Bootloader update finished, 5.1 seconds
19:54:13.962 (loader): Board is: Teensy 4-Beta1 (IMXRT1052), version 0.02
Bootloader update successful :D
 
Time to reboot my machine perhaps - Trying UPLOAD request HUNG IDE before it 'cleared' Console window from prior upload - waited 20+ seconds <before button push> - Then saw T_Loader was on T4 image and RED LED was on in some fashion? Button tap - nothing - unplugged T4 and T_3.1 and I think another tap and it uploaded after IDE came back to life - ALL GOOD, just IDE STALL before upload again


I put if (Serial ) before prints and the BLINK runs when SerMon closed - and I get debug out from this:
Code:
  if ( Serial )   Serial.println( micros() - oMicros );
  else   Serial4.print( "   Serial Offline!" );
 
Last edited:
BME280 Library ISSUE:

Reason I am making this a separate message is that most of Adafruits sensor libraries that use SPI and I2C use the follow construct:
Code:
Adafruit_BME280::Adafruit_BME280()
    : _cs(-1), _mosi(-1), _miso(-1), _sck(-1)
{ }
then when you do a
Code:
Adafruit_BME280 bme; // I2C
it suppose to default to I2C by testing whether the _cs = -1 or not. Right now if you print _cs out it returns a 0 so never initializing I2C. Just as a check I ran this code to read the sensor id:
Code:
void setup() {
  while (!Serial);
  Wire.begin();
  delay(1000);
  Wire.beginTransmission(0x77);
  Wire.write(0xD0);
  Wire.endTransmission();
  Wire.requestFrom(0x77, (byte)1);
  Serial.println(Wire.read(), HEX);
}
and it returned the correct value. So i2c is working but that construct doesn't seem to be. And before you ask it been that way for years and I have run it on a T3.2 and T3.5. So not sure if its a compiler issue or not. Just needed to get this out there since I think one of reasons for testing was to check the libraries as well.
 
Updated the temperature monitoring sketch to read out CCM_ANALOG_MISC1 register bits for the temp IRQ flags. High trips when you get the temp over the high alarm temp but low temp bit seems to be always set - not sure how to get that cleared. The high bit clears automatically when it goes below the high alarm threadhold. Still trying to figure out how to set up nvic enable and association a function call with that. Guess that's next.
 
Updated the temperature monitoring sketch to read out CCM_ANALOG_MISC1 register bits for the temp IRQ flags. High trips when you get the temp over the high alarm temp but low temp bit seems to be always set - not sure how to get that cleared. The high bit clears automatically when it goes below the high alarm threadhold. Still trying to figure out how to set up nvic enable and association a function call with that. Guess that's next.

Good work Mike - got a fork, but not run it yet. Been distracted with CycleCounter and startup that is working Very Well now!

Is this what you need>> Msg #6 item :: AttachInterrupt is on the list.
 
Updated the temperature monitoring sketch to read out CCM_ANALOG_MISC1 register bits for the temp IRQ flags. High trips when you get the temp over the high alarm temp but low temp bit seems to be always set - not sure how to get that cleared. The high bit clears automatically when it goes below the high alarm threadhold. Still trying to figure out how to set up nvic enable and association a function call with that. Guess that's next.

You have to enable interrupts in the control registers, then it goes something like
attachInterruptVector(IRQ_TEMPERATURE, &yourisr);
NVIC_ENABLE_IRQ(IRQ_TEMPERATURE);

attachInterruptVector(IRQ_TEMPERATURE_PANIC, &yourisr2);
NVIC_ENABLE_IRQ(IRQ_TEMPERATURE_PANIC);
 
@manitou
That's exactly what I need todo. Was googling it. Something else I never played with, man, this is a learning experience. Something so simple but takes me forever to get working.

EDIT: Guess attachInterruptVector works. I added that to the sketch and its working as expected. Unfortunates still have to sort out the issue with the low temp irq bit always being set.

EDIT2: Just committed the change to github
 
Last edited:
Adafruit_BME280::Adafruit_BME280()
: _cs(-1), _mosi(-1), _miso(-1), _sck(-1)
{ }
Probably another case, like I was running into that the constructor and the like may not be called...
Paul mentioned this as regard to my test around #178 and #180.

Currently trying to figure out why my changes to HardwareSerial constptr stuff is not currently working... I believe everything is initialized with stuff that should not require compiler calling to constructor...
 
Teensy 4 beta arrives. MIIMXRT1052 CTAJ1820B (batch date, i reckon) #26
LED blinking
Using 1.8.8 with 1.46-beta4 linux32

Code:
           CCM_ANALOG_PLL_ARM 0x80002064
           CCM_ANALOG_PLL_USB1 0x80003040
           CCM_ANALOG_PLL_USB2 0x12000
           CCM_ANALOG_PLL_SYS 0x80002001
           CCM_ANALOG_PFD_480 0xF1A2318
           CCM_ANALOG_PFD_528 0x18131818
           CCM_CBCDR 0x180A8300
           CCM_CBCMR 0x35AE8304
           CCM_CCGR1 0xFCFFC000
           CCM_CCGR2 0xC3FF033
           CCM_CCGR3 0xF00FF300
           CCM_CCGR4 0xFFFFFF
           CCM_CCGR5 0xF0033C33
           CCM_CCGR6 0xFCFF3FC3
           CCM_CSCMR1 0x66930040
           CCM_CSCDR1 0x6490B40
           SCB_CPACR 0xF00000
           SYST_CSR 0x10003
           SYST_RVR 0x63

mjs513's clocks
          System Clock: 600000000
          IPG Clock: 150000000
          RTC Clock: 32768
          USB1pll Clock: 480000000

mjs513 tempmon
   TEMPMON driver example.
   The chip initial temperature is 48.09
   temperature is 49.6 
   temperature is 49.6 
   temperature is 48.8

LED blink power (through hacked USB cable) LED off/on 85.0/88.2 ma (specs 0.11ma/MHz ==> 66 ma)

Vin 4.97v 3v3 3.29v pin 13 high 3.242v
Code:
coremark@600mhz  (timing with micros())
   Total time (secs): 10.875010
   Iterations/Sec   : 2298.848461   -O2
   Iterations       : 25000
   -O3  2420.504578
   -O1  1720.399523

               coremarkish   Dhrystone 2.1
              iterations/sec  DMIPS
    T4@600mhz      2421        2175   gcc -O3
    M7@600mhz      2438        2033   ARM CC -O3
      @528mhz      2146
      @132mhz       536
       @24mhz        97
  T3.6@256mhz       659        1120   Fastest+pure+LTO
  T3.6@180mhz       434         287   Faster
  T3.6@120mhz       289         191   Faster
  T3.5@120mhz       261         138   Faster
  T3.2@120mhz       254         106   Faster
  adaM4F@120mhz     272         168   -O2  SAMD51
  STM32L4@80mhz     208          63

   coremark compiler optimizations (iterations/sec)  1062@600MHz
                         Teensy4  Teensy4   NXP SDK
gcc compiler               5.4.1    7.3.1     7.2.1
-O3                       2427.4   2394.7    2439.2
-O3 -funroll-loops        2563.2   2564.9    2626.7
-O3 -funroll-all-loops    2659.4   2625.4    2673.3
compare with other MCU performance

analogWrite(1,128) OK, scope reports 4.46khz, 50% duty, Vpp 3.88 (flexpwm)
analogWrite(0,128) ok

analogWrite(10,128) ok, scope 3.6 khz (qtmr)

confirmed digitalRead(13) reads 0 :confused: with pinMode OUTPUT and 13 HIGH. GPIO2_DR reports pin 13 settings correctly.

Code:
Speed test
----------
F_CPU = 396000000 Hz
1/F_CPU = 0.0025 us
The next tests are runtime compensated for overhead
nop                       : 0.003 us
Arduino digitalRead       : 0.089 us
Arduino digitalWrite      : 0.069 us
pinMode                   : 0.214 us
multiply volatile byte    : 0.017 us
divide volatile byte      : 0.027 us
multiply volatile integer : 0.015 us
divide volatile integer   : 0.027 us
multiply volatile long    : 0.017 us
multiply single float     : 0.012 us
divide single float       : 0.039 us
multiply double float     : 0.022 us
divide double float       : 0.052 us
random()                  : 0.102 us
bitSet() with volatile    : 0.013 us
analogRead()              : 18.002 us
analogWrite() PWM         : 0.282 us
delay(1)                  : 1000.002 us
delay(100)                : 100000.002 us
delayMicroseconds(1)      : 1.017 us
delayMicroseconds(5)      : 5.021 us
delayMicroseconds(100)    : 100.002 us
F_CPU is 396, but clock is really 600 mhz
 
Last edited:
Probably another case, like I was running into that the constructor and the like may not be called...
Paul mentioned this as regard to my test around #178 and #180.
you mean this:

Maybe it's all that C++ stuff I didn't put into the linker script yet?
Or could be the C++ constructor init stuff missing in setup.c?
Yeah, I have this bad tendency to call everything with the C++ a compiler issue guess I have to get out of that habit.
 
Congrats Manitou - welcome to the club! F_CPU is passed in from BUILD as F_CPU = 396000000

Your numbers are good, telling and fun as usual!

Here are some trivial ones from a new sketch:
>> elapsedMillis based BLINK cycles Loop() at :: ~ 22227958 or 21412780 (when blink logic counted) times per second.

>> T4 arrives in setup() at millis=143

>> No problem with early Serial.print, in setup() this : while ( !Serial ) { Serial.println( millis() ); ii++; } takes ii from Zero to 1214493 (sometimes 890955) with printing before Serial gets active on this run at millis=547
No Harm and no Foul and these values appear to be buffered before it starts (newlines removed):
317 528 528 532 532 533 533 533 533 534 535 537 537 540 540

and the sketch:
Code:
#define HW_SERIAL Serial4

uint32_t SFirst = 0;
uint32_t ii = 0;
elapsedMillis noDelay;
void setup() {
  pinMode(LED_BUILTIN, OUTPUT);
  digitalWrite( LED_BUILTIN, HIGH );
  Serial.println("\n" __FILE__ " " __DATE__ " " __TIME__);
  HW_SERIAL.print( "   millis=" );
  HW_SERIAL.println( millis() );
  Serial.print( "   millis=" );
  Serial.println( millis() );
  while ( !Serial ) {
    Serial.println( millis() );
    ii++;
  }
  Serial.println("\n" __FILE__ " " __DATE__ " " __TIME__);
  SFirst = millis();
  Serial.print( "   Serial First millis=" );
  Serial.println( SFirst );
  Serial.print( "   while Count ii=" );
  Serial.println( ii );
  delayMicroseconds( 100 );  // test of Cycle Counter Active
  ii = 0;
  noDelay = 0;
}

bool flip = true;
void loop() {
  ii++;
  if ( noDelay > 1000 ) {
    noDelay -= 1000;
    digitalWrite( LED_BUILTIN, flip );
    flip = !flip;
    HW_SERIAL.println( ii );
    ii = 0;
  }
}

<updated is delayMicroseconds test> After update new version 880K fewer loops because noDelay -= 1000; counts time in if to blink.
<edited Msg #6 for beta 4 fixes>
 
Last edited:
@manitou
Glad you got the T4 to play with. I always liked how you did your analysis - methodical.

Saw you used my clock stuff. Just a couple things to remember. RTC clock is fixed at 32768 so don't plan on using to measure the actual rtc values. Had to do a kludge to get it to work - but going to try and get rid of that soon. Too many coals in the fire once I got the T4. Also you are not limited to those clocks - should be able to get them all. I only used a couple in my sketch. They are all listed the pll enumerator.

Now back to I2C.
I modified Kris Winer's MPU-9250 sketch that he uses for his MPU-9250 board to use Wire and not i2c_t3. Some good things came out of it:
1. The i2cScanner code (mirror of the stand alone) correctly identified the AK8963 Magnetometer, the MPU-9250, and the BME280 pressure sensor.
2. Sketch was able to pull all the raw data (mag, gyro and accel) correctly - at least from looking at the data. 1g was pretty much along the z-axis.
3. The AHRS algorithm (Mahoney) ran and was giving good results - didn't really do a great mag calibration as just wanted to test i2c.

So I would say that I2C seems to be working, used 100khz. Using the adafruit FRAM library to test the fram breakout board worked fine - wrote and read the values back correctly without errors. Think I need to start focusing on getting one thing done at a time - but then again that wouldn't be any fun - I think.

EDIT: Have been using while(!Serial) and that seems to be working without an issue.
 
Maybe already reported, but Serial.read/Serial.available() not working --- hanging.

I have to hit the program button after most uploads ??

some of my benchmarks that take < 10 us are getting 0 us, since micros() resolution is only 10 us, because SysTick is running with 100 KHz clock -- i may have to hack the core to make SysTick use 600mhz clock. :(

util/crc16.h not available
 
Last edited:
Didn't want to leave anything hanging to go over to the New Year so:
1. Temp Monitor sketch updated and now works exactly the way it should with the interrupts.
2. Update the get clock frequency sketch to get rid of that kludge I put in for testing and added the prints for all the clocks:
Code:
System Clock: 600000000
IPG Clock: 150000000
RTC Clock: 32768
USB1pll Clock: 480000000
Peripheral Clock: 24000000
Osc Clock: 24000000
Arm Clock: 1200000000
Semc Clock: 200000000
Usb1PllPfd0 Clock: 360000000
Usb1PllPfd1 Clock: 246857130
Usb1PllPfd2 Clock: 332307684
Usb1PllPfd3 Clock: 576000000
Usb2Pll Clock: 24000000
SysPll Clock: 528000000
SysPllPfd0 Clock: 396000000
SysPllPfd1 Clock: 396000000
SysPllPfd2 Clock: 500210514
SysPllPfd3 Clock: 396000000
EnetPll0 Clock: 0
EnetPll1 Clock: 0
AudioPll Clock: 0
VideoPll Clock: 0

Have to do a better job on the names. A lot of bloat in the .h file because of the defines, one of these days may just hardcode them where they belong.

Forgot the updated sketches are on my GitHub page and more important since its about 7pm here

HAPPY AND SAFE NEW YEAR!!
 
Last edited:
Maybe already reported, but Serial.read/Serial.available() not working --- hanging.

I have to hit the program button after most uploads ??

On the list in p#6 - "USB Serial receive".

I've uploaded many times - unless the LED is PANIC blink from fault or bad code otherwise the Button not needed? Try sketch post #196 a few times?

Wondering about WFI I found this in sleep.h :: #define sleep_cpu() ({__asm__ volatile("wfi");})
<based on my post #49 note: There are new [Pre/POST] steps for WFI - page 11 of this : iMXRT_LowPower_AN12085 >

Is it correct that systick_isr is no longer a thing? It is handled internally without an interrupt?

Doing WFI left the sketch halted. So I added IntervalTimer ITtest; to start an _isr.

Results are mixed? Sketch below cycles, but the clock is running half speed with NO_WFI? If that line is commented it doesn't run beyond the WFI - so no waking interrupt.
Alternatively - leave NO_WFI defined and swap to this line and it runs once 'enough' interval timer _isr have come through? :: //volatile uint32_t jj = 996;

Not sure why interrupts are not waking from WFI, and wondering why a seconds seems to take 2000 ms's?

Code:
#define NO_WFI 1

#define HW_SERIAL Serial4
#define sleep_cpu()    ({__asm__ volatile("wfi");})

IntervalTimer ITtest;
volatile uint32_t jj = 0;
//volatile uint32_t jj = 996;


void TimeSome() {
  jj++;
}

elapsedMillis noDelay;
void setup() {
  pinMode(LED_BUILTIN, OUTPUT);
  digitalWrite( LED_BUILTIN, HIGH );
  while ( !Serial );
  Serial.println("\n" __FILE__ " " __DATE__ " " __TIME__);
  ITtest.begin( TimeSome, 1000);
  noDelay = 0;
}

bool flip = true;
void loop() {
  if ( noDelay > 1000 ) {
    noDelay -= 1000;
    digitalWrite( LED_BUILTIN, flip );
    flip = !flip;
    HW_SERIAL.print( "ITcnt=" );
    HW_SERIAL.println( jj );
    HW_SERIAL.print( "micros=" );
    HW_SERIAL.println( micros() );
    jj = 0;
    //sleep_cpu();
  }
#ifdef NO_WFI
  if ( jj<995 )
#endif
    sleep_cpu();
}
 
Last edited:
Status
Not open for further replies.
Back
Top