K66 Beta Test

defragster · Jun 21, 2016

Same results on CLEAN installed Win_7 machine with IDE 1.6.9 TD_1.29b3 with unedited clocks so far. 240 never plays , 216 sometimes sow - often just SPEWS 'Start playing'. Device often powered off - no change. - normally I see no issues changing clock speed before the Audio Card?

These files are versioned the same - so it is a current problem as far as I can see.

"I:\arduino_169\hardware\teensy/../tools//teensy_post_compile" "-file=Part_1_03_Playing_Music.ino" "-path=C:\Users\Tim\AppData\Local\Temp\build4fa42db0bab9334eb2e06a3f9be609c1.tmp" "-tools=I:\arduino_169\hardware\teensy/../tools/" "-board=TEENSY35"
Using library Audio at version 1.03 in folder: I:\arduino_169\hardware\teensy\avr\libraries\Audio
Using library SPI at version 1.0 in folder: I:\arduino_169\hardware\teensy\avr\libraries\SPI
Using library SD at version 1.0.8 in folder: I:\arduino_169\hardware\teensy\avr\libraries\SD
Using library SerialFlash at version 0.4 in folder: I:\arduino_169\hardware\teensy\avr\libraries\SerialFlash
Using library Wire at version 1.0 in folder: I:\arduino_169\hardware\teensy\avr\libraries\Wire

Will make the clock edits FrankB suggested on this machine in all three files and update.

Frank - Thanks for reading the Winbond docs - Flash 50MHz max. The one sample file under 14MB - I'll put that on 16MB SerFlash and try this sample from there too.

<edit>: it will sometimes play for a short time at 240 MHz - sometimes longer then just quits- after power cycle or a K66 (GND short to) Reset.

This $4 device is great to power cycle Teensy without unplugging: Digispark Programming Tool is a USB switch with a female USB connector on one end, a proper male connector on the other, and a switch on the USB 5v power connection

Frank B · Jun 21, 2016

oops.. mp3/aac/flac plays too fast with these numbers! -> need more investigation

I've updated.. FLAC is working now in "standard-mode"

Had to choose a different interrupt# - but i found a free one which is the same on all Teensy 3.1...3.5

So..audiocodecs-update is done.

FLAC-Sample-Sketch(update filename!)

Code:

// Simple Flac file player example
//
// Requires the audio shield:
//   http://www.pjrc.com/store/teensy3_audio.html
//
// This example code is in the public domain.

#include <Audio.h>
#include <Wire.h>
#include <SPI.h>
#include <SD.h>

#include <play_sd_flac.h>


// GUItool: begin automatically generated code
AudioPlaySdFlac           playFlac1;       //xy=154,78
AudioOutputI2S           i2s1;           //xy=334,89
AudioConnection          patchCord1(playFlac1, 0, i2s1, 0);
AudioConnection          patchCord2(playFlac1, 1, i2s1, 1);
AudioControlSGTL5000     sgtl5000_1;     //xy=240,153
// GUItool: end automatically generated code

void setup() {
  Serial.begin(9600);

  // Audio connections require memory to work.  For more
  // detailed information, see the MemoryAndCpuUsage example
  AudioMemory(6);

  sgtl5000_1.enable();
  sgtl5000_1.volume(0.5);

  SPI.setMOSI(7);
  SPI.setSCK(14);
  if (!(SD.begin(10))) {
    // stop here, but print a message repetitively
    while (1) {
      Serial.println("Unable to access the SD card");
      delay(500);
    }
  }
}

void playFile(const char *filename)
{
  Serial.print("Playing file: ");
  Serial.println(filename);

  // Start playing the file.  This sketch continues to
  // run while the file plays.
  playFlac1.play(filename);

  // Simply wait for the file to finish playing.
  while (playFlac1.isPlaying()) {
    // uncomment these lines if your audio shield
    // has the optional volume pot soldered
    //float vol = analogRead(15);
    //vol = vol / 1024;
    // sgtl5000_1.volume(vol); 
    yield();
  }
  
}


void loop() {
  playFile("T1_2048.FLA");
  delay(500);
}

PaulStoffregen · Jun 21, 2016

Looks like some chips might not overclock all the way to 240 MHz.

The chip I have here on my desk seems to run well for many hours at 240 MHz, but it does get noticeably warm.

defragster · Jun 21, 2016

I've edited those number in 3 OUTPUT_xxx.cpp files and:

>216 may have correct speed - but hard to tell in 1 to 10 notes before it stops.
>240 plays for some seconds or longer or not at all at the right speed.

Doing power cycle or RESET seems the same.

This Win_7 (x64 Ultimate) machine is a ZIP extract to a fresh IDE 1.6.9 directory with 1.29b3 and boards.txt and now these edited files:

I:\arduino_169\hardware\teensy\avr\libraries\Audio>

06/21/2016 12:27 PM 10,248 output_i2s_quad.cpp
06/21/2016 12:28 PM 12,830 output_i2s.cpp
06/21/2016 12:28 PM 12,407 output_spdif.cpp

My k66 has never felt noticeably warm and stable for overnight runs - doing minimal code mostly Manitou RTC clock isr code.

sumotoy · Jun 21, 2016

PaulStoffregen said:
Looks like some chips might not overclock all the way to 240 MHz.

I've runned some SPI as burn test for a while. Get stuck a couple of times (SCLK HIGH and CPU freezed). Doing same at lower speed was not a problem.

Frank B · Jun 21, 2016

had mine running over night > 6 Hours with ILI9341 and my "fire" demo @ 240MHz, 120MHz F_BUS, 60MHZ SPI. Felt slightly warm (not much) , and it was still running without problems this morning.
Ok, but it seems to have problems with I2S with 216..240 MHz (independed from F_BUS)

manitou · Jun 21, 2016

Paul, is the K66 programmed with Ethernet MAC address? (I may not have the latest sketch, but i get all 0s. sketch works with T3.2)
ref: https://forum.pjrc.com/threads/91-teensy-3-MAC-address

How is the ether shield?

KurtE · Jun 21, 2016

Again starting to play with SPI1... So far added delta to kinetis.h to add SPI1 registers:

Code:

#if defined(__MK64FX512__) || defined(__MK66FX1M0__)
#define KINETISK_SPI1		(*(KINETISK_SPI_t *)0x4002D000)
#define SPI1_MCR		(KINETISK_SPI1.MCR)	// DSPI Module Configuration Register
#define SPI1_TCR		(KINETISK_SPI1.TCR)	// DSPI Transfer Count Register
#define SPI1_CTAR0		(KINETISK_SPI1.CTAR0)	// DSPI Clock and Transfer Attributes Register, In Master Mode
#define SPI1_CTAR0_SLAVE	(KINETISK_SPI1.CTAR0)	// DSPI Clock and Transfer Attributes Register, In Slave Mode
#define SPI1_CTAR1		(KINETISK_SPI1.CTAR1)	// DSPI Clock and Transfer Attributes Register, In Master Mode
#define SPI1_SR			(KINETISK_SPI1.SR)	// DSPI Status Register
#define SPI1_RSER		(KINETISK_SPI1.RSER)	// DSPI DMA/Interrupt Request Select and Enable Register
#define SPI1_PUSHR		(KINETISK_SPI1.PUSHR)	// DSPI PUSH TX FIFO Register In Master Mode
#define SPI1_PUSHR_SLAVE	(KINETISK_SPI1.PUSHR)	// DSPI PUSH TX FIFO Register In Slave Mode
#define SPI1_POPR		(KINETISK_SPI1.POPR)	// DSPI POP RX FIFO Register
#define SPI1_TXFR0		(KINETISK_SPI1.TXFR[0])	// DSPI Transmit FIFO Registers
#define SPI1_TXFR1		(KINETISK_SPI1.TXFR[1])	// DSPI Transmit FIFO Registers
#define SPI1_TXFR2		(KINETISK_SPI1.TXFR[2])	// DSPI Transmit FIFO Registers
#define SPI1_TXFR3		(KINETISK_SPI1.TXFR[3])	// DSPI Transmit FIFO Registers
#define SPI1_RXFR0		(KINETISK_SPI1.RXFR[0])	// DSPI Receive FIFO Registers
#define SPI1_RXFR1		(KINETISK_SPI1.RXFR[1])	// DSPI Receive FIFO Registers
#define SPI1_RXFR2		(KINETISK_SPI1.RXFR[2])	// DSPI Receive FIFO Registers
#define SPI1_RXFR3		(KINETISK_SPI1.RXFR[3])	// DSPI Receive FIFO Registers
#endif

I also added SPI1 object to spi library, but trying to decide how to handle SPCR emulation. I guess I will do like was done for TeensyLC and create an SPCR1emulation object in avr_emulation.h/cpp...

PaulStoffregen · Jun 21, 2016

manitou said:
Paul, is the K66 programmed with Ethernet MAC address?

No. None of the beta boards will have this. For testing, we'll just have to make up 48 bits.

How is the ether shield?

Still being fabricated by OSH Park. I sent the files on June 15. It was a 4 layer design, so I'd expect at least another week, possibly 2 weeks until the bare PCBs arrive.

I'll send you one when they're assembled.

I also ordered a DM9161-based PHY breakout board from Elechouse. Their site says over 70 in stock, but so far no shipping notice. Whether this product really exists is a good question... it was designed for Arduino Due, but nobody ever wrote a library capable of doing anything useful.

defragster · Jun 21, 2016

PaulStoffregen said:
Looks like some chips might not overclock all the way to 240 MHz.

The chip I have here on my desk seems to run well for many hours at 240 MHz, but it does get noticeably warm.

That song plays - sketch running fine at 192 Hz.

Wondering if I should use 192 or 180 to go through the rest of the Tutorial and try the Audio Flash? ie. will I have general benefit in speed increase or just look or trouble for no real gain? 180 will push the bus speed - the other internals go faster.

<edit>: 192 MHz working :: Song still playing 6.5 hours later. Looks like 261 iterations of continuous play 1.5 minutes each

xxxajk · Jun 21, 2016

@Paul
I already have an IP stack, and it can be modified to use the acceleration bits in the ENET module pretty easily.
Soon as I get the beta board, and if I got a spare PHY laying around, I'll port it.
If I do not, let me know if you can throw one my way.
BTW, my IP stack is so small as it is, it can actually run very well on the teensy2++ with SLIP

so it aught to scream on this board, even if it only uses SLIP.
I could also now have a full excuse to provide an interface right on the USB connector too, so it would look like a USB ETH dongle... which is planned for the teensy3's anyway at some point. This would push it higher on my priority list though.

manitou · Jun 21, 2016

K66 tests: tone noTone and FreqCount work

FreqMeasure gets compile errors: 'capture_event' was not declared in this scope

need K66/K64 define's in hardware/teensy/avr/libraries/FreqMeasure/util/FreqMeasureCapture.h
(works if so modified)

other libraries that might need attention:
Adafruit_ST7735
Firmata
TimerOne
TimerThree
Snooze
Ethernet
Tlc5940
FrequencyTimer2
openGLCD
OSC
RA8875

Theremingenieur · Jun 22, 2016

Edit: FreqMeasureMulti v0.22 compiles.

Actually working on v0.3 which allows the use of all FTMs.

PaulStoffregen · Jun 22, 2016

xxxajk said:
@Paul
I already have an IP stack, and it can be modified to use the acceleration bits in the ENET module pretty easily.

What's the license?

Long-term, I want to move toward MIT or MIT-like license for all Teensy's critical infrastructure code. Currently many of the big libs, like SdFat & UHS seem to be GPL.

Theremingenieur · Jun 22, 2016

@Paul, several #defines like for example FTM0_CH0_PIN are in pins_teensy.c and thus not visible for libraries like FreqMeasureMulti. It would be very helpful if these defines could be moved to a more global scope. Waddaya think?

xxxajk · Jun 22, 2016

PaulStoffregen said:
What's the license?

Long-term, I want to move toward MIT or MIT-like license for all Teensy's critical infrastructure code. Currently many of the big libs, like SdFat & UHS seem to be GPL.

GPL 3

https://github.com/xxxajk/ajkstack

Any particular reason for wanting MIT-style license?

PaulStoffregen · Jun 22, 2016

xxxajk said:
Any particular reason for wanting MIT-style license?

The main reason is because I am well aware of many people who intend to use Teensy (or Arduino, or other similar dev boards) to prototype commercial products. Or would-be commercial products, usually described with phrases like "if this takes off..."

I personally don't feel right about merging GPL code when I believe a significant number of users will violate the license terms. Sure, I'm not necessarily responsible for other people's actions. Certainly merging already-written good quality code would be the quickest path to making Teensy fully functional, which is probably the most profitable decision I could make. But not everything I do is about maximizing profit or taking the easiest path, which probably shows in many of the decisions I make. Even if providing the source and license.txt file complies with the legal requirements, I actually do care about honoring the spirit of the original author's intention.

On the other hand, I generally like to take a practical approach to most things. This isn't a decision rooted in strong (inflexible) convictions about open source or free/libre software. In fact, it's not even 100% a decision, but merely a preference of mine to move towards MIT permissive terms over the long term.

PaulStoffregen · Jun 22, 2016

Theremingenieur said:
@Paul, several #defines like for example FTM0_CH0_PIN are in pins_teensy.c and thus not visible for libraries like FreqMeasureMulti. It would be very helpful if these defines could be moved to a more global scope. Waddaya think?

Sounds like a great idea. But 1.29 really needs to be wrapped up soon, so I'm putting off any significant features or refactoring until after 1.29 releases.

Theremingenieur · Jun 22, 2016

Ok, thanks! Thus, I'll continue to work on the v0.3 of FreqMeasureMulti with the "legacy" way of pin definitions. When would you need a fully tested version at latest to integrate it into 1.2.9 or do you prefer waiting for 1.3.0?

xxxajk · Jun 22, 2016

PaulStoffregen said:
The main reason is because I am well aware of many people who intend to use Teensy (or Arduino, or other similar dev boards) to prototype commercial products. Or would-be commercial products, usually described with phrases like "if this takes off..."

I personally don't feel right about merging GPL code when I believe a significant number of users will violate the license terms. Sure, I'm not necessarily responsible for other people's actions. Certainly merging already-written good quality code would be the quickest path to making Teensy fully functional, which is probably the most profitable decision I could make. But not everything I do is about maximizing profit or taking the easiest path, which probably shows in many of the decisions I make. Even if providing the source and license.txt file complies with the legal requirements, I actually do care about honoring the spirit of the original author's intention.

On the other hand, I generally like to take a practical approach to most things. This isn't a decision rooted in strong (inflexible) convictions about open source or free/libre software. In fact, it's not even 100% a decision, but merely a preference of mine to move towards MIT permissive terms over the long term.

I really don't have a problem with people selling anything that links to my code.
Furthermore IP/TCP/UDP/ICMP/etc are all in the public domain anyway.
It is basically a core, and if someone writes stuff that links into it, I'm all good with that.
Anyone who usually makes it that big, normally will give something to the original developer, so really, I'm not concerned.
If it helps someone learn something new, I think that is great too.

In any case, *which* MIT license exactly? There are many variants, which leads to a lot of confusion.
https://fedoraproject.org/wiki/Licensing:MIT?rd=Licensing/MIT

The GPL3 is fully compatible with the three "most common variants" of the "MIT license".

PaulStoffregen · Jun 22, 2016

Maybe a separate thread about licensing would be better?

Let's not get distracted from the K66 hardware, and specifically discovering what does and doesn't yet work.

WMXZ · Jun 22, 2016

Go today my beta board
(1.5 days from Oregon to Italy!)

after testing build-in blink
copied T3.5 relevant build options from board.txt to my makefile
simply compiled my application (quad I2S data logger) with (F_CPU=192 MHz)
only compilation issue were some uint8_t undefined (did not happen previously with older Teensyduino 1.27)
once corrected (include <stdint.h>) no compilation errors
- downloaded with custom modified teensy_loader_cli (first attempt failed, disconnected all (including hub), after reconnect and button press could then reprogram T3.5)

- program run as expected (but still unverified)

Will try to get sdcard working next

KurtE · Jun 22, 2016

Just issued two pull requests (Core and SPI), that created SPI1 object for new boards. (code is up on github.com/kurte)

I tested by hacking spiFlash library to use SPI1, I then connected up the Test board to propshield, using pins 0, 1, 20, 6 for SPI and was able to run a few of the spiFlash demo programs:

Code:

Flash Memory has 8388608 bytes.
Erasing ALL Flash Memory:
  estimated wait: 20 seconds.
  Yes, full chip erase is SLOW!
.................
Erase completed
  actual wait: 18 seconds.

Warning I have not tested all of the pin combinations yet, but code is in place to handle alternate pins
(0, 21), (1, 5), (20, 32), (6, 31). Also not maybe not fully test on CS as I believe spiFlash rolls their own CS code...

Maybe too late for current release?

jonr · Jun 22, 2016

Here is a minimally tested fix to AnalogWriteFrequency in pins_teensy.c:

Code:

        if (pin == FTM1_CH0_PIN || pin == FTM1_CH1_PIN) {
                cval = ((uint32_t)val * (uint32_t)(FTM1_MOD + 1)) >> analog_write_res;
#if defined(FTM2_CH0_PIN)
        } else if (pin == FTM2_CH0_PIN || pin == FTM2_CH1_PIN) {
                cval = ((uint32_t)val * (uint32_t)(FTM2_MOD + 1)) >> analog_write_res;
#endif
#if defined(FTM3_CH0_PIN)
        } else if (pin == FTM3_CH0_PIN || pin == FTM3_CH1_PIN || pin == FTM3_CH2_PIN || pin == FTM3_CH3_PIN || pin == FTM3_CH4_PIN || pin == FTM3_CH4_PIN || pin == FTM3_CH6_PIN || pin == FTM3_CH7_PIN) {
                cval = ((uint32_t)val * (uint32_t)(FTM3_MOD + 1)) >> analog_write_res;
#endif
        } else {
                cval = ((uint32_t)val * (uint32_t)(FTM0_MOD + 1)) >> analog_write_res;
        }

manitou · Jun 22, 2016

KurtE said:
Just issued two pull requests (Core and SPI), that created SPI1 object for new boards. (code is up on github.com/kurte)

Warning I have not tested all of the pin combinations yet, but code is in place to handle alternate pins
(0, 21), (1, 5), (20, 32), (6, 31).

Good job! Of course, there is also a SPI2

As for the SDIO pins (PTE*) on SPI1, there are no pin numbers for those pins, so it will take some trickery to configure SPI1 for the PTE* pins ...

K66 Beta Test

Senior Member+

Senior Member

Well-known member

Senior Member+

Well-known member

Senior Member

Senior Member+

Senior Member+

Well-known member

Senior Member+

Well-known member

Senior Member+

Senior Member+

Well-known member

Senior Member+

Well-known member

Well-known member

Well-known member

Senior Member+

Well-known member

Well-known member

Well-known member

Senior Member+

Well-known member

Senior Member+