K66 Beta Test

Status
Not open for further replies.
Serial6 update: There is probably still work to be done, but I do believe enough of it is working to go ahead and pull it in and allow others to play. So I issued a pull request: https://github.com/PaulStoffregen/cores/pull/158

I wrote a test sketch that I have a T3.2 using Serial1 connecting up to Serial6 of T3.5, as well as I have Pins 13 hooked up to each other, and the Master program (one that has D2 pulled low, walks through a list of baud rates and some formats. It lets the Slave know which table entry to use by how many times it blinks the led.
I then currently output the characters 'a'-'z' from host to slave, and if slave receives it it sends it back, which the host compares...

So far most everything is passing, except at baud rate 300. However I think the problem is with the T3.2, as when I look at the generated character with Logic Analyzer, it looks like it was generated at baud 1660. Will investigate.

If anyone is interested in test program:
Code:
// Quick and Dirty Serial Test between two Teensy processors.


#define MASTER_PIN 2
#define TRIGGER_PIN 13
#define TEST_PIN 3

#define FIRST_CHAR 'a'
#define LAST_CHAR ('z'+1)

#define Serial1 Serial1
#if defined(__MK66FX1M0__)
#define SLAVE_SERIAL Serial6
#else
#define SLAVE_SERIAL Serial3
#endif

uint32_t baudRates[] = {9600, 38400, 115200, 1000000, 2000000, 2400, 300, 38400, 38400, 38400, 38400, 38400};
uint32_t formats[] = {0, 0, 0, 0, 0, 0, 0, SERIAL_8N1_RXINV_TXINV, SERIAL_8N2, SERIAL_7E1, SERIAL_7O1};
uint8_t baudRatesIndex = 0xff;
bool we_are_master = false;

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))
    ;

  pinMode(MASTER_PIN, INPUT_PULLUP);
  pinMode(TEST_PIN, OUTPUT);

  we_are_master = !digitalRead(MASTER_PIN);

  if (we_are_master) {
    Serial.println("Master");
    pinMode(TRIGGER_PIN, OUTPUT);
    digitalWrite(TRIGGER_PIN, HIGH);
  } else {
    Serial.println("Slave");
    pinMode(TRIGGER_PIN, INPUT_PULLUP);
  }
  delay(500);
}

void loop() {
  if (we_are_master) {
    DoMasterStuff();
  } else {
    DoSlaveStuff();
  }
}

void DoMasterStuff() {
  // Lets tell Slave to go to new mode Blink the number of times
  if (baudRatesIndex >= (sizeof(baudRates) / sizeof(baudRates[0])))
    baudRatesIndex = 0;

  Serial.printf("Now Testing Baud rate: %d format: %x ", baudRates[baudRatesIndex], formats[baudRatesIndex]);
  digitalWrite(TRIGGER_PIN, LOW);
  for (uint8_t i = 0; i < baudRatesIndex; i++) {
    delay(100);
    digitalWrite(TRIGGER_PIN, HIGH);
    delay(100);
    digitalWrite(TRIGGER_PIN, LOW);
  }
  if (formats[baudRatesIndex])
    Serial1.begin(baudRates[baudRatesIndex], formats[baudRatesIndex]);
  else
    Serial1.begin(baudRates[baudRatesIndex]);
  baudRatesIndex++;
  delay(500);
  digitalWrite(TRIGGER_PIN, HIGH);
  delay(100);  // Give time to setup

  // Now try to output all valid characters and see if we get a response back...
  int charOut, charIn;
  uint32_t start_time;
  digitalWrite(TEST_PIN, HIGH);
  for (charOut = FIRST_CHAR; charOut < LAST_CHAR; charOut++) {
    for (uint8_t retry_count = 0; (retry_count < 5) && (charIn != charOut); retry_count++) {
      Serial1.write(charOut);

      // Now try to get a char back from the Slave
      start_time = millis();
      while (((charIn = Serial1.read()) == -1) && ((millis() - start_time) < 100)) ;
    }
    // See if I need to remove parity...
    if (charIn != -1) 
      charIn &= 0x7f;
    if (charIn != charOut) {
      digitalWrite(TEST_PIN, LOW);
      Serial.printf("FAIL: %d != %d delta time: %d\n\r", charIn, charOut, millis() - start_time);
      digitalWrite(TEST_PIN, HIGH);
      break;
    }
  }
  if (charOut >= LAST_CHAR)
    Serial.println("*** Succeeded ***");
  Serial1.end();
  digitalWrite(TEST_PIN, LOW);
  delay(500);
}

void DoSlaveStuff() {
  // See if master is trying to signal us...
  if (!digitalRead(TRIGGER_PIN)) {
    uint8_t blink_count = 0;
    uint32_t pulse_width;
    for (;;) {
      // Master is signalling.
      uint32_t start_time = millis();
      while (!digitalRead(TRIGGER_PIN)) ;
      pulse_width = millis() - start_time;
      if (pulse_width < 250) {
        blink_count++;  //
        // wait until it goes low again
        while (digitalRead(TRIGGER_PIN)) ;
      } else
        break;  // done
    }
    // SO hopefully we have the correct index to use from the master.
    if (baudRatesIndex != 0xff)
      SLAVE_SERIAL.end();
    // lets setup the baud rate
    baudRatesIndex = blink_count;
    Serial.printf("Now Testing Baud rate: %d format: %x\n\r", baudRates[baudRatesIndex], formats[baudRatesIndex]);
    if (formats[baudRatesIndex])
      SLAVE_SERIAL.begin(baudRates[baudRatesIndex], formats[baudRatesIndex]);
    else
      SLAVE_SERIAL.begin(baudRates[baudRatesIndex]);
    digitalWrite(TEST_PIN, !digitalRead(TEST_PIN));
  }
  // mainly just echo anything we receive back
  int charIn = SLAVE_SERIAL.read();
  if (charIn != -1) {
    charIn &= 0x7f; // see if this fixes Parity stuff...
    SLAVE_SERIAL.write(charIn);
    Serial.write(charIn);
  }
}

Here is some output from masters terminal:
Code:
Master
Now Testing Baud rate: 38400 format: 0 *** Succeeded ***
Now Testing Baud rate: 115200 format: 0 *** Succeeded ***
Now Testing Baud rate: 1000000 format: 0 *** Succeeded ***
Now Testing Baud rate: 2000000 format: 0 *** Succeeded ***
Now Testing Baud rate: 2400 format: 0 *** Succeeded ***
Now Testing Baud rate: 300 format: 0 FAIL: 112 != 97 delta time: 24

Now Testing Baud rate: 38400 format: 30 *** Succeeded ***
Now Testing Baud rate: 38400 format: 4 *** Succeeded ***
Now Testing Baud rate: 38400 format: 2 *** Succeeded ***
Now Testing Baud rate: 38400 format: 3 *** Succeeded ***
Now Testing Baud rate: 38400 format: 801 *** Succeeded ***
Now Testing Baud rate: 9600 format: 0 *** Succeeded ***
Now Testing Baud rate: 38400 format: 0 *** Succeeded ***
Now Testing Baud rate: 115200 format: 0 *** Succeeded ***
Now Testing Baud rate: 1000000 format: 0 *** Succeeded ***
Now Testing Baud rate: 2000000 format: 0 *** Succeeded ***
Now Testing Baud rate: 2400 format: 0 *** Succeeded ***
Now Testing Baud rate: 300 format: 0 FAIL: 96 != 97 delta time: 24

Now Testing Baud rate: 38400 format: 30 *** Succeeded ***
...
Update:Looks like the Pull Request was pulled in :D

Figured out 300 baud won't work on T3.2 at 96mhz.
Serial1 uses F_CPU to calculate 13 bit baud divisor:
Code:
#define BAUD2DIV(baud)  (((F_CPU * 2) + ((baud) >> 1)) / (baud))
Which with 96mhz and 300 baud comes out to Divisor of: 320000 or 0x4E200 Which won't fit in 13 bits
 
Last edited:
I've updated the ADC library to support Teensy 3.4/3.5.
I've tested it on the Teensy 3.5 PROTO5 I have, however I have no access to the A10-A11 pins, could some of you with the PROTO6 board test those for me?
Download the latest version from github and run the example readAllPins.ino. Check if the pins A10 (column #10), A11 (column #10) and the differential results are correct.

Pedvide - Is there a better post than this for the Post_8 as the sticky link? This one doesn't have a link direct to the github. This one?: https://github.com/pedvide/ADC

I put the sample code Paul used for analog pin test in p_8 - seems there was one for digital pins / general hardware test?

Updated name refs to K66 as Teensy 3.6 on p_8

<edit> KurtE your Post link is out of date with the merge to cores of Serial6
 
Last edited:
exFat is possible but must be configured in ffconf.h (needs also lfn)
I found it sometimes useful with brand new 'camera' uSD's to simply reformat with PC

(Caveat: have no working K66, so my help is limited)

Sorry you lost your K66, I just touched mine with soldering iron for Serial6/ext pin headers, A10/A11 and a set of 6 GND, still works.

I'm not sure what his is telling me when LFN and exFAT is enabled?:: To enable the LFN, Unicode handling functions (option/unicode.c) must be added to the project.
I did the obvious things I saw in ffconf.h and got lots of errors.:: #define _USE_LFN 3, #define _LFN_UNICODE 1, #define _FS_EXFAT 1
> but I don't have a Unicode.c?

Long wait to do a FULL format on the 32GB SDHC - same results 30-32 Mbaud, It hadn't had much written since it was formatted last.

As far as the NEW card - that is the one that pulled 75 Mbaud out of the package that said it was "UP TO" 80 MB/s read speed and UHS-I: I think 75 is close enough. The 32GB should be UHS-I, it is marked HC1 not XC1 like the larger one - X .vs. H should be just a size indicator, it seems the 1 after the C suggests UHS1 class - but there is a UHS-50 and UHS-104 option on that for theoretical 50 .vs. 104 MB/s.

Well I have Serial6 headers so time to update my serial loop through test.

Paul/KurtE: This is missing from Yield.cpp::
Code:
#ifdef HAS_KINETISK_LPUART0
	if (Serial6.available()) serialEvent6();
#endif
 
Paul:
> Are these pins not exposed on the Proto_6 boards :: Wire3: I2C_PINS_42_43
> Are there no ALT pins for Ser2-Ser5 on T_3.6?

KurtE - I modified the bottom pin list in p_8 from Paul's post. SDHC pins removed as ports and pin numbers looked odd? Also: I don't see details on pins 52-57 after that edit.
 
Hi defragster, and Paul:

There are alternate pins for most if not all of the UARTS. If you look at my Excel document, you will see them marked sort of in a Salmon color.

Remember the UART numbers are one off for Serial. That is UART2_TX is the TX pin for Serial3. I believe I have all of them also in the source code. What I have not verified yet, is which ones should be the default pins for each of them.

When I updated my document for pin 40-57 in my document, you will see several of the new pins with RED pin numbers, I believe these are not on the current board: 40-47, 49, 50, 54

Note: my Excel document has the actual signal names, I have not translated them into the User Friendly names, nor into specific columns, but instead showing them in their ALT columns.

Details about these pins are up in the posting #756

Also note: the Pin card does not show all of the options, that each pin can do.

Also I wish that the Pin Card would Add a little more info for CS pins, that is I wish to know which ones are Alternates of each other. Would maybe Like: For pin 2, it is CS-0, and 6 is CS-1, 9 (CS-1), 10 (CS-0)...

So same program can not use pins 6 and 9 as unique CS pins...

As for SDCard pins: Paul, should I issue Pull Request to make them optional pins 58-63? Personally I think they are very useful, for those who may not need SDCard support in a project, they have great SPI1 support (CLK, MISO, MOSI, CS0-2), Serial1 and Serial3 alternate pins, I2C1 pins...

In my current Branches for these, I have support in for GPIO and SPI, I have not done the others yet, but will.
 
Last edited:
Well I have Serial6 headers so time to update my serial loop through test.

Paul/KurtE: This is missing from Yield.cpp::
Code:
#ifdef HAS_KINETISK_LPUART0
	if (Serial6.available()) serialEvent6();
#endif
Yes, forgot to add it there, I would probably make the #if look like:
Code:
#if defined(HAS_KINETISK_UART5) || defined (HAS_KINETISK_LPUART0)
To handle both boards.

Paul - is it semi-official that the board is now T3.6? (new Boards.txt file ?)

Thanks

Update: I added the code, and issued pull request: https://github.com/PaulStoffregen/cores/pull/160
Update2: Pull request was merged in.
 
Last edited:
Paul: Again not sure if you are interested in having the user be use the 6 pins for the SDCARD, but in case you might, I did do a Pull request for CORES and SPI projects
that have this capability working pretty well:
If you use the Sparkfun Sniffer, the Data pin closest to the board is 58, 59, 60, vcc, gnd, 61, 62, 63.

The two Pull requests gives you the ability for SPI1: SCK/MISO/MOSI CS0-2
Also Serial2 TX/RX/CTS/RTS
Serial4 TX/RX
GPIO: setPinMode(58, OUTPUT)...

I have not updated any libraries yet for I2C1 pins, nor have I looked at what other capabilities yet, like AtoD...

Should mention: I have tested GPIO, at least some pinMode, digitalRead, digitalWrite.
Test SPI1 with my ILI9341_t3n version, using all of the pins.
Test Serial2 and Serial4, using my Serial tester program. I verified on Serial1 I used pins TX/RX 10/9 58/59
And on Serial4 32/31 and 62/63

Kurt
 
Last edited:
Thanks Kurt - I saw the 'ALT' SDHC on port_D and that is what mislead me - as used they are on port_E per your sniffer card silkscreen. I think it would be good to have them as labeled pins - even if under ifdef - apparently too many pins can never be enough - and 6 pluggable pins on one port might be a good feature.

Indeed the XL sheet shows ALT UART pins on your MUX sheet - I was looking at the 'card' sheet.
 
Trying to update my Serial Loop Through and the pin# from Paul's Post

47
GND
3.3V
48 RX6
49 TX6

Doesn't match the Serial6 code?
CORE_PIN47_CONFIG = PORT_PCR_PE | PORT_PCR_PS | PORT_PCR_MUX(1); // Rx
CORE_PIN48_CONFIG = PORT_PCR_PE | PORT_PCR_PS | PORT_PCR_MUX(1); // Tx

Which is good because 49 isn't on the Proto_6 10 pin group and shown by KurtE

When I insert Serial6 into my looping between S5 and S4 I'm not seeing it work - even using Kurt's code as pulled from CORES.

I suppose I should start with a simpler test for function - but the posted pins info isn't in agreement now as noted.
 
Yes - Paul's table in that post, did not match the Pin table, that Paul updated in the code commit. ...

Just wanted to make it known. No doubt you saw it right to make it work - but I had a bit of difficulty finding pin 49 and 48 was the wrong direction.

Kurt - if you update your XL sheets please send me a copy. I want to hack my combo display sketch to bring in the serial and ethernet to see how many pins I can use, while doing some background stuff.
 
Paul - is it semi-official that the board is now T3.6? (new Boards.txt file ?)

Yes, semi-official at this point.

I'm preparing to post a 1.30-beta1 installer with the boards.txt file included. Which things should I import now? Is the latest i2c_t3 on github yet?
 
Just wanted to make it known. No doubt you saw it right to make it work - but I had a bit of difficulty finding pin 49 and 48 was the wrong direction.

Kurt - if you update your XL sheets please send me a copy. I want to hack my combo display sketch to bring in the serial and ethernet to see how many pins I can use, while doing some background stuff.
It is only half way updated. That is the first page I have only done the Serial, I2C, SPI pins, I have not scanned through to figure out I2S, Analog, PWM, ...
 
Is the latest i2c_t3 on github yet?

Sorry not yet, I'm in the middle of cleaning the examples and docs. However you can do an intermediate update if you want.

The main .cpp and .h files are in post #808 here: https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=110008&viewfull=1#post110008

Those have the pins configured as described by Kurt in the bottom of post #756 here: https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=109539&viewfull=1#post109539

If that pin information is still valid then just grab those main lib files and copy them over the old ones (some examples may not compile right, but T3.6 is fully supported - although it's referred to as T3.5). I'll try and expedite the update (I've got about 100 top priorities right now...).
 
Are there any plans to enable the LPUART in e.g. Snooze (it can run in VLPS)? Or will it be implemented as a regular UART?
 
I'm not sure what his is telling me when LFN and exFAT is enabled?:: To enable the LFN, Unicode handling functions (option/unicode.c) must be added to the project.
I did the obvious things I saw in ffconf.h and got lots of errors.:: #define _USE_LFN 3, #define _LFN_UNICODE 1, #define _FS_EXFAT 1
> but I don't have a Unicode.c?

Long wait to do a FULL format on the 32GB SDHC - same results 30-32 Mbaud, It hadn't had much written since it was formatted last.

As far as the NEW card - that is the one that pulled 75 Mbaud out of the package that said it was "UP TO" 80 MB/s read speed and UHS-I: I think 75 is close enough. The 32GB should be UHS-I, it is marked HC1 not XC1 like the larger one - X .vs. H should be just a size indicator, it seems the 1 after the C suggests UHS1 class - but there is a UHS-50 and UHS-104 option on that for theoretical 50 .vs. 104 MB/s.

I upgraded to CHaN's latest release (last patch 23-july) and compiled library examples with exFAt and consequently Unicode enabled
(has now again option subdirectory)

while compilation on A1.6.9 TD1.29b3 works fine (96 MHz optimized) I cannot test it myself.
In particular, I never worked with Unicode and have not found the right utilities in Arduino/Teensy that help with Unicode (read/write, compare etc)
So, any help is appreciated:
- does it work with fat32 and exfat?
- how to handle string write/read?
- are directory listings proper displayed?
 
KurtE - I see Serial6 working. Single port test with Tx wired to Rx.

60.5K Chars/sec :: Running at 4,000,000 baud I can send 241 characters plus a newline as fast as every 4ms. When serialEvent6() is called does readBytes of the available chars and then writes them to USB Serial.

Code is nothing fancy - starts sending out the alphabet 1 char at a time with a delay between. Whenever the alphabet is done it sends a newline and shows (characters read / time_taken) and restarts.

Delay between alpha letters starts at 700ms and sending 't' in USB drops to 50ms then reduces that down with each 't' toward 4ms.
Sending 'w' in USB adds ten 'period' chars after each alpha char, up to 240.

At less than 4Mbaud, delay() of 4ms was too fast to send again. I tried 6Mbaud and it doesn't work as well, even just one char after short waits gets krappy - thought the characters print to USB - it is not properly timed. Not sure what stops 6M from doing nearly as well as 4M - which I saw before at lower rates on the multiport linking.

I didn't test any of the other ports individually like this - just the cascading loop through that I didn't work out yet inserting Serial6 in the loop. But now I know I have a working Serial6 port. As a group they wouldn't run this fast - I'm not sure how such large prints work on one port with over flowing the buffers and only serialEvent taking out characters unless default priority on Serial causes this to happen in putchar()?
Code:
else if (priority >= 256) {
			yield(); // wait

But the priority starts set at 64? Does the priority get bumped lower or changed if the user doesn't do it? I see it updating the priority inside this while() as if it could change all the time, rather than just checking before the while.
Code:
	while (tx_buffer_tail == head) {
		int priority = nvic_execution_priority();
View attachment Only_qBlink_6.ino
 
Hi Epyon - I currently have it running as Serial6 as a normal Uart, I have not experimented at yet trying some of the other clocks and the like and trying to figure out which ones still work (or can be configured to work), in snooze or the like, nor other unique capabilities of it.

Defragster - Sounds like you did a pretty good test. With my testing, where I used a T3.5 to control it, I only tried as high as 2mbs. Also the max and min bauds it can do will depend on what CPU speed the processor is set to. Which Clock it chooses depends on CPU speed. It uses the PLLFLL stetting which was setup external and it figures out which clock setting from the register.

As for Priority stuff, I simply used the same stuff from the other Serial(x).c code. As I recall the code only bumps the priority if the queue is full and you are trying to output to the queue and it believes that your priority is such that it believes that it's interrupt handler may not be called, when the uart completes sending a character, which would then pull a character or characters out of the queue...

My guess is that we should make a pass through all of these and see if there are a few things that need fixing or cleaning up. For example yesterday I found two bugs in the Serial2/4 changes to enable the pins on the SDCARD, which I fixed as part of that optional Pull Request. Depending on if this Pull is taken or not, will create separate pull. Things like: Serial4.setTX (or was it RX), was using the wrong test (SIM_SCGC4 & SIM_SCGC4_UART2) Should have been UART3. Likewise Serial2.end(), will always reconfigure pins 9 and 10 to digital pin mode, regardless if the Uart was configured to use other pins like 26 and 31.

What I have not updated yet, is the inconsistencies of what happens when we reconfigure TX/RX pins when not to use them as Serial pins. That is if we have code like:
Code:
Serial1.begin(9600);
Serial1.setTX(5);
Serial1.setRX(21);
Serial1.end()
When we call the begin, it will configure pins 0, 1 into UART mode ALT(3). When we call the setRX or setTX, it will first configure the previous configured TX/RX pin to disabled ALT(0) and then set to new pin to Serail ALT(3). But when we call end, it sets the current pins to digital mode or ALT(1)... My gut tells me we should in both cases should either set to digital mode or disabled. Not sure which is better...

Kurt
 
Are there any plans to enable the LPUART in e.g. Snooze (it can run in VLPS)? Or will it be implemented as a regular UART?
Yes with new version 6 I can add a driver for this very easly for (VLPW i.e. "sleep" in Snooze). I'm moving right now so it will be in week or so.
 
Paul, Defragster and others:

I am doing a quick pass through my spreadsheet, trying to update the first page which is a copy of the "Card" (more or less). I have updated the SPI section to show which CS channel a CS pin is.

I just finished making pass through PWM markings. So far no changes for PWM, for the new pins and/or SDCard pins. That is I believe that the duplicates are pins: 13, 16, 17, 18, 19, 56, 57 and maybe 63. I am assuming that as part of this beta are not going to extend PWM support to allow ALTernate pins. Example 56 instead of 36 for FTM3_CH5.

Next up: Analog and I2S

Update: Analog - I think I need to recheck pins 40-45 as from the Analog code:
Code:
#elif defined(__MK64FX512__) || defined(__MK66FX1M0__)
	if (pin <= 13) {
		index = pin;       // 0-13 refer to A0-A13
	} else if (pin <= 23) {
		index = pin - 14;  // 14-23 are A0-A9
	} else if (pin >= 31 && pin <= 39) {
		index = pin - 19;  // 31-39 are A12-A20
	} else if (pin >= 40 && pin <= 41) {
		index = pin - 30;  // 40-41 are A10-A11
	} else if (pin >= 42 && pin <= 45) {
		index = pin - 21;  // 42-43 are A21-A22, 44 is temp sensor, 45 is vref
	} else {
		return 0;
	}
#elif defined(__MKL26Z64__)
I believe this is probably earlier pin mappings, so we may need to double check
 
Last edited:
K66 Ethernet and lwIP
I fixed the problems with tcp_write(), TCP sends 100 1000-byte "packets" at 59 mbs using window of 4*MSS.
See post #686 where I added a github link to the files required to "make" the lwIP tests. The test sketch just demonstrates the polling and callbacks needed for TCP and UDP client/servers. It's not clear how one would integrate lwIP build into IDE?? The sketch flash/ram memory usage is 52/40 KB plus heap usage for packet buffers (pbuf).

Good luck.
 
Last edited:
More on Analog Pins and updates for new pins:

If I look at the Analog pin mapping table:
Code:
#elif defined(__MK64FX512__) || defined(__MK66FX1M0__)
static const uint8_t channel2sc1a[] = {
	5, 14, 8, 9, 13, 12, 6, 7, 15, 4, // A0-A9
	3, 19+128,                        // A10-A11
// A10  ADC1_DP0/ADC0_DP3
// A11  ADC1_DM0/ADC0_DM3
	14+128, 15+128, 17, 18, 4+128, 5+128, 6+128, 7+128, 17+128,  // A12-A20
// A12  PTB10  ADC1_SE14
// A13  PTB11  ADC1_SE15
// A14  PTE24  ADC0_SE17
// A15  PTE25  ADC0_SE18
// A16  PTC8   ADC1_SE4b
// A17  PTC9   ADC1_SE5b
// A18  PTC10  ADC1_SE6b
// A19  PTC11  ADC1_SE7b
// A20  PTA17  ADC1_SE17
	23, 23+128, 26, 18+128  // A21-A22, temp sensor, vref
// A21  DAC0  ADC0_SE23
// A22  DAC1  ADC1_SE23
};
#endif
Things still are valid for A0-A20

But not sure about A21-A24, Probably still the DACs. Is there temp and vref on new boards?

Also with new pin definitions, I believe that pins 49 and 50 (which I don't believe are on Beta boards can be valid Analog pins as well?
Code:
49	B4	ADC1_SE10	ADC1_SE10	PTB4			ENET0_1588_TMR2	SDRAM_CS1-b	FTM1_FLT0
50	B5	ADC1_SE11	ADC1_SE11	PTB5			ENET0_1588_TMR3		FTM2_FLT0
Should they be added at end or before DAC? I believe they would be added as 10+128 and 11+128.

Also again if we use SDCard pins, E0-E3 can be analog pins as well,
Code:
58	PTE0	ADC1_SE4a	ADC1_SE4a	PTE0	SPI1_PCS1	UART1_TX	SDHC1_D1	TRACE_CLKOUT	I2C1_SDA	RTC_CLKOUT
59	PTE1	ADC1_SE5a	ADC1_SE5a	PTE1/LLWU_P0	SPI1_SOUT	UART1_RX	SDHC0_D0	TRACE_D3	I2C1_SCL	SPI1_SIN
60	PTE2	PTE2/LLWU_P1	ADC1_SE6a	PTE2/LLWU_P1	SPI1_SCK	UART1_CTS_b	SDHC0_DCLK	TRACE_D2		
61	PTE3	ADC1_SE7a	ADC1_SE7a	PTE3	SPI1_SIN	UART1_RTS_b	SDHC0_CMD	TRACE_D1		SPI1_SOUT
But I am not sure yet how having an a and a b of the same analog channel works yet. That is we already have A16 use ADC1_SE4b, so can we also use
ADC1_SE4a?

Hope that makes sense.
Kurt
 
Is there temp and vref on new boards?

Yes, temp sensor and VREF work on K66, see post 322. Paul patched analog.c to enable K66 VREF output. One could argue that these pins/channels should have symbolic names to hide the different numberings for each MCU.
 
Last edited:
Yes, temp sensor and VREF work on K66, see post 322. Paul patched analog.c to enable K66 VREF output. One could argue that these pins/channels should have symbolic names to hide the different numberings for each MCU.
Thanks,

I agree a symbolic name might be nice for the special ones. Also wondering if these analog channels are only on the Beta1/2 boards or will also be on the final boards.

Thanks again
 
Status
Not open for further replies.
Back
Top