K66 Beta Test

Status
Not open for further replies.
This lib by WMXZ:https://github.com/WMXZ-EU/uSDFS and the example uSDFS_test (can be edited to use USB) with different speeds.
But don't forget to make a backup of your SD-card ... :)

When switching to high speeds, delete the HELL10.TXT first or change the filename to something different to force writing to the FAT.
 
Last edited:
Paul: As you get comfortable exposing more committed details- there are probably things that could help summarize the lessons learned from groups 1 and 2 - as the next larger group goes out.

I got as far as: perhaps a quick and dirty printable pin reference table (like I prematurely posted) - maybe you have one in the works - I think I summarized the current list to a CSV file that I could import>export as PDF/Excel sheet and colorize (working from a solid ref. might keep the smoke in things and certainly aids in putting wires/testing more efficiently). The other might be a single new K66 thread (semi-Wiki) where beta recipients could use one post each to summarize details and github or usage details of their progress. Basically a condensed summary of stuff already in this this 28 page thread - but would be a shorter read or up to date info in one place. And could be easily be indexed in one post by subject area.

Some people have liked the google spreadsheet that I did in the past to compare the 3.0/3.1/3.2/LC. I have added the details as far as I can tell for the new processors (I'm in the 3rd round of beta testers, so I haven't seen the board yet). As per Paul's wishes, I haven't published the link yet, but if people want the link before it can be made public, send me a private message, and I will send you the link.
 
This lib by WMXZ:https://github.com/WMXZ-EU/uSDFS and the example uSDFS_test (can be edited to use USB) with different speeds.
But don't forget to make a backup of your SD-card ... :)

When switching to high speeds, delete the HELL10.TXT first or change the filename to something different to force writing to the FAT.
Thanks - When changing to USB also needed to change SERIAL.begin(...) as the USB version does not take two arguments...

Not sure what all to test. I took a 4GB micro sd card (Lexar 4GB Micro SD HC) to linux and GPARTED it, to make sure only one volume, also formated it to FAT16. But also reformatted on Windows 10 machine to remove the extra few files that Ubuntu put on the disk... I copied a few directories and files including a very large one the like into it, I ran the test at 120, 180, 192, 216. I have run at 216 about 4 times now. Last run:
Code:
uSDFS

Create a new file (hello10.txt).


Write a text data. (Hello world!)


Close the file.


Open same file (hello10.txt).


Type the file content.

Hello world!

Second Line

Third Line

Fourth Line

Habe keine Phantasie


Close the file.

open binary file
write file
close file
Logger_test done

Open root directory.


Directory listing...

   <dir>  SYSTEM~1
   <dir>  RC_REC~1
   <dir>  BNO055~1
   <dir>  SCANNER
   <dir>  SRF08
   <dir>  ARDUIN~1
   <dir>  RC_REC~2
   <dir>  RC_REC~3
    2166  SRF08-~1.ZIP
    5866  RC_REC~1.ZIP
    2392  SRF08-~2.ZIP
1128795520  UBUNTU~1.XZ
      74  HELLO10.TXT
    4096  TEST00.BIN

Test completed.

I then remove sd from T3.5 and move to windows 10 machine, and try things like:
Code:
C:\Windows\System32>g:

G:\>dir
 Volume in drive G is TEST
 Volume Serial Number is 7CCD-5208

 Directory of G:\

07/04/2016  11:13 AM    <DIR>          RC_Receiver_PulseIn
07/02/2016  10:04 AM    <DIR>          BNO055_Test
07/08/2016  04:16 PM    <DIR>          scanner
07/07/2016  03:29 PM    <DIR>          SRF08
07/05/2016  03:08 PM    <DIR>          arduino_cmps03
07/05/2016  10:08 AM    <DIR>          RC_Receiver_Attach_PulsePosition
07/04/2016  09:37 PM    <DIR>          RC_Receiver_Attach_Interrupt
07/07/2016  07:43 AM             2,166 SRF08-160707a.zip
07/05/2016  10:19 AM             5,866 RC_Receiver_Attach_PulsePosition-160705a.zip
07/07/2016  03:30 PM             2,392 SRF08-160707b.zip
07/08/2016  06:29 AM     1,128,795,520 ubuntu-16.04-mate-odroid-xu3-20160708.img.xz
07/09/2016  07:44 AM                74 HELLO10.TXT
07/09/2016  07:44 AM             4,096 TEST00.BIN
               6 File(s)  1,128,810,114 bytes
               7 Dir(s)   2,876,899,328 bytes free

G:\>cat HELLO10.TXT
Hello world!
Second Line
Third Line
Fourth Line
Habe keine Phantasie

G:\>cat TEST00.BIN
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000011111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111
G:\>rm HELLO10.TXT

G:\>dir
 Volume in drive G is TEST
 Volume Serial Number is 7CCD-5208

 Directory of G:\

07/04/2016  11:13 AM    <DIR>          RC_Receiver_PulseIn
07/02/2016  10:04 AM    <DIR>          BNO055_Test
07/08/2016  04:16 PM    <DIR>          scanner
07/07/2016  03:29 PM    <DIR>          SRF08
07/05/2016  03:08 PM    <DIR>          arduino_cmps03
07/05/2016  10:08 AM    <DIR>          RC_Receiver_Attach_PulsePosition
07/04/2016  09:37 PM    <DIR>          RC_Receiver_Attach_Interrupt
07/07/2016  07:43 AM             2,166 SRF08-160707a.zip
07/05/2016  10:19 AM             5,866 RC_Receiver_Attach_PulsePosition-160705a.zip
07/07/2016  03:30 PM             2,392 SRF08-160707b.zip
07/08/2016  06:29 AM     1,128,795,520 ubuntu-16.04-mate-odroid-xu3-20160708.img.xz
07/09/2016  07:44 AM             4,096 TEST00.BIN
               5 File(s)  1,128,810,040 bytes
               7 Dir(s)   2,876,964,864 bytes free

G:\>chkdsk
The type of the file system is FAT.
The volume is in use by another process. Chkdsk
might report errors when no corruption is present.
Volume TEST created 7/9/2016 6:50 AM
Volume Serial Number is 7CCD-5208
Windows is verifying files and folders...
File and folder verification is complete.

Windows has scanned the file system and found no problems.
No further action is required.

4,007,395,328 bytes total disk space.
       65,536 bytes in 1 hidden files.
      458,752 bytes in 7 folders.
1,129,906,176 bytes in 17 files.
2,876,964,864 bytes available on disk.

       65,536 bytes in each allocation unit.
       61,148 total allocation units on disk.
       43,899 allocation units available on disk.

G:\>
I normally use the Eject to remove it from Windows, but am pretty sure that is not necessary for SD cards as I believe they default to buffering turned off...
 
Hm that looks good. I used FAT32... did you create a new File with > 120MHZ ?
Well..if it works for you.. why does it not work for me ? :confused: I'll try FAT16...

Ok, Paul said, he used I2S @ with Teensy @ 240MHz... does not work for me, too.

A problem with my board ?
 
Is there a test/instructions, that you would like some of us to try?
Unfortunately, I'm out of business (my K66 is on the way back to PJRC for testing)
I'm trying to get a FRDM K64F up and running with KDS but I have some issues
(e.g. downloaded program, or better bin file coped to mbed disk, disappears, maybe it is crashing?)
 
Unfortunately, I'm out of business (my K66 is on the way back to PJRC for testing)
I'm trying to get a FRDM K64F up and running with KDS but I have some issues
(e.g. downloaded program, or better bin file coped to mbed disk, disappears, maybe it is crashing?)

Well, my experience with K64F and the mbed online compiler is that when I copy (drag & drop) the .bin on to the mbed disk, the LED flashes as the .bin gets loaded into flash, then i push RESET button, and program runs and output goes /dev/ttyACM0 (linux) -- AND the .bin file "disappears" from the MBED disk, a feature.
 
I ran the test at 120, 180, 192, 216. I have run at 216 about 4 times now. Last run:
ah..can you please change the filename in the sketch to something else and just one try @ 180MHz?

If you did your test in this order, it wrote the correct filename @ 120MHZ. I experienced the same. So, please just edit the the filename to HELLO3.TXT and retry @ 180MHz (NOT 120). Does this work ?
 
If I understood correctly, my last run as at 120mhz and so it had the two created files...

I then edited sources and changed where it created HELLO10.TXT to instead create HELLO3.TXT and I downloaded the program at 180mhz. The program ran fine. I took the SD to my PC and verified all of the files looked valid, chkdsk did not find any errors. I did a rename of HELLO10.TXT to HELLO11.TXT on pc and it still looked OK...
 
Well, my experience with K64F and the mbed online compiler is that when I copy (drag & drop) the .bin on to the mbed disk, the LED flashes as the .bin gets loaded into flash, then i push RESET button, and program runs and output goes /dev/ttyACM0 (linux) -- AND the .bin file "disappears" from the MBED disk, a feature.

Yes, I got an official program running. the "acceleration level app", but the K64_FatFs_KSDK is not working, but I have not given up (yet)
 
Ok..thanks... so something is wrong with my setup, my card, or my board.
But good to know that is not a general problem!
Great.
 
Quick I2C/Wire question: maybe should be different thread, but...

Setting the clock speed on I2C Buss. Example: I know that the SSD1306 display is valid for 400K clock speed.

So is it valid and/or good thing to add: Wire.setClock(400000K) to it's begin method? There is code to to this for Arduino Due? What if other devices can not handle it?

But also in their code for the main display function they have:
Code:
    // save I2C bitrate
#ifdef TWBR
    uint8_t twbrbackup = TWBR;
    TWBR = 12; // upgrade to 400KHz!
#endif
...
   Wire.begin...
...
#ifdef TWBR
    TWBR = twbrbackup;
#endif
But currently I am not seeing any way to do this with Teensy. That is I don't believe that this register is emulated and
I don't see any way in the SPI interface to retrieve current speed?

Again sorry if not totally 3.5 specific
 
Quick I2C/Wire question: maybe should be different thread, but...
Setting the clock speed on I2C Buss. Example: I know that the SSD1306 display is valid for 400K clock speed.
So is it valid and/or good thing to add: Wire.setClock(400000K) to it's begin method? There is code to to this for Arduino Due? What if other devices can not handle it?
... Again sorry if not totally 3.5 specific

Indeed this should apply to any valid Wire usage with the Adafruit lib - but to confirm the T_3.5 is running optimally it seems a good thing to try.

In Adafruit ssd1306_128x64_i2c.ino setup() does a series of graphic displays before starting the 'stars' falling (draw/erase/redraw). It has a series of inline delay()'s between that I shortened but didn't remove. The sketch can set wire speed after and get much smoother and better performance from the display!

I'm testing on Wire2 at 240 MHz - after display.begin() with :: Wire.setClock(400000UL); // Set I2C frequency to 400kHz
elapsed Micros=10,902,574 and without that call: elapsed Micros=33,046,170.

However if the speed is set high before display.begin() something must get confused with library doing setup of wire? This seems like a library setup issue - may related to using i2c_t3?

The speed up is over 3 times as the static delays are measured in both cases.

Watching the flakes series with random delay removed and not timing the delay() @ 400kHz a series takes elapsed Micros=34,621 versus elapsed Micros=114,146, so the default clock AdaFruit is getting is 3.3 times slower and not i2c_t3 fully compliant? The sketch can make this call and the speed change persists - but must do it at the right time.

I put this line (@~214) in Adafruit_SSD1306::begin() after Wire.begin(); and removed from sketch and it is fast and clean and good - as long as the devices the library uses can take 400 kHz.

Code:
#ifdef I2C_T3_H
		Wire.setClock(400000UL); // Set I2C frequency to 400kHz
#endif
 
Yes - I played around with it. For the fun of it I issued a pull request back to Adafruit:
https://github.com/adafruit/Adafruit_SSD1306/pull/68

If I am reading the specs correctly: https://cdn-shop.adafruit.com/datasheets/SSD1306.pdf
Page 54, the clock cycle time min is 2.5us, so 400K should work.

But still wondering about if it makes sense to maybe emulate TWBR here...
And/Or: either change: setClock to return uint32_t instead of void and return previous Clock and/or have another method clock or getClock...

Maybe I will play a little...
 
Could you please test Talkie from here ? (Output is now DAC0-PIN as stated in the readme) Is it better ?: https://github.com/FrankBoesing/Talkie/tree/patch-1

no not 'better' ... it is AWESOME! Great Discovery!

Indeed side by side pin A14 is garbled and awful, With pin change to A21 is clear and perfect! Tested at 96 and 240 MHz { and also good at 216 & 8 & 4 }.

At 8 and 4MHz - sound is perfectly paced and if not as good I can't tell - finally breaks into dull patter at 2 MHz.

Also just as good on DAC1 A22 @216MHz.
 
The checksum field of ICMP echo/reply messages is supposed to be 0, so your changes to the request packet to create the reply maintained that field. You commented out the TACC setting that would have enabled automatic checksum calculation/insertion. However, due to the wimpy TCP/IP checksum algorithm (half-words can be re-ordered and sum will be the same), the IP header checksum will still be correct for your reply packet. ;)
Re: ethernet hardware IP checksums
I enabled the IP and proto checksum in the TACC register so the hardware would calculate and insert the IP and underlying protocol checksum in outgoing packets. You MUST zero the IP and UDP/TCP/ICMP checksum field in the outgoing packet. It doesn't appear the mbed K64 lwIP library utilizes the hardware checksum. other details in post #686

EDIT: With the UDP blast test, linux reported some "bad IP headers", checksum failure ... investigating
 
Last edited:
Paul (and others):

For the fun of it I am again wanting to play around some with the 6 IO pins associated with the SD Card. I now have one of the Sparkfun microSD Sniffer boards and I am wanting to try out using some of the IO pins.

In particular I think it would be great to use for SPI1. Why? Currently SPI1 only has one CS pin available (PCS0 on two pins), with these pins you would have PCS1 and PCS2 as well. So we could then try displays like the ili9341 on spi1...

These pins have other features as well like alternate pins to use for UART1, UART3, I2C1 and of course GPIO and Analog...

For my first experiment, I am thinking about doing a semi Hack for SPI1, where I allow you to pass in 0xe0, 0xe4, and 0xe5 into:
bool SPI1Class::pinIsChipSelect(uint8_t pin)

And say they are valid pins. and likewise update: uint8_t SPI1Class::setCS(uint8_t pin)
to also check these values and set the appropriate pin information...

I may do similar for setting the sin, sout and clock pins, but that will require hacking the SCR1 code.

Will be interesting to see how well it works. If it works well, I will recheck my diptrace design files and order a set of adapters from OSHPark. Would be fun, to be able to hook all of the pins of a display up to adapter and simply have to plug it in to here...

Again currently thinking of doing this with Bogus pin number (Match the physical pins), but wondering if instead, I should create real pin numbers (either starting at 40 or 48 and update the information in core_pins.h

Kurt

Update
: again not sure how this will end up, but have made most of the edits to allow SPI1 to use the pins on the SDIO connector. I also did a quick and dirty test program:
Code:
void setup() {
  // put your setup code here, to run once:
  while (!Serial && millis() < 5000) ;

  Serial.println("Try set pins on PortE");
  pinMode(13, OUTPUT);

  // Try to set pins E0-E5 as GPIO Output pins. 
  PORTE_PCR0 = PORT_PCR_SRE | PORT_PCR_MUX(1);
  PORTE_PCR1 = PORT_PCR_SRE | PORT_PCR_MUX(1);
  PORTE_PCR2 = PORT_PCR_SRE | PORT_PCR_MUX(1);
  PORTE_PCR3 = PORT_PCR_SRE | PORT_PCR_MUX(1);
  PORTE_PCR4 = PORT_PCR_SRE | PORT_PCR_MUX(1);
  PORTE_PCR5 = PORT_PCR_SRE | PORT_PCR_MUX(1);

  GPIOE_PDDR |= 0x3f;   

}

void loop() {
  digitalWrite(13, HIGH);

  uint32_t mask = 0x3f;   // start off with all bits set;

  while (mask) {
    GPIOE_PSOR = mask;  // Turn on the ones...
    delay(50);
    GPIOE_PCOR = mask;  // turn back off
    mask >>= 1;     // remove MSB bit
    delay(50);
  }
  digitalWrite(13, LOW);
  delay(250);
}
I hooked up logic analyzer, to verify which signals were on which pin with the Sparkfun sniffer. It appears like:
Date1(E0), Dat0(E1), Clk(E2), CMD(E3), CD(E4), and Dat3(E5)

Now to edit ILI9341_t3 to allow SPI1...
 
Last edited:
UDP receive test: linux box sends 20 1000-byte UDP packets as fast at it can. k66 receives all in 1620us (bout 98 mbs), receiver clock is started when first packet arrives.

Artnet folks controlling huge numbers of LEDs are going to be really happy with this. :)
 
Ok..thanks... so something is wrong with my setup, my card, or my board.

The card was the problem. Well, the card is ok and works great in other devices.. It is a no-name class 4 8 GB SDHC Card.

I replaced it with a Sandisk Ultra 16GB - now, all is perfectly ok...:D
 
The card was the problem. Well, the card is ok and works great in other devices.. It is a no-name class 4 8 GB SDHC Card.

I replaced it with a Sandisk Ultra 16GB - now, all is perfectly ok...:D

Great, but there may be still some timing issues, especially as the K66 may have fast execution times.
 
TeensyDuino 1.29 released - installed okay - seems we need to supply a T_3.5 aware Boards.txt - the prior copy still the right one?

... As per Paul's wishes, I haven't published the link yet, but if people want the link before it can be made public, send me a private message, and I will send you the link.

Is the post #3 accurate and complete - any added ALT pin updates? I put it to a colorized PDF from a word doc table in full sheet size and 0.10 spaced table to align easier counting of the pins.
 
Last edited:
Thanks - When changing to USB also needed to change SERIAL.begin(...) as the USB version does not take two arguments...

Not sure what all to test. I took a 4GB micro sd card (Lexar 4GB Micro SD HC) to linux and GPARTED it, to make sure only one volume, also formated it to FAT16. But also reformatted on Windows 10 machine to remove the extra few files that Ubuntu put on the disk... I copied a few directories and files including a very large one the like into it, I ran the test at 120, 180, 192, 216. I have run at 216 about 4 times now. Last run:
<SNIP>
Have you given my improved fat filesystem a try? Although it is "geared" for USB, it should be able to drive an SD card driver front end. All you would need to do ins provide a few hooks, and present it to it, and it will work with it. This is better than having to use the included SDcard stuff, since it ends up as an abstraction layer. It also has some major bug fixes. For example, the old code doesn't update the other copies of the FAT tables, mine does, and eliminates a lot of the corruption problems people have seen when writing.

Last time I tested FAT32, my FS driver worked to the total limits of FAT32, as long as LBA32 was the maximal block addressed. I've not implemented LBA48 on USB, but I do plan on doing this, as well as expanding the block range on it to 64bit. I just have not gotten around to doing this yet. Once I do, then the SDcard size shouldn't matter.
 
Yes,use the same boards.txt. Very little changed in the last couple betas.
...
... much to keep track of 721 posts and 29 pages - I haven't been trying except the stuff I'm testing at the moment. Thus my note about Beta group thread with an indexed Semi-Wiki up to date 1post per person. Also I cut out and taped up my colorized 0.10" Word Table pin card and it just showed me I had a pin off by one on sketch to follow. Maybe the B3 boards have the labels closer to the headers - but the 33/VIN side is hard to gauge - even without my dual header daughter Proto board ( which wholly obscures the GND/32 labels).

I made a sample sketch : View attachment SerialEvent.ino ( in response to Serial2-Alternate-pins-26-and-31 )
It opens USB Serial and takes input and echoes that to Serial and to Serial1 - with a twist Serial1 starts on pins 0/1 then after each USB string, with Serial1.set{R,T]X() cycles the pins to 21/5 then 27/26 and repeats. Just takes a jumper wire on each of those pairs and when data comes in Serial1 it is echoed out USB Serial. It does this with the SerialEvent sample as a start point and I just extended to use SerialEvent1() - and shifting the pins.
Also I soldered up my other new Prop_LC and it works (no searing AMP heat) on both a T_3.1 and the T_3.5 with FrankB's edit to Talkie to adjust for A21/DAC0 on K66. That is a good change.
 
I think a wiki would be an asset as well. Perhaps basecamp would be a good idea, as it provides a wiki plus other goodies. It is free for open source last I checked.
Greping thru all these posts is painful, and it could use better organization.
Perhaps a set of subforums could work as well, where you have an area for each component that is being worked on as an alternative if Paul wants to keep control of the data.
 
I think a wiki would be an asset as well . . .
A true wiki still on the list for scheduling . . . "Wiki-Coming-Please-link-worthy-posts" but a bit much for now. I suggested a "Semi-Wiki"/Thread as one where Beta users could make/edit one post on a (2nd K66 Beta) thread exclusively for that - so the posts might get long - but would be a dedicated summary of open and closed issues without banter or the real answer 'x' posts away. Non-Beta user posts would get spammed away - (OP could be a maintained index of general subject area links to posts) - not a real wiki but would allow whatever portion of the ~80 folks getting boards to get/stay up to speed in one place.
 
Status
Not open for further replies.
Back
Top