K66 Beta Test

Status
Not open for further replies.
Donziboy2 said:
Not that im aware of. I will be making one in the next few days, I need one for another project i'm working on that is to big for free eagle.
Click to expand...
Thanks for all the work on this. It shouldn't be too bad getting it into Kicad now that you have the exact dimensions nailed down.
 
DaQue said:
Thanks for all the work on this. It shouldn't be too bad getting it into Kicad now that you have the exact dimensions nailed down.
Click to expand...

Yep, started it dis morning, my biggest hurdle is figuring out all the pin assignments after #39. I started digging but had to leave for work.
I want to make sure both symbols have roughly the same pin information. I think an assignment card for pins after #39 would be nice. There are also a lot of alternate functions on some of the pins.
 
I know that a few of us have posted things about what is on all of these pins.

Including for example my Excel document, which here is my current one, which has the updated tabs.

Also earlier in the thread is my diptrace versions. In case anyone is interested I also uploaded newer version with my experiment for cutouts to maybe solder directly...

Also not sure if anyone is interested, but I also have my 3d step file, I created to view in 3d in diptrace. Current version is shown in my breakout board thread:

attachment.php
 

Attachments

  • Teensy 3.6 breakout Layout.pdf
    368.9 KB · Views: 234
  • Teensy Diptrace library files.zip
    14.6 KB · Views: 145
Ignore, see post 1159
Latest updates for the eagle symbol. Think I have learned to decipher the datasheet.
I will post it tomorrow after I have had time to double check/cleanup and get comments.
 
Last edited:
Made a few more changes and grabbed the T36 top card and added some markings(RX5/TX5).
Has anyone started the T36 backside card? If not I may do a lazy mans paint version just to get it started.
YA6haaj.jpg

qV8rja5.png

edit.. edit2.. damn autocorrect
Congrats to Paul at exceeding your T3.0 backers :)
 
Last edited:
@Robin My package arrived on Monday. Thanks! Awesome board. It strikes me every time that something this powerful and versatile can have such a low component count :) .
 
Donziboy2 said:
Made a few more changes and grabbed the T36 top card and added some markings(RX5/TX5).
Has anyone started the T36 backside card? If not I may do a lazy mans paint version just to get it started.
View attachment 7926

View attachment 7927
Click to expand...
Looks great, may have to update my Diptrace version to have some more information and maybe the order of things. One thing I wonder about as I do that is what to do with all of the GND and 3.3v pins. I typically add them as their own entry on the Schematic Component and Pattern and I either add some or all of them to the same signal like GND. The problem is each one I add, I then typically have to run etch between them as the system does not know they are connected. Not sure if I can tell Diptrace they are connected, and sometimes probably don't want them to be assumed as for example would not want all of the servos to run their GND through the chip...
 
KurtE said:
Looks great, may have to update my Diptrace version to have some more information and maybe the order of things. One thing I wonder about as I do that is what to do with all of the GND and 3.3v pins. I typically add them as their own entry on the Schematic Component and Pattern and I either add some or all of them to the same signal like GND. The problem is each one I add, I then typically have to run etch between them as the system does not know they are connected. Not sure if I can tell Diptrace they are connected, and sometimes probably don't want them to be assumed as for example would not want all of the servos to run their GND through the chip...
Click to expand...

For eagle I have to name each pin differently so I do something like GND0, GND1, GND2 and so on, then when I combine the Symbol and Footprint I just select all the pins for the 1 GND connection I put on the symbol. For Kicad I have to have 1 Connection for Each pin, which can be annoying when you have a lot of grounds lol.
 
el_supremo said:
With the -36000 in the array size declaration, the code was 463,420 bytes long and loads and executes without problem. Remove the -36000 and the code size becomes 535,420 bytes, the sketch won't run and the serial port disappears.
Click to expand...

Just to confirm, this is a bootloader bug. I will be working on it soon.
 
KurtE said:
Was wondering, would you like us to continue to have most of the Teensy 3.5/3.6 Beta/Kickstarter conversation still in this thread or start new threads for different things.
Click to expand...

This thread is still best. This is the place I'm looking for important things I've missed over the last week....
 
PaulStoffregen said:
Just to confirm, this is a bootloader bug. I will be working on it soon.
Click to expand...

FYI, with 1.6.11 and 1.30 beta3 on macos, the sketch seems to work for me, even with code size 535KB. Also works on ubuntu 14.04 32-bit and 64-bit. (on one of my 32-bit ubuntu's, the compile still fails with const array > 250KB, that machine only has 3 GB of memory, so compiler may be memory-limited ?? ... whatever)
 
Just received the Teensy 3.6 today... Thank you very much!

... and rushed to build and link, upload and run a sketch with embedXcode.

It worked on the first try. Congratulations for the clean software implementation!
 
Last edited:
PaulStoffregen said:
This thread is still best. This is the place I'm looking for important things I've missed over the last week....
Click to expand...
Sounds Good.

As I mentioned in another thread there was the issue about not yet exposing the two new Analog pins on the bottom of the board, which are on pins 49 and 50. I went ahead and made some changes to add these as A23 and A24, I left it such that if you pass in the special numbers of pin 44 and 45 it will still get the temp and VRef values. I personally think these should be out in some other range and have some #define for it. Anyway I created a quick and dirty test program and it appears to be able to talk to those pins, so I issued a pull request: https://github.com/PaulStoffregen/cores/pull/167

manitou said:
I don't think the getmac function has been updated. Paul fetches the serial number for the USB id in usb_init_serialnumber() in
https://github.com/PaulStoffregen/cores/blob/master/teensy3/usb_desc.c#L1218
Ethernet MAC will uses lower 24-bits of the serial number word (as I understand it).
Click to expand...
Note: there is an issue of being able to read the USB serial number if you are running at a speed over 120mhz, which is why windows will not necessarily know one T3.6 from another and so which Serial port may not be consistent. I have a "hack" that I believe is working on my machine, where I grab the serial number before we switch to high speed.
Not sure if that approach is the best, but it works better for me than not having it: Again this is up in Pull request: https://github.com/PaulStoffregen/cores/pull/166

Edit: in case someone would like to see my Quick and dirty analog test:
Code: 
#include <Bounce.h>
#define MIN_DELTA 5
uint8_t analog_pins[] = {A0, A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A13, A14, A15, A16,
                         A17, A18, A19, A20, A21, A22, A23, A24, 44, 45
                        };
uint8_t analog_pin_index = 0;

Bounce button0 = Bounce(0, 15);
uint16_t last_analog_val = 0;



void setup() {
  pinMode(0, INPUT_PULLUP);

  while (!Serial && (millis ()  <= 3000));
  Serial.begin(115200);
  delay(200);
  Serial.println("Test Analog T3.6 analog pins");
  Serial.printf("Temp: %d Volt: %d\n\r", analogRead(44), analogRead(45));
}

void loop() {
  button0.update();

  if (button0.fallingEdge()) {
    analog_pin_index++;
    if (analog_pin_index >= sizeof(analog_pins))
      analog_pin_index = 0;
    last_analog_val = 0;
    Serial.printf("Checking A%d\n\r", analog_pin_index);
  }
  if (Serial.available()) {
    analog_pin_index = Serial.parseInt();
    last_analog_val = 0;
    Serial.printf("Checking A%d\n\r", analog_pin_index);
    while (Serial.read() != -1) ;
  }
  uint16_t analog_val = analogRead(analog_pins[analog_pin_index]);
  if (abs(analog_val - last_analog_val) >= MIN_DELTA) {
    last_analog_val = analog_val;
    Serial.printf("A%d %d\n\r", analog_pin_index, analog_val);
  }
  delay(50);
}
 
First run today with Teensy 3.6 beta. Nice to see Blinky again after changing the Arduino/Teensyduino to 1.6.11 and 1.30 beta3.

My code for the "Precision Frequency Standard" ran first time with no changes at all. Interesting that this config is using the Epson 16 MHz module - my previous test on T3.1 had an NDK 16 MHz module, so the digital capacitors are working great and still dithering between OSC_CR = "02h" and "0Ch" to hit the sweet spot on frequency. The evidence is here in the scope display of the phase locked 60 KHz... (now using a 3.3v supply obviously on the CD4046 to comply with signal input demands...)

PrecisionFreqStd on T36.jpg
 
8 bit Parallel data port access

Hi, just a quick query.

Just wondering what pins would be best for 8 bit parallel data lines. Should be 8 continuous pins on the same port somewhere that can be spared.

Been creating a lot of libraries for the 32 bit Arduino Due but these new boards seem a lot better.

For all my libraries I hook into a hardware abstraction layer for the low level pin setting.

Example

Code: 
/*
These routines are built for speed... they assume valid pins ... use with caution

They are board specific constant access to pins cause every board has different ways of doing basically the same stuff at a low level!
*/

#if defined(__MK20DX256__) // 3.1
	#define __TEENSY_3_1__
	#define __TEENSY_3__
#endif

#if defined(__MK20DX128__) // 3.0
	#define __TEENSY_3_0__
	#define __TEENSY_3__
#endif

#if defined(__TEENSY_3__)
  
#define BOARD_MSG "** Teensy 3.x 32 bit ARM code!" 

// These variables are the native 8/32 bit types and used for things 0-127 and 0-255

static const uintX_t digitalPinCount = CORE_NUM_TOTAL_PINS;

// https://www.pjrc.com/teensy/td_libs_Wire.html

// Two Wire (aka I2C) ports

#define SDA_PIN SDA
#define SCL_PIN SCL

// https://www.pjrc.com/teensy/td_libs_SPI.html

#define SS_PIN    SS
#define MOSI_PIN  MOSI 
#define MISO_PIN  MISO 
#define SCK_PIN   SCK

struct pin_map_t
{
	volatile uint32_t *ddr;
	volatile uint32_t *inp;
	volatile uint32_t *write_set;
	volatile uint32_t *write_clear;
	volatile uint32_t *write_toggle;
	uint32_t port_bit;
};

#define ADDR(_p,_b) &GPIO##_p##_PDDR, &GPIO##_p##_PDIR, &GPIO##_p##_PCOR, &GPIO##_p##_PSOR, &GPIO##_p##_PTOR,  1 << _b

static const pin_map_t digitalPinMap[] =
{
	{ ADDR(B,16) }, // 0
	{ ADDR(B,17) },  // 1
	{ ADDR(D,0) }, // 2
	{ ADDR(A,12) }, // 3
	{ ADDR(A,13) }, // 4
	{ ADDR(D,7) }, // 5
	{ ADDR(D,4) }, // 6
	{ ADDR(D,2) }, // 7
	{ ADDR(D,3) }, // 8
	{ ADDR(C,3) }, // 9
	{ ADDR(C,4) }, // 10
	{ ADDR(C,6) }, // 11
	{ ADDR(C,7) }, // 12
	{ ADDR(C,5) }, // 13
	{ ADDR(D,1) }, // 14
	{ ADDR(C,0) }, // 15
	{ ADDR(B,0) }, // 16
	{ ADDR(B,1) }, // 17
	{ ADDR(B,3) }, // 18
	{ ADDR(B,2) }, // 19
	{ ADDR(D,5) }, // 20
	{ ADDR(D,6) }, // 21
	{ ADDR(C,1) }, // 22
	{ ADDR(C,2) }, // 23
	{ ADDR(A,5) }, // 24
	{ ADDR(B,19) },  // 25
	{ ADDR(E,1) }, // 26
	{ ADDR(C,9) }, // 27
	{ ADDR(C,8) }, // 28
	{ ADDR(C,10) }, // 29
	{ ADDR(C,11) }, // 30
	{ ADDR(E,0) }, // 31
	{ ADDR(B,18) }, // 32
	{ ADDR(A,4) } // 33	
};


static __INLINE__ void fastDigitalToggle(uint32_t pin) { *digitalPinMap[pin].write_toggle = digitalPinMap[pin].port_bit; }

#define SHIELD_MSG "** DIB 8/16 bit interface pins NOT implemented"

static __INLINE__ void fastDigitalWrite8_1(uint32_t val8) { //todo }
static __INLINE__ void fastDigitalWrite8_2(uint32_t val8) { //todo }

static __INLINE__ void fastPinMode8_1_INPUT() { }
static __INLINE__ void fastPinMode8_2_INPUT() { }

static __INLINE__ void fastPinMode8_1_OUTPUT() { }
static __INLINE__ void fastPinMode8_2_OUTPUT() { }

static __INLINE__ uint32_t fastDigitalRead8_1() { return 0; }
static __INLINE__ uint32_t fastDigitalRead8_2() { return 0; }

static __INLINE__ void setPinMode(uint32_t pin, uint32_t val) {	pinMode(pin, val); }

static __INLINE__ void fastDigitalWrite(uint32_t pin, boolean val)
{
  if (val)
  {
	  *digitalPinMap[pin].write_set = digitalPinMap[pin].port_bit;
  }
  else
  {
	  *digitalPinMap[pin].write_clear = digitalPinMap[pin].port_bit;
  }
}

static __INLINE__ uint32_t fastDigitalRead(uint32_t pin) { return (*digitalPinMap[pin].inp & digitalPinMap[pin].port_bit); }

struct strFastPin
{
	uintX_t pin;
	uint32_t mask;
	volatile uint32_t *set;
	volatile uint32_t *unset;
	volatile uint32_t *read;
};

static __INLINE__ void fastpinSet(strFastPin &v, uint32_t value) { if (value) { *v.set = v.mask; } else { *v.unset = v.mask; } }
static __INLINE__ void fastpinSetHigh(strFastPin &v) { *v.set = v.mask; }
static __INLINE__ void fastpinSetLow(strFastPin &v) { *v.unset = v.mask; }
static __INLINE__ uint32_t fastpinRead(strFastPin &v) { return *v.read & v.mask; }

For the Due it has 2 areas where there are continuous pin so I define 2x8 bit access functions. I have these that work for the Due, Teensy 3.x, Mega and Uno.

Example (bit of a pain to setup but once done have standard low level pin access to different platforms)
Code: 
#define SHIELD_MSG  "** NO SHIELD - DIB 8/16 bit interface pins 33-40(0-7) 51-44(8-15)"

static __INLINE__ void fastDigitalWrite8_1(uint32_t val8)
{
	REG_PIOC_CODR = (0x000000FF << 1);  
	REG_PIOC_SODR = ((val8) << 1); // &(0x000000FF << 1);
}

static __INLINE__ void fastDigitalWrite8_2(uint32_t val8)
{
	REG_PIOC_CODR = (0x000000FF << 12);
	REG_PIOC_SODR = ((val8) << 12); // &(0x000000FF << 12);
}

static __INLINE__ void fastPinMode8_1_INPUT() { pinMode(33, INPUT); pinMode(34, INPUT); pinMode(35, INPUT); pinMode(36, INPUT); pinMode(37, INPUT); pinMode(38, INPUT); pinMode(39, INPUT); pinMode(40, INPUT); }
static __INLINE__ void fastPinMode8_2_INPUT() { pinMode(44, INPUT);pinMode(45, INPUT);pinMode(46, INPUT);pinMode(47, INPUT);pinMode(48, INPUT);pinMode(49, INPUT);pinMode(50, INPUT);pinMode(51, INPUT); }

static __INLINE__ void fastPinMode8_1_OUTPUT() { pinMode(33, OUTPUT); pinMode(34, OUTPUT); pinMode(35, OUTPUT); pinMode(36, OUTPUT); pinMode(37, OUTPUT); pinMode(38, OUTPUT); pinMode(39, OUTPUT); pinMode(40, OUTPUT); }
static __INLINE__ void fastPinMode8_2_OUTPUT() { pinMode(44, OUTPUT);pinMode(45, OUTPUT);pinMode(46, OUTPUT);pinMode(47, OUTPUT);pinMode(48, OUTPUT);pinMode(49, OUTPUT);pinMode(50, OUTPUT);pinMode(51, OUTPUT); }

static __INLINE__ uint32_t fastDigitalRead8_1(void) { return ((REG_PIOC_PDSR >> 1) & 0x000000FF); }
static __INLINE__ uint32_t fastDigitalRead8_2(void) { return ((REG_PIOC_PDSR >> 12) & 0x000000FF); }

#endif

static __INLINE__ void fastDigitalWriteLOW(uintX_t pin) { g_APinDescription[pin].pPort->PIO_CODR = g_APinDescription[pin].ulPin; }
static __INLINE__ void fastDigitalWriteHIGH(uintX_t pin) { g_APinDescription[pin].pPort->PIO_SODR = g_APinDescription[pin].ulPin; }
static __INLINE__ void setPinMode(uintX_t pin, uintX_t val) { pinMode(pin, val);	}

static __INLINE__ void fastDigitalWrite(uintX_t pin, boolean val)
{
  if (val) 
  {
    g_APinDescription[pin].pPort->PIO_SODR = g_APinDescription[pin].ulPin; // set
  }
  else
  {
    g_APinDescription[pin].pPort->PIO_CODR = g_APinDescription[pin].ulPin; // unset
  }
}


static __INLINE__ uintX_t fastDigitalRead(uintX_t pin)
{
  return (g_APinDescription[pin].pPort->PIO_PDSR & g_APinDescription[pin].ulPin) ? HIGH : LOW;
}

struct strFastPin
{
	uintX_t pin;
	uint32_t mask;
	WoReg *set;
	WoReg *unset;
	WoReg *read;
};

static __INLINE__ void fastpinSet(strFastPin &v, uint32_t value) { if (value) { *v.set = v.mask; } else { *v.unset = v.mask; } }
static __INLINE__ void fastpinSetHigh(strFastPin &v) { *v.set = v.mask; }
static __INLINE__ void fastpinSetLow(strFastPin &v) { *v.unset = v.mask; }
static __INLINE__ uint32_t fastpinRead(strFastPin &v) { return *v.read & v.mask; }
 
I extracted this from a sorted version of the K66/T3.6 pinout. Ports C and D are the best bets for 8 contiguous pins:
Code: 
Port pin   Teensy pin
 PTC0       15
 PTC1       22
 PTC2       23 
 PTC3        9 
 PTC4       10 
 PTC5       13 
 PTC6       11 
 PTC7       12 

 PTD0        2 
 PTD1       14 
 PTD2        7 
 PTD3        8 
 PTD4        6 
 PTD5       20 
 PTD6       21 
 PTD7        5

Pete
 
Ahhhh... great! Thanks for the quick reply. I had been making a shield for the Due but will use it as a learning experience and make the same for the Teensy 3.5/3.6. Will have to figure out how to deal with the pins that are on solder pads. I'd want the Teensy board to be pluggable into the breakout so I can have several breakouts for testing and not need several MCU's. I assume soldering smd pins on the pads is an option if I can figure out the spacing.

One thing the breakout did was route the 8 bit ports into headers where it's easier to hookup. LMAO ... the pins look almost random :p
 
hoek67 said:
Ahhhh... great! Thanks for the quick reply. I had been making a shield for the Due but will use it as a learning experience and make the same for the Teensy 3.5/3.6. Will have to figure out how to deal with the pins that are on solder pads. I'd want the Teensy board to be pluggable into the breakout so I can have several breakouts for testing and not need several MCU's. I assume soldering smd pins on the pads is an option if I can figure out the spacing.

One thing the breakout did was route the 8 bit ports into headers where it's easier to hookup. LMAO ... the pins look almost random :p
Click to expand...

One method that people use for breakout boards is to use a castellated design, such as this board for Teensy 3.1/2 from FrankB: https://oshpark.com/shared_projects/cYQjHdCu. His newer board is here (but the pictures don't show the castellation): https://pcbs.io/user/FrankB.

You might want to check out this thread from KurtE about a carrier board he is designing: https://forum.pjrc.com/threads/36244-Teensy-3-5-3-6-Breakout-board-to-test-things-with.

Here is a post from Jimmayhaug on a sturdier way to solder pins to the underneath pads: https://forum.pjrc.com/threads/26071-Using-all-Teensy3-x-pins-with-a-socket.

Note, in the 3.5/3.6 all of those pins are on the outside edges, so you might not need to solder to the pads underneath the Teensy.
 
A simple T3.6 query... is there any physical difference/advantage/disadvantage to drawing current (up to 250 mA) from the 3.3v pin located between pins 12 and 24 in comparison to doing this from the 3.3v pin between pin 23 and AnalogGND?

I'm wondering about track thickness/length/routing and potential local heating effects (especially near the 16 MHz crystal module) ??

Is one of these pins much closer to the regulator (and thereby a preferable power source) ?
 
All of them are connected by a power plane on layer 5. But that plane layer is split, where the portion underneath the regulator is GND, which is done to give the thermal vias 2 planes (all of layer 2 is the plane for ground) to help dissipate the heat.

plane.jpg
 
Status
Not open for further replies.
Back
Top