K66 Beta Test

[PaulStoffregen]

Paul,
Is this just for Teensys currently in the field?
Will future T3.5s and T3.6s ship with these bootloader updates already in place?

Yes. All production boards will ship with this 1.03 bootloader.

Exactly 96 preproduction boards and 28 early betas (large PQFP chip hand soldered by Erin) were made with the 1.02 bootloader. 11 of them are on my desk. This update only applies to the 78 sent to beta testers and 35 sent as early rewards for top-tier Kickstarter backers.

 

[manitou]

Ethernet update:
lwIP TCP is a little more complicated than my early single-direction tests revealed. I adapted a lwIP raw API TCP echo example to the K66/K64, it is tcpecho_raw.ino in the src/ directory in the github distribution. I also have a little web server (websrv.ino) that turns the LED on or off. The web page looks like:
--------

--------
A possible extension would be to provide web pages from the microSD.

There is also a bug (me thinks) in the lwIP 1.4.0 core that causes TCP server to hang if not connected to in 20 seconds. I ifdef'd out the SYNACK_RCVD timeout in lwip/core/tcp.c to bypass this irritant.

details and links to github stuff at #686

 

[maxbot]

I will integrate the Teensy 3.6 into the DIY-Thermocam, a standalone thermal imager based on the FLIR Lepton3:



The device really needs more processing power, than the previously used Teensy 3.2 was capable to deliver.
And the larger RAM will finally allow it to render full-screen (320x240) thermal images, so looking forward to it!

 

[defragster]

@Defragster - I can't understand what you're saying.

... I couldn't understand what my PROTO board was doing either. And for some reason my PC 'atypically' did a hard hang while I was looking at it about to see if the T_3.6_KS_beta3 acted the same.

With the PC hang I lost my post and included code and details and the time to get a anywhere for a bit. The critical question was::

Post 1391: Is there 'expected' to be any chance of something odd with the PROTO unit?
After 1.03 bootloader upgrade my PROTO unit boots very SLOWLY


TODAY :: Powered the other desktop without TYQT . . . so to answer my own question 'No' ... The K66_PROTO board seems to be working fine uploading the same sketch.

 

[defragster]

OK, I updated my K66 beta3 board with 32-bit teensy. all is well.
I'll wait another day or so before updating my other K66 (proto) and K64 ... to see if any Murphy's Law effects are revealed.

@Manitou (others) - not to worry. The K66_PROTO I have is now running fine on another machine after the bootloader upgrade.
That simple blink serial sketch is online printing USB in good shape near 1.5 seconds and I just pushed the FASTLED test back to it and the lights are on in about 1 second as it is not waiting for USB.

I exhausted/confused my computer or something apparently with the many EEPROM uploads and too many (12+) IDE sketches open.

<edit> See post 1414 for update on Long Press wipe making my Proto board work better.

 

[Wozzy]

I'm working on bootloader fixes and improvements.

I have code that detects and recovers from the locked condition of WMXZ's board.
...
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.

Paul,

Curiosity is killing me...

1. Did my T3.6 have the same problem as WMZX's board, was it dead, or was it a different problem all together?
2. Would the 15 second program button press have allowed it to recover (if it had bootloader V1.03)?
3. Were you able to recover mine, considering it had the older V1.02 bootloader?

 

[Wozzy]

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.

Paul,

What are the implications of pressing the program button for 15 seconds?
Does it recover to be just like a factory fresh Teensy 3.5 or 3.6 without the blink program installed?

Under what conditions would one use this feature?

Are there any risks involved?

 

[firehopper]

I will integrate the Teensy 3.6 into the DIY-Thermocam, a standalone thermal imager based on the FLIR Lepton3:

View attachment 8180

The device really needs much more processing power. than the Teensy 3.2 has offered so far.
And the larger RAM will finally allow it to render full-screen (320x240) thermal images, so looking forward to it!

I know I would be interested in one of these, I have a teensy 3.6 from the kickstarter, just need to wait for it

 

[defragster]

<UPDATE HERE> I got a working long press to WIPE both T_3.6's and my PROTO board is no longer acting like noted in this post below. This sketch now runs right from TYQT and it also programs at 120 MHz.


As I noted post 1392 - neither of my T_3.6's do anything other than program mode with a button push of 15-30 seconds. On repowering they return to the prior sketch. Just tested the same to no effect on the T_3.5.

My PROTO K66 with fastled sketch has the lights running in about under a second. However on both machines the PROTO USB Serial is not online for a long time on both my Windows desktops - if programmed by TYQT.

The two devices are now working the same using TYQT only the PROTO exhibits this slow USB start behavior. Using Teensy.exe to push the SAME HEX for the sketch below the PROTO USB is online fast.

Seems to be a TYQT issue that won't be resolved as Koromix has no PROTO_K66, and it is not a production unit - it is odd that the bootloader update causes this difference - possibly TYQT relying on Serial# that the PROTO does not have and now reported differently for HSRUN T_3.6's. TYQT wholly fails to program PROTO at 120 MHz, but beta3 is fine. Time to put the PROTO on 'display' and wait for my KS rewards.

Here are numbers from this sketch The T_3.6_Beta3 is always fast, the PROTO results show what I see - for completeness I saw the T_3.5_beta work fine as shown using TYQT:

For the T_3.6_beta3:

BOOT_on_Time=400
Serial_on_Time=1126
millis() =1126

For the PROTO with TYQT:

BOOT_on_Time=400
Serial_on_Time=6308
millis() =6309

For the PROTO with Teensy.exe:

BOOT_on_Time=400
Serial_on_Time=1293
millis() =1294

For the T_3.5_beta:

BOOT_on_Time=400
Serial_on_Time=1137
millis() =1138

uint32_t BOOT_on_Time;
uint32_t Serial_on_Time = 10000;
int DisplayLimit = 2;
void setup() {
  BOOT_on_Time = millis();
  Serial.begin(57600);
}

void loop() {
  while ( !Serial ) {
    Serial_on_Time = millis();
  }
  if ( 0 != DisplayLimit ) {
    DisplayLimit-=1;
    Serial.print("BOOT_on_Time=");     Serial.println(BOOT_on_Time);
    Serial.print("Serial_on_Time=");     Serial.println(Serial_on_Time);
    Serial.print(" millis() =");    Serial.println(millis());
  }
}

 

[PaulStoffregen]

Did my T3.6 have the same problem as WMZX's board, was it dead, or was it a different problem all together?

Yes, same issue.

Would the 15 second program button press have allowed it to recover (if it had bootloader V1.03)?

1.03 automatically detects this condition and automatically recovers, so with 1.03 you would never have been in this unusable state where you'd try holding the button for 15 seconds. I tested the automatic detection and recovery on your board, by flashing the MLK02 chip without disturbing the K66 chip. Version 1.03 did indeed restore your board automatically.

But if for some reason the problem happened in a way where the automatic detection didn't work, yes, the 15 second button press would initiate the mass erase which recovers.

Were you able to recover mine, considering it had the older V1.02 bootloader?

Yes. Sorry, I meant to email you, but so many things are moving fast here to get ready to ship the Kickstarter rewards. I'm constantly falling far behind on messages....

Your board is fully restored and updated to 1.03. I shipped it back last night, with a drop off at the late night post office in Portland (it'll be postmarked Sept 14), so you should get it Friday or Saturday. Email Robin if you'd like the tracking number.

 

[Frank B]

Bootloader-update worked flawlessly:

20:56:32: Teensy Loader 1.31-boot-update, begin program
20:56:32: Listening for remote control on port 3149
20:56:32: initialized, showing main window
20:56:32: HID/win32:  vid:046A pid:0023 ver:0220
20:56:32: HID/win32:  vid:046A pid:0023 ver:0220
20:57:12: Verbose Info event
20:57:16: Verbose Info event
20:57:55: remote connection opened
20:57:55: remote cmd: "comment: Teensyduino 1.30-beta3 - WINDOWS"
20:57:55: remote cmd: "dir:f:\builddebb6a7a8b869e61df2be40f82065a39.tmp\"
20:57:55: remote cmd: "file:Blink.pde.hex"
20:57:55: File "Blink.pde.hex". 20636 bytes, 2% used
20:57:55: remote cmd: "status"
20:57:55: status data sent
20:57:55: remote cmd: "auto:on"
20:57:55: remote connection closed
20:57:56: remote connection opened
20:57:56: remote cmd: "comment: Teensyduino 1.30-beta3 - WINDOWS"
20:57:56: remote cmd: "dir:f:\builddebb6a7a8b869e61df2be40f82065a39.tmp\"
20:57:56: remote cmd: "file:Blink.pde.hex"
20:57:56: File "Blink.pde.hex". 20636 bytes, 2% used
20:57:56: remote cmd: "status"
20:57:56: status data sent
20:57:56: remote connection closed
20:57:56: remote connection opened
20:57:56: remote cmd: "status"
20:57:56: status data sent
20:57:56: remote cmd: "status"
20:57:56: status data sent
20:57:56: remote cmd: "status"
20:57:56: status data sent
20:57:56: remote cmd: "status"
20:57:56: status data sent
20:57:56: remote cmd: "status"
20:57:56: status data sent
20:57:56: remote cmd: "status"
20:57:56: status data sent
20:57:56: Device came online, code_size = 1048576
20:57:56: Board is: Teensy 3.6 (MK66FX1M0), version 1.02
20:57:56: File "Blink.pde.hex". 20636 bytes, 2% used
20:57:56: set background IMG_ONLINE
20:57:56: File "Blink.pde.hex". 20636 bytes, 2% used
20:57:56: elf size appears to be 1048576
20:57:56: elf binary data matches hex file
20:57:56: Code size from .elf file = 1048576
20:57:56: begin operation
20:57:56: Bootloader upgrade: 1.02 -> 1.03
20:57:56: flash, block=0, bs=1024
20:57:56: flash, block=1, bs=1024
20:57:56: flash, block=7, bs=1024
20:57:56: flash, block=8, bs=1024
20:57:56: HID/win32: waiting for device
20:57:56: HID/win32: waiting for device
20:57:56: HID/win32: waiting for device
20:57:56: HID/win32: waiting for device
20:57:56: HID/win32: waiting for device
20:57:56: HID/win32: waiting for device
20:57:56: HID/win32: waiting for device
20:57:56: remote cmd: "status"
20:57:56: status data sent
20:57:56: remote connection closed
20:57:56: flash, block=9, bs=1024
20:57:56: flash, block=10, bs=1024
20:57:56: flash, block=11, bs=1024
20:57:56: flash, block=12, bs=1024
20:57:56: flash, block=13, bs=1024
20:57:56: HID/win32: waiting for device
20:57:56: flash, block=14, bs=1024
20:57:56: flash, block=15, bs=1024
20:57:56: flash, block=16, bs=1024
20:57:56: flash, block=17, bs=1024
20:57:56: HID/win32: waiting for device
20:57:56: flash, block=18, bs=1024
20:57:56: flash, block=19, bs=1024
20:57:56: flash, block=20, bs=1024
20:57:56: flash, block=21, bs=1024
20:57:56: HID/win32: waiting for device
20:57:56: flash, block=22, bs=1024
20:57:56: flash, block=23, bs=1024
20:57:56: flash, block=24, bs=1024
20:57:56: flash, block=25, bs=1024
20:57:56: HID/win32: waiting for device
20:57:56: flash, block=26, bs=1024
20:57:56: flash, block=27, bs=1024
20:57:56: HID/win32: waiting for device
20:57:56: flash, block=28, bs=1024
20:57:56: flash, block=29, bs=1024
20:57:56: flash, block=30, bs=1024
20:57:56: HID/win32: waiting for device
20:57:56: flash, block=31, bs=1024
20:57:56: flash, block=32, bs=1024
20:57:56: HID/win32: waiting for device
20:57:56: flash, block=33, bs=1024
20:57:56: flash, block=34, bs=1024
20:57:56: flash, block=35, bs=1024
20:57:56: flash, block=36, bs=1024
20:57:57: HID/win32: waiting for device
20:57:57: flash, block=37, bs=1024
20:57:57: begin wait_until_offline
20:57:57: offline, waited 3
20:57:57: Bootloader update: 0% of estimated 8 seconds
20:57:57: HID/win32:  vid:046A pid:0023 ver:0220
20:57:57: HID/win32:  vid:046A pid:0023 ver:0220
20:57:57: Bootloader update: 1% of estimated 8 seconds
20:57:57: Bootloader update: 3% of estimated 8 seconds
20:57:57: Bootloader update: 4% of estimated 8 seconds
20:57:57: Bootloader update: 5% of estimated 8 seconds
20:57:57: Bootloader update: 6% of estimated 8 seconds
20:57:57: Bootloader update: 8% of estimated 8 seconds
20:57:57: Bootloader update: 9% of estimated 8 seconds
20:57:58: Bootloader update: 10% of estimated 8 seconds
20:57:58: Bootloader update: 11% of estimated 8 seconds
20:57:58: Bootloader update: 13% of estimated 8 seconds
20:57:58: Bootloader update: 14% of estimated 8 seconds
20:57:58: Bootloader update: 15% of estimated 8 seconds
20:57:58: Bootloader update: 16% of estimated 8 seconds
20:57:58: Bootloader update: 18% of estimated 8 seconds
20:57:58: Bootloader update: 19% of estimated 8 seconds
20:57:58: Bootloader update: 20% of estimated 8 seconds
20:57:59: Bootloader update: 21% of estimated 8 seconds
20:57:59: Bootloader update: 23% of estimated 8 seconds
20:57:59: Bootloader update: 24% of estimated 8 seconds
20:57:59: Bootloader update: 25% of estimated 8 seconds
20:57:59: Bootloader update: 26% of estimated 8 seconds
20:57:59: Bootloader update: 28% of estimated 8 seconds
20:57:59: Bootloader update: 29% of estimated 8 seconds
20:57:59: Bootloader update: 30% of estimated 8 seconds
20:57:59: Bootloader update: 31% of estimated 8 seconds
20:58:00: Bootloader update: 33% of estimated 8 seconds
20:58:00: Bootloader update finished, 2.6 seconds
20:58:00: Board is: Teensy 3.6 (MK66FX1M0), version 1.03
20:58:00: flash, block=0, bs=1024, auto=1
20:58:00: flash, block=1, bs=1024, auto=1
20:58:00: flash, block=2, bs=1024, auto=1
20:58:00: flash, block=3, bs=1024, auto=1
20:58:00: HID/win32: waiting for device
20:58:00: HID/win32: waiting for device
20:58:00: HID/win32: waiting for device
20:58:00: HID/win32: waiting for device
20:58:00: HID/win32: waiting for device
20:58:00: HID/win32: waiting for device
20:58:00: HID/win32: waiting for device
20:58:00: HID/win32: waiting for device
20:58:00: HID/win32: waiting for device
20:58:00: HID/win32: waiting for device
20:58:00: HID/win32: waiting for device
20:58:00: HID/win32: waiting for device
20:58:00: flash, block=4, bs=1024, auto=1
20:58:00: flash, block=5, bs=1024, auto=1
20:58:00: flash, block=6, bs=1024, auto=1
20:58:00: HID/win32: waiting for device
20:58:00: flash, block=7, bs=1024, auto=1
20:58:00: flash, block=8, bs=1024, auto=1
20:58:00: HID/win32: waiting for device
20:58:00: flash, block=9, bs=1024, auto=1
20:58:00: flash, block=10, bs=1024, auto=1
20:58:00: flash, block=11, bs=1024, auto=1
20:58:00: HID/win32: waiting for device
20:58:00: flash, block=12, bs=1024, auto=1
20:58:00: flash, block=13, bs=1024, auto=1
20:58:00: flash, block=14, bs=1024, auto=1
20:58:00: HID/win32: waiting for device
20:58:00: flash, block=15, bs=1024, auto=1
20:58:00: flash, block=16, bs=1024, auto=1
20:58:00: flash, block=17, bs=1024, auto=1
20:58:00: HID/win32: waiting for device
20:58:00: flash, block=18, bs=1024, auto=1
20:58:00: flash, block=19, bs=1024, auto=1
20:58:00: HID/win32: waiting for device
20:58:00: flash, block=20, bs=1024, auto=1
20:58:00: sending reboot
20:58:00: begin wait_until_offline
20:58:00: offline, waited 2
20:58:00: end operation
20:58:00: set background IMG_REBOOT_OK
20:58:00: redraw timer set, image 14 to show for 1200 ms
20:58:00: HID/win32:  vid:046A pid:0023 ver:0220
20:58:00: HID/win32:  vid:046A pid:0023 ver:0220
20:58:01: redraw, image 9

 

[tcottle]

Updated Kickstarter beta board w/o issues. Running Win10 64bit Arduino 1.6.11

 

[johnnyfp]

Mine got to 36% I win!

08:54:48: Bootloader update: 36% of estimated 8 seconds
08:54:48: Bootloader update finished, 2.9 seconds

 

[defragster]

Ok, here is the update:
Linux 32 http://www.pjrc.com/teensy/beta/k66_boot_update/linux32/teensy

Linux 64 http://www.pjrc.com/teensy/beta/k66_boot_update/linux64/teensy

Mac http://www.pjrc.com/teensy/beta/k66_boot_update/mac/teensy.zip

Windows http://www.pjrc.com/teensy/beta/k66_boot_update/windows/teensy.exe

To use this, first quit Teensy Loader if you have it running. Then run this new copy of Teensy Loader. Use Help > About (or Teensy > About on Mac) to check the version. It should say "1.31-boot-update". If you see 1.30 or older, quit Teensy Loader and try again. Only one instance can run, so if you have an older copy running, this new one can't start.

Then use Arduino to upload any sketch. The update takes only a couple seconds.

To check if it worked, open the Help > Verbose Info window. Turn off Auto mode and press the button on your Teensy. You should see it detected as "Board is: Teensy 3.6 (MK66FX1M0), version 1.03" in the verbose info. All the beta and preproduction boards shipped with version 1.02.

Just clicked the EXE again and it works to start for Windows download. I linked to that post in post #8. If you plan to update the update - or have more notes that post is in the sticky link post now:
For those with BETA and EARLY KICKSTARTER units please see this post for into about bootloader update on your device :: LINK to POST


Paul - UPDATES:: -- Long press worked and it fixed my PROTO K66 USB start issue!

T_3.6:: LONG PRESS RESET:: I got it to work, closed TYQT/TEENSY.exe, plugged with button press, released and re-pressed and held (windows device arrival sound NOT HEARD). Teensy went BLANK! Used Teensy to upload sketch and it is up and running.

PROTO:: Still no long press reset when attached to PC ( following the previous steps Windows picked it up - it seems when PC talks to it the long press doesn't proceed?). Plugged into USB battery pack. Pressed, released and re-pressed and held. Returned to PC and it was BLANKED! Did upload of prior post #1409 sketch, the TYQT upload went with NO HITCH.

Doing the Long Press Wipe seems to have cleared up some cobwebs in my Proto board. Good Work!

<edit>: To confirm this includes programming the PROTO unit with TYQT at 120 MHz that failed before.

On PROTO - a TYQT upload of EEPROM code, then back to the post #1409 sketch and boot time is GOOD:

BOOT_on_Time=400
Serial_on_Time=1288
millis() =1289

<edit>: plugged in T_3.5 unit and it came up running showing TYQT USB serial - did a long press and this time it went blank. It then reprogrammed normally as expected. Not sure why this time - but it did.

 

[defragster]

Paul: in Boards.Txt I uncommented T_3.5 speed of 168 MHz - I just noticed it now defaults to that 168 on switching devices and it is not marked as (overclock). Not sure if that is by design or something you want to edit?

 

[DaQue]

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?

 

[KurtE]

I am wondering, with the T3.5 and T3.6 having multiple I2C interfaces, if we should add these to the Wire library?

Yes I know that they are available with i2c_t3 library, but for compatibility with Arduino Due which installs Wire and Wire1 as part of wire library, I am wondering if we should do the same?

Kurt

 

[MichaelMeissner]

I am wondering, with the T3.5 and T3.6 having multiple I2C interfaces, if we should add these to the Wire library?

Yes I know that they are available with i2c_t3 library, but for compatibility with Arduino Due which installs Wire and Wire1 as part of wire library, I am wondering if we should do the same?

Kurt

Frankly, I wish the Teensy Wire.h was replaced with an include file that includes i2c_t3.h (assuming recent IDE's that will include other libraries mentioned without having to edit the main .ino/.pde file, and any minor incompatibilities are fixed). It is getting tiresome trying to explain how to convert libraries to use i2c_t3. But I know Paul has an enormous backlog of things to get to.

 

[mxxx]

quick question: am i reading the MK66 datasheet correctly in that (unlike T 3.1/2, but like T LC) there's no 470R resistor connecting V_REFH to VDDA, right?

(sorry if this has been addressed/answered before. quick search didn't turn up anything)

 

[KurtE]

Frankly, I wish the Teensy Wire.h was replaced with an include file that includes i2c_t3.h (assuming recent IDE's that will include other libraries mentioned without having to edit the main .ino/.pde file, and any minor incompatibilities are fixed). It is getting tiresome trying to explain how to convert libraries to use i2c_t3. But I know Paul has an enormous backlog of things to get to.

Hi Michael,

I know what you mean. Personally I think we should resolve this and believe there are a few different ways to handle this, from very simple to a little more work.

a) Punt...

b) Change i2c_t3 to not create the Wire object. Maybe instead create Wire0. if the app includes both, should be default use standard Wire library for the Wire object. Would probably need to change the Wire0 object to not hard code interrupt vectors, but install them at init time...

c) Add Wire1, maybe Wire2, ... To standard Wire library. The user can then choose which library wish to use. Sort of like ILI9341_t3 versus standard Adafruit, or I also have ILI9341_t3n which allows me to use different SPI interfaces...

d) Replace Wire library with I2c_t3 library, but there are some incompatiblities, like i2c_t3, does not allow me to individually change SCL and SDA pins. Instead it has you choose from hard coded sets.

I personally think any but a) are valid approaches. But I don't know enough about i2c_t3, to know if there are any downsides versus wire? Example does it take substantially more data or code space?

 

[defragster]

KurtE / Michael - Agreed - from my limited use - it seems on Teensy when I want I2c I change to use I2c_t3 - like with ILI9341_t3 as Kurt mentions. This is a general Teensy issue - but the K66 with more bus pin sets makes it more common and where I saw it last hooking up multiple I2c displays earlier in this beta - not sure about net code size - but the I2c_t3 was a good drop in replacement.

 

[nox771]

Hi Michael,
b) Change i2c_t3 to not create the Wire object. Maybe instead create Wire0. if the app includes both, should be default use standard Wire library for the Wire object. Would probably need to change the Wire0 object to not hard code interrupt vectors, but install them at init time...

c) Add Wire1, maybe Wire2, ... To standard Wire library. The user can then choose which library wish to use. Sort of like ILI9341_t3 versus standard Adafruit, or I also have ILI9341_t3n which allows me to use different SPI interfaces...

d) Replace Wire library with I2c_t3 library, but there are some incompatiblities, like i2c_t3, does not allow me to individually change SCL and SDA pins. Instead it has you choose from hard coded sets.

I personally think any but a) are valid approaches. But I don't know enough about i2c_t3, to know if there are any downsides versus wire? Example does it take substantially more data or code space?

Just my 2c:

b) This is a no-go. The advantage of the current system is to swap libraries you only need to change one line, the header include. If you would rename Wire to Wire0 (or anything else) then you need to find and replace every Wire call in the whole project from "Wire" to "Wire0" (but without changing say Wire1 to Wire01). And then later if you want to revert it, then change it all back, and so on. It's a lot of changes versus one change on existing project code.

d) Current i2c_t3 methodology is to have adjacent pairs of pins as a "set" (this is actually true even in discontinuous numbers such as 26/31 on T3.2, which is still adjacent backside SMT pads). There is some flexibility in having them separate, but this gets very cumbersome across different parts (eg. 3.2 vs LC vs 3.6) as the pins are not common. Further these are "Arduino" pin numbers, not physical pin numbers, so you would practically need a secret decoder card to figure out what pin goes where on which part. Even with predefined pin sets the list is complex enough to be a PITA code-wise (there is a slew of #if defined blocks to prevent using say T3.2 pins on a T3.6 part):

             Interface  Devices     Pin Name      SCL    SDA
    //          ---------  -------  --------------  -----  -----    (note: in almost all cases SCL is the
    //             Wire      All    I2C_PINS_16_17    16     17      lower pin #, except cases marked *)
    //             Wire      All    I2C_PINS_18_19    19     18  *
    //             Wire    3.5/3.6  I2C_PINS_7_8       7      8
    //             Wire    3.5/3.6  I2C_PINS_33_34    33     34
    //             Wire    3.5/3.6  I2C_PINS_47_48    47     48
    //            Wire1       LC    I2C_PINS_22_23    22     23
    //            Wire1    3.1/3.2  I2C_PINS_26_31    26     31
    //            Wire1    3.1/3.2  I2C_PINS_29_30    29     30
    //            Wire1    3.5/3.6  I2C_PINS_37_38    37     38
    //            Wire2    3.5/3.6  I2C_PINS_3_4       3      4
    //            Wire3      3.6    I2C_PINS_56_57    57     56  *

If someone wants to go down that road, then have at it, but I don't think I'll be going there.

Regarding code space, it definitely uses more flash and ram than basic Wire, but on these new parts IMO this is a minor concern (flash in particular is huge now). It's code style is designed to share functions as much as possible across interfaces (Wire, Wire1, Wire2...) so my guess is if standard Wire was modified to support all those they would probably be comparable size-wise.

There is some trickery one can use on the Arduino build system to trick it into using i2c_t3 instead of Wire on libraries, by only modifying one line in the main sketch. It is described here:
https://forum.pjrc.com/threads/21680-New-I2C-library-for-Teensy3?p=79995&viewfull=1#post79995
Also: https://forum.pjrc.com/threads/21680-New-I2C-library-for-Teensy3?p=80340&viewfull=1#post80340
That was some time ago so it may or may not still work.

 

[MichaelMeissner]

Hi Michael,

I know what you mean. Personally I think we should resolve this and believe there are a few different ways to handle this, from very simple to a little more work.

a) Punt...

Yes, but it would be nice to do something.

b) Change i2c_t3 to not create the Wire object. Maybe instead create Wire0. if the app includes both, should be default use standard Wire library for the Wire object. Would probably need to change the Wire0 object to not hard code interrupt vectors, but install them at init time...

While this would solve the immediate problem of not being able to access the secondary i2c buses, I tend to think the problem is more systemic.

c) Add Wire1, maybe Wire2, ... To standard Wire library. The user can then choose which library wish to use. Sort of like ILI9341_t3 versus standard Adafruit, or I also have ILI9341_t3n which allows me to use different SPI interfaces...

This is the nub of the problem that extends way beyond just using i2c_t3.h. All of the libraries that deal with i2c and SPI need to be extended to have an alternate constructor that takes the i2c/SPI/CAN/etc. bus variable, and it would default to the standard version if not given. Fortunately, C++ does allow for constructors with different number of arguments to choose between the two.

While the work can proceed piecemeal, the core of the problem is that the source of most of these libraries are not PJRC libraries, and you have to work with the library maintainers to get your changes in. Or you fork the libraries, and maintain your own branch (possibly merging in changes from time to time from the original branch). Of course getting people to change their libraries may be a problem. A few years ago, it looked from outside, that nobody was really maintaining the core Arduino libraries, so getting changes in was hard. And often times you get into issues that it just takes so long to get the changes in that it can be frustrating.

And even if you come up with the changes, the library maintainer might decide they don't want them. For example, I complained on the Adafruit forums, that one of the libraries had some warnings in them when compiled on the Teensy, and eventually provided a patch to fix the warnings. But the response from one of the Adafruit employees left me with the feeling that they really don't care to improve their libraries and fix it for other platforms.

Like most things, the libraries grew over time, and the Teensy 3.6 has vastly more power than the Arduino Uno with the AVR328P, and the original authors couldn't imagine having more than one i2c bus. Also, I believe in some/many of the libraries, the people writing them really aren't programmers, and have learned about things like superclasses, being able to deal with different objects without modifying the header, etc.

d) Replace Wire library with I2c_t3 library, but there are some incompatiblities, like i2c_t3, does not allow me to individually change SCL and SDA pins. Instead it has you choose from hard coded sets.

Yes, I imagine there are some things in i2c_t3 that need to be adapted from Wire.h. Also, it leaves out in the cold anybody that needs to use i2c_t3 on the main bus to change parameters.

I personally think any but a) are valid approaches. But I don't know enough about i2c_t3, to know if there are any downsides versus wire? Example does it take substantially more data or code space?

I would suspect it is a little bigger and I believe the Wire data structure is bigger, but for most programs that would not be a major thing. I do recall when it first came out, there were one or two interface changes where the Arduino library used uint8_t and i2c_t3 needed to use a wider type because there were more options. But this can be fixable by having multiple functions with different arguments. You do need time to dig in and look at the problem, and right now, Paul has so many things on his plate, that I dunno if it can be fixed.

KurtE / Michael - Agreed - from my limited use - it seems on Teensy when I want I2c I change to use I2c_t3 - like with ILI9341_t3 as Kurt mentions. This is a general Teensy issue - but the K66 with more bus pin sets makes it more common and where I saw it last hooking up multiple I2c displays earlier in this beta - not sure about net code size - but the I2c_t3 was a good drop in replacement.

Another option that occurs to me is if we can get Paul to adapt the Teensydunio installer to ask whether to install i2c_t3 as the default Wire (and perhaps make the default no). It still doesn't answer the problem about getting the libraries to incorporate alternate i2c/SPI/CAN buses.

It may be better to start a set of new libraries that take the original libraries and modify them, rather than trying to fix the infrastructure (at least as a start, it would be better long term to get the fixes merged back into the original libraries). However note, in doing so, it will take effort to update the new libraries whenever the old libraries are modified (or else the new libraries become abandonwear). Whether it should be named Teensy or try to work with the other machines (like the Adafruit feather M0, the Intel Edison, etc.).

 

[MichaelMeissner]

Just my 2c:

b) This is a no-go. The advantage of the current system is to swap libraries you only need to change one line, the header include. If you would rename Wire to Wire0 (or anything else) then you need to find and replace every Wire call in the whole project from "Wire" to "Wire0" (but without changing say Wire1 to Wire01). And then later if you want to revert it, then change it all back, and so on. It's a lot of changes versus one change on existing project code.

Though the disadvantage is you have to fix/rename all of the libraries that use Wire.h that you may not realize they do (i.e. the Audio libraries). I understand why we have the two libraries, and we are sort of between a rock and a hard place. There may not be a solution.

But as I said, it can get a little tiresome to explain it the n-th time.

 

[nox771]

Though the disadvantage is you have to fix/rename all of the libraries that use Wire.h that you may not realize they do (i.e. the Audio libraries). I understand why we have the two libraries, and we are sort of between a rock and a hard place. There may not be a solution.

But as I said, it can get a little tiresome to explain it the n-th time.

Well as mentioned there is a workaround to this:

There is some trickery one can use on the Arduino build system to trick it into using i2c_t3 instead of Wire on libraries, by only modifying one line in the main sketch. It is described here:
https://forum.pjrc.com/threads/21680...ll=1#post79995
Also: https://forum.pjrc.com/threads/21680...ll=1#post80340
That was some time ago so it may or may not still work.

but in general yes this is a problem for libraries that call other libraries. I don't know of a general solution, but this is really a general-case problem, as it applies to SPI or display or any other low-level library that you might want to swap with a different library.