K66 Beta Test

Status
Not open for further replies.
Ok, I think I found the bug. If you can test it again as before it should work now.

Code:
A11 to GND, A10 to 3.3v
A0: 2.58. A1: 2.15. A2: 1.92. A3: 1.94. A4: 1.79. A5: 1.64. A6: 2.20. A7: 2.03. A8: 2.14. A9: 2.26. A10: 3.30. A11: 0.01. A12: 1.44. A13: 1.53. A14: 2.87. A15: 2.42. A16: 2.36. A17: 2.16. A18: 2.08. A19: 2.11. A20: 2.33. A21: 2.45. A22: 1.81. 
Differential pairs: 0: 3.30. 

A0: 2.59. A1: 2.15. A2: 1.93. A3: 1.95. A4: 1.81. A5: 1.73. A6: 2.16. A7: 1.89. A8: 2.14. A9: 2.26. A10: 3.30. A11: 0.01. A12: 1.38. A13: 1.50. A14: 2.87. A15: 2.43. A16: 2.41. A17: 2.24. A18: 2.16. A19: 2.10. A20: 2.33. A21: 2.43. A22: 1.82. 
Differential pairs: 0: 3.30. 




A10 to GND, A11 to 3.3v
A0: 1.73. A1: 2.03. A2: 1.98. A3: 1.82. A4: 1.86. A5: 1.73. A6: 2.29. A7: 2.17. A8: 2.06. A9: 2.21. A10: 0.01. A11: 3.30. A12: 2.61. A13: 2.01. A14: 1.64. A15: 1.94. A16: 2.47. A17: 2.15. A18: 2.02. A19: 2.04. A20: 2.21. A21: 2.17. A22: 1.76. 
Differential pairs: 0: -3.30. 

A0: 1.73. A1: 2.14. A2: 2.08. A3: 2.03. A4: 1.98. A5: 1.75. A6: 2.33. A7: 2.24. A8: 2.11. A9: 2.29. A10: 0.01. A11: 3.30. A12: 2.67. A13: 1.90. A14: 1.64. A15: 1.89. A16: 2.47. A17: 2.17. A18: 2.02. A19: 2.03. A20: 2.21. A21: 2.24. A22: 1.76. 
Differential pairs: 0: -3.30.
 
Updated to latest ADC, connected up A10 and A11 to a couple resister dividers
+3.3 22K A10 22k GND -> 1.66v (looks good)
3.3 22K A11 47K GND -> 2.25v (looks good)
differential -.54

If I jumper A11 to 0 or 3.3v shows 1.66 or -1.66

Code:
A0: 1.79. A1: 1.58. A2: 1.60. A3: 1.13. A4: 1.19. A5: 1.26. A6: 1.79. A7: 1.64. A8: 1.54. A9: 1.45. A10: 1.64. A11: 2.25. A12: 2.39. A13: 1.99. A14: 1.60. A15: 1.40. A16: 2.14. A17: 1.89. A18: 1.80. A19: 1.81. A20: 1.90. A21: 1.19. A22: 1.55. 
Differential pairs: 0: -0.54.
 
Last edited:
Ok, great!
Thanks a lot manitou and KurtE!
There are a few (internal) details still unfinished, but that's all I needed!
 
Paul, Do you have sort of a prioritized list of things you would like tested or converted or extended?

For example I believe we now have Serial1-5 working well? Does it look promising that the pads will be in place for Serial6? If so should I take a shot at LPUART?

Have SPI and I believe working SPI1, although I don't believe my changes have been merged in yet. The merge also added the defines for SPI2 in the main header file. Have not gone beyond that yet, waiting until we know if SPI2 pads will be exposed.

I2C - I believe we have ability to use multiple ones? Need more testing?

SD, USB - I don't have much experience on programming these, but can run tests, and maybe help debug...

Or, should I try doing some random things, like, grab random devices, like different display, or sensors and see if they compile and appear to work...

Suggestions?
 
I was thinking along the same line (that is why I printed SDHC_BLKATTR after read)
Will continue with your single assignment version

Edit: sdhc-test and uSDFS are corrected to use multi-sector operations correctly

EDIT: removed shdc_test from GitHub as functionality is in uSDFS

I "unported" your driver to run on mbed K64F (120mhz). Unsurprisingly, low-level sector read tests ran just fine on the K64. @40 mhz baud, single sector took 280us (14.6mbs), and 4-sector took 439us (37.3mbs) using same SanDisk 8GB.

It would also read 5 sectors when requesting 4 if the original or'ing was used (SDHC_BLKATTR |= SDHC_BLKATTR_BLKCNT(count) ). I thought it might be a compiler thing, but mbed uses ARM gcc. so why the mask/or stuff doesn't work is still a mystery.

(PTE* SPI pins are accessible on mbed K64 and their SDFileSystem library supports it, so with SPI1 clock at 30mhz, a 512-byte file read takes 1504us (2.7mbs), SPI SD library does not use DMA/FIFO)

(I haven't yet tried to figure out why f_read() fails ...)
 
Last edited:
I ran the example (you need Serial.printf for printf in die()), commented out write/read, and got directory listing OK. then tried to read my RAW.DAT, but sketch hung on

rc=f_read(&fil,(void *)sector,sizeof(sector),<h);

Maybe file structure that wrote RAW.DAT different from uSDFS?? further study required...

EDIT: I can read TST.C with f_gets() -- is my semantics for f_read() wrong ??

Oooops, pilot error, f_read() works just fine (one shouldn't use "()" to define a vector, DUH. I must have had a FORTRAN-moment.)

295us (13.9mbs) for one-sector (512 byte) read from file (bout same as underlying 1-sector read time)
Reading 4*512 bytes in a single f_read() takes 396us (41.4 mbs)

4-bit SDIO vs SPI
By comparison using teensy SD.h (SPI clock 30 mhz) for file IO read of 512-byte block, it takes 456us (9mbs) (K66 CPU 120mhz)
 
Last edited:
Indeed an over view of what to test and what is thought to work might be helpful - I just randomly did what I have on hand with some usage experience - and tried to leave a testable sketch for someone to debug what I don't know about - the audio playing (from SerFlash) - and brought the HSRUN on EEPROM access issue to Paul's attention - and beat on Serial#'s to find them working. I've done more soldering the past weeks than many prior months combined - and all the years before 2015.

KurtE - from my test Serial5 is a useful part of the K66. It has anything coming in USB sent to Serial1 wired Rx through Serial5.write() into serialEvent5() pulled that in for parsing user commands. And all the sketch output - somewhat copious at 15-25K chars/second was directed to Serial5.print all test under 1Mbps but mostly at 2-3.2 Mbps - that then looped #4>#3>#2 where it was then reliably posted to USB. I could re-roder the looping to put S#5 in the middle -

Since that testing only needed four jumper wires on 8 pins the I2C ports are open ( all 3 non-conflicting #0=37,38, #1=37,38 and #2=3,4) - but I left my SSD1306 displays downstairs - so I went back to the EEProm test writing at low speed to make it ready to hit high speed when the needed clock speed shifting is done. I need to make my EEprom looping a bit more generic and specific - then I can run it on a T_3.2 to see if my observed odd timing issues are unique to the K66 - and also generate CSV usable data output to see what the trends really show. Having one or two SSD1306's there for details won't hurt and will get them tested too.

I also have a onehorse Bubble Display Frontpack I2C RAM mapped display with parts to solder up with code to test. So once I have usable EEPROM test code as I see it - I'll work in some I2C's.

Very cool the SDHC is coming online! That for an independent very high speed I/O bus to non-volatile big data will be handy!
 
Last edited:
On K66 I got a working I2C Adafruit_SSD1306 on I2C_0 == SCL0/SDA0. { SSD1306_128_64 }

Looking at getting it working on I2C_1 == SCL1/SDA1 I got as far as i2c_t3.h for Wire1. But looking at that it doesn't have altered definitions from T_3.1 using I2C1== i2c_pins == I2C_PINS_29_30 where T_3.5 needs:: I2C_PINS_37_38 [ and perhaps I2C_PINS_4_3 ].

I hacked the Adafruit_SSD1306 to use Wire1 with "#define Wire Wire1" and have my K66 look alike T_3.1 running on those pins 29_30

This special case was modified for T_3.4/T_3.5 but specifies unusable pins - am I missing something is there another way around - or finding an area needing to be fixed?:
#if (I2C_BUS_NUM >= 2) && (defined(__MK20DX256__) || defined(__MK64FX512__) || defined(__MK66FX1M0__)) // 3.1-3.2/3.4/3.5
,{&I2C1_A1, &I2C1_F, &I2C1_C1, &I2C1_S, &I2C1_D, &I2C1_C2,
&I2C1_FLT, &I2C1_RA, &I2C1_SMB, &I2C1_A2, &I2C1_SLTH, &I2C1_SLTL,
{}, 0, 0, {}, 0, 0, I2C_OP_MODE_ISR, I2C_MASTER, I2C_PINS_29_30, I2C_PULLUP_EXT, I2C_RATE_100, I2C_STOP, I2C_WAITING,
0, 0, 0, 0, I2C_DMA_OFF, nullptr, nullptr, nullptr, 0}

And this that ties the T_3.5 to those pins in pinConfigure_:
#if I2C_BUS_NUM >= 2
if(bus == 1)
{
#if defined(__MK20DX256__) || defined(__MK64FX512__) || defined(__MK66FX1M0__)// 3.1
if(pins == I2C_PINS_26_31)
 
Oooops, pilot error, f_read() works just fine (one shouldn't use "()" to define a vector, DUH. I must have had a FORTRAN-moment.)

295us (13.9mbs) for one-sector (512 byte) read from file (bout same as underlying 1-sector read time)
Reading 4*512 bytes in a single f_read() takes 396us (41.4 mbs)

f_write seems to work only if there are single cluster writes (buffer sizes up to 2*512-1)
e.g: buffersize = 7*128 is fine, but buffersize=8*128 crashes

NOTE crashes seems to mean USB crashes (loose COM port, need to disconnect USB hub for new upload, button press is not sufficient)
Filesystem my corrupt USB, or vice versa
Still investigating
 
Paul, Do you have sort of a prioritized list of things you would like tested or converted or extended?


Have SPI and I believe working SPI1, although I don't believe my changes have been merged in yet. The merge also added the defines for SPI2 in the main header file. Have not gone beyond that yet, waiting until we know if SPI2 pads will be exposed.


Suggestions?

I don't think christoph has received a beta board yet. You might try his DmaSpi library with your SPI1. library supports SPI1 on LC, so it might just work. I think DmaSpi worked for me on K66 (using SPI0).

EDIT: it looks like library will need to have a class DmaSPI1 defined for KINETISK
 
Last edited:
On K66 I got a working I2C Adafruit_SSD1306 on I2C_0 == SCL0/SDA0. { SSD1306_128_64 }

Looking at getting it working on I2C_1 == SCL1/SDA1 I got as far as i2c_t3.h for Wire1. But looking at that it doesn't have altered definitions from T_3.1 using I2C1== i2c_pins == I2C_PINS_29_30 where T_3.5 needs:: I2C_PINS_37_38 [ and perhaps I2C_PINS_4_3 ].

I hacked the Adafruit_SSD1306 to use Wire1 with "#define Wire Wire1" and have my K66 look alike T_3.1 running on those pins 29_30

This special case was modified for T_3.4/T_3.5 but specifies unusable pins - am I missing something is there another way around - or finding an area needing to be fixed?:


And this that ties the T_3.5 to those pins in pinConfigure_:
It looks like it is off to me, like it needs to be fixed: it should be special cased like the LC for pins 37 and 38 and it should be for ALT2 not ALT6.
If you want I can take a look at it.

Edit: Forgot to mention, that it looks like it should be extended for pins 4_3, but that should be for Wire2...
 
Last edited:
Random Testing: Trying out 2.2" TFT display (ILI9340)

Tried Adafruit_ILI9340 library with graphictest using default wiring. Appears to work.
Code:
Adafruit 2.2" SPI TFT Test!
Benchmark                Time (microseconds)
Screen fill              1472608
Text                     91341
Lines                    898389
Horiz/Vert Lines         121168
Rectangles (outline)     77853
Rectangles (filled)      3057596
Circles (filled)         470819
Circles (outline)        392656
Triangles (outline)      284926
Triangles (filled)       1016970
Rounded rects (outline)  171763
Rounded rects (filled)   3340025
Done!

Tried TFT_ILI9340 library (Sumotoy) - Does not compile (I am using the latest stuff off of github)...
Edited #if defined statements in library now compiles and runs
Code:
Benchmark                Time (microseconds)
Screen fill              435229
Text                     20885
Lines                    196627
Horiz/Vert Lines         35525
Rectangles (outline)     22592
Rectangles (filled)      903562
Circles (filled)         124462
Circles (outline)        86013
Triangles (outline)      62362
Triangles (filled)       292699
Rounded rects (outline)  41672
Rounded rects (filled)   982471
Done!

Only tested on default pins... Can issue pull request if desired. But my changes are simply changing all lines like this:
Code:
-#if defined(__MK20DX128__) || defined(__MK20DX256__)
+#if defined(KINETISK)
Note: looks like it does not support LC. Not sure if anyone is using this library much if it is worthwhile trying to adapt to be able to use SPI1 as well?

Edit: I may want to do another edit of the main spi.cpp as I believe pin #26 is a valid CS pin (CS0) for SPI... Would need to add it both as a valid pin and also in the two pin test, that you are not using it with either 2 or 10...
 
Last edited:
f_write seems to work only if there are single cluster writes (buffer sizes up to 2*512-1)
e.g: buffersize = 7*128 is fine, but buffersize=8*128 crashes

NOTE crashes seems to mean USB crashes (loose COM port, need to disconnect USB hub for new upload, button press is not sufficient)
Filesystem my corrupt USB, or vice versa
Still investigating

preliminary conclusion:

There are interferences of filesystem (f_read/f_write) with other functionality of K66 (especially USB)
So, I introduced work around in file-system interface (diskio.c) to force single sector read/write. (resulting in somewhat slower operation)
Noted further that filesystem should not be operated from interrupt level higher than normal (i.e lower nvic level than 8*16)

under examples there is a logger_test where the interested user can play.

e.g.
F_CPU = 240 MHz
timer frequency: 150, buffer size: 16*128, nvic level 8*16: Success
timer frequency: 150, buffer size: 16*128, nvic level 7*16: FAIL
but
timer frequency: 150, buffer size: 15*128, nvic level 7*16: SUCCESS
timer frequency: 100, buffer size: 16*128, nvic level 7*16: SUCCESS

These cases may differ from MCU to MCU and depending on host computer, especially if USB is involved

Note: I used Samsung 32 Gig class 6, (only free uSD with FAT32), so uSD card may be also a factor.

Edit: updated GitHub
Edit: fixed compile error in diskio.c

UPDATE: nvic level error is most likely due to USB interaction (regular interrupt every 1 ms ?)

replacing SERIAL by SERIAL1
timer frequency: 150, buffer size: 16*128, nvic level 7*16: SUCCESS

IMO: USB related issues are increasingly visible with always faster MCU's

Edit: using Serial1 does not solve multi-sector I/o issue

Edit: fixed another diskio interface bug.
 
Last edited:
Tried TFT_ILI9340 library (Sumotoy) - Does not compile (I am using the latest stuff off of github)...
Edited #if defined statements in library now compiles and runs
Code:
Benchmark                Time (microseconds)
Screen fill              435229
Text                     20885
Lines                    196627
Horiz/Vert Lines         35525
Rectangles (outline)     22592
Rectangles (filled)      903562
Circles (filled)         124462
Circles (outline)        86013
Triangles (outline)      62362
Triangles (filled)       292699
Rounded rects (outline)  41672
Rounded rects (filled)   982471
Done!

Wonder how that compares to a Teensy 3.2
 
It looks like it is off to me, like it needs to be fixed: it should be special cased like the LC for pins 37 and 38 and it should be for ALT2 not ALT6.
If you want I can take a look at it. ...

Thanks KurtE Looks like you saw what I saw with Wire2 == I2C_PINS_4_3 and Wire1 == I2C_PINS_37_38.

Looks like a dozen uses of I2C_PINS_37_38 to #ifdef. The only thing that looks like more than just copy and edit will be the MUX(?) settings in function pinConfigure_().

I can't say I'll do it in a day or two - but seems wasn't holding anyone up yet or underway on anyone else's plate?

If the SSD1306 on I2C is a good representative device I can use it to start (that I can see working:) ). That and the scanner example with the Adafruit library that I found hacks to Wire1, and hopefully the onehorse bubble display sketch will port over to Wire1/Wire2 easily.

Kurt(Paul/?): Am I inferring correctly that all three K66 I2C ports will be MUX(2) when you say "not ALT6"? That is the part I won't see without some RTFM or guidance.
Code:
pinConfigAlt2 = (pullup == I2C_PULLUP_EXT) ? (PORT_PCR_MUX(2)|PORT_PCR_ODE|PORT_PCR_SRE|PORT_PCR_DSE)
                                                        : (PORT_PCR_MUX(2)|PORT_PCR_PE|PORT_PCR_PS);

The other thing I took note of was that the K66/K64 seems to have LC interrupt detect, unlike T_3.1 : "//TODO: 3.4 & 3.5 have stop detect interrupt", so those special LC cases will be modelled instead of the T_3.1 workaround.

Quick Add - OMG - As I was forking - I just read the README.md - there are some good details there! I also happen to have a fresh "MPU-9250 9DoF with AHRS sensor fusion" from onehorse that I can test with as it already uses Wire1.

@NOX771 - have you gotten your K66 board? Were you planning to work on the i2c_t3?
 
Last edited:
Edit: I may want to do another edit of the main spi.cpp as I believe pin #26 is a valid CS pin (CS0) for SPI... Would need to add it both as a valid pin and also in the two pin test, that you are not using it with either 2 or 10...
Adding code to allow pin 26 as CS pin, but wonder:
Code:
bool SPIClass::pinIsChipSelect(uint8_t pin)
{
	if (pin == 10 || pin == 9 || pin == 6 || pin == 2 || pin == 15) return true;
	if (pin >= 20 && pin <= 23) return true;
	return false;
}

bool SPIClass::pinIsChipSelect(uint8_t pin1, uint8_t pin2)
{
	if (!pinIsChipSelect(pin1) || !pinIsChipSelect(pin2)) return false;
	if ((pin1 ==  2 && pin2 == 10) || (pin1 == 10 && pin2 ==  2)) return false;
	if ((pin1 ==  6 && pin2 ==  9) || (pin1 ==  9 && pin2 ==  6)) return false;
	if ((pin1 == 20 && pin2 == 23) || (pin1 == 23 && pin2 == 20)) return false;
	if ((pin1 == 21 && pin2 == 22) || (pin1 == 22 && pin2 == 21)) return false;
	return true;
}
To add pin 26 to this, I would need to add tests for 2/26, 26/2, 10/26, 26/10, which is all doable, but wonder if it would make sense, to change both functions like:
Code:
bool SPIClass::pinIsChipSelect(uint8_t pin)
{
	switch (pin) {
	  case 10: return 0x01; // PTC4
	  case 2:  return 0x01; // PTD0
	  case 9:  return 0x02; // PTC3
	  case 6:  return 0x02; // PTD4
	  case 20: return 0x04; // PTD5
	  case 23: return 0x04; // PTC2
	  case 21: return 0x08; // PTD6
	  case 22: return 0x08; // PTC1
	  case 15: return 0x10; // PTC0
#if defined(__MK64FX512__) || defined(__MK66FX1M0__)
	  case 26: return 0x01;
#endif
	}

    return 0;
}

bool SPIClass::pinIsChipSelect(uint8_t pin1, uint8_t pin2)
{
	uint8_t pin1_mask, pin2_mask;
	if ((pin1_mask = pinIsChipSelect(pin1)) == 0) return false;
	if ((pin2_mask = pinIsChipSelect(pin2)) == 0) return false;
	if ((pin1 & pin2) != 0) return false;
	return true;
}
 
Thanks KurtE Looks like you saw what I saw with Wire2 == I2C_PINS_4_3 and Wire1 == I2C_PINS_37_38.
Yep...

Kurt(Paul/?): Am I inferring correctly that all three K66 I2C ports will be MUX(2) when you say "not ALT6"? That is the part I won't see without some RTFM or guidance.
Code:
pinConfigAlt2 = (pullup == I2C_PULLUP_EXT) ? (PORT_PCR_MUX(2)|PORT_PCR_ODE|PORT_PCR_SRE|PORT_PCR_DSE)
                                                        : (PORT_PCR_MUX(2)|PORT_PCR_PE|PORT_PCR_PS);
The other thing I took note of was that the K66/K64 seems to have LC interrupt detect, unlike T_3.1 : "//TODO: 3.4 & 3.5 have stop detect interrupt", so those special LC cases will be modelled instead of the T_3.1 workaround.
Which Alt will which pins, from my Excel document:
Pin 3/ALT5=I2C2_SCL
Pin 5/Alt5=I2C2_SDA
Pin 7/Alt7=I2C0_SCL
Pin 8/Alt7=I2C0_SDA
16/2=0_SCL
17/2=0_SDA
18/2=0_SDA
19/2=0_SCL
26/5=2_SCL
33/5=0_SCL
34/5=0_SDA
37/2=1_SCL
38/2=1_SDA

Possibly others if access to SD Card pin and likewise the possible 8 pins on the table.

Let me know if you get a chance to play with it, otherwise I also have a few I2C sensors I was going to try out, like BNO055 IMU, maybe other ping like sensors.
 
Adding code to allow pin 26 as CS pin, but wonder:
Code:
bool SPIClass::pinIsChipSelect(uint8_t pin)
{
    if (pin == 10 || pin == 9 || pin == 6 || pin == 2 || pin == 15) return true;
    if (pin >= 20 && pin <= 23) return true;
    return false;
}

bool SPIClass::pinIsChipSelect(uint8_t pin1, uint8_t pin2)
{
    if (!pinIsChipSelect(pin1) || !pinIsChipSelect(pin2)) return false;
    if ((pin1 ==  2 && pin2 == 10) || (pin1 == 10 && pin2 ==  2)) return false;
    if ((pin1 ==  6 && pin2 ==  9) || (pin1 ==  9 && pin2 ==  6)) return false;
    if ((pin1 == 20 && pin2 == 23) || (pin1 == 23 && pin2 == 20)) return false;
    if ((pin1 == 21 && pin2 == 22) || (pin1 == 22 && pin2 == 21)) return false;
    return true;
}
To add pin 26 to this, I would need to add tests for 2/26, 26/2, 10/26, 26/10, which is all doable, but wonder if it would make sense, to change both functions like:
Code:
bool SPIClass::pinIsChipSelect(uint8_t pin)
{
    switch (pin) {
      case 10: return 0x01; // PTC4
      case 2:  return 0x01; // PTD0
      case 9:  return 0x02; // PTC3
      case 6:  return 0x02; // PTD4
      case 20: return 0x04; // PTD5
      case 23: return 0x04; // PTC2
      case 21: return 0x08; // PTD6
      case 22: return 0x08; // PTC1
      case 15: return 0x10; // PTC0
#if defined(__MK64FX512__) || defined(__MK66FX1M0__)
      case 26: return 0x01;
#endif
    }

    return 0;
}

bool SPIClass::pinIsChipSelect(uint8_t pin1, uint8_t pin2)
{
    uint8_t pin1_mask, pin2_mask;
    if ((pin1_mask = pinIsChipSelect(pin1)) == 0) return false;
    if ((pin2_mask = pinIsChipSelect(pin2)) == 0) return false;
    if ((pin1 & pin2) != 0) return false;
    return true;
}


I quote this, looks better!
 
I'll give NOX771 time to reply about (his?) i2c_t3 library now that he has a Beta batch #2 board and look back at my EEPROM tester until tomorrow, I put multiple access methods in the group of 163 and I suspect I should break them out into individual passes as some are likely more efficient than others and knowing which will help decide what needs to be looked at.

... Which Alt will which pins, from my Excel document:
. . .

KurtE - would like to see your XL sheet - is this where you got that info: 11.3.1 K66 Signal Multiplexing and Pin Assignments (pg 184 K66)?

I see columns for the package pins with info like this :
ALT6 >> I2C1_SDA / I2C1_SCL
ALT2 >> I2C3_SDA / I2C3_SCL
ALT5 >> I2C0_SCL / I2C0_SDA
ALT4 >> I2C3_SDA / I2C3_SCL
ALT5 >> I2C2_SDA / I2C2_SCL
ALT2 >> I2C0_SCL / I2C0_SDA
. . .

Am I right assuming the ALT#==MUX(#) defining the mode of operation for that pin? When doing Alt Serial2 pins I think I got halfway there but didn't see this table for the T_3.2 and got the wrong impression that MUX(2) meant 'use as serial.' - not that it just happened to be that those pins [Serial1 and Serial2 - primary and secondary] supported serial when set to the same MAX(2).

BTW KurtE: - fun again with github I think I got resolved - I forked i2c_t3 - but MASTER not the right branch for K66 . . . after removing on windows and selecting on github in my fork then re-Desktop'ing I see the right files.
 
As for my SPI pinIsChipSelect code above, couple of issues.
if ((pin1 & pin2) != 0) return false;
Should have been:
if ((pin1_mask & pin2_mask ) != 0) return false;
Or simply (pin1_mask != pin2_mask)

The other issue us trying to return specific values through a bool. It appears that all not zero values are returned as 1.
If I change the function to return uint8_t instead of bool, then the code works.
Not sure if anyone would object to changing it?

Otherwise will go back to other way. Alternative is to add helper method pinIsChangeSelect_internal, which returns uint8_t I use in both cases
and add a pinIsChipSelect, which calls it and returns bool. Method could be inline...

Anyway testing with ILI93xx and it working with the 2.2" display with SPI. Don't think SPI1 is enabled yet...
 
Status
Not open for further replies.
Back
Top