Got mine today so I'll work on getting Snooze to work this weekend.
K66 Beta Test
- Thread starter Paul
- Start date
- Status
xxxajk
Well-known member
LWIP is far from light weight.
I wrote what I did 16 years ago because nothing out there fit within 48k... it simply did not exist.
That 48K had to hold the code and the data and the program, and the other restriction is that it had to work on a 2MHz 8bit CPU.
I've never moved to another stack on an MCU because... well, IMHO they all suck, and don't use the standard calls. In fact, they look nothing close to any standard. Mine do.
Given the fact that it already works on any thing with serial right now, the answer to your question is...
just because everyone else thinks it is great, doesn't mean it is.
I'm willing to bet that punch-for-punch, my stack will beat lwip in speed too.
defragster
Senior Member+
SUCCESS: Minor note of Audio Board with 16MB flash chip: I went to 120MHz and used Teensy Transfer to put the 13.3 MB Audio Sample "SDTEST3.WAV" onto the erased flash no problem. Then at 120 MHz I did a read "-r SDTEST3.WAV > sdt3.wav" to read it back to a new file on the computer. I jumped to 240MHz and repeated the read to a file - both worked and I'm now playing the wav file on my PC. Next step is updating the sketch to play from flash instead of SD. Not sure why but now erasing at 240 MHz and will re-write and repeat all at 240 MHz. Done all at 240 MHz and the WAV is playing after two way transfer without loss.
<edit>: I wondered if those SDHC pins might have other use as well - but saying 'space is at a premium' is probably an understatement.
<edit>: I wondered if those SDHC pins might have other use as well - but saying 'space is at a premium' is probably an understatement.
Last edited:
KurtE
Senior Member+
Thanks Paul,
Makes sense.
I was also going to ask about the USB Host adapter pins, especially if the connector is not included and/or mounted on final board as per the other thread:
But if I am correct the 3 IO pins (USB1_DP, USB1_DM, USB1_VBUS) that are associated with the USB port can only be used for USB...
KurtE
Senior Member+
Might be interesting if someone made a simple sdhc sized board, which had connections to the sdhc pins an wires that came out...
Then I might suggest maybe adding pin numbers for each of the signal pins...
defragster
Senior Member+
Not sure of the SD location - if it will be toward the edge as it on the beta - perhaps just extending those pads could make the difference to connectivity.
With the right USB flash drive - or other device (WiFi FlashAir or ezShare, EyeFi or blutooth?) - and some duct tape - and some soldering that USB port could add a 256GB drive or internet connection?
Epyon
Well-known member
I have some PHY PCB's laying around from back in the Due days if it's any help, when I worked with some people on bringing out the Ethernet interface on that board. Think I used a Davicom 9161A.
In a lot, if not most applications adding a USB drive is not an option - be it out of space or professional considerations. SDHC would be a nice feature, especially for my applications (long time remote data logging).
defragster
Senior Member+
Indeed - I used the words 'duct tape' on purpose. But with the power and resources of the K66 - if the USB stack gets there I was wondering if it might be a growth path for future devices.
manitou
Senior Member+
I have used the mbed TLS on Teensy. The crypto routines work (AES, MD5, SHA256, bignum/RSA) with no change. The file/printf IO would need to be adjusted/avoided. The next step would be to use the K66 crypto-acceleration unit (CAU) within AES/MD5/SHA256, and utilize the hardware random generator as an entropy source.
EDIT: I configured TLS to use the K66 hardware random number generator as the entropy source.
Last edited:
PaulStoffregen
Well-known member
The 6 SDHC signals (which are native pins PTE0 to PTE5) will route only to the micro SD socket on the board. On the round 1 & 2 boards already shipped, they route only to the micro SD socket on the right hand side. If you want to get access to them for something else, you'll have to solder little wires to the exposed pads on the edge of the socket.
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.
el_supremo
Well-known member
Received the k66 late this afternoon.
I've added pins to an audio board and mounted it on the K66
Things I've tested so far which work:
- the Examples|Audio|Synthesis|Guitar demo worked out-of-the-box.
- once I had updated the Audio library, my sketch which uses freeverb and KarplusStrong
to play a piece by Bach works.
- program to list files on Audio board's uSD card - uses SD.h
- Examples/SerialFlash/EraseEverything
- My code to write files from uSD to flash (using my own file format on flash) works
and the code to list the resulting directory on flash also works.
Maybe tomorrow I'll get it playing the WAV files in flash.
Is there a magic incantation required to have code use the FPU? The tests I've run suggest that the speed increase is only due to the faster clock.
Pete
I've added pins to an audio board and mounted it on the K66
Things I've tested so far which work:
- the Examples|Audio|Synthesis|Guitar demo worked out-of-the-box.
- once I had updated the Audio library, my sketch which uses freeverb and KarplusStrong
to play a piece by Bach works.
- program to list files on Audio board's uSD card - uses SD.h
- Examples/SerialFlash/EraseEverything
- My code to write files from uSD to flash (using my own file format on flash) works
and the code to list the resulting directory on flash also works.
Maybe tomorrow I'll get it playing the WAV files in flash.
Is there a magic incantation required to have code use the FPU? The tests I've run suggest that the speed increase is only due to the faster clock.
Pete
defragster
Senior Member+
K66 AudioPlaySerialflashRaw works for WAV's at 96 MHz and higher as noted/updated, 180 MHz seem good - played a string of 8 passes:
<edit>:
- 240 MHz iffy - plays most of the way through usually - then just stops, sometimes it won't start playing (persistently ?). Keeps blinking, sound stops
- 180 MHz tested well. Power Cycle and RESET
- Flash is 16 MB with 13.3 PJRC sample of 1.5 minutes
- 192 Mhz starting okay played through, <edit> plays many times through and will restart - may have been sketch
View attachment PlayFlashRaw.ino
Updated sketch to multitask in loop(), 1 second qBlink() and show playFlashRaw1.positionMillis() so sound stoppage is visual/recorded. Shows Play count Audio Ram of 1 Usage
Code adapted from AudioPlaySerialflashRaw
> Included the "SerialFlash.begin();"
> Made Mono to both ears
> Uncommented VOL Knob Pot A15 works
<edit>:
- 240 MHz iffy - plays most of the way through usually - then just stops, sometimes it won't start playing (persistently ?). Keeps blinking, sound stops
- 180 MHz tested well. Power Cycle and RESET
- Flash is 16 MB with 13.3 PJRC sample of 1.5 minutes
- 192 Mhz starting okay played through, <edit> plays many times through and will restart - may have been sketch
View attachment PlayFlashRaw.ino
Updated sketch to multitask in loop(), 1 second qBlink() and show playFlashRaw1.positionMillis() so sound stoppage is visual/recorded. Shows Play count Audio Ram of 1 Usage
Code adapted from AudioPlaySerialflashRaw
> Included the "SerialFlash.begin();"
> Made Mono to both ears
> Uncommented VOL Knob Pot A15 works
Last edited:
defragster
Senior Member+
Maybe this is something of what FrankB saw [he noted he had to power cycle on changing clock speeds] - once high speed (240) stops playing - .positionMillis() unchanging but sketch runs - it may take an upload at 96 to 168, 180 (?) to restore audio function. Sketch uploads and runs - but Audio never plays (no audio memory is even used) - even when power cycled or reset or rested unpowered a short time.
It occurred to me that knowing when it stopped might let the cause of the need to reprogram at lower speed be investigated - even if this is just a simple timing issue for the Audio - it is pushing something into a static bad state - and I feel no heat - just a normal warm. Not often but I have heard it run a minute at 240.
Modified the sketch to stop within 3 ms of play stoppage when music no longer advancing based on reported positionMillis(). If music starts or USB input arrives it will continue. 100ms flash LED and USB output are shown.
View attachment PlayFlashRawD.ino
<edit> 192 MHz 7+ hours and 176 iterations still playing - sample is 153.7 seconds
<edit2> 216 MHz on reset it will play up to 3-4 seconds and stop - then not start - then start on repower/reprogram - so for somebody knowing where to look it is a good repro case of the problems. Temp 92°.
It occurred to me that knowing when it stopped might let the cause of the need to reprogram at lower speed be investigated - even if this is just a simple timing issue for the Audio - it is pushing something into a static bad state - and I feel no heat - just a normal warm. Not often but I have heard it run a minute at 240.
Modified the sketch to stop within 3 ms of play stoppage when music no longer advancing based on reported positionMillis(). If music starts or USB input arrives it will continue. 100ms flash LED and USB output are shown.
View attachment PlayFlashRawD.ino
<edit> 192 MHz 7+ hours and 176 iterations still playing - sample is 153.7 seconds
<edit2> 216 MHz on reset it will play up to 3-4 seconds and stop - then not start - then start on repower/reprogram - so for somebody knowing where to look it is a good repro case of the problems. Temp 92°.
Last edited:
PaulStoffregen
Well-known member
I started experimenting with the USBHS port. If anyone's curious, here's my very first (underwhelming) attempt.
https://github.com/PaulStoffregen/k66_usbhost/blob/master/k66_usbhost.ino
https://github.com/PaulStoffregen/k66_usbhost/blob/master/k66_usbhost.ino
KurtE
Senior Member+
Maybe slightly off topic, but was playing around a little with SPI, to see if there was an easy way to make it easier to switch which SPI buss you were using.
So I created a Quick and dirty class SPIN, which has the same methods as SPI and SPI1, except there is a method to set which buss you are using. Currently like SPI and SPI1 it creates a static object, which is simple:
Example method:
I then updated SPIFlash library to use the SPIN object instead of SPI in SerialFlashChip.cpp
Then in RawHardwareTest, if I build it with no changes, it uses SPI. To change to using SPI1, I simply add
Not sure how much it effects performance, more or less adds if statement...
With the RawHardwareTest app, Some of the timings given;
Using SPI directly: Read write test 418 Erase time 150065
Using SPIN(0): RW: 420 Erase: 142975
Using Spin(1): RW: 419 Erase: 144403
Which tells me timings are influenced more by other stuff...
In case anyone wishes to take a look, here is current SPIN code... May look at changing from everything being static, so possibly can have two SPIN objects, so can configure program where SPIN(0) is used in display object and SPIN(1) is used for some other object.
So I created a Quick and dirty class SPIN, which has the same methods as SPI and SPI1, except there is a method to set which buss you are using. Currently like SPI and SPI1 it creates a static object, which is simple:
Example method:
Code:
inline static uint8_t transfer(uint8_t data) {
switch (buss_)
{
default:
return SPI.transfer(data);
break;
#if defined(__MK64FX512__) || defined(__MK66FX1M0__) || defined(KINETISL)
case 1:
return SPI1.transfer(data);
break;
#endif
}
}
Code:
#elif defined(__MK64FX512__) || defined(__MK66FX1M0__)
#define SPIPORT SPINThen in RawHardwareTest, if I build it with no changes, it uses SPI. To change to using SPI1, I simply add
Code:
SPIN.setBuss(1); // Set to SPI1...With the RawHardwareTest app, Some of the timings given;
Using SPI directly: Read write test 418 Erase time 150065
Using SPIN(0): RW: 420 Erase: 142975
Using Spin(1): RW: 419 Erase: 144403
Which tells me timings are influenced more by other stuff...
In case anyone wishes to take a look, here is current SPIN code... May look at changing from everything being static, so possibly can have two SPIN objects, so can configure program where SPIN(0) is used in display object and SPIN(1) is used for some other object.
For all that are interested
in https://github.com/WMXZ-EU/sdhc_test is an other attempt (in addition to Manitou's work) to use the SDIO protocol to access the K66 beta uSD board.
it is based on work by a NXP employee without explicit Copyright notice (link in files), so I do not know how it can be used within this community, but may be used as a starting point for own developments
in https://github.com/WMXZ-EU/sdhc_test is an other attempt (in addition to Manitou's work) to use the SDIO protocol to access the K66 beta uSD board.
it is based on work by a NXP employee without explicit Copyright notice (link in files), so I do not know how it can be used within this community, but may be used as a starting point for own developments
In the forum link about Petr Gargulak's demo SDIO code, he reports 17 MB/sec transfer rate (136 Mbit/sec) on a fast SanDisk 64GB card using 50 MHz SD clock. That's pretty impressive, if true. https://community.nxp.com/thread/99202
That's in the same class as the Raspberry Pi SD card performance: http://elinux.org/RPi_SD_cards#SD_card_performance
That data rate could transfer uncompressed 8bpp 800x600 video at 30 fps.
That's in the same class as the Raspberry Pi SD card performance: http://elinux.org/RPi_SD_cards#SD_card_performance
That data rate could transfer uncompressed 8bpp 800x600 video at 30 fps.
Last edited:
PaulStoffregen
Well-known member
I just got a notice from OSH Park. The first 3 ethernet PHY test boards are back from the fab.
manitou
Senior Member+
Nice. DMA is nice. F_CPU @ 120mhz, I ran it and saw 17.46 mbs (assuming it's really reading data
)EDIT: i read my known sector from my microSD card -- data is good
EDIT 2: I tried reading 4 sectors at a time ... nope.
Last edited:
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"
defragster
Senior Member+
Posting here in case Koromix can get TYQT working for me - others.
I built a T_3.1 with top female header to match beta board - but running both on same machine that TYQT does easily is trouble for IDE SerMon. And TYQT static output across execution cycles is helpful at times, and it connects more readily so it is a better tool.
Koromix - when you have time to look into making TYQT work for K66 Beta I'm ready for a test build to hopefully get the needed protocol to talk to it. I can do a RESET one time (then logs "Reboot does not seem to work")- then it loses the unit until it restarts. Maybe the Arduino integration won't work right away - but it makes a much better serial monitor when comparing K66 .vs. T_3.1 when both powered - IDE SerMon loses connection on reset/button - only reconnects when it does upload itself otherwise needs to restart SerMon - normal trouble - that's why TYQT is so great!
Here I cleared the TYQT LOG - it found K66 - did a reset - repowered K66 then reset again:
Other note to Koromix:
I hosed my IDE 1.6.9 with Beta boards.txt when I got tired of guessing which of 5 serial ports in the IDE related to which Teensy that was or wasn't plugged in - I opened TYQT (being able to disable monitor is great) - but then I clicked 'integrate to arduino' - which wasn't helpful - but clicking 'Restore' was FATAL in some fashion - I'm not sure what changed but it seems integrate/restore with 1.6.9 and TeensyDuino 1.29b2 with K66 boards.txt presented something odd, it was restored with 1.29b3 upgrade.
I built a T_3.1 with top female header to match beta board - but running both on same machine that TYQT does easily is trouble for IDE SerMon. And TYQT static output across execution cycles is helpful at times, and it connects more readily so it is a better tool.
Koromix - when you have time to look into making TYQT work for K66 Beta I'm ready for a test build to hopefully get the needed protocol to talk to it. I can do a RESET one time (then logs "Reboot does not seem to work")- then it loses the unit until it restarts. Maybe the Arduino integration won't work right away - but it makes a much better serial monitor when comparing K66 .vs. T_3.1 when both powered - IDE SerMon loses connection on reset/button - only reconnects when it does upload itself otherwise needs to restart SerMon - normal trouble - that's why TYQT is so great!
Here I cleared the TYQT LOG - it found K66 - did a reset - repowered K66 then reset again:
Other note to Koromix:
I hosed my IDE 1.6.9 with Beta boards.txt when I got tired of guessing which of 5 serial ports in the IDE related to which Teensy that was or wasn't plugged in - I opened TYQT (being able to disable monitor is great) - but then I clicked 'integrate to arduino' - which wasn't helpful - but clicking 'Restore' was FATAL in some fashion - I'm not sure what changed but it seems integrate/restore with 1.6.9 and TeensyDuino 1.29b2 with K66 boards.txt presented something odd, it was restored with 1.29b3 upgrade.
Last edited:
- Status