PDA

View Full Version : K66 Beta Test



Pages : [1] 2 3 4 5 6 7

Paul
06-09-2016, 02:13 PM
We're going to begin beta testing the MK66FX1M0 (http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/kinetis-cortex-m-mcus/k-series-performance-m4/k6x-ethernet/kinetis-k66-180-mhz-dual-high-speed-full-speed-usbs-2mb-flash-microcontrollers-mcus-based-on-arm-cortex-m4-core:K66_180) chip for a high-end Teensy.

Update: See post #8 for latest status (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=106291&viewfull=1#post106291). (special thanks to defragster for keeping #8 updated)

The following people will receive free beta test boards. PJRC will pay for shipping too. For packages outside the USA, you'll need to pay any extra tariff/fee the carrier charges upon delivery.
adrian, adrianfreed, Avenue33, bboyes, Ben, Bill Greiman, blackketter, bperrybap, cartere, christoph, Constantin, Cosford, craiglindley, cyborgv2, Defragster, dgarcia42, Donziboy2, doughboy, duff, Elmue, el_supremo, embedded-creations, Epyon, Experimentalist, fms1961, Frank B, Fyod, GremlinWrangler, happyinmotion, Headroom, HWGuy, jakezimmer, jakorten, JBeale, jbliesener, jimmayhugh, joe_prince, jonr, johnnyfp, Jp3141, Koromix, kpc, kriegsman, KurtE, LAtimes, linuxgeek, macaba, manitou, markonian, Markus_L811, MichaelMeissner, MickMad, mlu, monkeybiscuits, mortonkopf, MuShoo, mxxx, Nantonos, nlecaude, nox771, onehorse, pawelsky, Pedvide, Pensive, pictographer, potatotron, robsoles, stevech, sumotoy, syso2342, teachop, Tectu, tenkai, tetsuo, Theremingenieur, tlb, Tomek, turtle9er, whollender, WMXZ, Wozzy, Xenoamor, xxxajk, yeahtuna


Unfortunately, we can't ship everyone a board right away, so they'll be made in 3 or maybe 4 rounds. Rounds 1 and 2 will be a large (approx 3x3 inch) board with the TQFP version of the chip, with sockets at the intended final form factor (2.4 by 0.7 inch). Round 1 will have 10 boards, shipping next week. Round 2 will add 18 more boards over the next few weeks. Round 3 will be a pre-production run of the actual board with the BGA version of the chip and final power supply circuitry. If we can't make enough on these first 3 rounds, a 4th round might be added.

Everyone on this list has been a regular forum contributor or software developer. Robin and I really appreciate everything you've done. We want to get all of you boards as early as possible. But as a practical limit with so much hand soldering, we need to prioritize. So far, for round 1 we will send to:
Frank B, Theremingenieur, KurtE, dgarcia42, manitou, Defragster, sumotoy, el_supremo


If you'd like to receive a board in round 1 or 2, the magic words are "I do have time for beta testing" and some idea of what things you might try testing. If you're busy, I recommend waiting for round 3, which will have a nice USB host current limit circuit that's not present in rounds 1 & 2. If there are extra boards, we might open up a 4th round and perhaps include people not on the original list.

To receive a beta test board please contact Robin directly at robin at pjrc dot com, especially if your forum email address is not your primary one.

I'd like to ask everyone to please avoid posting photos of the boards, and to keep all conversation on this forum thread. I'm trying to allow openness and access to technical information while avoiding premature promotion & vaporware. Hopefully a text-only forum thread is a good compromise. Please don't post pictures, especially on social networks, until we've finalized a page on the website (with photos) for ordering the final board.

manitou
06-09-2016, 02:50 PM
Let's do it!

Ben
06-09-2016, 03:28 PM
Do not post pictures or mockups of the new Teensy here or anywhere else. Do not post pinout diagrams. Do not post videos. Do not talk/post about the new Teensy on social media sites or news sites. Keep all conversation about the new Teensy in this thread, and keep it text-only.

==>Additional Information in Post #8 (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=106291&viewfull=1#post106291)!

Datasheets K66 (3.3V only):
K66 Data Sheet (electrical specs): http://cache.nxp.com/files/32bit/doc/data_sheet/K66P144M180SF5V2.pdf
K66 Reference Manual (programming specs): http://cache.nxp.com/files/32bit/doc/ref_manual/K66P144M180SF5RMV2.pdf

Datasheets K64 (5V tolerant):
K64 Data Sheet (electrical specs): http://cache.nxp.com/files/microcontrollers/doc/data_sheet/K64P144M120SF5.pdf
K64 Reference Manual (programming specs: http://cache.nxp.com/files/microcontrollers/doc/ref_manual/K64P144M120SF5RM.pdf

Tips for the FPU:

Just wondering if there was a simple fun thing to do with the FPU I came across this with some functional notes:
10 useful tips to using the floating point unit on the ARM« Cortex«-M4 processor (https://community.arm.com/docs/DOC-7544)
{ and license required Fast FP for ARM and Thumb2: GoFast Floating Point Library - Micro Digital (https://community.arm.com/docs/DOC-7775) }

Pads/Pins: UPDATED 06/19/16


Outside edge pads (counterclockwise)
------------------------------------

Pin ADC Ser PWM SPI I2C CAN Touch I2S Eth Native
--- --- --- --- --- --- --- ----- --- --- ------
GND
0 RX1 MOSI1 TOUCH B16
1 TX1 MISO1 TOUCH B17
2 PWM D0
3 PWM SCL2 TX0 txd0 RXD1 A12
4 PWM SDA2 RX0 lrclk RXD0 A13
5 tx1 PWM D7
6 PWM CS1 D4
7 RX3 PWM mosi0 scl0 D2
8 TX3 PWM miso0 sda0 D3
9 RX2 PWM CS0 BCLK C3
10 TX2 PWM CS0 C4
11 MOSI0 MCLK C6
12 MISO0 C7
3.3V
24 CLK E26
25 bclk RXER A5
26 tx1 txd1 RXDV A14
27 rx1 rxd0 TXEN A15
28 rxd1 TXD0 A16
29 PWM tx0 TOUCH bclk B18
30 PWM rx0 TOUCH lrclk B19
31 A12 RX4 B10
32 A13 TX4 SCK1 B11

33 A14 TX5 scl0 TX1 E24
34 A15 RX5 sda0 RX1 E25
35 A16 PWM mclk C8
36 A17 PWM C9
37 A18 PWM SCL1 C10
38 A19 PWM SDA1 rxd1 C11
39 A20 mclk TXD1 A17
DAC0 A21
DAC1 A22
GND
13 SCK0 RXD0 C5
14 A0 PWM sck0 D1
15 A1 CS0 TOUCH txd1 C0
16 A2 scl0 TOUCH MDIO B0
17 A3 sda0 TOUCH MDC B1
18 A4 SDA0 TOUCH TIMER B3
19 A5 SCL0 TOUCH TIMER B2
20 A6 PWM CS0 D5
21 A7 rx1 PWM CS0 D6
22 A8 PWM TOUCH TXD0 C1
23 A9 PWM TOUCH LRCLK C2
3.3V
AGND
VIN



Interior pads (same location as Teensy LC & 3.2)
-------------
A10
A11
AREF
VUSB

Interior pads (located between pin 27 & 38/A19)
-------------
Reset
Program
GND
3.3V
Vbat

Interior pads (meant for 5 pin header)
-------------
VUSBHOST
Host D-
Host D+
GND
GND

On-board SD card (decicated 4-bit SDIO)
----------------
DAT2 (PTE5)
DAT3 (PTE4)
CMD (PTE3)
3.3V
CLK (PTE2)
GND
DAT0 (PTE1)
DAT1 (PTE0)

TBD: extra pads if they fit on bottom side
------------------------------------------
40 TX6 sca0
41 RX6 scl0
42 SCL3 lrclk
43 SDA3 txd0
44 MISO2
45 MOSI2
46 SCK2
47 CS2
3.3V
GND


boards.txt for beta testers here: https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=110741&viewfull=1#post110741 (NEW 7/28/16)

The beta test boards use a Mini-USB connector, not Micro-USB.

List of stuff to test: THIS LIST IS OUTDATED, LAST UPDATE 6/18/16!


FUNCTIONS
digitalWrite
digitalRead
pinMode INPUT
pinMode INPUT_PULLUP
pinMode OUTPUT
analogRead(num) https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=107336&viewfull=1#post107336
analogRead(A*) https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=107336&viewfull=1#post107336
analogRead(???) temperature
analogRead(???) bandgap ref
analogRead noise level
analogReference INTERNAL
analogReference EXTERNAL
analogReadResolution
analogWrite
analogWriteResolution
analogWriteFrequency
analogWrite DAC https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=107357&viewfull=1#post107357
IntervalTimer brief test indicates no problem (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=107341&viewfull=1#post107341)
tone, noTone
delay brief test indicates no problem (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=107341&viewfull=1#post107341)
delayMicroseconds brief test indicates no problem (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=107341&viewfull=1#post107341)
millis brief test indicates no problem (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=107341&viewfull=1#post107341)
micros brief test indicates no problem (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=107341&viewfull=1#post107341)
elapsedMillis brief test indicates no problem (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=107341&viewfull=1#post107341)
elapsedMicros brief test indicates no problem (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=107341&viewfull=1#post107341)
attachInterrupt
pulseIn
shiftIn
shiftOut
Serial1
Serial1 RTS CTS
Serial1 Alternate Pins
Serial2
Serial3
Serial4 Merged from KurtE, needs testing (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=107297&viewfull=1#post107297)
Serial5 Merged from KurtE, needs testing (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=107297&viewfull=1#post107297)
Serial6
Serial1.transmitterEnable(pin)
Serial2.transmitterEnable(pin)
Serial3.transmitterEnable(pin)
Serial4.transmitterEnable(pin)
Serial5.transmitterEnable(pin)
Serial6.transmitterEnable(pin)
touchRead fixed (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=107343&viewfull=1#post107343)
DMAChannel
PJRC PRODUCTS, SHIELDS
DISPLAY_ILI9341 (Color 320x240 TFT Display)
DISPLAY_ILI9341_TOUCH (Color 320x240 TFT Touchscreen)
PROP_SHIELD SPI SerialFlash ListFiles OK with SPI flash on prop shield (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=107216&viewfull=1#post107216)
PROP_SHIELD_LC Audio Amp chip gets hot (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=107246&viewfull=1#post107246)
TEENSY3_AUDIO (Audio Adaptor Board) Paul: Yes, I tested the audio shield, but so far only playing wav files. No testing yet with SPI flash or SPI RAM. (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=107208&viewfull=1#post107208)
WIZ820_SD_ADAPTOR (WIZ820io & Micro SD Card Adaptor)
OCTO28_ADAPTOR (OctoWS2811 Adaptor)
KIT_XBEE_ADAPTOR (Teensy to XBee Adaptor Kit)
SMARTMATRIX_KIT
AVR EMULATION
AVR emu: PORT
AVR emu: PIN
AVR emu: DDR
AVR emu: SPI registers
AVR emu: SREG
AVR emu: EIMSK
AVR eeprom_read_byte
AVR eeprom_read_word
AVR eeprom_read_dword
AVR eeprom_read_block
AVR eeprom_write_byte
AVR eeprom_write_word
AVR eeprom_write_dword
AVR eeprom_write_block

portOutputRegister
portInputRegister
portModeRegister
pgm_read_byte
pgm_read_word
pgm_read_dword
random
Hardware-RNG: https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=107268&viewfull=1#post107268 https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=107308&viewfull=1#post107308
HID
Keyboard.print brief test indicates no problem (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=107341&viewfull=1#post107341)
Mouse.move
usbMIDI.sendNoteOn
USB SERIAL
Serial.print (USB Serial)
Serial.print (USB HID)
LIBRARIES
Wire
Wire slave mode
Wire1
i2c_t3 compiles with this change (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=107237&viewfull=1#post107237)
SPI The DMASPI example does not work. (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=107373&viewfull=1#post107373)
SPI1
SPI.setCLK(14)
SPI.setMISO()
SPI.setMOSI()
SD
Ethernet W5100 chip
Ethernet W5200 chip
EEPROM fix needs testing (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=107352&viewfull=1#post107352): test1 ok (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=107358&viewfull=1#post107358), test2 ok (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=107368&viewfull=1#post107368)
Firmata
LiquidCrystal
LiquidCrystalFast
Servo
Encoder
Keypad
SoftwareSerial
Stepper
PS2Keyboard
OneWire
IRremote Compiles with 48MHz F_BUS, uses defined(KINETISK), needs logic for other F_BUS speeds (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=107298&viewfull=1#post107298)
TinyGPS
Bounce
AccelStepper
SoftPWM
ShiftPWM
Time
TimeAlarms
Metro
TimerOne
TimerThree
FreqMeasure
FreqCount
Adafruit NeoPixel Fixed (#ifdef) - Paul merged in change (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=107273&viewfull=1#post107273)
ILI9341_t3
OctoWS2811
Audio Opps, looks like the audio lib doesn't work. I'm investigating.... (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=107374&viewfull=1#post107374)
FTOLED
Adafruit_CC3000
Adafruit DotStar Tested with propshield and worked with no change (test program changed to turn on level shifters) (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=107273&viewfull=1#post107273)
Adafruit_ILI9340
Adafruit_ILI9341
Adafruit_nRF8001
Adafruit_RA8875
Adafruit_SSD1306 I2C 128x32
Adafruit_SSD1306 I2C 128x64
Adafruit_SSD1306 SPI 128x32
Adafruit_SSD1306 SPI 128x64
Adafruit_ST7735
Adafruit_STMPE610
Adafruit_VS1053
AltSoftSerial
Artnet
CapacitiveSensor
DmxSimple
DogLcd
DS1307RTC
Entropy
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. (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=107216&viewfull=1#post107216)
FlexiTimer2
FrequencyTimer2
ks0108
LedControl
LedDisplay
MIDI
MsTimer2
NewPing
OSC
Ping
PulsePosition PulsePosition loopback example worked on K66 (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=107277&viewfull=1#post107277)
PWMServo
RadioHead
SPIFlash SPI SerialFlash ListFiles OK with SPI flash on prop shield (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=107216&viewfull=1#post107216)
ST7565
Tlc5940
UTFT
UTouch
VirtualWire
x10
OpenGLCD
SdFat
ledRings
FastCRC Frank B: FastCRC is ready & tested. (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=107232&viewfull=1#post107232)




Edit1: Added K64 Datasheet links
Edit2: spelling
Edit3: Added quote by defragster
Edit4: Added pinout by Paul
Edit5: Changed pinout by Paul to pinout by Frank B with Ports added
Edit6: Pins 3 and 4 are not touch-capable. Added USB pin row and Reset/Program/Vbat row.
Edit7: Add link to boards.txt, add info mini usb
Edit8: Add list of stuff that needs testing
Edit9, 10 11, 12: Update test list
Edit13: Add link to Post#8, add warning about outdated information

Constantin
06-09-2016, 03:40 PM
Thank you for choosing me. However, please feel free to put me at the back of the bus re: distributions. I am currently very busy with my loggers!

Look forward to the K66!!!

Frank B
06-09-2016, 04:35 PM
Oh great,
I emailed Robin.

Does it have a 16MHz crystal ?

Robin
06-09-2016, 05:19 PM
Don't forget to include your user name when you email me. I recognize most of the names, but it does help me out a lot when the info is included. Also, if you are outside the US and are in round 1 or 2, let me know which carrier works best in your country - UPS, Federal Express, or DHL.

MichaelMeissner
06-09-2016, 05:54 PM
Great, I'm looking forward to it (in stage 3), though I probably don't stress the Teensy's like others do. It would be useful at some point to get a final pin assignment list, and a brief spec list of what of the K66 will be brought out, but that can wait until it is closer to announce (I assume we will have the information on the card and/or pcb when it physically arrives).

defragster
06-09-2016, 05:58 PM
Repurposing this post (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=106291&viewfull=1#post106291) to provide LINKS into what now is almost 800 posts to the current state of T_3.6 Beta hardware notes and library and usage developments. [name:: K66 to be released as Teensy 3.6]

LIVE ON KICKSTARTER :: This project WAS funded on Wed, Sep 7 2016 11:59 PM PDT. (https://www.kickstarter.com/projects/paulstoffregen/teensy-35-and-36/description)

NEWER SHORTER Thread - that may collect other good info : Quick-Links-to-Teensy-3-5-3-6-Git-Libraries (https://forum.pjrc.com/threads/37396-Quick-Links-to-Teensy-3-5-3-6-Git-Libraries?p=116582&viewfull=1#post116582) . . . with the shipping of the Kickstarter rewards, BETA info here may now grow stale . . .

ALL regular KickStarter rewards are shipping with latest firmware. For those with BETA and EARLY KICKSTARTER units please see this post for into about bootloader update on your device :: LINK to POST (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=115374&viewfull=1#post115374)

8067
KS Rev of Teensy 3.6 card PDF's. (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=114537&viewfull=1#post114537)

Teensy 3.6 Analog Reference Card showing pin source (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=114102&viewfull=1#post114102)

Preliminary Eagle footprint Library For KS Teensy 3.5/3.6 (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=112826&viewfull=1#post112826), Another Eagle Teensy drawing (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=114719&viewfull=1#post114719) and Another version Eagle Library - includes prior Teensy 3 and LC (https://forum.pjrc.com/threads/935-Eagle-library-with-Teensy-3-0-footprint?p=115664&viewfull=1#post115664)


Teensy K66 Beta Pinout ... 8/29/16 ... Excel document (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=113643&viewfull=1#post113643).


... google spreadsheet that compares the Teensy (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=112462&viewfull=1#post112462) 3.0, 3.1, 3.2, 3.5, 3.6 and LC.

8155Pin Spreadsheet by Ben (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=115072&viewfull=1#post115072)

See post one (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=106266&viewfull=1#post106266) and perhaps post three (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=106275&viewfull=1#post106275) above for added info on working with the Teensy 3.6 K66 board is __MK66FX1M0__. [ corresponding ID for Teensy 3.5 K64 is __MK64FX512__ ]

Some Beta Teensy 3.5 boards were sent out and a new thread started for Features and coverage with that Device: K64-Beta-Test-Teensy-3-5 (https://forum.pjrc.com/threads/36567-K64-Beta-Test-Teensy-3-5)

Essentials - you need TeensyDuino 1.30++ installed:
latest K66/K64 boards.txt included in released 1.30 (https://forum.pjrc.com/threads/36756-Teensyduino-1-30-Beta-4-Available?p=114575&viewfull=1#post114575) (Aug18)
On Teensy 3.6 (K66) No pins are 5V tolerant - other than Vin on the T_3.6 [ Teensy 3.5 is 5 volt tolerant on Digital Pins]
CORES Hardware definition on GitHub (https://github.com/PaulStoffregen/cores/)

Device libraries:
uSDFS :: ported ELM-CHaN's FATFS to K66 as Teensy library (with GitHub link) (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=107980&viewfull=1#post107980) Post w/details (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=109193&viewfull=1#post109193)
i2C_t3 :: Updated i2c_t3 library given the recent K66 pin information (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=110008&viewfull=1#post110008)
Serial# :: K66 has working support for 6 Serial ports (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=107964&viewfull=1#post107964) - [ Merged in CORES (https://github.com/PaulStoffregen/cores) ]
SPI :: Library on GitHub (https://github.com/PaulStoffregen/SPI)
Wire :: Library on GitHub (https://github.com/PaulStoffregen/Wire)
UHS30 :: Teensy K66 and USB Host Library version 3.0. [ EXTERMELY ALPHA! ] (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=109304&viewfull=1#post109304)
ADC :: Updated the ADC library to support Teensy 3.5/3.6(K66) (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=107984&viewfull=1#post107984) - [github.com/pedvide/ADC (https://github.com/pedvide/ADC)]
Snooze :: Working BETA for K66/K64 low power usage (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=110427&viewfull=1#post110427)
DMASPI :: library updates here (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=111030&viewfull=1#post111030)
CAN :: Simultaneous Dual CAN (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=113720&viewfull=1#post113720)


Hardware Adjustments - Bus speed etc:
Modifying F_BUS Speed (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=109690&viewfull=1#post109690)
ADC VREF selection for K66 (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=107457&viewfull=1#post107457)

Software Samples and Features:

manitou RTC clock sketch sync (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=107346&viewfull=1#post107346)

KurtE's Float/Double loop (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=107927&viewfull=1#post107927)

manitou's RNG generation (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=107134&viewfull=1#post107134)

K66 crypto acceleration unit (CAU) sticky post (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=108621&viewfull=1#post108621)

KurtE SPIn variation on adjustable SPI (https://forum.pjrc.com/threads/34808...l=1#post109594)

Analog Pin Testing (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=107471&viewfull=1#post107471)

Serial Loop through test :: USB & S1 & S2 & S3 & S4 & S5 (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=107950&viewfull=1#post107950)

TYQT - v0.7.5-187 :: works on my boards with IDE 1.6.11 (https://forum.pjrc.com/threads/27825-Teensy-Qt) Check that thread to get working version.



Notes on additional Hardware:

PJRC Beta ethernet shield fits with the PCB (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=109147&viewfull=1#post109147)
Ethernet shield testing on K66 sticky post (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=109161&viewfull=1#post109161)
Various sumotoy display drivers updated (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=107223&viewfull=1#post107223)
Audio board and Mic usage (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=110919&viewfull=1#post110919) >< vocoder effect (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=109353&viewfull=1#post109353) >< 16 channel vocoder (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=109733&viewfull=1#post109733)
Prop shield :: Working as designed - various posts 9dof (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=107304&viewfull=1#post107304)
PJRC TFT ili9341 :: Working as designed - various posts




Known Work Items/Issues:
T_3.6 EEPROM WRITE access not valid over 120MHz - needs speed drop from HSRUN mode. (https://forum.pjrc.com/threads/36808-EEPROM-writing-on-T_3-6-in-HSRUN-mode?p=114757&viewfull=1#post114757) - This is one way to do it.


Early Pin notes below are for PROTO (round 1 & 2) Beta boards. The Round 3 boards are ideally the final layout and design. Top primary pins are common - the bottom pins are now set in gold on Round 3 boards and functions should be as documented in this post (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=112157&viewfull=1#post112157).

Updated info PROTO_beta board pins:
Here is Paul's posted PinOut Post #93 (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=106730&viewfull=1#post106730)
The 2x5 header on the board (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=109944&viewfull=1#post109944) just below SDCard pins. From my previous posting about pin numbers with Pauls updated pin definitions, these pins are:

3.3V [] () GND
48 () () 47
57 () () 56
51 () () 52
53 () () 55

From this message: (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=109539&viewfull=1#post109539) ...
Here's an update on the likely extra bottom-side pins. ... probably be a total of 18 bottom side pins ...
Here is a link to extended pin map data and ALT I2C usage (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=110807&viewfull=1#post110807) - And this may show SDHC details (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=110462&viewfull=1#post110462) not yet confirmed as exposed by PJRC?


Pin ADC Ser PWM SPI I2C CAN Touch I2S Eth Native
--- --- --- --- --- --- --- ----- --- --- ------
GND
DBGEN
SWCLK
SWDAT
40 D15
41 D11
42 SDA3 txd0 E10
43 SCL3 lrclk E11
- - - - - - - - - - - - -
44 CS2 B20
45 MOSI2 B22
46 MISO2 B23
47 SCK2 B21
GND
3.3V
48 RX6 scl0 D8
49 TX6 sca0 D9
50 A23 TIMER B4
51 A24 TIMER B5



* have an evolving library - make a post and keep it updated in one place - send a link to be 'Sticky' - right click post number and send the URL. *
Feedback?:: PJRC, FrankB, Theremingenieur, KurtE, dgarcia42, manitou, sumotoy, el_supremo, pictographer, WMXZ, duff, bperrybap, nox771, Pedvide, xxxajk, macaba, mxxx, dgarcia42, JBeale, ...

And out go boards for round 3 (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=111689&viewfull=1#post111689) . . .

Initial post:
Awesome - I sent email to Robin ... Also looking forward to the K66

nlecaude
06-09-2016, 07:17 PM
Many thanks !!

Robin
06-09-2016, 07:21 PM
Does it have a 16MHz crystal ?

Yes (at least it's on the bill of materials I'm working with :) )

duff
06-09-2016, 07:29 PM
Put me in on Round 3 or even 4 if that is happening I'm moving again in July :(. Then again in a year, can't wait to be settled! I'm glad to see this becoming reality though!

jimmayhugh
06-09-2016, 07:38 PM
I'm more than happy to wait, and am honored to be on such a short list with so many talented people.:D

Pedvide
06-09-2016, 07:55 PM
Thank you both for you generosity!
I sadly don't have time to beta test it, so put me on the 3rd or 4th round.
Thank you again!

WMXZ
06-09-2016, 08:21 PM
Thank's for getting the opportunity to test the new K66 board.
yes, I'm very interested and I do have time for testing the K66 for ultrasound data acquisition and processing.

KurtE
06-09-2016, 08:23 PM
Sounds great! Should be a lot of fun.

I will be curious to try it out with Robot hexapod code base. Earlier I did work to port the code base from fixed based to floating point, but never fully debugged. Maybe gives me a good reason to do so now!

Thanks

WMXZ
06-09-2016, 08:50 PM
Paul,
would it be possible to get the schematic and pin description of the sockets?
I'm just revising the pcb of my ADC card, so this information would now be very useful, even if it needs some time for me to receive the board.
If you plan to put this info onto the forum in the next days, I can wait. If you have other plans, maybe you could e-mail the info to the list in post #1.

adrian
06-09-2016, 09:07 PM
PJRC you are very generous. Please put me down the list as I don't have time for Beta testing right now. I will email Robin later. Thankyou so much for your great products and awesome technical support.

Theremingenieur
06-09-2016, 09:23 PM
I feel honored. Just sent an email. Thank you very much!

Theremingenieur
06-09-2016, 09:49 PM
How do I tell Teensyduino that I'm using the K66? Do I have to patch boards.txt?

sumotoy
06-09-2016, 10:52 PM
Wow! Thanks Paul!

defragster
06-10-2016, 09:17 AM
In case Awesome (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=106291&viewfull=1#post106291) didn't cover it - Thanks indeed. Does this 'Beta Device' have a usable/official name? Even abbreviating to MostAwesomeFastestT3ppFPU Is too hard to type and probably makes a worse TLA. I suppose more telling questions will have answers this time next week :-)

Just wondering if there was a simple fun thing to do with the FPU I came across this with some functional notes:
10 useful tips to using the floating point unit on the ARM« Cortex«-M4 processor (https://community.arm.com/docs/DOC-7544)
{ and license required Fast FP for ARM and Thumb2: GoFast Floating Point Library - Micro Digital (https://community.arm.com/docs/DOC-7775) }

<edit> This from the 'Any-Chance-of-a-Teensy-3-1' Thread:

Cortex 4 play with the Freescale FRDM-K64F?

manitou
06-10-2016, 11:39 AM
Paul, I think for the LC beta thread you provided a "pin table" and a "to test" list ...

Xenoamor
06-10-2016, 11:52 AM
Oh wow, I'm really excited for this one! 180MHz rated... I wonder how far we can push it!

Put me down for a round 3/4 please, I'm truly bogged down in a large project with a lot of K20s at the moment 0.o

Will you be exposing the SWD or JTAG interface for debugging, I know a lot of people really want this option. Also if this is a chance to change the bootloader firmware allowing a long press of the button to trigger a reset would be a great addition

That ethernet controller looks very interesting, the Kinetis SDK has the TCP/IP stack (lwIP) available. We may even be able to make this device appear on a computer network which would be great for smart homes

fms1961
06-10-2016, 12:22 PM
I feel honored as well. Robin is informed. THX a lot!

MichaelMeissner
06-10-2016, 12:24 PM
That ethernet controller looks very interesting, the Kinetis SDK has the TCP/IP stack (lwIP) available. We may even be able to make this device appear on a computer network which would be great for smart homes

Though I suspect that for smart homes, the market has shifted to wi-fi over wired ethernet.

With ESP8266's being fairly cheap for single unit sales (under $2.50 from Chinese sellers, under $5.00 from US sellers), I suspect the ethernet support in the K66 may not be that big of a needed feature (having more spi, i2c, serial ports, more analog pins brought out for easy soldering, higher clock speed, single precision floating point, and 2 DACs are likely more things that bring people in).

Xenoamor
06-10-2016, 12:35 PM
Though I suspect that for smart homes, the market has probably to wi-fi over wired ethernet.
Ethernet to wifi adaptors exist. Or a USB wifi adaptor host could be written but I completely agree with you

fms1961
06-10-2016, 12:59 PM
Though I suspect that for smart homes, the market has shifted to wi-fi over wired ethernet.

Indeed, but for development purposes, you will be happy to have an ethernet alternative to avoid the "chicken-and-egg-problem".

pictographer
06-10-2016, 01:58 PM
Does this 'Beta Device' have a usable/official name?

My preference is simple names. "Teensy 4.0" would be my favorite. "Teensy F1" if you want something more different than "Teensy 3.x". Not a fan of '++' because it is reminiscent of 1984 and C++, it's a little harder to type, maybe harder to search for, and versioning gets ugly, e.g. Teensy++ 4.2 with confusion regarding which other PJRC product is most similar.

Theremingenieur
06-10-2016, 02:00 PM
I really like the idea of a Teensy F1 - like Formula 1 :)

BriComp
06-10-2016, 02:45 PM
Only use F1 if you want to be sued by Bernie

manitou
06-10-2016, 03:02 PM
Well, my vote for names is for Teensy K66, and it's cheaper sister, Teensy K64

The Etherenet, me thinks, will require a PHY chip/shield -- a power consumer. The mbed K64 (@120MHz) that I did some pre-K66 testing on has a PHY chip on board, and the lwIP Ethernet stuff worked just fine, though it uses mbed RTOS to manage all the TCP/IP tasks, see K64 testing (https://forum.pjrc.com/threads/24633-Any-Chance-of-a-Teensy-3-1?p=84807&viewfull=1#post84807), which includes some single-precision hardware float tests, and RNG and CAU tests.

manitou
06-10-2016, 03:11 PM
NXP/Freescale has library for the K66/K64 crypto acceleration unit (CAU), but it's GNU assembler (.s). I got it compiled for the mbed, and just now tried compiling in the Arduino IDE in anticipation of the K66. Changed names to .S, but IDE wasn't happy with the .include xx.hdr file in the .S files. I assume the build commands needs a -I for assembler includes, sigh. The other thought was using the lib (cau.a) that I built for the mbed, but I don't know how to tell the IDE to use a .a file ? Any hints?

I ultimately just pasted the included .hdr file in each of the .S files to get the CAU sketch to compile.

The NXP/Freescale library only provides API to access the transform function for each of the crypto operations, additional coding would be required to manage multiple blocks, pad the hashes, and provide the various encryption modes (CCB, etc)

EDIT: an alternate build solution worked. i copied libcau.a to hardware/tools/arm/arm-none-eabi/lib/ and in boards.txt changed to
teensy35.build.flags.libs=-larm_cortexM4lf_math -lm -lcau

PaulStoffregen
06-10-2016, 03:19 PM
Oh wow, I'm really excited for this one! 180MHz rated... I wonder how far we can push it!

Good question. I did a little experimenting with 192 MHz, which seemed to work fine.

The chip actually has a special HSRUN mode for faster than 120 MHz. Freescale isn't very specific, but it appears to slightly increase the internal voltage regulation inside the chip. Like the VLPR modes, HSRUN has some restrictions about turning more things on/off. So far I haven't adapted code to follow these closely. This is one of several areas that'll take some time to get everything implemented fully.

PaulStoffregen
06-10-2016, 03:37 PM
Does this 'Beta Device' have a usable/official name?

Actually, the name is one pretty big unresolved question at this point.

First, I want to put the kibosh on "4.0". This is very much a 3.x product. Sure, we're getting a big step up in performance, a FPU and a few awesome new peripherals, but this is still a Cortex-M4 that very similar to Teensy 3.2 with excellent compatibility. Perhaps "4.0" will be meaningful when we get a Cortex-M7 in 65 or 40 nm silicon.

Second, we're going to make this board in 2 versions, one with the K66 chip and another with a K64 chip. The main reason is 5V tolerance, which the K64 has but K66 does not. Other than max speed, memory size, and the extra USB host port, these 2 chips are very similar in feature set. So 2 names are going to be needed.

I've been leaning towards Teensy 3.4 and Teensy 3.5, which keeps 3.3 available for a possible upgrade of 3.2 to a faster chip but keeping the same 28 pin form factor. Earlier I was thinking "Teensy+ 3.x" and "Teensy++ 3.x".

Now's the time to go crazy with name ideas. ;)

defragster
06-10-2016, 04:03 PM
Given the MCU has K66 chip and K64 chip how about: T_3.6 (K66) and T_3.4 (K64)?

That leaves room for a 5V T_3.4 upgrade to a T_3.5 as well?

fretless_kb
06-10-2016, 04:19 PM
Given the MCU has K66 chip and K64 chip how about: T_3.6 (K66) and T_3.4 (K64)?


+1 I was about to suggest the same.

Ben
06-10-2016, 04:34 PM
Now's the time to go crazy with name ideas. ;)
Teensy 3.x HE (High end)
or
Teensy 3.x HP (High performance)
You could start with 3.0 HE for a fresh start or 3.2 HE (or HP) to keep it consistent with the current T3.2, and you won't run into already-taken names when upgrading the T3.2
The K64-based models could be named Teensy 3.x HE 5V or Teensy 3.x HP 5V.

defragster
06-10-2016, 04:58 PM
Given the MCU has K66 chip and K64 chip how about: T_3.6 (K66) and T_3.4 (K64)?


+1 I was about to suggest the same.

Since PJRC already has history with the T2 and T++2 :: perhaps T++_3.6 and T++_3.4 would be better?

JBeale
06-10-2016, 05:22 PM
Given the MCU has K66 chip and K64 chip how about: T_3.6 (K66) and T_3.4 (K64)?
I agree- I like the idea of something like "Teensy 3.4". Simple and straightforward.

I won't say that the ++ nomenclature is double-plus-ungood, exactly, but it seems awkward to me.

Theremingenieur
06-10-2016, 05:45 PM
I'd really like to see the updated boards.txt. Knowing about available F_CPU and more important, F_BUS values would greatly help me to prepare my test environment...

KurtE
06-10-2016, 06:09 PM
I like the simple 3.4 and 3.6. Or alternatively something like 3.45 and 3.4P for 5v versus performance.

Frank B
06-10-2016, 06:13 PM
I'd really like to see the updated boards.txt. Knowing about available F_CPU and more important, F_BUS values would greatly help me to prepare my test environment...

https://github.com/PaulStoffregen/cores/blob/master/teensy3/mk20dx128.c
look for __MK66FX1M0__

You can make your own boards.txt..

Frank B
06-10-2016, 06:18 PM
Second, we're going to make this board in 2 versions, one with the K66 chip and another with a K64 chip. The main reason is 5V tolerance, which the K64 has but K66 does not.

A name that indicate the 5V tolerance /3 Volt only would make sense - easier for newbies and less questions (less destroyed teensys...)

edit: something like Teensy 3.3 3V, Teensy 3.4 5V ?

MichaelMeissner
06-10-2016, 06:58 PM
A name that indicate the 5V tolerance /3 Volt only would make sense - easier for newbies and less questions (less destroyed teensys...)

edit: something like Teensy 3.3 3V, Teensy 3.4 5V ?

I still think users will get confused, as it still runs at 3.3v, just the digital input pins can handle 5v. If you try to run ws2812b/neopixel or apa102/dotstar LEDs directly on the Teensy (or anything else that needs 5v data signal), it may not work. I tend to like KurtE's suggestion, perhaps adding a V or F suffix, i.e.

3.4V (the K64 product that is 5v tolerant);
3.6F (the K66 product that is fast).


Or maybe:

3.64;
3.66.

WMXZ
06-10-2016, 07:16 PM
I've been leaning towards Teensy 3.4 and Teensy 3.5, which keeps 3.3 available for a possible upgrade of 3.2 to a faster chip but keeping the same 28 pin form factor.

For me, these names (Teensy 3.4 and Teensy 3.5) are fine, there is no real need for more complicated naming.

defragster
06-10-2016, 07:47 PM
Easily confusing - T_3.2 compatible - but in a ++ size.

The more powerful one can't handle high 5V, but the lower speed unit is 5V tolerant like T_3.

At least having some ref to the CPU Model in the name K66 and K64 gives some SOLID reference when looking at MK64FX512 or MK66FX1M0 in the sources.

Also not having a T_3.5 with a '5' in for the not 5V tolerant makes sense, and models T_3.6 and over could all be the 3.3V only variants.

Ben
06-10-2016, 07:52 PM
I added links to the relevant datasheets in Post #3 https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=106275&viewfull=1#post106275
Can someone please confirm I picked the correct PDFs?

PaulStoffregen
06-10-2016, 08:09 PM
For me, these names (Teensy 3.4 and Teensy 3.5) are fine, there is no real need for more complicated naming.

Originally I was thinking "++", but lately I've been leaning towards simplicity. Definitely not wanting to make the number complex with a suffix or extra digits.

Still undecided....


I added links to the relevant datasheets in Post #3 https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=106275&viewfull=1#post106275
Can someone please confirm I picked the correct PDFs?

Yes, those are the right ones.


I'd really like to see the updated boards.txt. Knowing about available F_CPU and more important, F_BUS values would greatly help me to prepare my test environment...

I'll post a boards.txt file next week, when we ship the first 10 boards.

But F_BUS isn't in boards.txt. It's in kinetis.h, which you already have.

Frank B
06-10-2016, 08:55 PM
@paul, in mk20d128, you write:
"// config divisors: 180 MHz core, 60 MHz bus, 25.7 MHz flash, USB = not feasible"

Isn't it possible to use the IRC48 as clock for USB ?

Edit: The new chips are a chance to switch to higher F_BUS... some time ago we learned that F_BUS can be overclocked much much more..
Edit: I'll try to get 240MHz or more out of this beast.. :)

manitou
06-10-2016, 09:00 PM
EEPROM looking at eeprom.c, it appears K64/K66 will have 4KB of flash EEPROM

Frank B
06-10-2016, 09:48 PM
Yes, the manual confirms this.

manitou
06-10-2016, 11:59 PM
teensy3/analog.c : I may not be looking at the latest github file, but it doesn't seem that analogWriteDAC0 is defined for K64/K66, nor is the pin mapping set up for the internal ADC channels (temperature, VREF). When the K66 arrives, the truth will be revealed.

EDIT: I was wrong. ugly hack does map K66 to teensy 3 internal pins OK.

JBeale
06-11-2016, 12:46 AM
"Ethernet MAC with IEEE 1588 capability" is very cool. I've got a good collection of embedded devices with ethernet, but AFAIK I don't currently own any capable of IEEE 1588 (which apparently can achieve sub-microsecond time synchronization across a LAN). I do not actually have an application for that capability, but just thought it was interesting.

defragster
06-11-2016, 02:36 AM
Paul - the Beta boards will be the K66 - will they have SD socket and other expected shipping hardware config mounted ? Any open 'ports' that might need added hardware to use - like Ethernet? Just wondering what extra hardware might be good to have on hand, and wondering how to plan to set it up.

Batch one [ (approx 3x3 inch) board with the TQFP version of the chip, with sockets at the intended final form factor ] will fill and obscure half a 2"x6" protoboard. Perhaps two of those mounted side by side for usable pin area? Will the underside pads be present, and in your expected locations (i.e. T-3.2 layout, added pads)?

markonian
06-11-2016, 03:03 AM
Just wondering if there was a simple fun thing to do with the FPU I came across this with some functional notes:
10 useful tips to using the floating point unit on the ARM« Cortex«-M4 processor (https://community.arm.com/docs/DOC-7544)
{ and license required Fast FP for ARM and Thumb2: GoFast Floating Point Library - Micro Digital (https://community.arm.com/docs/DOC-7775) }


Thanks for posting this!

markonian
06-11-2016, 03:22 AM
For me, these names (Teensy 3.4 and Teensy 3.5) are fine, there is no real need for more complicated naming.

Me too. Simple is good. Remember that we are going to be typing and speaking the name a lot.

wizard69
06-11-2016, 04:06 AM
Actually, the name is one pretty big unresolved question at this point.

First, I want to put the kibosh on "4.0". This is very much a 3.x product. Sure, we're getting a big step up in performance, a FPU and a few awesome new peripherals, but this is still a Cortex-M4 that very similar to Teensy 3.2 with excellent compatibility. Perhaps "4.0" will be meaningful when we get a Cortex-M7 in 65 or 40 nm silicon.

I Paul, just hearing about this offering. That description above kinda says this isn't your basic 3.x product. You are suggesting a serious number of enhancements over the previous iterations. You might end up confusing customers if you try to sell it as another 3.x board.

I don't have a good suggestion for names but when it comes to dogs I love Husky's. They just love to run and run.


Second, we're going to make this board in 2 versions, one with the K66 chip and another with a K64 chip. The main reason is 5V tolerance, which the K64 has but K66 does not. Other than max speed, memory size, and the extra USB host port, these 2 chips are very similar in feature set. So 2 names are going to be needed.

I'd rather see 5 volt tolerance accomplished in some other fashion. Honestly I'd like to see some buffered I/O with the idea of supporting such uses as step and direction to stepper motor controllers. Maybe 8 bits with such buffering. 3.3 volt I/O isn't a big deal for many of the pins. However if you want to drive some of the larger commercial stepper drives you can really benefit from 5 volt buffered outputs.

The other problem is having two boards that are almost identical except for voltage tolerance leave with bad vibes. I would go with one or the other to avoid people accidentally destroying the boards.


I've been leaning towards Teensy 3.4 and Teensy 3.5, which keeps 3.3 available for a possible upgrade of 3.2 to a faster chip but keeping the same 28 pin form factor. Earlier I was thinking "Teensy+ 3.x" and "Teensy++ 3.x".

If you change the number of I/O pins it is even less of a 3.x device. In any event "++" is a no go for search engines. At least it has been in many cases when searching for C++ related materials.

Speaking of I/O pins I would love to see far more available. I don't know what your intentions are here but 44 pins would be a nice bump (16 more pins). . If they are arranged linearly so we can use breadboards or other prototyping solutions to get to all I/O pins it would be golden.


Now's the time to go crazy with name ideas. ;)

Yeah I wish I had some good ideas, El Capitan is already taken. If the board does indeed have more pins then we need to look for something that suggests a larger fatter Teensy. How about Teensy BigFoot as more pins implies a bigger board.

wizard69
06-11-2016, 04:20 AM
Originally I was thinking "++", but lately I've been leaning towards simplicity. Definitely not wanting to make the number complex with a suffix or extra digits.

Still undecided....

It is kinda funny because I was prompted to visit the forum due to a thread I was involved in over on Reddit. Part of the discussion concerned I/O as I was hoping you guys had a board in the works that would be ideal for CNC use. My thought over there was I/O pins, really outputs, dedicated to step and direction with 5 VDC tolerance. This plus more I/O in general.

In any event I'm off on a tangent here. In another post you implied more I/O (hope this is true) which implies more pins. Honestly the more the better as long as you avoid expensive high density connectors. The point I'm getting at here is that you really need to define a new board format, effectively another standard for larger devices. The low pin count Teensy 3.x series is great until you need more I/O. I'd like to see at least 16 more pins with all pins dual inline for easy breadboard use and ideally plug gable into a standard IC socket. The new format should have only one voltage tolerance level.




Yes, those are the right ones.



I'll post a boards.txt file next week, when we ship the first 10 boards.

But F_BUS isn't in boards.txt. It's in kinetis.h, which you already have.

defragster
06-11-2016, 05:02 AM
I Paul, just hearing about this offering.

Check out the now passÚ 22 page wishlist: Any-Chance-of-a-Teensy-3-1 (https://forum.pjrc.com/threads/24633-Any-Chance-of-a-Teensy-3-1)



"Well, it's a little late for this kind of feedback (http://www.subzin.com/s/Well%2C+it%27s+a+little+late+for+this+kind+of+feed back)"
Bill Murray - Scrooged (1988)



I'd rather see 5 volt tolerance accomplished in some other fashion.

The 5V tolerance is native to the Processor - just like the current Teensy 3.1 and 3.2 (not the T_3.0 (http://www.pjrc.com/teensy/teensy31.html))- it is only the K66 that loses this in trade off for faster/fuller featured CPU - Paul made a great explanation of related issues in a recent post (https://forum.pjrc.com/threads/34467-1-GHz-and-multiple-cores?p=104204&viewfull=1#post104204).

stefano.ant
06-11-2016, 05:50 AM
Hi All,
first of all sorry if my questions are out of topics but I am not really an expert.
I am using the teensy 3.2 for my projects and I am very curios and interested in this new board.
Will it have a battery management chip?
Something like :
https://www.tindie.com/products/onehorse/lipo-battery-charger-add-on-for-teensy-31/

This is very helpful and will simplify the life to people coming more from software that want to use the Teensy for some wireless project.
It will be even better if a version of the board will add some wireless connectivity to allow a mesh of wireless teensy to comunicate. For example a version with NRF24L+

Finally my take on the name: I will strongly prefer Teensy 4/Teensy 4 5v to Teensy 3.5/Teensy 3.6.
Having a little fun I will suggest Teensy One, I like it because reading One in Italian is the augmentative form of the name, will be something like Mega Teensy but more on the fun side.

wizard69
06-11-2016, 08:35 AM
Check out the now passÚ 22 page wishlist: Any-Chance-of-a-Teensy-3-1 (https://forum.pjrc.com/threads/24633-Any-Chance-of-a-Teensy-3-1)



I can see I don't spend enough time on the forums, never saw that.



The 5V tolerance is native to the Processor - just like the current Teensy 3.1 and 3.2

Yes that is why I mentioned 8 bits of buffered outputs. You can read buffers as level shifters if you want.


(not the T_3.0 (http://www.pjrc.com/teensy/teensy31.html))- it is only the K66 that loses this in trade off for faster/fuller featured CPU - Paul made a great explanation of related issues in a recent post (https://forum.pjrc.com/threads/34467-1-GHz-and-multiple-cores?p=104204&viewfull=1#post104204).

Honestly I'm a strong believer in one or the other here. Especially if the board will be standardizing a new foot print. Frankly long term what is on the board isn't as important as what the boards foot print is. The chips may change in the future but you really can't have the functions of the pins changing. Changing the voltage tolerance is changing the functions of the pins. This is bad for third party boards. Having one well defined set of pins for 5VDC interfacing is one way to deal with this but other wise 3.3 VDC interfacing is a smarter move.

defragster
06-11-2016, 08:53 AM
To the best of Paul's ability - and my memories from excessive time reading here - that linked thread should suggest this: The pins common to the T3.1/T3.2 will be functionally similar with the K64 including 5V tolerance - the K66 processor version offers the same layout and more horsepower and capacity, but the processor to do that loses all 5V tolerance. All new and added pins from the new processors are in the extended one inch area beyond the T3.x pin area. Both are expected to be drop in replacements for the T_3.2 - but longer, except when 5V is present. That's probably why two boards at once - only room for level shifters is external to Teensy

aikx
06-11-2016, 09:05 AM
Mostly compatible teensy-family plus new prozessor family/typ plus boardversion:

3.64.0
3.66.0

(No version 3.6 or higher ever)

Frank B
06-11-2016, 10:51 AM
Buffers: Maybe, but most users don't need level-shifters, so why add them (?) That's a perfect task for add-on boards.

Footprint: The footprint will be compatible (Like with the Teensy LC which is not 5V tolerant, too)- But having a fixed footprint which never changes means no development, no progress.. no way to add new features. Ok, this might be important for industry, but where's the point for hobbyists (and the Teensy is a product for hobbyists, today called "makers")
The past discussions showed that most users want new features, more pins, more xyz.. all that would'nt be possible .

wizard69
06-11-2016, 12:19 PM
Buffers: Maybe, but most users don't need level-shifters, so why add them (?) That's a perfect task for add-on boards.

Possibly! In my case I'm thinking in terms of hardware to control a wide variety of step and direction stepper drives.


Footprint: The footprint will be compatible (Like with the Teensy LC which is not 5V tolerant, too)- But having a fixed footprint which never changes means no development, no progress.. no way to add new features. Ok, this might be important for industry,

I don't buy this! A well defined I/O foot print is very good for hobbiest. It means a wide array of daughter cards are possible and can be affordable made. Think about Arduino here a well defined and maintained foot print is exactly why so many Arduino cards are in circulation right now. It means hobbiest can buy just about any board they need and plug it in reliably. Think about why some of the older cards are preferred to some of the less popular cards that have come out of Arduino.cc.


but where's the point for hobbyists (and the Teensy is a product for hobbyists, today called "makers")

This is so simple a wide array of daughter cards that are always pin compatible.

I can understand the need to expose new features in new controllers down the line. This however needs to be done in a way that doesn't invalidate the original standard.


The past discussions showed that most users want new features, more pins, more xyz.. all that would'nt be possible .

More pins is exactly what this new foot print provides from what I can see. All I'm saying is don't be changing pin functionality down the road after releasing this new design. Rather make sure it is right from the start. If new features are to be offered down the road, add a header for,users to plug into, or do something else that doesn't trash third party boards. If needed define an exclusion zone for third party makers that future Teensy's can grow into. In the end what I'm concerned about is all of those third party boards that hopefully will find their way to these new Teensy's.

By the way there is an additional reason to get away from the Teensy 3.x family naming. It makes it easier for third party board makers to indicate compatibility and reduce confusion. Teensy Bigfoot implies something physically different than Teensy 3.x for example.

KurtE
06-11-2016, 01:46 PM
Sorry, but I am personally trying to understand what the argument is here?

There has been lots of discussions on the thread Any-Chance-of-a-Teensy-3-1 (https://forum.pjrc.com/threads/24633-Any-Chance-of-a-Teensy-3-1?highlight=K66)

I am pretty sure Paul understands the idea of trying to keep things compatible, which is why he has mentioned that the pinout for this board will be as close to compatible with the Teensy 3.2. The chip will be something like an inch longer and the new functionality with new pins and new functionality.

Personally I like the idea behind the two different boards. If I want +5v compatibility I will use that one. Note: I earlier shied away from Teensy 3.0 as it did not have this, but as things change and more boards and sensors are 3.3v, there are now many times when 5v may not be necessary.

My assumption is that the pinouts will be the same for the two chips, however some of the pins may have additional functionality, example USB host.

As for adding in Level shifters on board, personally I am not sure that would be a great idea, other than potentially adding 1 or 2 output level shifters to +5v for Neopixel and/or Dotstar, like the LC.

But again this is a trade off, if you only have N pins exposed from the chip how many do you want to sacrifice for this? Also there are now many cases where I want 3.3v IO pins, for example when I talk to an XBee or maybe connect the IO pin to RPI.

In many cases I have seen general purpose level shifters being problematic. There have been many threads about problems with level shifters, like some don't work well with I2C, or some don't work well with Pull up resistors, or they are too slow. Also I have seen some other boards like Edison Arduino board, where you need to configure the level shifter from input to output (trying to remember if I2C or SPI), and to do this was so slow, that you could not reliably use a ping sensor...

At this point I am assuming that the board designs are complete and only if issues are found in the first rounds of testing will there be any modifications made.

Once some of this testing is done, I will probably play around with building my own adapter board(s).

Should be fun! :D

Kurt

MichaelMeissner
06-11-2016, 01:59 PM
To quote from page 21 of the thread about a then possible K66 (https://forum.pjrc.com/threads/24633-Any-Chance-of-a-Teensy-3-1/page21):


I'd like to ask everyone following this thread to refrain from creating illustrations or mock-up images. Please keep the conversation here on this forum thread, and please do not repost this info on social networking sites. Teensy is still nowhere near the scale and need for new product secrecy of Arduino. But we are at the point where new products are newsworthy for sites like Makezine & Hackaday, which is the main reason I've asked everyone to refrain from photos during beta tests.

Yes, that's still the plan, for a total PCB size of 2.4 by 0.7 inches.

The 28 pins on the left side will retain close compatibility with Teensy 3.2. The 20 new pins will add 3.3V (next to pin 12) and GND (next to pin 13), and digital pins 24 to 39 with analog on 31-39, and two analog-only pins for DAC0/A19 & DAC1/A20.

Most of the new left-side area will be occupied by a SD socket, with fast 4-bit SDIO bus, which is not shared with SPI or any other normally used pins.

A location solder a 5 pin through-hole header is planned, for the 2nd USB port (with 480 Mbit/sec speed & USB host mode). The pinout will be the same as 5 pin USB headers on PC motherboards, so you can add a header and plug in a commonly available USB front-panel cable. This is likely to be located close to pins 2-6.

Double rows or other changes in form factor are not planned. Best possible pinout compatibility with Teensy 3.x & LC is a major goal.

Given DAC0 will be moved out to the outer rows, and given a new pin # (A19 instead of A14/A12), I would suspect the back row (DAC, Program, Ground, 3.3v, Vbat) will disappear. This would mean for the prop shield, you would need to solder a wire to connect to the shield DAC pin. Some of onehorse's shields that use the back ground/3.3v pins would have to be similarly connected with wires.

PaulStoffregen
06-11-2016, 10:44 PM
At this point I am assuming that the board designs are complete and only if issues are found in the first rounds of testing will there be any modifications made.


Yes, exactly. While I do not wish to censor any conversation, the hardware design is pretty much fixed at this point and not really up for discussion. Indeed those conversations have already occurred many, many times. Especially to achieve Teensy's small form factor (2.4 by 0.7 inch for this one), quite a few compromises had to be made.

This beta test is really about software. Plenty of things are still in need of porting. New peripherals like the SDIO are not yet supported at all, and my hope is to work on those over the coming weeks, with your help beta testing.

Ben
06-11-2016, 10:54 PM
New peripherals like the SDIO are not yet supported at all,[...].
Your post made me realize that the K66 features an SD host controller. Will accessing an SD card through this controller speed up the access times and read/write speeds to a level where SPI flash will be obsolete for audio effects (delay)?

PaulStoffregen
06-11-2016, 11:34 PM
SDIO will speed up the portion of SD card access where a block of data is transferred. Today that part occurs at nearly 3 Mbyte/sec speed (SPI clocked at 24 MHz). In theory, the raw data transfer might increase to 24 MByte/sec, using 4 bit mode clocked at 48 MHz.

But with many SD cards, the raw data transfer is only about half of the time spent. The other half involves some overhead and mostly just waiting for the card. So today we get about 1.5 Mbyte/sec overall speed. If all the 50% overhead stays the same and data movement becomes 8X faster, you can expect about 2.7 Mbyte/sec overall speed. With a fairly "simple" replacement of the SPI code with SDIO in 4 bit, this is the likely speedup.

Perhaps some cards will respond faster in SDIO mode. I've heard people argue this from time to time, but so far I've never seen anyone back that up with actual measurements. I'm a bit skeptical.

Of course, much more might be possible with a massive redesign of the Arduino SD library. Perhaps some (most) cards respond with very little extra delay when multi-sector reads are used. Again, I've heard this said, and based on when I know of the cards and protocol, I believe this is very likely true. But to make use of it, quite a lot of memory will be needed for caching.

Likewise, with speculative read-ahead and delayed writing (even more memory for caching) and DMA to perform transfers while other code runs, perhaps even more speedup could be achieved in practical usage scenarios. But that's even more dramatic changes to the code.

I do want to eventually try all this... but I'm doubtful we'll ever get close to the theoretical speed of sustained 24 MByte/sec transfer for real applications which actually do something with the files they're reading or writing.

Donziboy2
06-12-2016, 12:41 AM
Ok, now that im done screaming like a little girl.....
I thank you for including me in the beta, but at this time I am not sure what assistance I could offer. I would like to be placed at the end of the line so that those with better coding/library abilities can get these first.

Im not sure I could warrant the cost of the board + shipping without a clear goal for the testing(I am however a RL test tech). I have zero skills when it comes to digging into the Kinetis datasheets. I have failed on many occasions to de-crypt them. I am mainly a HW guy who when a gun is placed against his head can do C coding (could not write a library to save my life).

On a lighter note, you mention needing memory for caching for high speed Sd Cards. Could the Flexbus/SDRAM controller in the K66 help in that regard ? (think i recall you saying they could not be brought out or they did not work as advertised)

Have the ADC's improved any or do we still have a 16Bit ADC that cant do more then 12-13bit? I have a CC Dummy Load project (https://forum.pjrc.com/threads/34863-Teensy-CC-Dummy-Load-300W) that may start using 13Bit if I can get enough clean values from it.

PS, the more I look the more ideas for future/current projects pop into my head. Who needs a life anyway lol.

defragster
06-12-2016, 01:44 AM
Paul: Is it correct that SD reader is attached on unique SPI that will work on Beta_K66 and can evolve to SDIO pins already selected and wired?

Maybe the SDIO will keep the SD from boredom and faster not parsing out single bits and the 50% overhead will drop, as well as the bonus 4X bit throughput with less traffic and we'll be surprised.

Excited for next week and K66 to get here to see what the 9 sq in beast looks like to hook it up!

Donziboy2 - I think the RAM was buffer space - hard to carve out of 64KB - RAM not so critical with ~4X on hand?

stevech
06-12-2016, 02:17 AM
SDIO in 1 bit mode is faster than SPI. But SDIO shines when you implement the 4 bit mode and of course DMA on all this.
Most all SDIO uses 4 bit mode. So it's wise to wire up those bits and not try to use those pins off-board.
The protocol and the data are on different serial data paths to eliminate overhead in addition to the parallel transfers.
I'm using SDIO on the Cortex M4 from ST, plus FAT FS. The DMA/SDIO driver and FATFS for this were from ST - plug and play. Maybe same from NXP?

GremlinWrangler
06-12-2016, 03:40 AM
Hi, have time to beta test against the assorted break out boards and parts around the place but not deep enough in the software world to usefully contribute libraries for this so prioritise accordingly. Also the wrong part of the world for sensible speedy shipping.

manitou
06-12-2016, 05:16 PM
Here are some library .cpp files that have conditional for MK20DX256 but not yet for MK66FX1M0 (nor K64)


TFT_ILI9163C.cpp
Adafruit_ST7735/Adafruit_ST7735.cpp
FastCRCsw.cpp FastCRChw.cpp
RH_NRF905.cpp
RA8875.cpp
OSCTiming.cpp
XBee.cpp
UTFT.cpp
OctoWS2811.cpp
i2c_t3.cpp

Frank B
06-12-2016, 05:35 PM
@Paul, for example FastCRC: Do you think it is better to use KINETISK or to add __MK64FX512__ and __MK66FX1M0__ ?

macaba
06-12-2016, 05:36 PM
Exciting news, here is the list of things I'd like to do:

1. General beta testing (i.e. responding when someone says 'can someone else check this works?'). I've got time for this.
2. Get the 1588 hardware timestamping working, perhaps then porting an existing 1588 library implementation to use the K66 driver. Paul can then fork this on Github and clean it up to his standard.
3. Beta test the IP stack Paul decides to use. Hopefully there is a reference Kinetis SDK stack with 1588 API methods in it already. I can imagine it'll be a few months before this is working.
4. Use the additional memory to finish my 128x128 OLED graphics driver (this keeps a framebuffer in memory, sent via DMA SPI, and can apply any screen rotation with decent anti-aliasing rather than being limited to 0/90/180/270, great for use with the Prop shield)

For anyone wondering what 1588 will give you:
- Multiple teensy on an Ethernet network that will very tightly synchronise an internal timer to each other, allowing you to issue commands like 'All Teensy - Set this pin high (i.e. trigger an interrupt) at exactly 09:00:00.000 tomorrow' and they'll all do it to within a few microseconds of each other.
- Multiple teensy on an Ethernet network can monitor inputs and upon a change, generate a very high resolution timestamp that is synchronised to GPS time, using only 1 GPS receiver on the network.

defragster
06-12-2016, 05:36 PM
Here are some library .cpp files that have conditional for MK20DX256 but not yet for MK66FX1M0 (nor K64)


TFT_ILI9163C.cpp


Looks like 35 instances there - I can test and do a pull request for those as that is one of the displays (multi with 3?) I'll want to plug in when Beta_K66 shows up.

They all seem to be simple T_3.2 usage that should be 1::1 with K66/K64 at least until their alternate SPI may come into play. Only hard part will be knowing what to call it in the comment :)

I still see T_3.4 and T_3.6 as most usable as those #defines grow:



#elif defined(__MK20DX128__) || defined(__MK20DX256__ || defined(__MK64FX512__ || defined(__MK66FX1M0__)//(arm) Teensy 3.0, 3.1, 3.2, 3.4, 3.6
if ((_mosi == 11 || _mosi == 7) && (_sclk == 13 || _sclk == 14)) {
SPI.setMOSI(_mosi);
// ...


<edit>: "#if defined(KINETISK)" could work here too and catch all four of those if it will work to clarify SPI hardware as needed?

@Paul, for example FastCRC: Do you think it is better to use KINETISK or to add __MK64FX512__ and __MK66FX1M0__ ?

Frank B
06-12-2016, 05:48 PM
4. Use the additional memory to finish my 128x128 OLED graphics driver (this keeps a framebuffer in memory, sent via DMA SPI, and can apply any screen rotation with decent anti-aliasing rather than being limited to 0/90/180/270, great for use with the Prop shield)


Oh, i have something similar for my C64 Emulation (ili9341) - currently DMA for single lines , but i change it to "Full Screen DMA" when i have the beta-board..

Wozzy
06-12-2016, 05:50 PM
Wow,

Thank you for selecting me.
I am honored.

I will be traveling quite a bit over the next several weeks, so round 3 is probably best for me.

Thanks again
Wozzy

manitou
06-12-2016, 07:43 PM
Here are some library .cpp files that have conditional for MK20DX256 but not yet for MK66FX1M0 (nor K64)


IRremote:
I think IRremote will work with addition of the K66 (and K64) conditionals in IRremoteInt.h probably in the zip file described in
https://www.pjrc.com/teensy/td_libs_IRremote.html

but Paul also has an out-of-date? repository at https://github.com/PaulStoffregen/Arduino-IRremote

and then there is the master repository https://github.com/z3t0/Arduino-IRremote

Frank B
06-12-2016, 08:34 PM
i've updated the mp3/aac/flac codecs..
flac need an additional update after testing - with more memory it possible to support std. blocksizes.

KurtE
06-12-2016, 09:33 PM
Wonder if many of the #ifdef looking for the processors, can be handled by some of the more generic ones like:

#if defined(__arm__) && defined(CORE_TEENSY)
or in some cases like just looking at __arm__
I see several cases in the current release with these types of testing and it sure looks better than something like:

#elif defined(__MK20DX128__) || defined(__MK20DX256__ || defined(__MK64FX512__ || defined(__MK66FX1M0__)//(arm) Teensy 3.0, 3.1, 3.2, 3.4, 3.6
It will be interesting.

Paul: Do you have a list of things showing what has been ported/tested/working?

Also I assume somethings may be done in stages. Example USART support. Make sure current stuff works like other T3s, but then there may be new functionality like the Transceiver Driver using RTS that may be interesting to take advantage of.

Frank B
06-12-2016, 09:43 PM
There are already existing defines like KINETISL (Teensy LC) and KINETISK (other Teensy 3.x)
Which to use depends on the use-case and what Pauls plans for the future are.. for FastCRC I tend to use KINETISK (is that ok Paul?), but for other purposes..(like SPI2) this is not possible..

alialiali
06-12-2016, 10:41 PM
Did I read "onboard crypto" ? That sounds amazing.

defragster
06-12-2016, 10:46 PM
Indeed you did:


2.2.5 Security and Integrity modules The following security and integrity modules are available on this device:

Table 2-6. Security and integrity modules

Cryptographic acceleration unit (CAU) Supports DES, 3DES, AES, MD5, SHA-1, and SHA-256 algorithms via simple C calls to optimized security functions provided by Freescale.

Random number generator (RNG) Supports the key generation algorithm defined in the Digital Signature Standard.

Cyclic Redundancy Check (CRC) Hardware CRC generator circuit using 16/32-bit shift register. Error detection for all single, double, odd, and most multi-bit errors, programmable initial seed value, and optional feature to transpose input data and CRC result via transpose register.

alialiali
06-13-2016, 02:46 AM
Indeed you did:

"The set of implemented algorithms provides excellent support for network security
standards, such as SSL and IPsec. Additionally, using the CAU efficiently permits the
implementation of any higher level functions or modes of operation, such as HMAC,
CBC, and so on based on the supported algorithms"

Fyod
06-13-2016, 01:00 PM
Awesome to be on the list. Would love to help out with testing!
I have some CAN stuff I can try and do some RX/TX speed tests with high speed LTE modules.
I'll email Robin in a bit, I'll be glad to pay the extra postage as I'm in the EU if you consider my offer to beta.

PaulStoffregen
06-13-2016, 02:22 PM
@Paul, for example FastCRC: Do you think it is better to use KINETISK or to add __MK64FX512__ and __MK66FX1M0__ ?

Either is fine.

Eventually I want to expand the HAS_KINETISK_XYZ defines. One should probably exist to tell whether the CRC peripheral is present. For now, all KINETISK chips have it.




Paul: Do you have a list of things showing what has been ported/tested/working?


Not yet....



Did I read "onboard crypto" ? That sounds amazing.

Like so many things, it is both amazing and underwhelming, depending on how you look at it. My understand so far is it's a small compute engine with with own (not so well documented) assembly-like language. It doesn't actually do all the work of a cipher, just the heavy lifting of the "rounds" some. Compiled examples exist for popular ciphers. Apparently there's also examples for various types of interpolation of data which can be used for arbitrary sample rate conversion, which is more interesting to me than crypto. I feel it may be quite a while until I can spend serious time fiddling with this hardware.... the SDIO controller is my top priority. The new USB controller and ethernet will also consume my time before I get to play with the CAU.

Frank B
06-13-2016, 03:05 PM
Eventually I want to expand the HAS_KINETISK_XYZ defines.


That's a good idea.

alialiali
06-13-2016, 03:32 PM
Either is fine.
The new USB controller and ethernet will also consume my time before I get to play with the CAU.

I think ethernet + SSL is most useful, so maybe related? ;D

Cosford
06-13-2016, 04:25 PM
Just got back from a week away - honoured to be given the opportunity to help. Will wait until the third round.
Thanks again.

PaulStoffregen
06-13-2016, 07:05 PM
Here's the pinout info.



Outside edge pads (counterclockwise)
------------------------------------

Pin ADC Ser PWM SPI I2C CAN Touch I2S Eth Native
--- --- --- --- --- --- --- ----- --- --- ------
GND
0 RX1 MOSI1 TOUCH B16
1 TX1 MISO1 TOUCH B17
2 PWM D0
3 PWM SCL2 TX0 txd0 RXD1 A12
4 PWM SDA2 RX0 lrclk RXD0 A13
5 tx1 PWM D7
6 PWM CS1 D4
7 RX3 PWM mosi0 scl0 D2
8 TX3 PWM miso0 sda0 D3
9 RX2 PWM CS0 BCLK C3
10 TX2 PWM CS0 C4
11 MOSI0 MCLK C6
12 MISO0 C7
3.3V
24 CLK E26
25 bclk RXER A5
26 tx1 txd1 RXDV A14
27 rx1 rxd0 TXEN A15
28 rxd1 TXD0 A16
29 PWM tx0 TOUCH bclk B18
30 PWM rx0 TOUCH lrclk B19
31 A12 RX4 B10
32 A13 TX4 SCK1 B11

33 A14 TX5 scl0 TX1 E24
34 A15 RX5 sda0 RX1 E25
35 A16 PWM mclk C8
36 A17 PWM C9
37 A18 PWM SCL1 C10
38 A19 PWM SDA1 rxd1 C11
39 A20 mclk TXD1 A17
DAC0 A21
DAC1 A22
GND
13 SCK0 RXD0 C5
14 A0 PWM sck0 D1
15 A1 CS0 TOUCH txd1 C0
16 A2 scl0 TOUCH MDIO B0
17 A3 sda0 TOUCH MDC B1
18 A4 SDA0 TOUCH TIMER B3
19 A5 SCL0 TOUCH TIMER B2
20 A6 PWM CS0 D5
21 A7 rx1 PWM CS0 D6
22 A8 PWM TOUCH TXD0 C1
23 A9 PWM TOUCH LRCLK C2
3.3V
AGND
VIN



Interior pads (same location as Teensy LC & 3.2)
-------------
A10
A11
AREF
VUSB

Interior pads (located between pin 27 & 38/A19)
-------------
Reset
Program
GND
3.3V
Vbat

Interior pads (meant for 5 pin header)
-------------
VUSBHOST
Host D-
Host D+
GND
GND
Host Power Enable = PTE6

On-board SD card (decicated 4-bit SDIO)
----------------
DAT2 (PTE5)
DAT3 (PTE4)
CMD (PTE3)
3.3V
CLK (PTE2)
GND
DAT0 (PTE1)
DAT1 (PTE0)

TBD: extra pads if they fit on bottom side
------------------------------------------

Pin ADC Ser PWM SPI I2C CAN Touch I2S Eth Native
--- --- --- --- --- --- --- ----- --- --- ------

GND
DBGEN
SWCLK
SWDAT
54 D15
55 D11
56 SDA3 txd0 E10
57 SCL3 lrclk E11

40 A28
41 A29
42 A26
51 D14
52 D13
53 D12

43 CS2 B20
44 MOSI2 B22
45 MISO2 B23
46 SCK2 B21
GND
3.3V
47 RX6 scl0 D8
48 TX6 sca0 D9
49 A23 TIMER B4
50 A24 TIMER B5

manitou
06-13-2016, 07:26 PM
Here's the pinout info.



If I look at cores/teensy3/touch.c, I don't see that pins 3 and 4 are configured as touch?? Is there a newer touch.c, or ?

linuxgeek
06-13-2016, 07:51 PM
I'm honored to be on the list of beta-testers. No rush for me. I'm incredibly busy ATM, but later on I imagine I'd like to test any SDIO library, serial communication, and I can try on whatever versions of linux I have at the time in round 3 or 4.

Frank B
06-13-2016, 07:59 PM
I've added the Ports:

Edit: See Post #3

Frank B
06-13-2016, 08:05 PM
Are you going to support faster ("overclock") F_BUS ?

Ben
06-13-2016, 09:10 PM
No Vbat, Reset, Program Pins?

PaulStoffregen
06-13-2016, 10:41 PM
No Vbat, Reset, Program Pins?

Oh, yeah, of course those are on the board. So are the USB host pads. I've updated #93.

PaulStoffregen
06-13-2016, 10:48 PM
Are you going to support faster ("overclock") F_BUS ?

Yes, and also on Teensy 3.2. But my #1 focus is on correct software support and compatibility. Especially updating peripheral code for more F_BUS options is a much lower priority.

manitou
06-13-2016, 11:57 PM
If I look at cores/teensy3/touch.c, I don't see that pins 3 and 4 are configured as touch?? Is there a newer touch.c, or ?

If pins 3 and 4 are PTA12 and 13, then they are not touch pins, and #93 needs to be updated.

PaulStoffregen
06-14-2016, 12:04 AM
Opps, yeah, simple mistake. I've edited #93.

MichaelMeissner
06-14-2016, 12:13 AM
This is where having a wiki would be helpful (editing the wiki, instead of going back to older messages).

Ben
06-14-2016, 12:41 AM
This is where having a wiki would be helpful (editing the wiki, instead of going back to older messages).

I'm trying to compile all useful information into Post #3 (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=106275&viewfull=1#post106275).

defragster
06-14-2016, 09:38 AM
FrankB's post #95 with Port#'s is nice <now in post #3> it is now 2 edits out of date ( Touch [p#101/102] and Old End Pins )

Wiki would be perfect for this indeed.

Re my post #78 (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=106582&viewfull=1#post106582) - I just saw Kinetis.h:: KINETISK_SPI0 [line 3842] that should track SPI as needed for TFT_ILI9163C better than four unique processor's in some mix for 42 instances?

sumotoy - you're on Beta list too - I'll make this change and test it in first days after I get K66 and get you a PULL if it makes it right unless you do it first or see an issue.

macaba
06-14-2016, 10:05 AM
Wiki would be perfect for this indeed.


Anyone can submit a pull request to this micro-site:
http://teensybase.github.io/

Uses nice clean Markdown syntax and hosted by Github.

olieske
06-14-2016, 10:19 AM
I'm a huge fan of the Teensy 3.2 + audio board. And I'm happy to hear about the beta test of the new K66 board.

@Paul:
If you consider your experience and the history of the Teensy 3.2, what is (roughly) a realistic date for the new boards to be available at the known european dealers?

And another question: How do you rate the role of the FPU for audio processing? Will it simplify audio-code and/or increasy numerical precision?

PaulStoffregen
06-14-2016, 11:07 AM
Anyone can submit a pull request to this micro-site:


Please keep all the beta test info only on this forum thread, and please the conversation text-based. Do not post hardware photos or pinout diagrams. Please do not post about this beta testing on social networks like Twitter & Facebook!

My hope is we can keep this public. Teensy isn't anywhere near the size of Arduino or Raspberry Pi, who need to keep their beta tests extremely secret. But too much premature publicity could make my life more complicated, which would ultimately mean less attention to development work... and the end of PJRC sharing this sort of info early. I know the forum & text only isn't as convenient. Please try.




@Paul:
If you consider your experience and the history of the Teensy 3.2, what is (roughly) a realistic date for the new boards to be available at the known european dealers?


This is exactly the question I don't want flooding my email inbox if sites like Hackaday find a permanent page with photos! (they're very unlikely to consider text-only forum conversation as "newsworthy")

Realistically, likely sometime in August 2016.



How do you rate the role of the FPU for audio processing? Will it simplify audio-code and/or increasy numerical precision?

The audio library doesn't use the FPU. Several of the Arduino API functions use float, but they're designed to inline to integer-only math in most cases. Even when they don't, the FPU is only used in the Arduino API side. All the actual audio processing is integer only. The Cortex-M4 DSP extensions allow significantly faster audio processing than the FPU, so my intention is to continue the integer-only design.

Ben
06-14-2016, 02:05 PM
FrankB's post #95 with Port#'s is nice <now in post #3> it is now 2 edits out of date ( Touch [p#101/102] and Old End Pins )
fixed. Note the "end pins" row (Vbat et altera) has moved, it's not between Pins 12 and 13.

If you carefully read the pin list and visualize the positions in your head I think you can deduce a very good image of how the new Teensy will look like, including the ÁSD slot.

@Paul, will the USB pads be SMD or THT? I guess THT, just want to be sure.

defragster
06-14-2016, 09:22 PM
Paul posted this (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=106730&viewfull=1#post106730):
> Interior pads (same location as Teensy LC & 3.2) [A10, A11, AREF , VUSB]
> Interior pads (located between pin 27 & 38/A19) [RESET, PROGRAM, GND, 3.3V, Vbat]
> Interior pads (meant for 5 pin header) [ VUSBHOST, Host D-, Host D+, GND, GND ]

<edit>
Through Hole pads

PaulStoffregen
06-14-2016, 09:42 PM
> Interior pads (same location as Teensy LC & 3.2) [A10, A11, AREF , VUSB]
> Interior pads (located between pin 27 & 38/A19) [RESET, PROGRAM, GND, 3.3V, Vbat]
> Interior pads (meant for 5 pin header) [ VUSBHOST, Host D-, Host D+, GND, GND ]


All of these will be through-hole. Yes, they do make parts placement and routine much harder.

Robin
06-14-2016, 09:42 PM
Beta boards are going out today to the following users:
manitou
Defragster
KurtE
el_supremo
adrianfreed
jonr
Theremingenieur
Frank B
sumotoy
GremlinWrangler

More beta boards will be going out by early next week to those who have told me that you have time for testing.

manitou
06-15-2016, 01:08 AM
teensy3/analog.c : I may not be looking at the latest github file, but it doesn't seem that analogWriteDAC0 is defined for K64/K66, nor is the pin mapping set up for the internal ADC channels (temperature, VREF). When the K66 arrives, the truth will be revealed.

Never mind'ish, I see the "ugly hack" in analog.c

#if defined(__MK64FX512__) || defined(__MK66FX1M0__) // ugly hack for now...
#define __MK20DX256__
#endif


Though K66/K64 don't have VREFOUT, but have bandgap on AD27 and need to set PMC_REGSC like LC
[B]
EDIT: I was wrong, K66 does have VREF output, ADC1/AD18, just like teensy 3

defragster
06-15-2016, 07:36 AM
Question - what about sketch/library sources? Okay for GitHub sharing.

( MichaelMeissner - this CSV is for you - CSV file type is not valid - added .txt )
7374

<pulled the word table >

Xenoamor
06-15-2016, 12:00 PM
Can you stick a few solder points on for PTA0/3 (SWD_CLK/SWD_DIO)? Hacking the current Teensy is difficult (https://mcuoneclipse.com/2014/08/09/hacking-the-teensy-v3-1-for-swd-debugging/)

Theremingenieur
06-15-2016, 12:03 PM
@defragster: I fear that your PNG files violate Paul's "Text only" policy...

Donziboy2
06-15-2016, 12:42 PM
Is the position of DAC0 changing or just the numbering for it?

MichaelMeissner
06-15-2016, 12:58 PM
Is the position of DAC0 changing or just the numbering for it?

I believe both are changing.

If I read the pin layout correctly, the back row of pins in the current Teensy 3.2 that aren't on the outside rows (DAC/A14, Program, Ground, 3.3v, Vbat) will not be in the current location.

DAC0 is now on the the left side of the Teensy. Beyond pin 13, there is a ground pin, DAC0 and DAC1, and then pins 39-33. So if you are connecting the Teensy to a breadboard or perfboard, you can bring out the pin normally.

There will be another row of interior pins that have Reset, Program, Ground, 3.3v, and Vbat on it (yeah, that Reset is now a through hole pin once again).

If you wanted to mount the Prop Shield, you would need to add a wire connecting the Shield's DAC pin to the new DAC0 on the board.

KurtE
06-15-2016, 02:36 PM
@defragster: I fear that your PNG files violate Paul's "Text only" policy...
I wondered that as well, although exact same data as Paul's list, but maybe easier to read.

Likewise another thing I have done, is to build an equivalent spreadsheet using the K66 Signal Multiplexing and Pin Assignments, from the K66 documents and extracted the pins that are used into one table in the Teensy pin number order. This way I find it easier to find things like, what are the Alternate pins that I can use for RX1...

But not sure if including a table with this is allowed in this thread?

Kurt

WMXZ
06-15-2016, 02:52 PM
I wondered that as well, although exact same data as Paul's list, but maybe easier to read.

Likewise another thing I have done, is to build an equivalent spreadsheet using the K66 Signal Multiplexing and Pin Assignments, from the K66 documents and extracted the pins that are used into one table in the Teensy pin number order. This way I find it easier to find things like, what are the Alternate pins that I can use for RX1...

But not sure if including a table with this is allowed in this thread?

Kurt

My argument is, that Paul has published the pin list, which seems not to be complete (see last section), but everyone who will do beta testing is invited to check the board ans Paul's list with the documentation.
In fact, I would not blindly trust any of the lists . If here are errors or missing functionality, it could be reported, so that Paul can correct his official list. As I see the K66 port numbers as most important info, I would only appreciate if Paul could augment his list with the correct port numbers. (I know Frank has done something, but .... )
Everyone (as KurtE) has different approaches but a proliferation of pin lists may only generate confusion, or increase entropy.

Frank B
06-15-2016, 03:30 PM
My list is from the info here:
https://github.com/PaulStoffregen/cores/blob/master/teensy3/core_pins.h#L732

But I would appreciate, if someone could double-check it :)

WMXZ
06-15-2016, 05:36 PM
@Paul
As far as I can see, PTD2 has no I2S BCLK

KurtE
06-15-2016, 05:50 PM
Everyone (as KurtE) has different approaches but a proliferation of pin lists may only generate confusion, or increase entropy.
Actually I usually need both types of lists.

I like the simple card, however it is usually not complete, and so you need to look elsewhere.
Examples: suppose I wish to try out the ILI9341 display on the new board, I need to know which IO pins are hardware CS pins. The 3.2 card I think shows 6 of them, but I believe there are 9 of them supported by the software..

Likewise USARTs - Supposed I wish to use the CTS pin for a USART, I don't believe any of these are shown on the card.

Frank, yep I use the same header file. I have not double checked your findings yet, but will do. Earlier I was trying to figure out some of the missing ones like A10/A11, which I will do later.

Thanks!

MichaelMeissner
06-15-2016, 06:09 PM
I like the simple card, however it is usually not complete, and so you need to look elsewhere.
Examples: suppose I wish to try out the ILI9341 display on the new board, I need to know which IO pins are hardware CS pins. The 3.2 card I think shows 6 of them, but I believe there are 9 of them supported by the software..

Likewise USARTs - Supposed I wish to use the CTS pin for a USART, I don't believe any of these are shown on the card.

Frank, yep I use the same header file. I have not double checked your findings yet, but will do. Earlier I was trying to figure out some of the missing ones like A10/A11, which I will do later.

Thanks!
With my goggle document spreadsheet, I now track CTS and RTS (even though I don't think the library yet supports CTS/RTS for anything by Serial1). However, adding the K66 (and K64 if it has different pinout or functionality other than slower speed and 5v tolerance) will make it unusable. I suspect it may be time to retire the Teensy 3.0 columns.

How to display things where on the Teensy 3.0/3.1/3.2 has 10 pins on pads underneath the teensy, the K66 now brings these out to the 20 new pins that were added is something I've been thinking of.

Frank B
06-15-2016, 06:53 PM
@Paul
As far as I can see, PTD2 has no I2S BCLK

Hm, yes, there's something wrong..


#define CORE_PIN7_BIT 2
#define CORE_PIN7_PORTREG GPIOD_PDOR

KurtE
06-15-2016, 06:57 PM
From my cheat sheet:

7 129 C4 PTD2/LLWU_P13 DISABLED PTD2/LLWU_P13 SPI0_SOUT UART2_RX FTM3_CH2 FB_AD4/SDRAM_A12 I2C0_SCL

FYI - I went through the core_pins.h file and I have found the same pin mapping as you mentioned.

Frank B
06-15-2016, 07:02 PM
Yes, I see there are problems with other pins, too (?) (starting with PIN0 !)


95 E10 B10 62 PTB16 DISABLED PTB16 SPI1_SOUT UART0_RX FTM_CLKIN0 FB_AD17 EWM_IN

Edit.. ok..makes sense if UART0 is RX1/TX1

Edit:
But, then.. PIN 3:


64 K9 PTA12 CMP2_IN0 CMP2_IN0 PTA12 CAN0_TX FTM1_CH0 RMII0_RXD1/MII0_RXD1 I2C2_SCL I2S0_TXD0 FTM1_QD_

There is I2C_SCL, not SDA.

Edit Pin4, similar problem..

I assume, there is a little bug .) Either in the list, or in the code..

PaulStoffregen
06-15-2016, 07:56 PM
Thanks for pouring over the pin descriptions. I'll edit later this week.

As for the native pins, I can tell you the code on github absolutely does match the hardware. I personally tested all 10 round 1 boards with a hand-wired 42 LED shield and a simple sketch that blinks all 40 pins and the 2 DACs in sequence.

If I seem a little distracted, rest assured it's with a *lot* of relevant stuff. These last couple days I did a quick first attempt at an ethernet shield, using a LAN8720A (www.microchip.com/wwwproducts/en/LAN8720A) chip. Submitted it to OSH Park just this morning and ordered all the missing parts from Digikey. While I imagine it'll be a year until we have really good, usable networking, before absolutely finalizing the beta test I want to receive just 1 ethernet packet, even if only a broadcast ARP and ICMP (ping) datagram. There'll be a couple extra boards, if anyone *really* wants to dig into the low-level ethernet stuff.

On shields, a package just arrived today from OSH Park for a 40 LED shield. We're going to start hand soldering these 9 boards tomorrow. Another group with 42 LEDs is coming later...

manitou
06-15-2016, 08:30 PM
first attempt at an ethernet shield... Submitted it to OSH Park just this morning and ordered all the missing parts from Digikey. While I imagine it'll be a year until we have really good, usable networking, before absolutely finalizing the beta test I want to receive just 1 ethernet packet, even if only a broadcast ARP and ICMP (ping) datagram. There'll be a couple extra boards, if anyone *really* wants to dig into the low-level ethernet stuff.


Well, in an earlier life I did a lot of TCP/UDP/IP testing, so if I can be of assistance ...

Frank B
06-15-2016, 09:49 PM
Interesting Info:

K66:
- The Drive-Strength setting works for PTB0/PTB1, PTC3/PTC4, PTD4-PTD7 only
- Digital Glitch Filter: Port D only

- DMA: 32 Channels

K64:
- The Drive-Strength setting: All pins (??? or "bug" in manual ?)
- Digital Glitch Filter: Port D only

- DMA 16 Channels

jonr
06-15-2016, 10:12 PM
I've long thought that it would be wise to build educational boards with a few pins that have extra protection (eg, a resistor and a BAT54S). Then encourage beginners to use these pins.

jonr
06-15-2016, 10:17 PM
> Can you stick a few solder points on for PTA0/3 (SWD_CLK/SWD_DIO)?

I would also like to see this.

MichaelMeissner
06-15-2016, 11:24 PM
I've long thought that it would be wise to build educational boards with a few pins that have extra protection (eg, a resistor and a BAT54S). Then encourage beginners to use these pins.

When I was still using Arduino Uno's, I recall there was the ruggeduino:
http://www.rugged-circuits.com/ruggeduino

Frank B
06-16-2016, 02:53 PM
I got my Beta-testboard !
It is luxurious! :)

manitou
06-16-2016, 02:58 PM
I got my Beta-testboard !
It is luxurious! :)
Mine is in the local mail truck and should arrive in a few hours. I've hacked a boards.txt, but I assume Paul will release something official soon ...

PaulStoffregen
06-16-2016, 03:21 PM
Here's a boards.txt file to use.

As you could guess from "-DTEENSYDUINO=129", this is meant to be used with Teensyduino 1.29-beta2 (https://forum.pjrc.com/threads/34732-Teensyduino-1-29-Beta-2-Available).

Frank B
06-16-2016, 03:53 PM
Works and blinks faster:)

hehe.. had a well-known-problem.... first attempt...with a usb-charging cable..

@all: you need a usb-MINI cable for the beta-board, not micro.

Edit:

- FastCRC: Works .

- My "Coremark"-sketch with the gcc 4.8 -compiler (192 MHz) (note: integer only):


2K performance run parameters for coremark.
CoreMark Size : 666
Total ticks : 16824
Total time (secs): 16.824000
Iterations/Sec : 356.633381
Iterations : 6000
Compiler version : GCC4.8.4 20140725 (release) [ARM/embedded-4_8-branch revision 213147]
Compiler flags :
Memory location : STACK
seedcrc : 0xe9f5
[0]crclist : 0xe714
[0]crcmatrix : 0x1fd7
[0]crcstate : 0x8e3a
[0]crcfinal : 0xa14c
Correct operation validated. See readme.txt for run and reporting rules.
CoreMark 1.0 : 356.633381 / GCC4.8.4 20140725 (release) [ARM/embedded-4_8-branch revision 213147] / STACK

https://forum.pjrc.com/threads/29017-Cxxmark-Compiler-Performance-LC-3-1?highlight=coremark


(https://forum.pjrc.com/threads/29017-Cxxmark-Compiler-Performance-LC-3-1?highlight=coremark)

defragster
06-16-2016, 04:32 PM
I got my Beta-testboard !
It is luxurious! :)

Congratulations Frank!
Mine is still 5 miles away where it has been for about 24 hours - at the local post office - after over 200 miles traveling the package needed to rest . . . wait it got done sorting . . . soon . . .

KurtE
06-16-2016, 04:34 PM
Mine should arrive later today as well. Hopefully I will get into town (9 miles away) to pick it up maybe around noon :D

KurtE
06-16-2016, 04:36 PM
Here's a boards.txt file to use.

As you could guess from "-DTEENSYDUINO=129", this is meant to be used with Teensyduino 1.29-beta2 (https://forum.pjrc.com/threads/34732-Teensyduino-1-29-Beta-2-Available).

Would you suggest working off of Beta2 or off of clone of cores?

Frank B
06-16-2016, 05:09 PM
ILI9341_t3 library: Works


Edit:

...tried F_BUS overclocking @192 MHz..
SIM_CLKDIV1_OUTDIV2(1) works. 0 not :) (Too fast for the Display or perhaps the the "long" wires, but the Teensy runs happily with SIM_CLKDIV1_OUTDIV2(0) )

defragster
06-16-2016, 05:10 PM
KurtE - based on this - I just put on a fresh IDE 1.6.9 With TeensyDuino 1.29b2 and this boards.txt - looks like we have T_3.4 and T_3.5::


Here's a boards.txt file to use.

As you could guess from "-DTEENSYDUINO=129", this is meant to be used with Teensyduino 1.29-beta2 (https://forum.pjrc.com/threads/34732-Teensyduino-1-29-Beta-2-Available).

Ben
06-16-2016, 06:11 PM
Should we coordinate library testing / porting with a list in this thread or via github-issues?

JBeale
06-16-2016, 06:43 PM
Should we coordinate library testing / porting with a list in this thread or via github-issues?
Unless Paul changes his mind, looks to me that it is all right here: https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=106782&viewfull=1#post106782 "Please keep all the beta test info only on this forum thread"

defragster
06-16-2016, 06:52 PM
So right Frank: I got my Beta-testboard ! It is luxurious!

Did I miss notes on what speeds USB will work at? USB works at 192MHz or any speed tested at 96 or over, except 180MHz? At 180 MHz Win_10 says it saw a bad USB device.

Quite a few times I had to button push to upload? Though now with IDE SerMon online at 192MHz it is working.

Teensy did not respond to a USB-based request to automatically reboot.
Please press the PROGRAM MODE BUTTON on your Teensy to upload your sketch.

Theremingenieur
06-16-2016, 06:56 PM
Oy! Have I got a beautiful belated birthday gift today! :D

Theremingenieur
06-16-2016, 06:58 PM
@defragster: it looks from the core files that there is no suitable divider for the USB clock when run at 180MHz.

Frank B
06-16-2016, 07:01 PM
Happy Birthday !
180MHz: Maybe there is a trick and the IRC48 clock canbe used somehow.

just for fun, i tried 240 MHz... works.. (but not with SIM_CLKDIV1_OUTDIV4(8); instead value 7 works (?))

Edit:
...but F_BUS with 240MHz does not work :) Oh, there is indeed a limit.. :)

defragster
06-16-2016, 07:19 PM
@defragster: it looks from the core files that there is no suitable divider for the USB clock when run at 180MHz.

Interesting - I picked 180 as the 'spec speed' for my first run with Serial spew and blink - was met with oddity . . .

Donziboy2
06-16-2016, 07:28 PM
Happy Birthday !
180MHz: Maybe there is a trick and the IRC48 clock canbe used somehow.

just for fun, i tried 240 MHz... works.. (but not with SIM_CLKDIV1_OUTDIV4(8); instead value 7 works (?))

Edit:
...but F_BUS with 240MHz does not work :) Oh, there is indeed a limit.. :)

You should slow down before you get a ticket :P

Theremingenieur
06-16-2016, 07:43 PM
General technical question out of the context, not directly MK66/64 related: can the bus clock divider be modified after booting, for example in the setup() part of a sketch?

Frank B
06-16-2016, 07:52 PM
yes, easy.
just write the new value.

for example, for 96MHz F_CPU, same F_BUS:
SIM_CLKDIV1 = SIM_CLKDIV1_OUTDIV1(0) | SIM_CLKDIV1_OUTDIV2(0) | SIM_CLKDIV1_OUTDIV4(3);

SIM_CLKDIV1_OUTDIV2 is for F_BUS

..but read the manual to get a better understanding!

manitou
06-16-2016, 07:58 PM
does teensy K66 have 16 mhz crystal? (same make and model as teensy 3?) if so, 16mhz doesn't divide 180 mhz (VCO multiplier of 22 gives 176 mhz), or am I wrong again? (12 mhz crystal would let you reach 180 mhz).

-inquiring minds

Frank B
06-16-2016, 08:04 PM
Yes, 16MHz. And there is no divisor.
But the K66 has an own 48MHz clock for USB - At the moment, i don't know if both can be used simultanously.

If not, there is a way NOT to use the crystal @ 180 MHZ, and instad the 48MHz clock only.
Had this seen on a forum (Freescale?), but I lost the bookmark..

Edit: I meant, there is no divisor for USB. 180MHz F_CPU are possible with the crystal:

MCG_C5 = MCG_C5_PRDIV0(1);
MCG_C6 = MCG_C6_PLLS | MCG_C6_VDIV0(29);

PaulStoffregen
06-16-2016, 08:05 PM
Would you suggest working off of Beta2 or off of clone of cores?

Either is fine.


Should we coordinate library testing / porting with a list in this thread or via github-issues?

Please keep all the conversation here. Obviously code fixes go on github.

If someone would like to maintain a list of known problems or outstanding issues, probably list a list of message numbers, that'd really help.



180MHz: Maybe there is a trick and the IRC48 clock canbe used somehow.


Yes, that's one of many little things needed...



just for fun, i tried 240 MHz... works.. (but not with SIM_CLKDIV1_OUTDIV4(8); instead value 7 works (?))

Edit:
...but F_BUS with 240MHz does not work :) Oh, there is indeed a limit.. :)

:)

So far 192 was the fastest I ever tried.

Theremingenieur
06-16-2016, 08:05 PM
Thank you, Frank. Obviously you have more luck with the SIM than me with the PITs... :(

I think that after modifying the bus clock in that way, it's needed to re-define F_BUS, so that libraries like FreqMeasureMulti which rely on that will do the appropriate pulse count to frequency conversion. But I will try to check next weekend first if the FTMs can run on 96 instead of 48 MHz, too. That would allow me to do 14bit PWM at 5859.375Hz with a simpler Sallen-Key filter in my current project.

JBeale
06-16-2016, 08:08 PM
"...but F_BUS with 240MHz does not work" Is that the clock used for the internal timers? I'm interested in what the best available timer resolution is, if it is different from T3.2. For example, I think the PulsePosition library (https://www.pjrc.com/teensy/td_libs_PulsePosition.html) based on this comment (https://forum.pjrc.com/threads/25890-New-Pulse-Position-Modulation-(PPM)-Library?p=96044&viewfull=1#post96044) can do 21 nsec timing (F_BUS = 48 MHz with T3.1/3.2 CPU at either 48 or 96 MHz). Does the new Beta board improve on this, and if so by how much?

manitou
06-16-2016, 08:08 PM
Yes, 16MHz. And there is no divisor.
But the K66 has an own 48MHz clock for USB - At the moment, i don't know if both can be used simultanously.

If not, there is a way NOT to use the crystal @ 180 MHZ, and instad the 48MHz clock only.
Had this seen on a forum (Freescale?), but I lost the bookmark..

maybe this https://freescale.jiveon.com/thread/356104

sumotoy
06-16-2016, 08:14 PM
Mine arrived today (gorgeus!) and just tested with TFT_ILI9163C library (modified).
Seems works perfectly till 168Mhz, but jumped to 180Mhz code worked but serial stop working, gived this error 'Error while setting serial port parameters: 38,400 N 8 1'.
The Teensyloader shows an even more interesting state, at the bottom 'Beanchmark.ino is unreadable'
At 192Mhz, surprise! It works, but it changed the serial port number!

UPDATE:
Going back from 192Mhz to 180Mz the sketch upped correctly but Serial disappeared completely!
Have to press reset, then switch back to 168Mhz and serial resumed.
The benchmark showed that at 168Mhz is much faster, ok, it's the first test and uses only SPI.
Looks like it doesn't like Serial at 180Mhz.

Frank B
06-16-2016, 08:20 PM
Yes, all libs need a change if modifing F_BUS... will take some weeks /month i think..
..i did just a quick test, if it is possible !

@sumotoy: For 180MHz, USB is not supported at the moment.

Robin
06-16-2016, 08:23 PM
I'm going to start sending out the next round of beta boards next week. If you are on the list (see post #1) and want to get your hands on one to start testing be sure to send me an email and I'll get one out to you.

PaulStoffregen
06-16-2016, 08:28 PM
Here's a quick shout-out for Erin, who hand soldered all these beta test boards. :)

https://forum.pjrc.com/attachment.php?attachmentid=3421

This photo is actually from when she soldered the Teensy LC betas (https://forum.pjrc.com/threads/27624-Coming-Soon-Teensy-LC-(low-cost-Teensy)?p=63271&viewfull=1#post63271).

sumotoy
06-16-2016, 08:32 PM
@sumotoy: For 180MHz, USB is not supported at the moment.
Ok, that make sense, something related divisor maybe?, btw I already feel there's a demon fast beast inside!

Frank B
06-16-2016, 08:45 PM
Ok, found the reason for my OUTDIV4-Problem.
Manual: "When OUTDIV1 equals 0000 (divide by 1), the otherdividers cannot be set higher than 0111 (divide by 8)."
Unfortunately, that means more than 240MHz is only possible with disabling the Flashmemory.

Theremingenieur
06-16-2016, 08:53 PM
Yes, all libs need a change if modifing F_BUS... will take some weeks

Perhaps a simple

#ifdef F_BUS
#undefine F_BUS
#define F_BUS 96000000
#endif
After modifying the divider in setup() as in the example above would do the job?

KurtE
06-16-2016, 09:02 PM
It arrived :D

Nice looking board. Will be interesting to see how you squish everything down to fit in between those two rows of pins.

Also wish I could borrow Erin to solder a few of my own boards, but that is a different topic ;)

Looks like I need to do some editing of my own libraries to work. My assumption is Teensy 3.5?

Should be easy but may not test the bioloid library using half duplex as to not risk having servo respond at 5v... I will try to breadboard up level shifter.

Again wondering if there is preferred way you prefer ifdefs. Example in my bioloid library I have code like:


void ax12Init(long baud, Stream* pstream, int direction_pin ){
// Need to enable the PU resistor on the TX pin
s_paxStream = pstream;
s_direction_pin = direction_pin; // save away.

// Lets do some init here
if (s_paxStream == &Serial) {
Serial.begin(baud);
}

if (s_paxStream == (Stream*)&Serial1) {
Serial1.begin(baud);
#if defined(__MK20DX256__) || defined(__MKL26Z64__)
if (s_direction_pin == -1) {
UART0_C1 |= UART_C1_LOOPS | UART_C1_RSRC;
CORE_PIN1_CONFIG = PORT_PCR_DSE | PORT_PCR_SRE | PORT_PCR_MUX(3) | PORT_PCR_PE | PORT_PCR_PS; // pullup on output pin;
} else {
Serial1.transmitterEnable(s_direction_pin);
}
#elif defined(TEENSYDUINO)
// Handle on Teensy2...
if (s_direction_pin != -1) {
Serial1.transmitterEnable(s_direction_pin);
}
#endif
}
...

My first pass will be to probably add some more to the first #if

Also in this case I am wondering about if it would make sense to try transceiver driver enable (59.5.1.7) if the direction pin is defined on am RTS pin.

Assuming I can breadboard this up and works, should this be done as part of the library or potentially wrapped into Serial1.transmitterEnable code.


Now time to get to work

manitou
06-16-2016, 09:05 PM
My first pass will be to probably add some more to the first #if

You could use #if defined(KINETISK) and get all 4 teensy3*

manitou
06-16-2016, 09:13 PM
Perhaps a simple

#ifdef F_BUS
#undefine F_BUS
#define F_BUS 96000000
#endif
After modifying the divider in setup() as in the example above would do the job?
I don't think so. the F_BUS symbols are used at compile time. setup() is runtime

Frank B
06-16-2016, 09:17 PM
Perhaps a simple

#ifdef F_BUS
#undefine F_BUS
#define F_BUS 96000000
#endif
After modifying the divider in setup() as in the example above would do the job?

Yes, if there no #if F_BUS == XYZ in the library..

But simply halving the values should do the trick, too. For example instead of Serial1.begin(9600) , Serial1.begin (4800)... same with other devices which are clocked by F_BUS.
But this is off-topic.. :-) You can do this with any Teensy 3.x

PaulStoffregen
06-16-2016, 09:33 PM
Some stuff like serial baud rates use equations, which should automatically adapt. Other stuff like I2C clock rates uses a big list of #ifdef checks for specific speeds, so that code will need to be updated.

defragster
06-16-2016, 10:04 PM
Indeed - Thanks to Erin! Great looking work - Sooooo many tiny pins on that huge K66!


Mine arrived today (gorgeus!) and just tested with TFT_ILI9163C library (modified).
UPDATE:
Looks like it doesn't like Serial at 180Mhz.

sumotoy can you drop a zip of your TFT_ILI9163C mods? I just soldered a display board and starting with the ILI9341.

KurtE
06-16-2016, 10:08 PM
You could use #if defined(KINETISK) and get all 4 teensy3*
Sounds good, tried in my own library and fixed it.

Then compile failed on Adafruit_neopixel. Did same fix in there and it now compiles. However I have two versions of this library installed. The Teensyduino installed one, and the Adafruit one, luckily it looks like you synced up recently.

Anyway put in pull request to make it compile on the new board.

EDIT: Adafruit_Neopixel test app strandtest is working

defragster
06-16-2016, 10:28 PM
Yes, KINETISK or KINETISK_SPI0 (Assuming _SPI# may define added SPI?) would be much cleaner than #if for 4 things. I'll edit my own ILI9163C when I get back if sumotoy doesn't drop his.

ILI9341 working in the demo I ran with stored FFT Data! (from what I did for the ILI9361C).

Also the last TOUCH ColorButtonsMark3 sample I did for XPT2046_Touchscreen and ILI9341_t3 are working fine. (using PJRC Purple Touch board from OSH)

> BOTH of those at 96 and 192 MHz!

sumotoy
06-16-2016, 10:33 PM
sumotoy can you drop a zip of your TFT_ILI9163C mods? I just soldered a display board and starting with the ILI9341.
Sure, here's only parts to be replaced

Question:
Should I Pull changes in my library or just wait?

defragster
06-16-2016, 10:53 PM
Sure, here's only parts to be replaced

Thanks, Done - Works! And works FAST! K66 a bit faster at 192MHz than T_3.2 was at 120MHz with the SPI clock doubled on the SomeBars demo with FFT data doing two VU graphs on screen.

Text only - but - CAUTION- GRAPHIC numbers ahead:
Sketch uses 154,704 bytes (14%) of program storage space. Maximum is 1,048,576 bytes.
Global variables use 5,316 bytes (2%) of dynamic memory, leaving 256,828 bytes for local variables. Maximum is 262,144 bytes.

sumotoy
06-16-2016, 10:57 PM
I found is faster at 168Mhz than 192Mhz.
Also tested at 96Mhz on Teensy 3.2 and 3.5, it's a bit faster with Teensy 3.5, just a bit.

manitou
06-16-2016, 11:04 PM
Beta testing PROTO6 board, K66 @180mhz (using Serial1), IDE 1.6.7, teensyduino 1.29beta ubuntu 14.04

16mhz crystal drift: -8 ppm (NTP host) and GPS pps
RTC crystal (32khz) drift: -1 ppm (measured against micros()), 0 ppm measured with LPTMR
RTC alarm sketch ok

power: LED 13 off/on via hacked USB cable: 73.1/76.1 ma (LED forward voltage 1.842)
with asm("wfi") in yield.cpp (power-saving for delay()): 38.6/41.6 ma (@180mhz)
NOTE: probably don't want WFI in yield.cpp, yield() is in loop() while of main.cpp. put WFI in delay()

linpack single precision floating point (100x100) 30 mflops ; double precision, 2.15 mflops (no hardware assist)

crypto acceleration unit (CAU)
md5 10240 bytes 618 us KBs 16569.58
sha256 10240 bytes 2211 us KBs 4631.39
aes set key us 2
aes cbc 64 bytes 12 us KBs 5333.33

uses NXP assembler routines, reference http://www.freescale.com/products/arm-processors/kinetis-cortex-m/k-series/k7x-glcd-mcus/crypto-acceleration-unit-cau-and-mmcau-software-library:CAUAP
also see CAU results for mbed K64 (https://forum.pjrc.com/threads/24633-Any-Chance-of-a-Teensy-3-1?p=84807&viewfull=1#post84807)

PaulStoffregen
06-16-2016, 11:10 PM
If anyone wants to dig into the details, the K66 has a large 8K cache. I honestly haven't even looked into whether it's even enabled. I'm mostly focused on getting code working correctly.... so by all means, play with this performance stuff I haven't even touched. :)

EDIT: also curious whether FASTRUN makes a big difference?

manitou
06-16-2016, 11:25 PM
random number generator, @180mhz, you get 7.7 million random bits/second (spec is 32-bits every 256 F_BUS ticks == 7.5mbs)

BUG
The RNG register addresses in kinetis.h did NOT work! I used the register addresses from my MBED K64F tests, and then RNG worked

these worked

#define RNG_CR (*(volatile uint32_t *)0x40029000) // RNGA Control Register
#define RNG_SR (*(volatile uint32_t *)0x40029004) // RNGA Status Register
#define RNG_ER (*(volatile uint32_t *)0x40029008) // RNGA Entropy Register
#define RNG_OR (*(volatile uint32_t *)0x4002900C) // RNGA Output Register

test sketch with Serial1

// random RNG
#define PRREG(x) Serial.print(#x" 0x"); Serial.println(x,HEX)

#define REPS 50

#define RNG_CR_GO_MASK 0x1u
#define RNG_CR_HA_MASK 0x2u
#define RNG_CR_INTM_MASK 0x4u
#define RNG_CR_CLRI_MASK 0x8u
#define RNG_CR_SLP_MASK 0x10u
#define RNG_SR_OREG_LVL_MASK 0xFF00u
#define RNG_SR_OREG_LVL_SHIFT 8
#define RNG_SR_OREG_LVL(x) (((uint32_t)(((uint32_t)(x))<<RNG_SR_OREG_LVL_SHIFT))&RNG_SR_OREG_LVL_MASK)
#define SIM_SCGC6_RNGA ((uint32_t)0x00000200)
//#define Serial Serial1
uint32_t trng(){
RNG_CR |= RNG_CR_GO_MASK;
while((RNG_SR & RNG_SR_OREG_LVL(0xF)) == 0); // wait
return RNG_OR;
}

void setup() {
Serial.begin(9600);
Serial.println("hello"); delay(2000);
SIM_SCGC6 |= SIM_SCGC6_RNGA; // enable RNG
PRREG(SIM_SCGC6);
RNG_CR &= ~RNG_CR_SLP_MASK;
RNG_CR |= RNG_CR_HA_MASK; // high assurance, not needed
PRREG(RNG_CR);
PRREG(RNG_SR);
}

void loop() {
uint32_t t, r;
int i;

t=micros();
for(i=0;i<REPS;i++) r=trng();
t=micros()-t;
float bps = REPS*32.e6/t;
Serial.println(bps,2);
Serial.println(r,HEX);

delay(2000);

}

EDIT: Who knew? there are two RNGA peripheral enables. CGC3 implies the original RNG register addresses in kinetis.h, using CGC6 wants the the new addresses I supplied (actually there were comments in kinetis.h to that effect)

ran a million bytes from RNG through NIST statistical tests -- random bits look good.

EDIT:
Ref 38.1 recommends for better crypto strength, use only 1 bit per 32-bits returned.

FYI, later thread with some statistical testing (DIEHARD, STS)
https://forum.pjrc.com/threads/48745-Teensy-3-6-Random-Number-Generator

manitou
06-16-2016, 11:34 PM
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

adrianfreed
06-17-2016, 12:13 AM
I got my board today, checked the baseline test of OSC library and all good so far!
I have to update the OSC demonstration code to accommodate all those extra pins - exactly the problem I was
hoping for. Thanks Paul and crew!

Donziboy2
06-17-2016, 12:43 AM
If anyone wants to dig into the details, the K66 has a large 8K cache. I honestly haven't even looked into whether it's even enabled. I'm mostly focused on getting code working correctly.... so by all means, play with this performance stuff I haven't even touched. :)

EDIT: also curious whether FASTRUN makes a big difference?

You gave toys to a bunch of grown up kids, of course they will just start poking stuff in random orders :P

manitou
06-17-2016, 12:58 AM
USB latency and readbytes test @120mhz to ubuntu 14.04

latency_test /dev/ttyACM0
port /dev/ttyACM0 opened
waiting for board to be ready:
.ok
latency @ 1 bytes: 0.14 ms average, 0.85 maximum
latency @ 2 bytes: 0.13 ms average, 0.54 maximum
latency @ 12 bytes: 0.16 ms average, 1.58 maximum
latency @ 30 bytes: 0.16 ms average, 0.41 maximum
latency @ 62 bytes: 0.28 ms average, 1.76 maximum
latency @ 71 bytes: 0.29 ms average, 1.69 maximum
latency @ 128 bytes: 0.39 ms average, 1.42 maximum
latency @ 500 bytes: 1.02 ms average, 2.52 maximum
latency @ 1000 bytes: 1.77 ms average, 2.85 maximum
latency @ 2000 bytes: 3.25 ms average, 3.56 maximum
latency @ 4000 bytes: 6.38 ms average, 6.55 maximum
latency @ 8000 bytes: 12.63 ms average, 13.04 maximum

receive_test /dev/ttyACM0
port /dev/ttyACM0 opened
ignoring startup buffering...
ignoring startup buffering...
ignoring startup buffering...
...
Bytes per second = 1023437
Bytes per second = 1023507
Average bytes per second = 1023484


http://www.pjrc.com/teensy/benchmark_usb_serial_receive.html

manitou
06-17-2016, 01:22 AM
some ADC pins misbehaving??
unconnected ADC read: on most ADC pins with analogRead() I get a randomish non-zero number EXCEPT for A11, A13, A14, A21, and A22 which all read as 0. A21 and A22 are the DAC's. And pulling A15-A19 to GND does not result in 0, but stays randomish at 300 to 400 ??? Pulling A0-A9 to GND reads 0.

defragster
06-17-2016, 01:40 AM
random number generator, @180mhz, you get 7.7 million random bits/second

Is this the code as you used it? Cut and pasted and never runs past:
RNG_CR &= ~RNG_CR_SLP_MASK;

Note: I moved to Serial from Serial1. Was Serial1 used just to hit 180MHz?

manitou
06-17-2016, 04:59 AM
Is this the code as you used it? Cut and pasted and never runs past:
RNG_CR &= ~RNG_CR_SLP_MASK;

Note: I moved to Serial from Serial1. Was Serial1 used just to hit 180MHz?

Did you patch kinetis.h as indicated? (Serial1 was for running at 180mhz)

JBeale
06-17-2016, 05:38 AM
I have not yet absorbed the 2237 page data sheet... I gather the chip has both USB0 and USB1 which use different pins, and the latter offers USB 2.0 High-Speed (480 MHz). Is USB HS available, or are the connected pins for the USB0 device (LS/FS only)?

defragster
06-17-2016, 06:31 AM
RTC Crystal installed - RTC takes the time and time survives RESET under power - Anyone see a pad labeled VBAT?,- that interior pin group seems not present Beta board? <edit> Time also maintained/recognized and works keeping time uploading prior compiled sketch when power maintained, when power lost it puts in the old compile time.



Did you patch kinetis.h as indicated? (Serial1 was for running at 180mhz)

:confused: Of course not . . . it works when I do that :) - Thanks. I was looking to do the RNG, I'll use your code to finish reading, maybe I'll learn ...

Of course bit create clock varies with multiplier :: 96MHz, 144MHz to 192 MHz:: 6,106,870.00<< bps, but 120 MHz (like 180 MHz) :: varies 7,619,047.50 to 7,7294,68.50<< bps

Prepped a Prop_LC and a pluggable AdaF Perma-Protoboard for an SSD-1306 ... ESP8266 ...

Win 10 IDE 1.6.9 with TeensyInstall 1.29b2 working fine with K66_Beta board. Good results with TeensyDuino and SerMon - except [NOT NEW to K66] on button or Power cycle or Reset - SerMon gets orphaned.

Paul should do a Kickstarter for these! :)

Unless there is a pending fix for this? BOARDS.TXT:: line 77 (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=107069&viewfull=1#post107069) :

teensy35.menu.speed.180opt=180 MHz optimized (No USB)

BenS: Perhaps your post #3 could list items tested to work? (links to posts)
> XPT2046_Touchscreen, RTC, ILI9341_t3, TFT_ILI9163C, RNG, SerialFlash, TeensyTransferTool as HI, OSC, PROP_LC

<edit> TeensyTransferTool works against K66 @192MHz as HID using PROP_LC 8MB Serial Flash:


C:...\teensytransfer>teensytransfer.exe -e
........................................
C:...\teensytransfer>teensytransfer.exe -i > 1.txt
C:...\teensytransfer>teensytransfer.exe -i teensy > 2.txt
C:...\teensytransfer>teensytransfer.exe -w 1.txt
.
C:...\teensytransfer>teensytransfer.exe -w 2.txt
.
C:...\teensytransfer>teensytransfer.exe -l
71 1.txt
164 2.txt
C:...\teensytransfer>teensytransfer.exe -r 1.txt
ID : EF 40 17
Serial: D1 65 38 25 47 25 39 2F
Size : 8388608 Bytes
C:...\teensytransfer>teensytransfer.exe -r 2.txt
Model : ?? (MK66FX1M0)
Serial: 327680
MAC : 05:00:00:05:00:00
EEPROM: 4096 Bytes
F_CPU : 192000000 Hz
F_PLL : 192000000 Hz
F_BUS : 48000000 Hz
F_MEM : 27428571 Hz


>> And (of course) RAW_HID fails at 180MHz as well.

PaulStoffregen
06-17-2016, 08:50 AM
Anyone see a pad labeled VBAT?


On the round 1 & 2 boards, the K66's VBAT pin is hard-wired to 3.3V.

defragster
06-17-2016, 09:05 AM
On the round 1 & 2 boards, the K66's VBAT pin is hard-wired to 3.3V.

Confirmed - Thanks, assumed that was the case given how it is working, and no apparent spare pads. 2 layers? Not much room - the big open bottom side is very full - as already noted good luck putting 2" of stuff inside .5 inches.

Except for needing to clear a bigger hole on my desk - it looks Very Good on the first pass! Very excellent 'Beta' "Proto" board to work with!

manitou
06-17-2016, 10:24 AM
more pin tests:
PULLUP on all pins, respond to pull to GND, OK -- except DAC0 DAC1
measured pullup resistance on several pins 39Kohms
test PWM pins, OK 488hz

touchRead() hangs ????

ADC, see post #184 some ADC pins misbehaving??

DAC sine output to scope looks OK on A21 and A22

manitou
06-17-2016, 11:10 AM
"Of course bit create clock varies with multiplier :: 96MHz, 144MHz to 192 MHz:: 6,106,870.00<< bps, but 120 MHz (like 180 MHz) :: varies 7,619,047.50 to 7,7294,68.50<< bps"

Ref manual says RNG generates 32 random bits every 256 ticks of the F_BUS clock

manitou
06-17-2016, 02:22 PM
more pin tests:

touchRead() hangs ????

The touch (TSI) registers for the K66 are very different than the teensy 3 TSI registers. So additional logic will have to be added to hardware/teensy/avr/cores/teensy3/touch.c

Frank B
06-17-2016, 02:41 PM
If anyone wants to dig into the details, the K66 has a large 8K cache. I honestly haven't even looked into whether it's even enabled. I'm mostly focused on getting code working correctly.... so by all means, play with this performance stuff I haven't even touched. :)

EDIT: also curious whether FASTRUN makes a big difference?

- The value of LMEM_PCCCR is 3, which means writebuffer and cache are enabled
- Fastrun... ehm.. it is faster without it... ! (but I tested with only one little short sketch only)

Ben
06-17-2016, 02:42 PM
BenS: Perhaps your post #3 could list items tested to work? (links to posts)
> XPT2046_Touchscreen, RTC, ILI9341_t3, TFT_ILI9163C, RNG, SerialFlash, TeensyTransferTool as HI, OSC, PROP_LC

I can do that, but to be honest I lost track of who is testing what. I fear if I take the job as a "human bug tracker" I can't satisfy your needs if I only update once or twice a day.
Maybe a list of all Libraries and all Shields/Adaptors with a short description of the current status can be put in Post 3? I'd try to update that dayly, and if I miss something you could PM me or post here? But for that I'd need that list as a start.

defragster
06-17-2016, 03:19 PM
"Of course bit create clock varies with multiplier :: 96MHz, 144MHz to 192 MHz:: 6,106,870.00<< bps, but 120 MHz (like 180 MHz) :: varies 7,619,047.50 to 7,7294,68.50<< bps"

Ref manual says RNG generates 32 random bits every 256 ticks of the F_BUS clock

- yes, that was the 'of course bit create' part - I had scanned that



I can do that, but to be honest I lost track of who is testing what.

Yeah - posted that and realized it could be a big chore - not as easy as an unchanging pin list . . . at 8 pages and growing and so many topics and 8 folks turning in to 80 ...

... and the list - I wonder if Paul has one or the LC list to start with?

I put FASTRUN on the super short trng() code and - natural code management probably keeps all that.

Ran last 8hrs - 10 trng()'s and the still current RTC clock spewing serial

manitou
06-17-2016, 04:17 PM
Another example of floating point hardware in float-intensive filters for prop shield IMU, (no sensor data collection). The NXP kalman filter is compiled with
#pragma GCC optimize ("O3")

Times are in microseconds

Teensy 3.2 K64 K66 K66 mbed K64 stm32l4 F469NI mega2560
@120mhz @120mhz @180mhz @120mhz @120mhz @80mhz @180mhz @16mhz
NXP/kalman 3396 358 250 367 368 535 315 30272 us
madgwick 223 7 7 10 8 8 6 2628
mahony 125 5 5 8 6 6 4 1548

manitou
06-17-2016, 04:39 PM
Ye old sdFAT SPI/FIFO sketch runs at 27.4 megabits/sec with SPI clock @ 30mhz. Good.

but some old teensy SPI DMA sketches seem to be hanging ... TODO

the default SPI library runs at 13.3 mbs with 30mhz SPI clock.

I2C scan works with prop-shield, but onehorse prophshield sketch won't compile (i2c_t3 lib ?)

NXPMotionSense orientation example OK with propshield

EEPROM sketch reads EEPROM, but hangs in write() ???? works on teensy 3.2

KurtE
06-17-2016, 04:43 PM
I decided to try hooking up Dotstar leds, My first attempt failed as tried using same level shifter I used for Neopixel test (TXB0108). Did not work. So decided to instead
try using Propshield, so I jumper-ed the appropriate pins from this board to propshield, and then tried running, the Adafruit_dotstar libraries test program strandtest with a couple slight mods (pinmode(7, OUTPUT)... and also used the SPI contructor). Appears to run fine.

Next up trying the FastLed test app that is listed in the prop shield page. Fails to compile, now time to edit...

Ben
06-17-2016, 04:43 PM
Another example of floating point hardware in float-intensive filters for prop shield IMU, (no sensor data collection). The NXP kalman filter is compiled with
#pragma GCC optimize ("O3")

Times are in microseconds


T3.2@120mhz K66@180mhz
NXP 3396 285
madgwick 223 7
mahony 125 3

Are the filters using the "0x5f3759df" fast inverse square root? Maybe that speed-for-accuracy optimization can be omitted on the K66.

sumotoy
06-17-2016, 04:58 PM
Times are in microseconds


T3.2@120mhz K66@180mhz
NXP 3396 285
madgwick 223 7
mahony 125 3


Impressive!!!!!!!!!!!

Am I missed the trick to get the serial working at 180Mhz or have to use Serial1?

Frank B
06-17-2016, 05:03 PM
BUG
The RNG register addresses in kinetis.h did NOT work! I used the register addresses from my MBED K64F tests, and then RNG worked

these worked

#define RNG_CR (*(volatile uint32_t *)0x40029000) // RNGA Control Register
#define RNG_SR (*(volatile uint32_t *)0x40029004) // RNGA Status Register
#define RNG_ER (*(volatile uint32_t *)0x40029008) // RNGA Entropy Register
#define RNG_OR (*(volatile uint32_t *)0x4002900C) // RNGA Output Register


That's interesting and a big bug in the manual !

Epyon
06-17-2016, 05:28 PM
Maybe a bit late to the party, but wonderful news! I've signed myself up for third or four round because I'm still on holidays (writing you this from sunny Sitges beach :cool: ). I won't be able to do much code porting, but I'll sure give the K66 some good usage tests in some industrial applications (mainly industrial field busses and datalogging). Looking forward to it.

Frank B
06-17-2016, 05:36 PM
@Paul, did you test the audioshield ? Mine are all soldered to Teensys :-(

manitou
06-17-2016, 05:45 PM
Are the filters using the "0x5f3759df" fast inverse square root? Maybe that speed-for-accuracy optimization can be omitted on the K66.

Yes, they are Paul's version with invSqrt() and 2 iterations. somone had a benchmark comparing invSqrt and 1/sqrt, here is a run on k66 @180mhz

Computing 5000 inverse square roots using the normal sqrtf() function took 1139 microseconds.
Computing 5000 inverse square roots using the fast qsqrtf() function took 972 microseconds.
maximum absolute error with fast sqrt was: 0.000000029802322
and occurred when computing qsqrtf(13.292902946472167).
normal sqrt was 1.1718 times slower

and the invSqrt (2 iterations) is faster than hardware float sqrt (and the divide)

manitou
06-17-2016, 05:47 PM
Impressive!!!!!!!!!!!

Am I missed the trick to get the serial working at 180Mhz or have to use Serial1?

you have to use Serial1 (#define Serial Serial1)

defragster
06-17-2016, 06:02 PM
@Paul, did you test the audioshield ? Mine are all soldered to Teensys :-(

I had that question too (with added FLASH? or RAM?). I have one here unpinned.

Started with Prop_LC for Talkie & DotStar, and to perhaps 'reflow' the Audio Tutorial to work (as it can) on the Prop_LC.

Ben
06-17-2016, 06:17 PM
Yes, they are Paul's version with invSqrt() and 2 iterations. somone had a benchmark comparing invSqrt and 1/sqrt, here is a run on k66 @180mhz Yeah, me :cool:

Ok so I guess it (just barely) makes sense to leave in the quick sqrt.

KurtE
06-17-2016, 06:19 PM
I now have the fastled working on the Prop shield, Had to edit two files in the library:
platform.h: Line 8

#elif defined(__MK20DX128__) || defined(__MK20DX256__) || defined(__MK64FX512__) || defined(__MK66FX1M0__)

likewise led_sysdefs.h: line 8

#elif defined(__MK20DX128__) || defined(__MK20DX256__) || defined(__MK64FX512__) || defined(__MK66FX1M0__)

For whatever reason in these files using

#elif defined(KINETISK) // Teensy 3.0 & 3.1/2 3.4 3.5
Did not work and I received compile errors on new board (as well as T3.2)

Kurt

Edit: P.S - Not sure where to delta it as the files don't appear to match what is in Paul's github project nor where his project is forked from?

PaulStoffregen
06-17-2016, 06:29 PM
I had that question too (with added FLASH? or RAM?). I have one here unpinned.


Yes, I tested the audio shield, but so far only playing wav files. No testing yet with SPI flash or SPI RAM.


This weekend I'm going to fix up the many issues reported over the last couple days and probably publish a third beta. Will also update the official boards.txt with lines to uncomment for the beta.

Today I have a couple other commitments, so look for this stuff late Saturday or sometime Sunday. Keep trying stuff. Seems quite a lot of broken at this moment, but hopefully starting next week we'll have things more solid.

shinji
06-17-2016, 07:50 PM
Not sure if this helps (taken from the LC thread https://forum.pjrc.com/threads/27689-Teensy-LC-Beta-Testing?p=63652&viewfull=1#post63652)



digitalWrite
digitalRead
pinMode INPUT
pinMode INPUT_PULLUP
pinMode OUTPUT
analogRead(num)
analogRead(A*)
analogRead(38) temperature
analogRead(40) bandgap ref
analogRead noise level
analogReference INTERNAL
analogReference EXTERNAL
analogReadResolution
analogWrite
analogWriteResolution
analogWriteFrequency
analogWrite DAC
IntervalTimer
tone, noTone
delay
delayMicroseconds
millis
micros
elapsedMillis
elapsedMicros
attachInterrupt
pulseIn
shiftIn
shiftOut
Serial1
Serial2
Serial3
Serial1.transmitterEnable(pin)
Serial2.transmitterEnable(pin)
Serial3.transmitterEnable(pin)
touchRead
DMAChannel
AVR emu: PORT
AVR emu: PIN
AVR emu: DDR
AVR emu: SPI registers
AVR emu: SREG
AVR emu: EIMSK
AVR eeprom_read_byte
AVR eeprom_read_word
AVR eeprom_read_dword
AVR eeprom_read_block
AVR eeprom_write_byte
AVR eeprom_write_word
AVR eeprom_write_dword
AVR eeprom_write_block
portOutputRegister
portInputRegister
portModeRegister
pgm_read_byte
pgm_read_word
pgm_read_dword
random

Keyboard.print
Mouse.move
usbMIDI.sendNoteOn

Serial.print (USB Serial)
Serial.print (USB HID)

Wire
Wire slave mode
Wire1
i2c_t3
SPI
SPI1
SPI.setCLK(14)
SPI.setMISO()
SPI.setMOSI()
SD
Ethernet W5100 chip
Ethernet W5200 chip
EEPROM
Firmata
LiquidCrystal
LiquidCrystalFast
Servo
Encoder
Keypad
SoftwareSerial
Stepper
PS2Keyboard
OneWire
IRremote
TinyGPS
Bounce
AccelStepper
SoftPWM
ShiftPWM
Time
TimeAlarms
Metro
TimerOne
TimerThree
FreqMeasure
FreqCount
NeoPixel
ILI9341_t3
OctoWS2811
Audio
FTOLED
Adafruit_CC3000
Adafruit_ILI9340
Adafruit_ILI9341
Adafruit_nRF8001
Adafruit_RA8875
Adafruit_SSD1306 I2C 128x32
Adafruit_SSD1306 I2C 128x64
Adafruit_SSD1306 SPI 128x32
Adafruit_SSD1306 SPI 128x64
Adafruit_ST7735
Adafruit_STMPE610
Adafruit_VS1053
AltSoftSerial
Artnet
CapacitiveSensor
DmxSimple
DogLcd
DS1307RTC
Entropy
FastLED
FlexiTimer2
FrequencyTimer2
ks0108
LedControl
LedDisplay
MIDI
MsTimer2
NewPing
OSC
Ping
PulsePosition
PWMServo
RadioHead
SPIFlash
ST7565
Tlc5940
UTFT
UTouch
VirtualWire
x10
OpenGLCD
SdFat
ledRings
FastCRC

manitou
06-17-2016, 08:25 PM
SPI SerialFlash ListFiles OK with SPI flash on prop shield

CMT timer PWM and interrupt (IRremote pre-test) OK

speedTest

F_CPU = 180000000 Hz
1/F_CPU = 0.0056 us
The next tests are runtime compensated for overhead
nop : 0.006 us
avr gcc I/O : 0.066 us
Arduino digitalRead : 0.084 us
Arduino digitalWrite : 0.117 us
pinMode : 0.192 us
multiply volatile byte : 0.039 us
divide volatile byte : 0.049 us
multiply volatile integer : 0.033 us
divide volatile integer : 0.039 us
multiply volatile long : 0.034 us
multiply single float : 0.044 us
divide single float : 0.109 us
multiply double float : 0.329 us
divide double float : 5.499 us
itoa() : 0.274 us
ltoa() : 1.199 us
dtostrf() : 16.949 us
random() : 0.224 us
y |= (1<<x) with volatile : 0.027 us
bitSet() with volatile : 0.028 us
analogReference() : 0.933 us
analogRead() : 7.149 us
analogWrite() PWM : 0.709 us
delay(1) : 999.999 us

Ben
06-17-2016, 09:07 PM
Not sure if this helps (taken from the LC thread https://forum.pjrc.com/threads/27689-Teensy-LC-Beta-Testing?p=63652&viewfull=1#post63652)
Thanks, i added the shields and adaptor boards and put the list in Post #3 (https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=106275&viewfull=1#post106275).
@all: If you want me to edit a line, add an item to the list, whatever, drop me a PM or post here. I'll try to keep the list up to date.

JBeale
06-17-2016, 09:17 PM
@Ben : your list of things to test includes Serial1 ... Serial3, but this device also includes Serial4 and Serial5 (?) At least, the TX/RX pins for 5 serial ports are listed on the pinout.

sumotoy
06-17-2016, 09:20 PM
TFT_ILI9163C (https://github.com/sumotoy/TFT_ILI9163C/tree/Pre-Release-1.0p7) modded for compatibility,tested and ready (is in the Teensyduino last beta but must replaced with this)
TFT_ST7735 (https://github.com/sumotoy/TFT_ST7735/tree/1.0p1) modded for compatibility,tested and ready
gpio_MCP23S17 (https://github.com/sumotoy/gpio_MCP23S17) modded for compatibility,tested and ready
TFT_ILI93xx (https://github.com/sumotoy/TFT_ILI93XX) modded for compatibility,tested and ready
RA8875 (https://github.com/sumotoy/RA8875/tree/0.79b11p10) modded for compatibility, still not tested (is in the Teensyduino last beta but must replaced with this)
OLED_pictivaWide (https://github.com/sumotoy/OLED_pictivaWide) modded for compatibility, tested and ready
All uses SPI and SPI Transactions

manitou
06-17-2016, 09:31 PM
IRremote:
I think IRremote will work with addition of the K66 (and K64) conditionals in IRremoteInt.h probably in the zip file described in
https://www.pjrc.com/teensy/td_libs_IRremote.html

but Paul also has an out-of-date? repository at https://github.com/PaulStoffregen/Arduino-IRremote

and then there is the master repository https://github.com/z3t0/Arduino-IRremote

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'm not sure what the official teensy IRremote distribution is.

defragster
06-17-2016, 09:37 PM
@Ben : your list of things to test includes Serial1 ... Serial3, but this device also includes Serial4 and Serial5 (?) At least, the TX/RX pins for 5 serial ports are listed on the pinout.

Indeed it does have Serial#1-#5, that was the Feb 2015 T_LC beta list pulled from the thread shinji found as Paul posted it. I'm wondering if there is a K66 version in the works?

I've completed 12 hours of my 'doing other stuff burn in the K66 test' so far today, it's got another hour or so to run. LED still blinking and RND nums spitting out with the time. No smoke or high temps.

Paul - is this K66 Beta board in line with the 3.3V regulator power and other specs that you expect to evolve in the end? Obviously the CPU package will change and some test fixtures and pins/pads supplied will be gone. Not that I intend to overload it - but if I stick on a display (or two), power an ESP-8266, Flash card etc in parallel will that relate? Does the per pin power change with the CPU package?

Frank B
06-17-2016, 09:48 PM
Tx6 & Rx6 are on the (planned) pins 40/41

Frank B
06-17-2016, 09:49 PM
What's needed (soft+hardware) to try the debug-pins ?
Edit: Someone mentioned a Teensy (LC?) as "debug-dongle" long time ago... I don't remember who it was ?

KurtE
06-17-2016, 10:00 PM
@Ben : your list of things to test includes Serial1 ... Serial3, but this device also includes Serial4 and Serial5 (?) At least, the TX/RX pins for 5 serial ports are listed on the pinout.
Fyi - I have started to hack up the Core3 files to try to add these two usarts...

Frank B
06-17-2016, 10:03 PM
Perhaps I can do the first steps to add 216/240MHz overclocking and full-featured FLAC-decoding during this weekend.
FastCRC is ready & tested.

Ben
06-17-2016, 11:12 PM
list updated up to Post 221. If I missed something PM me.

manitou
06-17-2016, 11:28 PM
Never mind'ish, I see the "ugly hack" in analog.c

#if defined(__MK64FX512__) || defined(__MK66FX1M0__) // ugly hack for now...
#define __MK20DX256__
#endif


Though K66/K64 don't have VREFOUT, but have bandgap on AD27 and need to set PMC_REGSC like LC
[B]
EDIT: I was wrong, K66 does have VREF output, ADC1/AD18, just like teensy 3

As noted in EDIT, I was wrong. the K66 internal ADC registers (temperature,and VREF output) work just like Teensy 3. One could add internal channels to read the two DACs, ADC0/AD23 and ADC1/AD23

jonr
06-18-2016, 01:14 AM
The board is nicely done.

> (i2c_t3 lib ?)

This change to i2c_t3.h helps compilation.

#if !defined(I2C_T3_H) && (defined(__MK20DX128__) || defined(__MK20DX256__) || defined(__MKL26Z64__) || defined(__MK66FX1M0__)) // 3.0/3.1/LC/3.5

KurtE
06-18-2016, 02:07 AM
Made some progress on Serial4 and Serial5 objects. I still need to do more testing, but simple sketch:

void setup() {
// put your setup code here, to run once:
delay(1000);
Serial.begin(115200);
delay(1000);
Serial3.begin(115200);
Serial4.begin(115200);
Serial5.begin(115200);
pinMode(13, OUTPUT);
delay(1000);
}

void loop() {
// put your main code here, to run repeatedly:
digitalWrite(13, HIGH);
Serial.println("Printing to Serial3");
Serial3.println("Hello World 3");
Serial.println("Printing to Serial4");
Serial4.println("Hello World 4");
Serial.println("Printing to Serial5");
Serial5.println("Hello World 5");
digitalWrite(13, LOW);
delay(500);
}
Is at least according to my logic analyzer I am getting the correct output on the correct pins. I have not tested input yet. In case anyone wishes to take a look, I pushed a new branch up on my core fork. https://github.com/KurtE/cores/tree/Serial4-Serial5

Also Serial4 and Serial5 do not show up a KEYWORD1 objects. Not, sure how to get that to happen...

defragster
06-18-2016, 03:01 AM
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?

defragster
06-18-2016, 06:55 AM
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.

WMXZ
06-18-2016, 07:25 AM
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 ?

defragster
06-18-2016, 09:15 AM
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.



#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();
}

Markus_L811
06-18-2016, 11:21 AM
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

Frank B
06-18-2016, 11:31 AM
@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..

Frank B
06-18-2016, 11:54 AM
...deleted...(wrong)

Somehow, it does not like less than 72MHz... I don't know why, at the moment.

PaulStoffregen
06-18-2016, 12:27 PM
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.

manitou
06-18-2016, 12:29 PM
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.

KurtE
06-18-2016, 01:09 PM
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

Frank B
06-18-2016, 01:30 PM
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.

:-) lol, I was about to make a pull request for overclocking :-)
I can confirm the n=80 for delayMicroseconds() ... This was finally a reason to use my Salae-LA

KurtE
06-18-2016, 01:49 PM
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.

manitou
06-18-2016, 02:42 PM
PulsePosition loopback example worked on K66

Ben
06-18-2016, 03:42 PM
List updated up to post #238

sumotoy
06-18-2016, 04:13 PM
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

manitou
06-18-2016, 04:34 PM
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

KurtE
06-18-2016, 04:39 PM
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:


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.

manitou
06-18-2016, 04:53 PM
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

Frank B
06-18-2016, 05:56 PM
Fix for 48 and 24 MHz:

https://github.com/PaulStoffregen/cores/compare/master...FrankBoesing:patch-1

I don't know why setting SIM_CLKDIV1_OUTDIV3 is not needed for other speeds,
but it works...

Maybe, it's better to set SIM_CLKDIV1_OUTDIV3 for other speeds as well ?

That field is not used on Teensy 3.1/3.2 (don't know if it compatible to 3.0), so no problem to use it for T3.1/T3.2, too.

KurtE
06-18-2016, 06:01 PM
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

sumotoy
06-18-2016, 06:41 PM
Nevermind. SPI1 and SPI2 for KINETISK are currently not present inside SPI.cpp
Trying to update SPI library...

PaulStoffregen
06-18-2016, 07:26 PM
Fix for 48 and 24 MHz:

https://github.com/PaulStoffregen/cores/compare/master...FrankBoesing:patch-1


Merged just now. Thanks! :)




I don't know why setting SIM_CLKDIV1_OUTDIV3 is not needed for other speeds,
but it works...


Good question. This is the first chip I've ever used which has OUTDIV3.

PaulStoffregen
06-18-2016, 07:29 PM
Pushed up more changes to Serial3.c Serial4.c and Serial5.c to the setTX functions.

Merged, plus a little fix for the open drain option.

Hopefully Serial4 & Serial5 are fully working now?

PaulStoffregen
06-18-2016, 07:34 PM
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.

PaulStoffregen
06-18-2016, 07:46 PM
Might be problems with the -0s code size optimization on K66. Maybe?