K66 Beta Test

Status
Not open for further replies.
hw999 - looks promising for your 8E2 needs, KurtE's the man - I was just giving some test cycles. I'm amazed at how easy and effective serialEvent() processing is for receiving buffered serial data as long as loop() doesn't stall or yield() is called.
I added a little code to serial5_format to use the bit 0x100 of format options to indicate you want 2 stop bits. The whole code I added was:
Code:
		// For T3.5/T3.6 See about turning on 2 stop bit mode
	if ( format & 0x100) {
		uint8_t bdl = UART4_BDL;
		UART4_BDH |= 0x20;		// Turn on 2 stop bits - was turned off by set baud
		UART4_BDL = bdl;		// Says BDH not acted on until BDL is written
	}
The first attempt I did of only setting BDH did nothing, but then reading the docs, it implied updates to BDH will not happen until you update BDL.
With this change, in my Test program I passed in 0x106 to format (as #define SERIAL_8E1 0x06)
Here is part of the output as shown in Logic Analyzer.
screenshot.jpg
So yes it can work. Question is, should I add such code to project (#ifdef to these processors?)

I updated the P_8 note on boards.txt and note on TD_1.29 or greater ... any other edits needed?
I personally think you should update #8 to the later update like nox771 quoted of mine in #917, with his remarks in that message for SCL0/SDA0
 
@KurtE

implementing 8E2 would be helpfull for my project - please do it. Thanks anyway for the research and testing.
 
@KurtE

implementing 8E2 would be helpfull for my project - please do it. Thanks anyway for the research and testing.
As I mentioned, it is more up to Paul, if he would like this feature added directly to code base. I verified it works also on Serial3 (of course changing the actual register names).

As a side note, this also works for the TLC, but it does not on T3.2. If you have a TLC, you can try it without changing the underlying code. Something like:
Code:
Serial3.begin(38400, SERIAL_8E1);
uint8_t bdl = UART2_BDL;
UART2_BDH |= 0x20;		// Turn on 2 stop bits - was turned off by set baud
UART2_BDL = bdl;		// Says BDH not acted on until BDL is written
 
I personally think you should update #8 to the later update like nox771 quoted of mine in #917, with his remarks in that message for SCL0/SDA0

I put links to those posts on the PIN map section. It would be cool to have a complete 'PJRC' card like map of the pins as they'll be named/exposed:
Here is a link to extended pin map data and ALT I2C usage - And this may show SDHC details not yet confirmed as exposed by PJRC?

I think those SDHC pins would be well to be published - and ALT usages that will work. If there is a better view for post_8 - update the post linked above I should copy from.
 
Manitou - you might want to revisit your RTC sketch and post to see if it is running better/differently? I was seeing something odd with volatiles the other day - that is gone now with TD_1.30b1 - still on IDE 1.6.9. Also some of the other numbers make more sense now. It is possible something changed for the better - maybe just me/my sketch.

Software Samples and Features:
manitou RTC clock sketch sync

<edit>
Koromix provided me a TYQT update that is working better again on serial startup with all Teensy. He doesn't have his beta K66 yet so he is guessing with my feedback - and from what I see the K66/TeensyDuino programming steps are a bit diff than T_3.1 - hopefully more updates soon. One oddity is that the GUI RESET starts programming then interrupts it somehow (unlike T_3.1) leaving the K66 blanked it seems - it springs back to life (~easily) each of the few times I did it. Working well with Verify and GUI BootLoader click or Button Press.
 
Last edited:
It seems that all important libs are ported, all is working and there are currently no visible problems.. (ok, I2S @ > 200MHZ does not work on my board)
Paul, are there any things on the TODO-List, where we (I ?) can help ?
 
As I mentioned, it is more up to Paul, if he would like this feature added directly to code base. I verified it works also on Serial3 (of course changing the actual register names).

As a side note, this also works for the TLC, but it does not on T3.2. If you have a TLC, you can try it without changing the underlying code. Something like:
Code:
Serial3.begin(38400, SERIAL_8E1);
uint8_t bdl = UART2_BDL;
UART2_BDH |= 0x20;		// Turn on 2 stop bits - was turned off by set baud
UART2_BDL = bdl;		// Says BDH not acted on until BDL is written
In case anyone is interested, I believe I made the same changes to all of the Serial port objects. I defined the actual field of BDH register in header file and likewise under BAUD register for LPUART. I compiled a test program for TLC, T3, T3.2, T3.5, T3.6 - To hopefully not give a compiler error... I have NOT yet issued a pull request, but did push up the changes to a new branch on github:
https://github.com/KurtE/cores/tree/T35-T36-TLC-UART-2StopBits This branch is in sync with Pauls master, so can simply use as is...

Will do some more testing hopefully later today, before I issue PR, but if anyone wishes to try it out, that would be great. Again not sure if/when PR might be accepted on this.

Kurt
 
It seems that all important libs are ported, all is working and there are currently no visible problems.. (ok, I2S @ > 200MHZ does not work on my board)
Paul, are there any things on the TODO-List, where we (I ?) can help ?

Agreed Frank - seems very stable.

The only thing on my p_8 list:
Known Work Items:
EEPROM access not valid over 120MHz - needs speed drop from HSRUN mode for access.

That might be fun for you - dropping clock speed/mode - calling eeprom code - putting the clock speed back?
 
Speaking of serial, I finished the FTDI interface driver last night, and cleaned up CDC-ACM for OTG host mode. :cool:
Still need to work out the other host port.

@Paul: If you get the chance, I'd like to see that reset/init code you did for the other USB port, it may save me some time on the setup.
 
The audio board on the K66 is acting strangely when I use a microphone as audio input.
A simple sketch to test the microphone does not work on the K66 but works on the Teensy3.2.
The K66 and T3.2 both use audio boards and a MEMS microphone powered with 3V3 from the board.
However, when I use the microphone as input to my 16 channel vocoder on the K66, it does work.

There's no mention of microphone in this thread. Has anyone tried one on the K66?

I've included three sketches here.
The first one plays the microphone audio directly through to the headphone output.
The second one plays the microphone audio through a mixer and then to the headphone output.
Both work on a Teensy3.2. Neither work on K66.
I looked at the vocoder and the first thing that the audio input goes through is a biquad bandpass filter. So I changed the mixer in the second test to a biquad and, sure enough, the microphone works.

I also tried them with USB set to MIDI but no difference. The reason for testing this was that I first noticed the problem while trying to add a MIDI keyboard to the vocoder and on one test (as noted in the second example) the microphone worked with USB MIDI just once and failed thereafter.

Arduino IDE 1.6.10, TeensyDuino 1.30 beta1

microphone straight through to headphones
Code:
// This example code is in the public domain.

#include <Audio.h>
#include <Wire.h>
#include <SPI.h>
#include <SD.h>
#include <SerialFlash.h>

const int myInput = AUDIO_INPUT_MIC;

/*
  Microphone straight to headphones
*/
// K66 this fails with USB Serial and USB MIDI!
// T3.2 works with USB Serial and USB MIDI

AudioInputI2S            audioInput;

AudioOutputI2S           audioOutput;

AudioConnection          patchCord1(audioInput, 0, audioOutput, 0);
AudioConnection          patchCord2(audioInput, 0, audioOutput, 1);

AudioControlSGTL5000     sgtl5000_1;

// Use these with the audio adapter board
#define SDCARD_CS_PIN    10
#define SDCARD_MOSI_PIN  7
#define SDCARD_SCK_PIN   14

void setup(void)
{
  Serial.begin(9600);

  AudioMemory(8);

  sgtl5000_1.enable();

  sgtl5000_1.inputSelect(myInput);
  // micgain for the MEMS microphone with 67dB preamp should be zero
  // micgain for my Sony microphone with no preamp should be 26-30
  sgtl5000_1.micGain(0);

  sgtl5000_1.volume(0.6);
}


void loop(void)
{
  static int volume;
  int n = analogRead(15);
  if (n != volume) {
    volume = n;
    sgtl5000_1.volume(n / 1023.);
  }

}

Microphone through mixer to headphones
Code:
// This example code is in the public domain.

#include <Audio.h>
#include <Wire.h>
#include <SPI.h>
#include <SD.h>
#include <SerialFlash.h>


const int myInput = AUDIO_INPUT_MIC;

/*
  Microphone through mixer and then to headphones
*/

// K66 this worked once with MIDI but has failed ever since

// K66 this fails with USB Serial and USB MIDI!
// T3.2 works with USB Serial and USB MIDI

AudioInputI2S            audioInput;
AudioMixer4              mixer1;
AudioOutputI2S           audioOutput;

AudioConnection          patchCord1(audioInput, 0, mixer1, 0);
AudioConnection          patchCord2(mixer1, 0, audioOutput, 0);
AudioConnection          patchCord3(mixer1, 0, audioOutput, 1);


AudioControlSGTL5000     sgtl5000_1;

// Use these with the audio adapter board
#define SDCARD_CS_PIN    10
#define SDCARD_MOSI_PIN  7
#define SDCARD_SCK_PIN   14

void setup(void)
{
  Serial.begin(9600);

  AudioMemory(8);

  sgtl5000_1.enable();

  sgtl5000_1.inputSelect(myInput);
  // micgain for the MEMS microphone with 67dB preamp should be zero
  // micgain for my Sony microphone with no preamp should be 26-30
  sgtl5000_1.micGain(0);

  sgtl5000_1.volume(0.6);
  mixer1.gain(0, .9);
}


void loop(void)
{
  static int volume;
  int n = analogRead(15);
  if (n != volume) {
    volume = n;
    sgtl5000_1.volume(n / 1023.);
  }

}

Microphone through biquad to headphones.
Code:
// This example code is in the public domain.

#include <Audio.h>
#include <Wire.h>
#include <SPI.h>
#include <SD.h>
#include <SerialFlash.h>


const int myInput = AUDIO_INPUT_MIC;

/*
  Microphone through biquad and then to headphones
*/

// K66 this WORKS with USB Serial and USB MIDI!
// T3.2 works with USB Serial and USB MIDI

AudioInputI2S            audioInput;
AudioFilterBiquad        biquad1a;
AudioOutputI2S           audioOutput;

AudioConnection          patchCord1(audioInput, 0, biquad1a, 0);
AudioConnection          patchCord2(biquad1a, 0, audioOutput, 0);
AudioConnection          patchCord3(biquad1a, 0, audioOutput, 1);


AudioControlSGTL5000     sgtl5000_1;

// Use these with the audio adapter board
#define SDCARD_CS_PIN    10
#define SDCARD_MOSI_PIN  7
#define SDCARD_SCK_PIN   14

void setup(void)
{
  Serial.begin(9600);

  AudioMemory(8);

  sgtl5000_1.enable();

  sgtl5000_1.inputSelect(myInput);
  // micgain for the MEMS microphone with 67dB preamp should be zero
  // micgain for my Sony microphone with no preamp should be 26-30
  sgtl5000_1.micGain(0);

  sgtl5000_1.volume(0.6);
  biquad1a.setBandpass(0,1800,2);
}


void loop(void)
{
  static int volume;
  int n = analogRead(15);
  if (n != volume) {
    volume = n;
    sgtl5000_1.volume(n / 1023.);
  }

}

Pete
 
Pete: I put that on P_8 : [*]Audio board and Mic usage - I haven't gotten to Audio Board - Anything else on Audio board is buried (in this thread) for now . . If you get a solution or do more - it is sticky linked for now

KurtE: I have an anomaly on Serial6. Now with TD_1.30b1 I should have complete code. I did the Serial_Test code that would run on any port 1-6. That came after I did the loop through code 1-5. When I extended that to put Serial6 in it failed days back. I just double checked my wires - pulled off Ethernet shield, and all displays - it won't work? Loopback #6 works - Loopthrough 1-5 works. Here's my code if anyone gets a chance to scan it.

Sample to test any port loop back (jumper Rx==Tx) #1-#6 :: View attachment Serial_Test.ino {this code works}

I have the pins for Serial6 working with above - for below I tried them both ways in case I confused Rx/Tx - no good. Something is not right when Serial 6 blends in to my larger test?

Working example below - Thanks KurtE: Only_qBlink_Loop6k

Sample loop through with jumpers as noted::
Code:
// cascade w/1-5 :: wire serial PORT to PORT :: pins>1-34,33-31,32-7,8-9 :: #1>#5>#4>#3>#2
// cascade w/1-6 :: wire serial PORT to PORT :: pins>1-34,33-31,32-47,48-7,8-9 :: #1>#5>#4>#6>#3>#2

... // line 167
void serialEvent4() {
  int avail = Serial4.available();
  if ( avail ) {
    Serial4.readBytes(readBuf, avail);
    readBuf[avail] = 0;
    Serial4.write( readBuf );
  }
}
 
Last edited:
@defragster. The only thing I've done with audio on the K66 is the 16 channel vocoder I mentioned in msgs #737 and #781.

The problem with teensy_gateway.exe and conhost.exe being spawned hasn't gone away yet. Last night I left the computer to go upstairs to watch a really heavy rainstorm. When I got back, the screen was black with small pieces of the taskbar scattered along the top of the screen (it should be at the bottom). I immediately disconnected the K66 and shut off the 61es keyboard and that seemed to stop any more processes spawning. When I finally saw the lower part of the task manager window it showed that there were 4153 processes - there are usually about 100. There's no easy way to kill that many processes so I rebooted.
At the moment I am trying to avoid the problem rather than find out what's causing it.

Pete
 
@defragster - I will try out some of the Serial6 loop back stuff and see if I find anything.

@Paul - I went ahead and issued a Pull request (https://github.com/PaulStoffregen/cores/pull/164) for the Serial 2 stop bit support, examples: 8E2/8O2.
Currently the 0x100 bit says 2 stop bits.

I used my test program and Saleae logic Analyzer to look at generated serial streams and tried turning on 2 stop bit modes on a Teensy LC for Serial ports 1, 2, 3.
I then tried on Beta board on Serial ports 3, 4, 5, 6

With the test program anything I enter in the Debug monitor is echoed out the currently selected Serial port. If the command starts with a # I assume it is a request for a new Serial port with the ability to enter the port TX-PIN RX-PIN Format. (if you enter 255 for RX or TX it is not used...).
Current version also added if the line starts with a $ I assume you simply want to enter a new format. Also quick and dirty coded added to allow me to enter hex values...

So for example If I enter: #6
It will start talking with Serial6 using no format value so 8N1, (It also outputs a default string to the serial port).

I can then enter: $0x107 it says: Do a format of 8O2

Code:
uint8_t command_line[100];
uint8_t command_line_len = 0;

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


HardwareSerial *pserial = 0;
void SetupSerialPort(uint8_t ser, uint8_t tx, uint8_t rx, uint32_t format)
{
  // Close previous
  Serial.printf("SetupSerialPort %d: %d %d %x\n\r", ser, tx, rx, format);
  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 defined(HAS_KINETISK_UART5) || defined (HAS_KINETISK_LPUART0)
    case 6:
      Serial.println("Serial 6");
      pserial = &Serial6;
      break;
#endif
  }
  if (pserial)
  {
    if (tx != 0xff)
      pserial->setTX(tx);
    if (rx != 0xff)
      pserial->setRX(rx);
    Serial.println("Before Begin");
    // See where things are hanging!
    if (format && (format != (uint32_t) - 1))
      pserial->begin(115200, format);
    else
      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, uint32_t *pnum)
{
  *pnum = 0;    // clear it out just in case.
  uint32_t num = 0;
  if ((psz == 0) || (*psz == 0)) {
    *pnum = (uint32_t) - 1; //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++;
  }

  if ((*psz == '0') && (*(psz + 1) == 'x'))
  {
    Serial.println("Hex input");
    psz += 2;
    for (;;)
    {
      if ((*psz >= '0') && (*psz <= '9'))
        num = num * 16 + (*psz++ - '0');
      else if ((*psz >= 'a') && (*psz <= 'f'))
        num = num * 16 + (*psz++ - 'a') + 10;
      else if ((*psz >= 'A') && (*psz <= 'F'))
        num = num * 16 + (*psz++ - 'A') + 10;
      else
        break;
    }
  }
  else
  {
    while ((*psz >= '0') && (*psz <= '9'))
    {
      num = num * 10 + (*psz++ - '0');
    }
  }
  *pnum = num;
  return psz;
}

uint32_t ser, tx, rx, format;
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 *psz = GetNextCmdNum(&command_line[1], &ser);
        psz = GetNextCmdNum(psz, &tx);
        psz = GetNextCmdNum(psz, &rx);
        psz = GetNextCmdNum(psz, &format);
        SetupSerialPort(ser, tx, rx, format);
      }
      else if ((command_line_len > 1) && (command_line[0] == '$'))
      {
        GetNextCmdNum(&command_line[1], &format);
        SetupSerialPort(ser, tx, rx, format);
      }
      command_line_len = 0; // clear out line
    } else
      command_line[command_line_len++] = (uint8_t)ch;
  }
}
 
Sounds good :)
I'll try to repair that.

ehm..no.
switching the speed causes problems with every communication-interface, including usb. all transfers will have errors during ee- write..

perhaps it's better disable eeprom writes for more than 120MHz. the path of least resistance..cause...i fear many many users will ask why things "suddenly" do not work when writing to eeprom..
saying eeprom does not work with > 120MHz is the more easy way..

any ideas ?
 
ehm..no.
switching the speed causes problems with every communication-interface, including usb. all transfers will have errors during ee- write..

perhaps it's better disable eeprom writes for more than 120MHz. the path of least resistance..cause...i fear many many users will ask why things "suddenly" do not work when writing to eeprom..
saying eeprom does not work with > 120MHz is the more easy way..

any ideas ?

I expect you are right Frank - I only held out hope because Paul didn't say that when he found the HSRUN note initially - but however long it takes will cause timing issues. Allowing writes only at 120 and under seems needed. I noticed the K66 2MB flash part seemed to exclude any use of EEPROM. A compromise combining speed and technologies to get a 220 MHz Arduino with FPU and MEGA class I/O - no 3.3V tolerance and no ON chip EEPROM use at high speed. I suppose it will work then on the K64?

<edit> - though duff does speed changes for snooze? Might be a good option to have - as long as the CPU doesn't need a reset - being able to go offline to update EEPROM could be handy
 
Last edited:
@defragster: Serial6 forwarding...

I tried a simple program:
Code:
void setup() {
  // put your setup code here, to run once:
  while (!Serial && millis() < 5000) ;

  Serial.println("Quick and dirty Serial forwarder test");
  Serial1.begin(1000000);
  Serial2.begin(1000000);
  Serial3.begin(1000000);
  Serial4.begin(1000000);
  Serial5.begin(1000000);
  Serial6.begin(1000000);
}

void loop() {
  // put your main code here, to run repeatedly:

}

void serialEvent() {
  int ch;
  while ((ch = Serial.read()) != -1)
    Serial1.write(ch); 
}

void serialEvent1() {
  int ch;
  while ((ch = Serial1.read()) != -1)
    Serial.write(ch); 
}

void serialEvent2() {
  int ch;
  while ((ch = Serial2.read()) != -1)
    Serial2.write(ch); 
}

void serialEvent3() {
  int ch;
  while ((ch = Serial3.read()) != -1)
    Serial3.write(ch); 
}

void serialEvent4() {
  int ch;
  while ((ch = Serial4.read()) != -1)
    Serial4.write(ch); 
}

void serialEvent5() {
  int ch;
  while ((ch = Serial5.read()) != -1)
    Serial5.write(ch); 
}

void serialEvent6() {
  int ch;
  while ((ch = Serial6.read()) != -1)
    Serial6.write(ch); 
}
I have jumpers 1-9, 10-7, 8-31, 32-34, 33-47, 48-0 (assuming I did not mistype. Tx1->Rx2, TX2->RX3, TX3->RX4, TX4->Rx5, TX5->RX6, TX6->RX1

So far this part appears to work.
 
@Paul: If you get the chance, I'd like to see that reset/init code you did for the other USB port, it may save me some time on the setup.

Sure, here it is

https://github.com/PaulStoffregen/k66_usbhost/blob/master/k66_usbhost.ino

Prepare to be underwhelmed. It does (seem to) initialize the hardware correctly. The port reset sequence completes and my Beagle analyzer sees SOF packets at 480 Mbit speed. But that's it... no actual communication works yet.

I have some uncommitted code which tries (but fails) to read a descriptor. If you want to see that too, just say the word and I'll commit it.
 
Sure, here it is

https://github.com/PaulStoffregen/k66_usbhost/blob/master/k66_usbhost.ino

Prepare to be underwhelmed. It does (seem to) initialize the hardware correctly. The port reset sequence completes and my Beagle analyzer sees SOF packets at 480 Mbit speed. But that's it... no actual communication works yet.

I have some uncommitted code which tries (but fails) to read a descriptor. If you want to see that too, just say the word and I'll commit it.

Not worried on any core parts, I have those already written. :) All I need to do is interface with the SIE and done. That's the really nice thing with UHS3.0, it is easy to integrate new hardware hosts. Drivers are much easier too, since they are now only *interface* drivers, not an entire USB driver like the old code. So yes, please commit it. It may have a few more nuggets in it.
 

Thanks.
Please note that FIFOs are not used or even supported in my core anywhere. This is mainly due to the fact that it is not running in any kind of true scheduler, and could have an impact on full performance. Another reason is that schedulers on AVRs suck, since the context switches are so expensive, so I just keep things as simple as possible.

What is interesting despite not using any FIFO, I can fully saturate the Kinetis low/full speed SIE currently on all T3's. I also have to actually slow down how often a packet is sent when a hub is involved. This is because normally there is usually only one TT, and the hub can't keep up. Didn't even seem to matter if the target on the far end was able to do high speed, which I found interesting, since on the other end of the hub, it is indeed high speed. This hub trick also allows me to run fast speed only devices, since the hub's TT allows this.

Reflecting back on the various USB host hardware I have written code for...

If the people designing this stuff are programmers, they aren't thinking like one at all.
I find it pretty much a crime that so much silicon is so stupid. It kind of reminds me in some ways of Ethernet is implemented. It tends to be over complicated, especially in older hardware, and caused many problems like IRQ storms on fast links, because the CPU had to do too much, whereas Arcnet is way easier. You literally put the packet in ram and say "send", then just wait for it to say "it was sent". Another analogy would be winprinter v.s. something with an actual brain like a PS printer. It tends to be pretty horrible and locks out a lot of innovation.
At least the designers of this particular hardware were intelligent enough to skip the whole dual transmitter junk, and just put in a TT, which helps reduce the code footprint and effort.
 
Quick update, on I2C I was able to get all four buses to talk to each other on K66. Wire as a master device, and the other three as slaves (had to use the 10-pin header location to get Wire3, as per post #8 info). Everything works correctly. That was done using external pullups.

So then I got to wondering about internal pullups, so I tried configuring it for that. I knew something was probably not going to work when I saw the pin LEDs double in brightness when I went from external pullups to internal. Sure enough, I couldn't get loopback to work with internal pullups.

So I figured I would measure the resistance. Well I thought Freescale really botched the T3.1/3.2 pullups when they measured out at <200 ohms, but that's got nothing on the T3.6 which I measured at ... 24 ohms. :p

Now it's possible I got the wrong internal pin config, so I'll go check the port configs again to see if bits shifted or something, but if someone could verify this number that would be helpful. Note that pullup strength when I2C is active vs not active, is not the same, the pin must be configured for the correct I2C ALT setting. IIRC normal pin pullups are generally reasonable.
 
@PaulStoffregen I take pin32 will be connected to a USB power switch, such as MIC2004? VBUS power on the board I have does not change, but I can add this on mine.
 
Quick update, on I2C I was able to get all four buses to talk to each other on K66. ... That was done using external pullups.

Glad post #8 was useful. Is that 4 bus code posted as a sample? With Ethernet it looks like pins are clear for I2C[0,1,3] but I2C2 and ALT's all conflict.

Also - Manitou's etherraw works from TeensyDuino 1.30b1 at 180 and 240 MHz.

To that eterraw sketch I added in the Serial1-6 loop through test at 4Mbaud that is running with 6ms elapsedMillis waits transferring 17,051 chars/sec (across each of 4 ports) and no apparent data loss while handling 222 byte pings on average of <=1ms with few 10ms or 15ms, max CPU surface temp I see is 101.4°F and I see 97°F max on the ethernet shield.
 
Status
Not open for further replies.
Back
Top