K66 Beta Test

Status
Not open for further replies.
Last edited:
Does Audio work ?
"Nothing" works.. for me..neither DAC nor SPDIF output.
Can someone pls. try a simple sketch with DAC output ? Maybe its my fault..
 
I did TALKIE that goes out the DAC through Prop shield, and that worked. I'm hearing quality issues versus what I recall on T_3.2 - functional but more noise - and song not as nice to hear.

RE: EEPROM - could the TeensyTransfer be useful in automated or repeat testing? It can read a binary copy of the stored data and write it to a known state. Not that it isn't still just a sketch - or does anything in the sketch you couldn't do alone - and introduces the challenge of validating the binary data outside. But it would allow a 'PC' session to push known data and retrieve expected data and reset or unpower the device from outside and load alternate sketches. Of course the HID interface gets in the way of talking to the sketch (unless you hack the library) - and there is an handy SD card for keeping status and storing the image data - and using that would allow USB user input.
 
Does Audio work ?
"Nothing" works.. for me..neither DAC nor SPDIF output.
Can someone pls. try a simple sketch with DAC output ? Maybe its my fault..

both DAC's work for me. I used them to test ADC input, with just analogWrite(A21,128); or (A22)
and I did a DAC sine wave to my cheap scope, also measured a few values with voltmeter

Code:
float phase = 0.0;
float twopi = 3.14159 * 2;
elapsedMicros usec = 0;

void setup() {
  analogWriteResolution(12);
}

void loop() {
  float val = sin(phase) * 2047.0 + 2048.0;
  analogWrite(A21, (int)val);
  phase = phase + 0.02;
  if (phase >= twopi) phase = 0;
  while (usec < 500) ; // wait
  usec = usec - 500;
}

DAC still works to ADC in latest core.

oh , and my favorite, https://github.com/manitou48/teensy3/blob/master/dacadc.ino
 
Last edited:
This should (hopefully) fix all the EEPROM issues.

https://github.com/PaulStoffregen/cores/commit/575f3092091409f40b85f1e0079a826369820dd0

Please let me know how this works for you. Testing EEPROM well is tricky, because the memory state persists across uploads. I tested this on only a single board, so it's difficult to know if I've truly fixed all the EEPROM issues.

simple arduino EEPROM sketch worked, wrote 100 bytes (30134 us), read 100 bytes (42 us), values are still good after a power cycle.


Wow, you've fixed lots of things!!! .... and on the seventh day he rested
 
Last edited:
Re: internal ADC, regression test
Hmmm, analogRead(39) VREF output, is now giving (millivolts)
2534
2247
2285
me thinks it was giving 3300 type numbers before

and analogRead(38) only returns 65535 (it too was doing something sensitive to temperature before:confused:

ADC pins look good when pulled to ground:D

touch pins look good :D

and USB @180mhz works


EDIT: oops, i see from analog.c that VREF is analogRead(45), but i get 643 reading (7637 mv?),
and temp sensor is (44), but still getting 65535 ?

EDIT 2: temperature is OK (got rid of INTERNAL as reference)
data sheet says VREF output is 1195mv

EDIT 3: VREF out is still a mystery
FWIW, i hacked analog.c to use AD27 (bandgap) for analogRead(45), and adjusted the sketch
PMC_REGSC |= PMC_REGSC_BGBE;
and I get 3284 millivolts, which is good

EDIT 4: RESOLVED
use VREF_SC |= VREF_SC_VREFEN | VREF_SC_MODE_LV(1);
 
Last edited:
EEPROM confirmed work, writed some data and get back after a power cycle.
Tested Serials at various speed and all seems work (btw,not tried the lower speeds)
Noticed that SPI performances vs CPU clock are not as I expected, for example 180Mhz has better performances than 192Mhz, I know performances are still not taked in count, probably Divider/Divisor stuff, etc.
Spend some hours around SPI lib but too early, cannot find references to CORE_PIN47_CONFIG (currently stops at pin 39) and more.
I've noticed that Paul touched the Wire lib, I will test in a min...
 
Last edited:
Noticed that SPI performances vs CPU clock are not as I expected, for example 180Mhz has better performances than 192Mhz, I know performances are still not taked in count, probably Divider/Divisor stuff, etc.
.

SPI is clocked by F_BUS. for 180mhz, F_BUS is 60mhz; for 192MHz, F_BUS is 48mhz (ref kinetis.h)
 
Last edited:
The DMASPI example does not work.

yep, none of my DMA SPI sketches worked. though memory-to-memory DMA worked (no DMAChannel)

Code:
     1424.70 mbs  23 us   memcpy32  DMA
     2184.53 mbs  15 us   memcpy32p   DMA quad-word aligned
     1424.70 mbs  23 us   memset32      DMA
     204.80 mbs  160 us   loop copy
     1213.63 mbs  27 us   memcpy
     2520.62 mbs  13 us   memset
     360.09 mbs  91 us   set loop
as on the teensy 3, the C lib memcpy() does just fine

my DACDMA sketch (PDB-clocked DAC output from DMA buffer (sine) did not work (uses DMAchannel)
 
Last edited:
Noticed that SPI performances vs CPU clock are not as I expected, for example 180Mhz has better performances than 192Mhz

Yes, there is no linear relationship between F_CPU and F_BUS, since Freescale is a bit restrictive or over-cautios regarding F_BUS. Makes sense for industrial applications, perhaps.

BUT:
If you want _REALLY_ fast F_BUS use this:

Code:
void setup() {

  #if F_CPU <=144000000
  SIM_CLKDIV1 = (SIM_CLKDIV1 & ~(0x0F<<24)) | (0 << 24);
  #define F_BUS_NEW (F_CPU)
  #else 
  SIM_CLKDIV1 = (SIM_CLKDIV1 & ~(0x0F<<24)) | (1 << 24);
  #define F_BUS_NEW (F_CPU / 2)
  #endif
.
.
.

..this is a hack and not supported by the libraries, so you might have issues with speeds/times...

Edit: My "Fire"-Demo is running with 134FPS @ 240MHz with the "hack".. above..
 
Last edited:
A brief test indicates that all of these work:
analogWrite
pulseIn

When I add analogWriteFrequency(2,380.), the output from analogWrite(2,64) changes from 25% to 38.92% (ie, analogWriteFrequency appears not to work).

Checked by wiring pin 2 to pin 3 and:

float a,b;
a = pulseIn(3, HIGH);
b = pulseIn(3, LOW);
Serial.println(100 * a/(a+b));

Using pins 22 and 23 worked OK. Ah, I see the problem in the libary - the if statement involving the calculation of cval doesn't include FTM3.
 
Last edited:
I edited the Wire library to support several faster F_BUS speeds. Work is still needed in analogRead, SPIFIFO, i2c_t3, ADC, and IRremote which use lists of discrete values. Most other uses of F_BUS have equations that scale automatically.
 
Re: DMA SPI and MUX
Looking at ref manual table 23-1, DMA MUX request sources for K66, I don' t think kinetis.h has the correct numbers: e.g., ref manual says SPIO TX is 15, but kinetis.h says 14
K64 has same problem.
these may not be correct:
#define DMAMUX_SOURCE_I2C0 18
#define DMAMUX_SOURCE_I2C2 18
#define DMAMUX_SOURCE_I2C1 19
#define DMAMUX_SOURCE_I2C3 19


my spiDMA sketch ran if i used the correct SPI0 TX MUX source number (although rate times are not right, so there may be other issues ... TODO)
 
Last edited:
I edited the Wire library to support several faster F_BUS speeds. Work is still needed in analogRead, SPIFIFO, i2c_t3, ADC, and IRremote which use lists of discrete values. Most other uses of F_BUS have equations that scale automatically.

I've added analogRead. I'm adding them now to SPIFIFO.
 
Good news :)
But which rate times ? :confused:

the duration of the SPI-DMA transfer fluctuates and is insensitive to buffer size (sketch works on T3.2), so it's under study ...
fixing DMA MUX values in kinetis.h did not fix my DmaSpi sketch, it still hangs
 
Status
Not open for further replies.
Back
Top