K66 Beta Test

KurtE · Sep 17, 2016

Thanks Nox771 and Defragster and Michael,

Not sure what we are all recommending here. My read here is a) Punt.

For me this is not much of an issue as I don't often use I2C, other than try to answer the issue coming up on the forum.

I was just hoping there was a reasonable answer for those who are using Wire for their stuff and then decide they would like to use the 2nd I2C interface to maybe add a sonar sensor, without having to go back and modify every library they use that includes Wire.

My thoughts on b) was, if you are now including i2c_t3.h because you wish to be able to use the other i2c buses, and not to change the actual functionality of your existing code, the existing code would use the Wire object that is part of the Wire library. If you are changing the functionality, you might also be adapting the library to be able to use any of the Wire objects, like I did while playing with the Sonar objects, where I pass in a reference to which object I wish to use. So in this case passing in Wire0 would not be much of an issue. But I do understand your point.

c) Again I totally understand. It is more of question of someone wishes to rename i2c_t3.h into Wire.h how compatible do these interfaces need to be. Believe me I understand the decoder card concept, as I did a lot of the work to add the new pins To Usarts and SPI...

As for size. I totally agree with you that on the T3.5/T3.6 who cares if we grow the library by a little bit. But is that true if you are currently running code on the TLC or T3.2?

Personally I like b) as I think it can give you better compatibility, for the reason I mentioned, but I totally understand the reasons for not doing so.

nox771 · Sep 17, 2016

The real problem is this part:

without having to go back and modify every library they use that includes Wire

To fix this problem in our current environment I would suggest using the linked workaround.

I think that workaround has the lightest touch I can think of (in terms of not messing with combining or rewriting code). Creating a superclass of various libraries, and choosing one to be active via defines and such could be done, but that is like a project unto itself (and some things are just plain different, such as the pin situation - although the more restrictive i2c_t3 method could call some lower-level arbitrary pin assignment method that ignores device checks). It would be somewhat difficult to test all the permutations of such a system.

PaulStoffregen · Sep 17, 2016

Indeed I can't do anything on this until October, when we've completed the Kickstarter. A few other thing are much more urgent, especially the SD lib. But in October, I'm planning to at least add Wire1, Wire2 and Wire3 to the normal Wire lib.

MichaelMeissner · Sep 17, 2016

nox771 said:
The real problem is this part:

To fix this problem in our current environment I would suggest using the linked workaround.

I think that workaround has the lightest touch I can think of (in terms of not messing with combining or rewriting code). Creating a superclass of various libraries, and choosing one to be active via defines and such could be done, but that is like a project unto itself (and some things are just plain different, such as the pin situation - although the more restrictive i2c_t3 method could call some lower-level arbitrary pin assignment method that ignores device checks). It would be somewhat difficult to test all the permutations of such a system.

Now, I'm not a C++ expert, but I'm wondering out loud whether using C++ namespaces in i2c_t3 would allow the two i2c implementations to be linked together. Now, you likely might have some issues if both try to use the same i2c bus. But in theory, it may allow them to co-exist. Of course that might be worse than getting a linker error, if it only works if you are real careful.

xxxajk · Sep 17, 2016

DaQue said:
Anyone know if there is a reason not to manuallly castellate the 48 pin dip lay out holes to surface mount the board? Anything routed out there to get out of a tight spot on any on the layers?

I've never had to do such a thing.
If you add enough paste and then reflow you will get a good connection.
If you are intending doing this by hand with an iron, I don't recommend doing so. Reflow it instead for best results.

PaulStoffregen · Sep 17, 2016

If you try to castellate the edges by shaving away material, be aware of the 3.3V and ground planes on layers 2 and 5. At the very least, before you solder anything, use an ohm meter on its highest range (lowest test current) to check 3.3V and ground aren't shorted to each other or any of the pins.

xxxajk · Sep 17, 2016

PaulStoffregen said:
If you try to castellate the edges by shaving away material, be aware of the 3.3V and ground planes on layers 2 and 5. At the very least, before you solder anything, use an ohm meter on its highest range (lowest test current) to check 3.3V and ground aren't shorted to each other or any of the pins.

A good mill with a sharp blade shouldn't cause a problem.
That said--
Paul: Your other boards do seem to be reflow friendly -- in my own built oven -- complete with fume exhaust and cooling!!
I've never had an issue as long as a proper reflow profile is used.
The new one I assume is using BGA, and should be just fine too, just like esp boards, which I reflow as well

DaQue · Sep 18, 2016

xxxajk said:
A good mill with a sharp blade shouldn't cause a problem.
That said--
Paul: Your other boards do seem to be reflow friendly -- in my own built oven -- complete with fume exhaust and cooling!!
I've never had an issue as long as a proper reflow profile is used.
The new one I assume is using BGA, and should be just fine too, just like esp boards, which I reflow as well

Thanks, I forgot about the power plains probably spilling out there. I won' be doing it anytime soon. I only kickstarted one.

defragster · Sep 18, 2016

Good to watch for the wiped metal bits for sure. For example even the OSH castellated pin holes often have metal that folds away faster than it is cut. Taking sand paper or a file it seems would remove any flared edge bits of the metal layers that 'connected'.

I put a breakout board on a T_3.1 with top headers to simulate the top header K66_PROTO board so I could swap anything I built to test. I solder pasted the pin holes to they would connect as soldered as the top female header wouldn't allow easily soldering before or at all after and it worked - but didn't have to. Castellating the pins would allow that for general use - but in such a case maybe that should be done on the add on PCB when ordered?

defragster · Sep 22, 2016

Just saw these are posted:: Status: pre-order. Expected ship date is October 6.

TEENSY36 Teensy 3.6 USB Development Board [ Info ] 29.25

TEENSY35 Teensy 3.5 USB Development Board [ Info ] 24.25

Placing my T_3.5 order before they are all gone

- and so my T_3.5 beta unit doesn't feel so outnumbered when the T_3.6 KS Six pack shows up.

neutron7 · Sep 22, 2016

Just in case anyone is interested,
I ran a benchmark i found with teensy 3.2 and 3.6 both at 120mhz, to get a sort of "apples to apples" comparison.

Code:

F_CPU = 120000000 Hz		teensy 3.2		teensy 3.6  "= same
1/F_CPU = 0.0083 us
  nop                       : 0.008 us			"
  digitalRead               : 0.124 us			: 0.126 us
  digitalReadFast           : 0.011 us			: 0.009 us
  digitalWrite              : 0.289 us			: 0.276 us
  digitalWriteFast          : 0.009 us			"
  pinMode                   : 0.334 us			: 0.276 us
  multiply byte             : 0.099 us			: 0.058 us
  divide byte               : 0.099 us			: 0.071 us
  add byte                  : 0.086 us			: 0.058 us
  multiply integer          : 0.049 us			: 0.050 us
  divide integer            : 0.059 us			"
  add integer               : 0.050 us			"
  multiply long             : 0.051 us			: 0.049 us
  divide long               : 0.049 us			"
  add long                  : 0.050 us			"
  multiply float            : 0.376 us			: 0.066 us
  divide float              : 3.824 us			: 0.174 us
  add float                 : 0.604 us			: 0.069 us
  itoa()                    : 0.444 us			: 0.414 us
  ltoa()                    : 1.799 us			"
  dtostrf()                 : 47.474 us			: 23.424 us
  random()                  : 0.624 us			: 0.599 us
  y |= (1<<x)               : 0.041 us			"
  bitSet()                  : 0.041 us			"
  analogReference()         : 0.184 us			"
  analogRead()              : 8.449 us			: 6.799 us
  analogWrite() PWM         : 1.094 us			: 0.769 us
  delay(1)                  : 1001.499 us		: 1000.499 us
  delay(100)                : 100000.000 us		"
  delayMicroseconds(2)      : 2.004 us			: 2.002 us
  delayMicroseconds(5)      : 5.011 us			: 5.006 us
  delayMicroseconds(100)    : 100.199 us		: 100.099 us

does "random" use the hardware RNG in the teensy 3.6? im guessing its probably a different (or not yet existing) function

manitou · Sep 22, 2016

neutron7 said:
does "random" use the hardware RNG in the teensy 3.6? im guessing its probably a different (or not yet existing) function

Nope, random() is just default Arduino PRNG (linear congruential). K64/K66 hardware RNG generates 32 random bits every 256 F_BUS cycles. So F-BUS @60MHz, would give you a random word in 4.267 us or 7.5 megabits/sec, though for cyrpto strength, ref manual suggests taking only 1 bit out of each 32-bits generated.

Donziboy2 · Sep 28, 2016

neutron7 said:

Just in case anyone is interested,
I ran a benchmark i found with teensy 3.2 and 3.6 both at 120mhz, to get a sort of "apples to apples" comparison.

Code:

F_CPU = 120000000 Hz		teensy 3.2		teensy 3.6  "= same
1/F_CPU = 0.0083 us
  nop                       : 0.008 us			"
  digitalRead               : 0.124 us			: 0.126 us
  digitalReadFast           : 0.011 us			: 0.009 us
  digitalWrite              : 0.289 us			: 0.276 us
  digitalWriteFast          : 0.009 us			"
  pinMode                   : 0.334 us			: 0.276 us
  multiply byte             : 0.099 us			: 0.058 us
  divide byte               : 0.099 us			: 0.071 us
  add byte                  : 0.086 us			: 0.058 us
  multiply integer          : 0.049 us			: 0.050 us
  divide integer            : 0.059 us			"
  add integer               : 0.050 us			"
  multiply long             : 0.051 us			: 0.049 us
  divide long               : 0.049 us			"
  add long                  : 0.050 us			"
  multiply float            : 0.376 us			: 0.066 us
  divide float              : 3.824 us			: 0.174 us
  add float                 : 0.604 us			: 0.069 us
  itoa()                    : 0.444 us			: 0.414 us
  ltoa()                    : 1.799 us			"
  dtostrf()                 : 47.474 us			: 23.424 us
  random()                  : 0.624 us			: 0.599 us
  y |= (1<<x)               : 0.041 us			"
  bitSet()                  : 0.041 us			"
  analogReference()         : 0.184 us			"
  analogRead()              : 8.449 us			: 6.799 us
  analogWrite() PWM         : 1.094 us			: 0.769 us
  delay(1)                  : 1001.499 us		: 1000.499 us
  delay(100)                : 100000.000 us		"
  delayMicroseconds(2)      : 2.004 us			: 2.002 us
  delayMicroseconds(5)      : 5.011 us			: 5.006 us
  delayMicroseconds(100)    : 100.199 us		: 100.099 us

does "random" use the hardware RNG in the teensy 3.6? im guessing its probably a different (or not yet existing) function

Very nice!
Could you add Double to your list?

edit, also Long Long

MichaelMeissner · Sep 28, 2016

Donziboy2 said:
Very nice!
Could you add Double to your list?

Note, double will have to be emulated in software like it is in the 3.2. That means, running at the same clock speed it will run at similar speed. On the Teensy 3.5/3.6, single precision float is done in hardware, and you see a great speedup.

neutron7 · Sep 28, 2016

wouldn't the single precision float be able to speed up emulation of double?

MichaelMeissner · Sep 28, 2016

neutron7 said:
wouldn't the single precision float be able to speed up emulation of double?

No. The emulation is done all via integer arithmetic. It may be possible to write such an emulation, but the soft-float emulation that is the default uses structures with integers to pick apart the sign, mantissa, and exponent, and then it uses integers in a structure to do the actual calculation.

defragster · Sep 28, 2016

There is a new thread : Quick-Links-to-Teensy-3.5/3.6-Git-Libraries that seems like a fresh point to pick up from this long Beta thread and the post #8 that went with it.

Looks my pack of KS T_3.6's should arrive 9/29! And I just got shipping confirmation that my Pre-Order T_3.5's are in the mail too!

It seems PJRC was up to the challenge with time to spare before taking a break!

defragster said:
Just saw these are posted:: Status: pre-order. Expected ship date is October 6.

Placing my T_3.5 order before they are all gone - and so my T_3.5 beta unit doesn't feel so outnumbered when the T_3.6 KS Six pack shows up.

Code:

Speed test	                :: T_3.1	  :: T_3.5	:: T_3.5	:: T_3.6	:: T_3.6
----------	                ----------	  ----------	----------	----------	----------
F_CPU =	                  	 96000000 Hz	120000000 Hz	168000000 Hz	180000000 Hz	240000000 Hz
1/F_CPU = 	                  0.0104 us	0.0083 us	0.0060 us	0.0056 us	0.0042 us
The next tests are runtime c					
  nop                       	 0.010 us	 0.008 us	0.006 us	 0.006 us	 0.004 us
  avr gcc I/O               	 0.103 us	 0.084 us	0.072 us	 0.066 us	 0.049 us
  Arduino digitalRead       	 0.158 us	 0.126 us	0.089 us	 0.084 us	 0.062 us
  [U]Teensy digitalReadFast	                 0.009 us	0.007 us	0.004 us	0.004 us[/U]
  Arduino digitalWrite      	 0.363 us	 0.284 us	0.214 us	 0.192 us	 0.152 us
  Teensy digitalWriteFast	                 0.009 us	0.007 us	0.004 us	0.004 us
  [U]pinMode                   	 0.378 us	 0.286 us	0.219 us	 0.192 us	 0.157 us[/U]
  multiply volatile byte    	 0.098 us	 0.064 us	0.048 us	 0.039 us	 0.029 us
  divide volatile byte      	 0.093 us	 0.074 us	0.049 us	 0.044 us	 0.039 us
  [U]multiply volatile integer 	 0.062 us	 0.050 us	0.036 us	 0.033 us	 0.024 us[/U]
  divide volatile integer   	 0.068 us	 0.059 us	0.044 us	 0.039 us	 0.029 us
  multiply volatile long    	 0.061 us	 0.049 us	0.034 us	 0.034 us	 0.027 us
  [U]multiply single float     	 0.451 us	 0.071 us	0.052 us	 0.044 us	 0.032 us[/U]
  multiply double float     	 0.698 us	 0.511 us	0.402 us	 0.329 us	 0.247 us
  divide double float       	 11.823 us	 9.124 us	6.749 us	 5.499 us	 4.124 us
  [U]itoa()                    	 0.553 us	 0.429 us	0.309 us	 0.274 us	 0.209 us[/U]
  ltoa()                    	 2.198 us	 1.699 us	1.299 us	 1.199 us	 0.799 us
  dtostrf()                 	 49.473 us	 38.324 us	31.074 us	 15.249 us	 11.449 us
  [U]random()                  	 0.398 us	 0.299 us	0.224 us	 0.199 us	 0.149 us[/U]
  y |= (1<<x) with volatile 	 0.052 us	 0.041 us	0.029 us	 0.028 us	 0.021 us
  bitSet() with volatile    	 0.052 us	 0.041 us	0.030 us	 0.027 us	 0.021 us
  [U]analogReference()         	 1.862 us	 1.614 us	1.324 us	 0.933 us	 0.802 us[/U]
  analogRead()              	 10.148 us	 7.949 us	7.699 us	 6.649 us	 6.549 us
  analogWrite() PWM         	 2.098 us	 1.924 us	1.649 us	 0.809 us	 0.624 us
  [U]delay(1)                  	 1000.998 us	 1001.499 us	1000.499 us	 999.999 us	 999.999 us[/U]
  delay(100)                	 99999.998 us	 99999.999 us	99999.999 us	 99999.999 us	 99999.999 u
  delayMicroseconds(1)      	 1.002 us	 1.002 us	1.002 us	 1.001 us	 1.001 us
  [U]delayMicroseconds(5)      	 5.011 us	 5.008 us	5.007 us	 5.003 us	 5.002 us[/U]
  delayMicroseconds(100)    	 100.198 us	 100.149 us	100.149 us	 100.099 us	 100.049 us

Source Post: Teensy-3-1-overclock-to-168MHz?

Missing the digital FAST calls where I found it - just replicated and renamed . . .

johnnyfp · Sep 28, 2016

Where can I find the source to this benchmark program? Want to run several iterations of it while monitoring power and temperature of each type of Teensy.

KurtE · Sep 28, 2016

defragster said:
Looks my pack of KS T_3.6's should arrive 9/29! And I just got shipping confirmation that my Pre-Order T_3.5's are in the mail too!

It seems PJRC was up to the challenge with time to spare before taking a break!

Looks like mine will arrive tomorrow as well

As you mentioned they have been busy!

Paul: It would be great if you could put some form of fix (Hack) to fix the issue where the USB serial # does not work on T3.6 when running at CPU speed > 120mhz. This causes semi random Serial port numbers, especially if you you plug in multiple units. I have one PR to fix it, but there is a simpler version that a few others did like Defragster, which are in the comments of the PR.

Again great job!

defragster · Sep 28, 2016

johnnyfp said:
Where can I find the source to this benchmark program? Want to run several iterations of it while monitoring power and temperature of each type of Teensy.

... Added link above ...

KurtE said:
Looks like mine will arrive tomorrow as well

As you mentioned they have been busy!

Paul: It would be great if you could put some form of fix (Hack) to fix the issue where the USB serial # does not work on T3.6 when running at CPU speed > 120mhz. This causes semi random Serial port numbers, especially if you you plug in multiple units. I have one PR to fix it, but there is a simpler version that a few others did like Defragster, which are in the comments of the PR.

Again great job!

KurtE - my T_3.6 serial number reports fine after the Bootloader update? I suppose you did this?

PaulStoffregen said:
I'm working on bootloader fixes and improvements.

I have code that detects and recovers from the locked condition of WMXZ's board. My hope is to test it on Wozzy's board later today, before releasing the update.

The 512K flash bug is fixed, the serial number is now reported properly, and a minor bug where bootloader mode is improperly ended (doesn't always reboot to your program) if the program button is tapped while the bootloader runs is also fixed.

One new feature will be added. If you hold the program button for 15 seconds (actually, between 13 to 17 seconds) the chip is fully erased, including eeprom data.

If testing goes well with Wozzy's board, I hope to have an update to you later today.

Except on PROTO unit that left (

sadly

)PJRC with no serial # - but the bootloader update and the 15 second CLEAR really helped my PROTO unit that was acting ODD.

defragster · Sep 28, 2016

On Ebay I found this 'universal Stripboard Prototypin' [5 piece $11 and free ship ] that looks like a good way to prototype with a Teensy?

It is plated one side - so the Teensy is shown in place on the wrong side - under the Teensy is a repeat of the pattern on the sides:

KurtE · Sep 28, 2016

Thanks Defragster, I did the update.

Will check again. if the Serial # is showing up properly, without the hack.

I am still seeing that for example: TyQT does not get the serial number without the hack shows up as 0.

Double checked that Verbose Info of loader is showing: 13:56:01: Board is: Teensy 3.6 (MK66FX1M0), version 1.03

PaulStoffregen · Sep 28, 2016

KurtE said:
Paul: It would be great if you could put some form of fix (Hack) to fix the issue where the USB serial # does not work on T3.6 when running at CPU speed > 120mhz.

It's near the top of my todo list. So is basic SDIO support in the SD library.

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

KurtE · Sep 28, 2016

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

Hope you have a great Relaxing few days off and have some fun! Although to me, traveling all the way across the country does not sound overly relaxing!

MichaelMeissner · Sep 28, 2016

defragster said:
On Ebay I found this 'universal Stripboard Prototypin' [5 piece $11 and free ship ] that looks like a good way to prototype with a Teensy?

Everybody has their own criteria on what makes a good prototype board. The above board is nicely laid for the Teensy with standard breadboard pins, and the pads on the one side look a lot better than some of the cheaper perf-boards. However, I've found that I prefer double sided boards, so that I can solder on either side. Also, if possible, I tend to prefer ordering from a USA shipper, so that it has a better chance of getting here in a reasonable time.

Because the board is populated with just 2 rows, it means you could attach Vusb, AREF, A10, and A11, which are usually hard on most boards that have more rows.

I haven't started doing much with my beta 3.6.

One that I just picked up, that it looks like it would be nice with the Teensy 3.6 (other than the inner pins) is this perfboard that fits in the Altoids mint tin: https://www.tindie.com/products/DrAzzy/mint-tin-size-prototyping-board/. Fortunately, it has 24 rows, which is perfect for the 3.6. It has power bridge down the center along with a ground bridge. One long edge would have 4 rows of attached pins plus a ground bridge that you can connect to directly. The other long edge has 2 and 3 rows for attaching some DIP-8 chips.

I've used this board on a Teensy 3.2 that I had the Adafruit Audio FX board mounted on it (before I moved to the prop shield and/or audio shield for sound): https://www.tindie.com/products/DrAzzy/2-x-4-prototypingproject-boards/

Of course there is the Adafruit perma-proto half sized breadboard PCB: https://www.adafruit.com/products/723, but with the Teensy 3.6 it is starting to get a little cramped, and it might make sense to go to the full-size perma proto board.

Now for the 3.2/LC, I sometimes prefer either the Adafruit small mint tin perma proto: https://www.adafruit.com/products/1214 or this board which is even narrower (but does not have the ground/power rails): https://www.tindie.com/products/DrAzzy/1x2-prototyping-board/

K66 Beta Test

Senior Member+

Well-known member

Well-known member

Senior Member+

Well-known member

Well-known member

Well-known member

Well-known member

Senior Member+

Senior Member+

Well-known member

Senior Member+

Well-known member

Senior Member+

Well-known member

Senior Member+

Senior Member+

Well-known member

Senior Member+

Senior Member+

Senior Member+

Senior Member+

Well-known member

Senior Member+

Senior Member+