K66 Beta Test

Status
Not open for further replies.
defragster said:
This is a K64 question but where does the K64 stand on OC? How usable are 144 and 168 - I edited in 168 but see 144 and 180 and 192 have specs but no menu entry? It seems I tried one other first and the compiler said that 'speed' wasn't defined.
Click to expand...

Perhaps worth a try and disable HSRUN for 144..168 MHZ on K66 completely ?
Some weeks ago, i tried it with 180MHz - this did not work.
 
Last edited:
tni said:
This digitalReadFast test is pretty bogus. Since the result doesn't get used, half of it gets optimized away. So it results in this:
Code: 
ldr	r0, [r3, #0]
This is missing the bit masking for the pin. This will never ever happen in real code where the result is not thrown away without looking at it. DigitalReadFast reads the entire port register and must thus mask out the other pins.

If I assign the result to a volatile bool in the test, it looks like this:
Code: 
ldr	r1, [r6, #0]
ubfx	r1, r1, #5, #1
strb.w	r1, [sp, #9]
The port register is read, bit 5 is extracted, the result is put into a bool on the stack. This takes 7x longer than the test above (this 7x is a bit unfair, since the stack store probably takes half the time).

I have experimented with using bitbanding, where you can extract the pin value in a single instruction (which does happen), but GCC generates code that is worse than digitalReadFast if you don't know exactly what you are doing.
Click to expand...

Rather than setting a volatile boolean variable, I would think a runtime test against digitalReadFast might mirror the code better (GCC on various machines, can optimize if ((a & mask) != 0) type tests).

Perhaps:

Code: 
volatile int read_fast;

   // ...
   read_fast = (digitalReadFast (pin)) ? 3 : 5;

Or maybe:
Code: 
volatile int read_fast;

    // ...
    int rf_count = 0;
    for (int i = 0; i < 10000; i++)
      {
        if (digitalReadFast (pin))
          rf_count++;
      }
    read_fast = rf_count;

The later doesn't do a store in the in loop, but uses a local variable to act as a counter (GCC would typically keep it in a register for the loop).
 
I had a little problem... i thought that my T3.6 pre-production (still waiting for the others..) was broken.
I happened this way:

It was running a sketch, just normal. Then, i pressed the "reset"-button in TYQT. It went away from USB but did NOT COME BACK (?).
I disconnected the USB-Cable, re-connected, and nothing happened. No Windows-Sound. No Sketch running, no USB. 3 Times.

It came back to live with a restart of the Teensy-loader and connecting the cable + pressing the button...

Phew...
 
Last edited:
MichaelMeissner said:
Rather than setting a volatile boolean variable, I would think a runtime test against digitalReadFast might mirror the code better (GCC on various machines, can optimize if ((a & mask) != 0) type tests).

Perhaps:

Code: 
volatile int read_fast;

   // ...
   read_fast = (digitalReadFast (pin)) ? 3 : 5;

Or maybe:
Code: 
volatile int read_fast;

    // ...
    int rf_count = 0;
    for (int i = 0; i < 10000; i++)
      {
        if (digitalReadFast (pin))
          rf_count++;
      }
    read_fast = rf_count;
The later doesn't do a store in the in loop, but uses a local variable to act as a counter (GCC would typically keep it in a register for the loop).
Click to expand...
Using a bool is no slower than an int. The "ubfx r1, r1, #5, #1" is using the pin mask to extract a single bit from the port input register that was just read. That is effectively a bool and ready for use.

If your intend is to minimize the non-digitalRead work, your code does MUCH more other work than the volatile bool store.
 
Frank B said:
I had a little problem... i thought that my T3.6 pre-production (still waiting for the others..) was broken.
I happened this way:

It was running a sketch, just normal. Then, i pressed the "reset"-button in TYQT. It went away from USB but did NOT COME BACK (?).
I disconnected the USB-Cable, re-connected, and nothing happened. No Windows-Sound. No Sketch running, no USB. 3 Times.

It came back to live with a restart of the Teensy-loader and connecting the cable + pressing the button...

Phew...
Click to expand...

Frank, a common 'feature' on my side is that I have from time to time to disconnect the hub where my teensy is connected to, from the PC to get a response from teensy.
It was not sufficient that I disconnected the teensy from the hub.

This indicates to me that from time to time it may happen that teensy corrupts the hub, or lets the bub in a strange state.
In my case, where I test my data acquisition software with 3Mbyte/s write to uSD and simlpy remove the uSD while software is still running, this situation is more frequent.

Also I'm using nearly exclusively my teensy_loader_cli.exe derivative.

Before you ask, the hub is a renkforce 4-port USB3.0 hub, which features also some connection leds that are very interesting to watch during the programming light, especially the time the teensy needs to connect to USB for programming and for running after programming.
 
Frank: I've been using TYQT pretty exclusively for programming and serial monitor ( now ver:7.5-210 ) and use the Reset often.

As the beta moved along I saw a couple times with odd - maybe similar behavior - I did have to get TeensyLoader involved it seemed when there were TDuino updates? Not recently however since later versions of TYQT and 1.30+ have released. Like WMXZ I suspect the PC's USB is getting bothered somehow as I have had times where a T_3.2 wouldn't reprogram until I put on a different unit to program first.
 
Frank B said:
I had a little problem... i thought that my T3.6 pre-production (still waiting for the others..) was broken.
I happened this way:

It was running a sketch, just normal. Then, i pressed the "reset"-button in TYQT. It went away from USB but did NOT COME BACK (?).
I disconnected the USB-Cable, re-connected, and nothing happened. No Windows-Sound. No Sketch running, no USB. 3 Times.

It came back to live with a restart of the Teensy-loader and connecting the cable + pressing the button...

Phew...
Click to expand...

Be careful that Teensy Loader is not running or that its autoflash mode is disabled when you do a reset (or upload) with TyQt. The reset button puts the Teensy in bootloader mode first, and then it triggers a reset without uploading anything... But if the Teensy Loader starts to flash the board when it detects it in bootloader mode, TyQt will then reset a partially flashed board and it won't work anymore. Until you flash it again, of course., just like you did.

Also, just like WMXZ and defragster say, some hubs get confused when a lot of USB connects and disconnects happen in a short time. Windows also does weird things on occasion.
 
Last edited:
Koromix said:
Be careful that Teensy Loader is not running or that its autoflash mode is disabled when you do a reset (or upload) with TyQt.
Click to expand...

Frank B said:
Opps. I guess, that was the problem.. This also explains why it seemed to be "dead".
Click to expand...

That could explain the incidents I saw as well - as noted they were during "TDuino updates?" - which means the TYQT integration was broken - and if TYQT was open when the IDE opened Teensy.exe there would be race to service a Teensy. Might be cool if TYQT could alert when Teensy.exe was resident? I likely recognized that at the time and fixed it and just didn't recall it above.
 
Fyod said:
Quick question - on the 3.5/3.6 can any digital pin be used for i2c interrupt?
Click to expand...

Which library is being used? wire or i2c_t3? Someone may know if it matters without looking, but I'd have to see the TeensyDuino installed code to know.
 
i2c_t3 due to the pins on the bottom being used. Ideally, I'd like to use bottom pin 46 for the interrupt.
 
I have not looked at this before - but will want to soon. Glancing at the i2c_t3 code I assume T_3.6 is the Master and the i2c Slave will interrupt on pin 46 when it has new information?

For that you do attachInterrupt( 46, blah_isr, -state- )? If so then all digital pins - including 46 - are interrupt capable on the T_3.6
 
Hey Paul,

Any updates on the release of the Teensy 3.6 schematic? Been loving playing with the new chips.

Best,
Brian
 
PaulStoffregen said:
It's near the top of my todo list. So is basic SDIO support in the SD library.

Whether I get it in tomorrow or early next week is a good question. Friday to Monday will be consumed with travel for NY Maker Faire.
Click to expand...

Paul, have you viewed my HSRUN drop/restore as a general solution to getting the USB_Serial number out while T_3.6 is in HSRUN? Functionally it works - like it does for EEPROM access, perhaps something is unsettling about it? At least during the INIT code interrupts are already off and nothing else is active yet. And once it is done the value seems cached on the usable side of the processor so subsequent user calls worked as I saw them without repeating the HSRUN drop/restore.

Even for extensive days long EEPROM I/O the HSRUN drop/restore works as presented in that PULL request. My tests intermingled with standard operation of processor and USB, Grieman SDIO during his yields, and MichaelM used it with PROP shield calibration. If you have concerns to test against let me know.
 
ChibiOS/RT on K64/K66
I managed to get Bill's ChibiOS library to work on K66/K64 (T3.6/T3.5). To make the library "compatible" I changed the architectures to * in ChibiOS/library.properties, and to get it to compile, to the front of ChibiOS/src/CMSIS/core_cm4.h i added
Code: 
#if defined(__MK66FX1M0__) || defined(__MK64FX512__)
#define __FPU_PRESENT 1U
#endif
Bill notes that that ChibiOS has evolved (from 3.0.3) since he developed the library, so it's unclear if the github will be updated.

Earlier discussions at https://forum.pjrc.com/threads/540-ChibiOS-RTand-FreeRTOS-for-Teensy-3-0
 
Status
Not open for further replies.
Back
Top