K66 Beta Test

Status
Not open for further replies.
Looks like it is hardcoded for #1, #2, #3?

"I:\arduino169\lib\keywords.txt"

Line 180:
Serial1 KEYWORD1 Serial DATA_TYPE
Serial2 KEYWORD1 Serial DATA_TYPE
Serial3 KEYWORD1 Serial DATA_TYPE

You might add something similar for those added #'s in the local Keywords.txt?
 
Talkie WORKS on K66 - 192MHz and 72 & 96MHz with USB. Though it seems not as well as I recall with the Beta Shield. Reverting to original Talkie code, will test later after the following is resolved.

This is a new PROP_LC and the AMP chip by the speaker +/- quickly gets too hot to touch for very long - I felt heat radiating as I pushed the button. (Near or over 120° with no sound playing - same with DAC & Headphones unplugged and no wires.) Seems louder and perhaps over driven? I never noticed that heat on T_3.2 with Beta PROP_WIT. Using same headphones - will retest on Beta Prop & T_3.2. As expected, No Temp rise with "digitalWrite(5, 1);//Enable Amplified." removed.

Using stock examples: First was 2_Voltmeter (okay), then later the diner was less clear, and ACORN and DANGER - loud and not great.


<UPDATED this post - see #229>:: Re-compile I noticed the 24 & 48MHz doesn't work at all. With or without USB, just starts with BUILTIN_LED ON.

Talkie works with NO USB at 16 MHz, and poorly pitch/timed at 8MHz (no surprise), slowest I ran before was LC at 24 MHz that was good.


< erroneous text removed - I thought 24 & 48 were working , must not have been hitting button to upload when I went no USB cases after a working speed was uploaded >


Note: For Talkie to work on PROP shield - its DAC pin must be wired to pin #33/A14
<edit 7/11> : The proper K66 DAC pins are A21 or A22. Later post Frank made a change to Talkie to move to those pins and it works properly as he coded to A21/DAC0! I then tested when moved to DAC1 and that worked as well. This change is in - will be in 1.30? - it did not make it for 1.29.
 
Last edited:
Did I (or anyone) note before that once you compile with a failed USB intolerant speed - my next program load fails? No Teensy RUN == NO_HID interface.

Requires BUTTON to upload. So it isn't that USB just doesn't work - but rather that it causes a failure to run in the Teensy from what I can see, confirmed with qBlink fail.

Is that not the default behavior / reason for having the program button, to allow programming when running sketch is programmed without (or with failing) USB ?
 
Is that not the default behavior / reason for having the program button, to allow programming when running sketch is programmed without (or with failing) USB ?

No doubt the button has great uses in the case of USER error, or NO USB/HID. Here the user error is picking 24 or 48 MHz that will never make a running sketch?

Sketch below runs "Serial" or "No USB" at 96 & 192 MHz and even 180 MHz (when USB fails "USB Device Not Recognized"), this line active or commented: "#define NO_SERIAL"

Problem is worse than noted (on my system):: at 48 MHz and 24 MHz, there will be no functional Teensy after upload. You can wear out the program button and it will never work. This is with "Serial" or "NO_USB", even with : "#define NO_SERIAL". On Upload or subsequent power up restart - the LED turns on and that is ALL I see (except the LED by "EN" flashes which seems normal?).

Note_1 :: This sketch with NO_USB runs fine at 8 & 16MHZ with : "#define NO_SERIAL", and skips the while() faster blink in setup with no usb.
Note_2 :: I have not removed my K66 from the baseplate at any time, Nor have I soldered anything to the K66. For this test nothing is in the headers.
Note_3 :: (to self) I need to connect a Serial1 PROXY Teensy to get debug Serial1.print() when Serial is not active to observe when non-USB.

Code:
#define qBlink() (digitalWriteFast(LED_BUILTIN, !digitalReadFast(LED_BUILTIN) ))

#define NO_SERIAL

void setup() {
  pinMode(LED_BUILTIN, OUTPUT);
  digitalWriteFast(LED_BUILTIN, 0);
  delay(1000);
  digitalWriteFast(LED_BUILTIN, 1);

#ifdef NO_SERIAL
  while ((millis ()  <= 8000)) {
    delay(80);  qBlink();
  }
#else // Expect and try to use Serial
  Serial.begin(38400);
  while (!Serial && (millis ()  <= 8000)) {
    delay(120); qBlink();
    delay(40);  qBlink();
  }
  Serial.println("Hello World");
#endif

}

void loop() {
  delay( 700 );
  qBlink();
}
 
Last edited:
The honor is on my side!.

Round 3 or 4 is fine for me, I will send a mail to Robin later, to keep more informations.

BR

Markus
 
@defragster: Yes, less than 72MHz is not supported, currently.
We should remove that from boards.txt for now...

edit. oops.. wrong.. i have to look more carfully..
 
...deleted...(wrong)

Somehow, it does not like less than 72MHz... I don't know why, at the moment.
 
Last edited:
That's interesting and a big bug in the manual !

Re: RNG register addresses

@Paul et al, my "bug" (post #179) for RNG register addresses in kinetis.h needs to be revisited. As it turns out (who knew? -- actually Paul may have known from comments in kinetis.h) there are TWO ways to enable the RNGA peripheral, one using SIM_SCGC3 and one using SIM_SCGC6. The first maps to the original RNG addresses in kinetis.h, the 2nd (which I used in example sketch) maps to the 0x40029000 addresses. So if i had used SIM_SCGC3, all would have been well! (I have since tested both mappings).

Paul, I fear the recent fix you applied to kinetis.h based on my assertion has put things askew, because you have commented out the SIM_SCGC6_RNGA. So I would be tempted to return things as they were, and I should update my example to use SIM_SCGC3 and your original register addresses.
 
Last edited:
I've committed several fixes to the core lib on github, and will do more over the next day. If you're testing, grab the latest from github.

https://github.com/PaulStoffregen/cores

Here's an updated boards.txt.
Looks great - It appears like you have now added the Serial4 and Serial5 objects which is great! Not sure if you used any of it off of my fork or not... Obviously looks similar but different on mainly what #if to use... Will sink up my core to yours and test.

Also with the serial ports should I also try to fix all of the setTX and setRX. Couple different issues.

Example: Serial1 - Serial1.setTX (26) should work on new boards.

Also Serial3.setTX(8, 1);- Currently only would work on Teensy_LC.

Kurt
 
Not sure if this should be PM or not, but summary of some of the things I have tried and/or fixed include:

Serial4/Serial5 objects: had a branch, but Paul has added to current core as of this morning.
Adafruit_Neopixel: Fixed (#ifdef) - Paul merged in change
Adafruilt_dotstar: Tested with propshield and worked with no change (test program changed to turn on level shifters)
What I have not tested or added was support for using hardware SPI on other IO pins including other SPI -Example MOSI1/MISO1/CS1.. Probably need more generic support in
SPI library...
FastLED: Fixed #ifdef...) Not sure where to try to merge in changes Again tested with propshield and test program that is part of propshield product page. Included zip file here.
 

Attachments

  • FastLED.zip
    225.2 KB · Views: 155
SPI and I2C on K66
Someone can confirm this? Gonna test soon...
----------------------- SPI -------------------------------------------
For SPI0: MOSI(11) MISO(12) SCLK(13) CS(9,10,15,20,21)
For SPI1: MOSI(0) MISO(1) SCLK(32) CS(6)
For SPI2: MOSI(45) MISO(44) SCLK(46) CS(47)
----------------------- I2C -------------------------------------------
For I2C0: SDA(18) SCL(19)
For I2C1: SDA(38) SCL(37)
For I2C2: SDA(3) SCL(4)
For I2C3: SDA(43) SCL(42)

I suppose the I2C needs pullups as the 3.2 right?

Update: Fixed SPI1 MOSI
 
Last edited:
SPI and I2C on K66
Someone can confirm this? Gonna test soon...
----------------------- SPI -------------------------------------------
For SPI0: MOSI(11) MISO(12) SCLK(13) CS(9,10,15,20,21)
For SPI1: MOSI(9) MISO(1) SCLK(32) CS(6)
For SPI2: MOSI(45) MISO(44) SCLK(46) CS(47)
----------------------- I2C -------------------------------------------
For I2C0: SDA(18) SCL(19)
For I2C1: SDA(38) SCL(37)
For I2C2: SDA(3) SCL(4)
For I2C3: SDA(43) SCL(42)

I suppose the I2C needs pullups as the 3.2 right?

I've only tested SPI0 and I2C0 (with external pullups), so yes for SPI0 and I2C0
 
Serial1.setTX(26) and Serial1.setRX(27) support

Changed Serial1.c - Created new branch issued pull request.
Tested with my Quick and dirty Serial Test sketch:
Code:
uint8_t command_line[100];
uint8_t command_line_len = 0;

void setup() {
  // put your setup code here, to run once:
  uint32_t start_time = millis();
  // Wait up to 2 seconds for Serial port...
  while (!Serial && ((millis() - start_time) < 2000))
    ;
  Serial.begin(115200);
  SetupSerialPort(1, 1, 0);
  pinMode(13, OUTPUT);
  delay(1000);
}

HardwareSerial *pserial = 0;
void SetupSerialPort(uint8_t ser, uint8_t tx, uint8_t rx)
{
  // Close previous
  if (pserial)
    pserial->end();
  pserial = 0;

  switch (ser)
  {
    case 1:
      pserial = &Serial1;
      break;
    case 2:
      pserial = &Serial2;
      break;
    case 3:
      pserial = &Serial3;
      break;
#ifdef HAS_KINETISK_UART3
    case 4:
      pserial = &Serial4;
      break;
#endif
#ifdef HAS_KINETISK_UART4
    case 5:
      pserial = &Serial5;
      break;
#endif
  }
  if (pserial)
  {
    if (tx != 0xff)
      pserial->setTX(tx);
    if (rx != 0xff)
      pserial->setRX(rx);
    pserial->begin(115200);
    Serial.printf("Starting Serial test on Serial%d using TX:%d RX:%d\n\r", ser, tx, rx);
    Serial.println("Text entered on Serial will echo to selected Serial port");
    Serial.println("lines start with # will choose new Serial port TX RX");
    pserial->println("Text entered here echos on debug terminal");
  }

}

uint8_t* GetNextCmdNum(uint8_t *psz, uint8_t *pnum)
{
  *pnum = 0;    // clear it out just in case.
  if ((psz == 0) || (*psz == 0)) {
    *pnum = 0xff;   //return error
    return 0; // bail if at end
  }
  // Skip all leading num number characters...
  while ((*psz < '0') || (*psz > '9'))
  {
    if (*psz == 0)
      return 0;  // end of the line...
    psz++;
  }
  while ((*psz >= '0') && (*psz <= '9'))
  {
    *pnum = *pnum * 10 + (*psz++ - '0');
  }
  return psz;
}

void loop() {
  // Look for input from Selected Serial port
  int ch;
  if (pserial)
  {
    while ((ch = pserial->read()) != -1)
      Serial.write((uint8_t)ch);
  }

  // Now See if anything came in on Serail
  while ((ch = Serial.read()) != -1)
  {
    if (pserial)
      pserial->write((uint8_t)ch);
    if ((ch >= 10) && (ch <= 15))
    {
      // Assume we have a command line
      command_line[command_line_len] = 0; // make sure null terminated
      if ((command_line_len > 1) && (command_line[0] == '#'))
      {
        uint8_t ser, tx, rx;
        uint8_t *psz = GetNextCmdNum(&command_line[1], &ser);
        psz = GetNextCmdNum(psz, &tx);
        psz = GetNextCmdNum(psz, &rx);
        SetupSerialPort(ser, tx, rx);
      }
      command_line_len = 0; // clear out line
    }
    else
      command_line[command_line_len++] = (uint8_t)ch;
  }
}
Also using 3.3v FTDI cable connected up to putty (actually kitty) window running at 115200. Have not run this through the other Serial objects yet, but will
It echoes whatever you type on Serial to which serial port you are working with and likewise from Serialx back to serial

If what you type on Serial starts with #, it grabs three numbers <which Serial> <tx> <rx>
So Tested new with: #1 26 27

Update: Also just pushed up a change to Serial2.c as it had TX pins for Serial 2, as it was setup for T3.2 where TX pins could be 10 and 31, but now 31 is RX4, likewise
for RX pins for Serial 2 on 3.2 was (9 and 26), but on T3.5 26 is TX0 pin.
 
Last edited:
SDHC 4-bit IO
I tried porting the sector-read code that I had working on MBED K64F --- not working. TODO
K64F tests discussed here https://forum.pjrc.com/threads/24633-Any-Chance-of-a-Teensy-3-1?p=103556&highlight=sdhc#post103556

UPDATE
The problem i had with my SDHC sketch was wrong GPIO pin setting for test pin in my driver (pin 12 on mbed not same as pin 12 on teensy K66). So I was able to correctly read a 512-byte sector from microSD card, took 305us (13.4 mbs):D

(this is low-level sector-read testing -- no FAT file system. FAT file system would utilize the sector read/write stuff) == proof of concept

From the URL to the mbed K64 testing, a lot of the "IO time" is spent waiting for DLA to become inactive. With analyzer on K66, the 2nd DLA wait time was 252us, and actual sector transfer time was 43us (= 97mbs) for 4-bit SDIO. F_CPU=96mhz

using SanDisk 8GB microSD
 
Last edited:
2nd Update on Serial ports.

Pushed up more changes to Serial3.c Serial4.c and Serial5.c to the setTX functions. Before on Serial3 it was only implemented for Teensy_LC as there are two TX pin and only 1 on other boards like 3.2. But now 2nd parameter changes the Open Drain. So now allow you to call through for all T3 boards, although only one valid TX pin... Added likewise for Serial4 and Serial5
 
Nevermind. SPI1 and SPI2 for KINETISK are currently not present inside SPI.cpp
Trying to update SPI library...
 
I changed the MK conditionals in IRremoteInt.h in the teensy zip file distribution to use defined(KINETISK), and I was able to compile and run examples for IRremote (checked with analyzer) on K66, but the library is mostly configured for a 48MHz F_BUS, so additional logic might be added for 60MHz or warnings.

I've added these in my copy of IRremoteInt.h, and a #error when F_BUS isn't 48 or 24 MHz.

Eventually I need to sync up with the upstream IRremote and support other F_BUS speeds, but that's a lower priority at this moment.
 
Status
Not open for further replies.
Back
Top