K66 Beta Test

Status
Not open for further replies.
Nice. DMA is nice. F_CPU @ 120mhz, I ran it and saw 17.46 mbs (assuming it's really reading data :D)

EDIT: i read my known sector from my microSD card -- data is good

EDIT 2: I tried reading 4 sectors at a time ... nope.

I played a little bit and could also not read more than 1 sector, also changing to single bit transfer did not degrade by a factor of 4, etc. So there is a playground.
(I was using class10 64 and 128 gig SanDisks). Will try to get a faster disk.
I noticed that non-virgin part of the disk are slower and have more random read times than sectors that were never used (I believe).
Max speed I achieved was 26.7 Mbit/s (using 80 Mhz sdhc speed (240/3))

I know, that is above spec, but curiously, throughput does not scale but seem limited by uSD card.

Noted further that in Aduino Menu only the optimized code did compile/run correctly the other speed settings generated weird Serial.printf values.
 
Oh.. what does THIS mean ?: https://github.com/WMXZ-EU/sdhc_test/blob/master/sdhc.c#L55
"// Switch of MPU unit (maybe bug of silicon)"

and ..

"// De-init GPIO - to prevent unwanted clocks on bus"

OK, I copied the code, but as I understand:

MPU: there is a errata from freescale http://cache.freescale.com/files/microcontrollers/doc/errata/KINETIS_2N03G.pdf
it is for K60 but maybe valid for K66. In fact, sdhc code was from K60
something to play with.

De-Init GPIO
this is to avoid GPIO interferences while setting baud rate.
 
usbMIDI works @180MHz with sendProgramChange and sendNoteOn (and implicitly a note off with a velocity of zero).
I haven't tried receiving MIDI though.

+edit
OneWire also works @180MHz with two DS18B20 on pin 8. Both parasite and non-parasite mode work and can be detected.

Pete
 
Last edited:
The 6 SDHC signals (which are native pins PTE0 to PTE5) will route only to the micro SD socket on the board. ...
Those signals aren't going to route anywhere else, partly because all the PCB real estate is already (over) committed to other stuff, but mostly because they're a 4 bit data + 1 bit command bus which runs at 48 MHz. Longer wires routing to multiple places, and especially even longer user connections to a breadboard or other stuff are definitely not something we want connected to that high speed bus.
Makes total sense.

Actually what I was wondering if would make sense, is if someone made a simple board like: (Hope this picture is OK...)
MicroSD_Adapter_3d.jpg
I did a somewhat quick layout in diptrace. Not sure if slot is exact or not, but probably close enough. Also not sure if any of you can get one thin enough. The smallest thickness I see at Seeedstudio is .6mm, I know the OSHPark ones are typically 1.6mm...

But assuming this could work then those who don't need SDCard could maybe have access to those pins.
 
The smallest thickness I see at Seeedstudio is .6mm, I know the OSHPark ones are typically 1.6mm...

Micro SD nominal thickness is 0.7mm, the little bump on the end is 1mm, but a flat 0.6mm will work with the slot.

Assuming the lines will not be impedance controlled, you generally want traces to be shorter than about 1/10th of the signal wavelength. A digital signal of 48MHz needs to behave well up to at least the fifth, better the seventh harmonic for good signal integrity, so 48MHz * 7 = 336 MHz, that corresponds to a wavelength of about 60cm (because signal speed is only about 2/3 of c_vacuum on PCBs). 1/10 of that is 6 cm, so I guess a small breakout will work, but anything on a breadboard will be unreliable and may even create unwanted antennas.
 
I hope it's useful to you; no idea how well it works at 50 MHz. We were doing much slower SPI stuff with it, maybe 4 MHz which was fine.
 
@Paul, is there a PULLUP on the CS for the SD-slot ?
Otherwise i'd enable the pin-pullup as early as possible in mk20dx128
 
To test Serial I chained pins together and used six serialEvent?()'s to pass the data along. sketch debug prints are Serial5>s4>s3>s2>USB and incoming USB==s1>s5 [parse program input]. { pins>1-34,33-31,32-7,8-9 }

Started with const uint32_t sharedBaud = 460800; and moved that up to 921600 and it is working - and also at 1843200.

A bit bulky with a tight while(available()){write(read() )}; when single char is transmitted every 4 ms - the buffers cascade and block in large groups to USB. All data runs as expected.
 
Thanks for the board!
I'm testing the ADC library and is going well, but I can't find A10-A11!
I'm using Paul's code in #333, so simply displaying the value of each pin.
In my board the numbers are offset by two; that is, what is marked as A10 (pin 31) is actually A12, an so on. This agrees with pins_arduino.h
However that means I don't know where A10-A11 are! Their pin numbers are 41 and 42, which aren't in my board.
Some of you have successfully tested anaogRead(), can you help me?

Thank you
 
I'm testing the ADC library and is going well, but I can't find A10-A11!

Does your board say PROTO5 or PROTO6 on the bottom side? Almost all of them are version 6.

Version 5 didn't have A10, A11 and AREF broken out to pads, and pins 31-39 are incorrectly labeled A10 to A18. Of course these should be A12 to A20, matching the pinout table in msg #93.

Version 6 has those 3 extra pins on the left side and in the same locations as Teensy 3.2, and the silkscreen is fixed. Version 6 is also only a 2 layer board (all earlier ones were 4 layers).
 
Last edited:
EDIT 2: I tried reading 4 sectors at a time ... nope.

I believe, I found the issue (waiting for DMA to be ready), corrected in sdhc.c ( https://github.com/WMXZ-EU/sdhc_test )
modified test program to check if data are real read: I believe so.
(will not tell you performance, so find it out)

Found a small issue: number of sectors is always an odd number (setting 4 or 5 will read 5 sectors)
If this is a K66 bug or bad programming, I do not know yet.

next TODO: remove locked wait for DINT but use sdhc_isr for asynchron sdhc access.

EDIT sdhc_test removed from GitHub. functionality is now part of uSDFS
 
Last edited:
Playing a little with floating point to see the differences of using float versus double also 3.5 vs 3.2...

Sort of a quick extract/hack from some hexapod gait code... Nothing special.
Code:
#define CYCLE_LENGTH 50
#define LOOP_COUNT  10000

void setup() {
  // put your setup code here, to run once:
  uint32_t timeStart = millis();
  while (!Serial && ((millis() - timeStart) < 5000))
    ;

  Serial.begin(38400);
  Serial.println("Test some floating point speeds");
}

void loop() {
  TestDouble();
  TestFloat();
  delay(5000);
}

void TestDouble()
{
  uint32_t start_time = micros();
  int cycle_period_ = 1;
  double base_X = 0.1;
  double base_Y = 0.1;
  double LEG_LIFT_HEIGHT = 0.1;
  double sum_x = 0;
  double sum_y = 0;
  double sum_z = 0;

  for (int i = 0; i < LOOP_COUNT; i++)
  {
    double period_distance = cos( cycle_period_ * PI / CYCLE_LENGTH );
    double period_height = sin( cycle_period_ * PI / CYCLE_LENGTH );
    double foot_x = base_X * period_distance;
    double foot_y = base_Y * period_distance;
    double foot_z = LEG_LIFT_HEIGHT * period_height;
    sum_x += foot_x;
    sum_y += foot_y;
    sum_z += foot_z;
    cycle_period_++;
    if (cycle_period_ > CYCLE_LENGTH)
      cycle_period_ = 1;
  }
  Serial.printf("Double Time: %u (%f, %f, %f)\n\r", micros()-start_time, sum_x, sum_y, sum_z);
}


void TestFloat()
{
  uint32_t start_time = micros();
  int cycle_period_ = 1;
  float base_X = 0.1;
  float base_Y = 0.1;
  float LEG_LIFT_HEIGHT = 0.1;
  float sum_x = 0;
  float sum_y = 0;
  float sum_z = 0;

  for (int i = 0; i < LOOP_COUNT; i++)
  {
    float period_distance = cosf( cycle_period_ * (float)PI / CYCLE_LENGTH );
    float period_height = sinf( cycle_period_ * (float)PI / CYCLE_LENGTH );
    float foot_x = base_X * period_distance;
    float foot_y = base_Y * period_distance;
    float foot_z = LEG_LIFT_HEIGHT * period_height;
    sum_x += foot_x;
    sum_y += foot_y;
    sum_z += foot_z;
    cycle_period_++;
    if (cycle_period_ > CYCLE_LENGTH)
      cycle_period_ = 1;
  }
  Serial.printf("float Time: %u (%f, %f, %f)\n\r", micros()-start_time, sum_x, sum_y, sum_z);
}

First times from Teensy 3.2 running at 120hz.
Code:
Test some floating point speeds
Double Time: 44272 (998.026743, 998.026743, 62.790524)
float Time: 18386 (997.956116, 997.956116, 62.789948)
Double Time: 44272 (998.026743, 998.026743, 62.790524)
float Time: 18384 (997.956116, 997.956116, 62.789948)

Now Teensy 3.5 at 120mhz.
Code:
Test some floating point speeds
Double Time: 21276 (998.026743, 998.026743, 62.790524)
float Time: 586 (997.956116, 997.956116, 62.789948)
Double Time: 21274 (998.026743, 998.026743, 62.790524)
float Time: 584 (997.956116, 997.956116, 62.789948)
So see speedups in both float and double.
Try at 192mhz...
Code:
Test some floating point speeds
Double Time: 13295 (998.026743, 998.026743, 62.790524)
float Time: 365 (997.956116, 997.956116, 62.789948)
Double Time: 13291 (998.026743, 998.026743, 62.790524)
float Time: 365 (997.956116, 997.956116, 62.789948)
So again speed up!

EDIT: OOPS forgot to increment the cycle_period count so using constant. Updated code above
Time now at 192 mhz: 230823 and 15791
At 120mhz: 368430 and 25275

and for T3.2 at 120mhz: 798583 and 452111
 
Last edited:
Also the board txt file is utterly confusing, I got it from here, is this right one? But anyway's 180 and 216 MHz USB works for me is that fixed? I'll update this board txt file if so. Also how about changing it so it is ordered from highest to lowest CPU speed where the optimized speeds are first?
Screen Shot 2016-06-25 at 9.16.24 AM.png
 
I believe, I found the issue (waiting for DMA to be ready), corrected in sdhc.c ( https://github.com/WMXZ-EU/sdhc_test )
modified test program to check if data are real read: I believe so.
(will not tell you performance, so find it out)

Found a small issue: number of sectors is allways an odd number (setting 4 or 5 will read 5 sectors)
If this is a K66 bug or bad programming, I do not know yet.

next TODO: remove locked wait for DINT but use sdhc_isr for asynchron sdhc access.

Wow, CPU @120mhz (baud 40mhz) with my 8GB SansDisk microSD, single sector DMA data rate 19.2 megabits/sec.
5-sector DMA data rate 300 mbs!
i'll instrument it and look with analyzer. (from my earlier posts using hacked BRTOS version got 14.2 mbs for single sector with FIFO, a lot of time was being lost waiting on DLA from card, but with analyzer, the transfer rate was close to 400mbs. i didn't believe or understand that, but maybe it's true)

EDIT: see later posts, data rate was 5 times too high, should be 60 mbs
 
Last edited:
Status
Not open for further replies.
Back
Top