K66 Beta Test
- Thread starter Paul
- Start date
- Status
defragster
Senior Member+
Updated 1.69 IDE w/1.29b3 and the cleaned up Boards.txt - all is well on Win_10. I discovered my issue last night was clicking the 1.68 IDE shortcut which doesn't know about the K66 . . . I haven't moved to my Win_7 machine yet to try.
My K66 Beta is running well with nothing unexpected or problematic!
Indeed Most Amazing- the vastness of the Teensy world is ... vast - no wonder there is a 2200+ page K66 manual. Even the K64 is still under 1800 pages. So easy to lose an hour+ just confirming and recompiling for one test that goes odd and so such an array of devices, protocols, speeds. Paul certainly made it ready for Beta and added exposure for better coverage.
Manitou - As noted it suits my expectation and purpose to validate the clock math is correct - the RTC 1 second isr() varies at most 10 microseconds according to elapsedMicros. The reported ppm is what I'm puzzled by the sketch you linked starts with ppm of '147660 to 800050' depending on the startup time: "2 2 1.742675 147660" or "2 2 1.111080 800050". With an elapsedMicros for updates I moved the 'set base time'=='normalization' into setup() to simplify the isr() - but haven't understood it well enough to pinpoint the anomaly I think I see.
My K66 Beta is running well with nothing unexpected or problematic!
Indeed Most Amazing- the vastness of the Teensy world is ... vast - no wonder there is a 2200+ page K66 manual. Even the K64 is still under 1800 pages. So easy to lose an hour+ just confirming and recompiling for one test that goes odd and so such an array of devices, protocols, speeds. Paul certainly made it ready for Beta and added exposure for better coverage.
Manitou - As noted it suits my expectation and purpose to validate the clock math is correct - the RTC 1 second isr() varies at most 10 microseconds according to elapsedMicros. The reported ppm is what I'm puzzled by the sketch you linked starts with ppm of '147660 to 800050' depending on the startup time: "2 2 1.742675 147660" or "2 2 1.111080 800050". With an elapsedMicros for updates I moved the 'set base time'=='normalization' into setup() to simplify the isr() - but haven't understood it well enough to pinpoint the anomaly I think I see.
PaulStoffregen
Well-known member
manitou
Senior Member+
I think you want to set the baseline in the ISR (baselline-if is only executed once), otherwise time will pass from when setup() runs til the first interrupt
KurtE
Senior Member+
You can easily make it compile by adding something like:
Code:
#elif defined(__MK64FX512__) || defined(__MK66FX1M0__)
#define ADC_TEENSY_3_1But this does not make any changes (if any) for functional differences to Teensy 3.2...
adrianfreed
Well-known member
B]EDIT: RESOLVED[/B]
you need VREF_SC |= VREF_SC_VREFEN | VREF_SC_MODE_LV(1);
(attn: Paul teensy 3.1 also has that register, but it seems to be set 0xE1 in analog.c )
I confirmed this fix and am able to measure power supply voltage with 1.29 beta3 on 1.6.8 and new boards.txt on OS X 10.11.5
I still can't get A14-A22 to read the pin voltages. Assuming it is something on my end I am simplifying the code.
manitou
Senior Member+
PaulStoffregen
Well-known member
Here's the sketch I used for testing the analog pins.
Code:
void setup() {
for (int i=0; i<=39; i++) {
pinMode(i, INPUT_PULLDOWN);
}
}
void loop() {
for (int i=14; i<=23; i++) {
Serial.print(analogRead(i));
Serial.print(" ");
}
Serial.print(" ");
Serial.print(analogRead(A10));
Serial.print(" ");
Serial.print(analogRead(A11));
Serial.print(" ");
for (int i=31; i<=39; i++) {
Serial.print(analogRead(i));
Serial.print(" ");
}
Serial.print(analogRead(A21));
Serial.print(" ");
Serial.print(analogRead(A22));
Serial.println();
delay(75);
}adrianfreed
Well-known member
Thanks,
Our OSC code base has some examples with an old and flawed way of iterating analog pin numbers.
Firmata seems to also use the same flawed technique:
Our OSC code base has some examples with an old and flawed way of iterating analog pin numbers.
Firmata seems to also use the same flawed technique:
defragster
Senior Member+
Soldered virgin Audio Card and put it on the K66 - Test Sketch:: Audio_Tutorial\Part_1_03_Playing_Music
First test was 180 Mhz started and played fine - same when dropped to 24 MHz! Went to 72 and it is playing okay.
PROBLEMS:
The song does not play through at 240 MHz. Did 240 between 180 and 24 and it stopped during compile for 24, went back to 240 and it stopped, hit a 'reset' it started again then stopped.
Even worse at 216 Mhz - pitch is OFF - half speed? and it may only play a couple seconds if at all - but does not hang. Added setup() for BUILTIN_LED and qBlink code in loop() as shown below and it always runs.
- Plugged in PJRC Tutorial 8GB flash and 216 MHz same behavior
- Only Serial output seen is "Start playing" - never shown any trouble on SD card init.
- Install is IDE 1.6.9 with TeensyInstall 1.29b3 and related boards.txt. No other changes or signs of trouble on other sketches at any speed.
- added a PJRC volume wheel and a DigiKey winbond 16MB I didn't test yet, thought I had a mic but started without it. The same 16GB AData class 10 used with PJRC Audio Tutorial/hardware.
<edit>: GOOD: Used TeensyTransfer to format Audio Serial Flash at 24 MHz, then wrote two text files that read back at 180 MHz. Recompiled at 216 MHz and first read output was faulty - started okay - but slow - then stuttered? Subsequent reads would not repeat on either file. Reads fine at 240 MHz.
Did a longer 5+ MB dir listing into a text file - wrote that - reading it back first time gave a "teensytransfer: Communication error" after some time - did a 'reset' retrying that now saving output to a file to compare - same length and top and bottom look the same. The winbond chip says it is good for 104MHz ( RAM only 24 MHz ) - - looks like SerFlash asks for 50 MHz max?: "#define SPICONFIG SPISettings(50000000, MSBFIRST, SPI_MODE0)". Does HID transfer limit the read rate? I just changed that to 80MHz - would 90 MHz give better multiply options? Tried with 90 MHz - file read looks good.
First test was 180 Mhz started and played fine - same when dropped to 24 MHz! Went to 72 and it is playing okay.
PROBLEMS:
The song does not play through at 240 MHz. Did 240 between 180 and 24 and it stopped during compile for 24, went back to 240 and it stopped, hit a 'reset' it started again then stopped.
Even worse at 216 Mhz - pitch is OFF - half speed? and it may only play a couple seconds if at all - but does not hang. Added setup() for BUILTIN_LED and qBlink code in loop() as shown below and it always runs.
- Plugged in PJRC Tutorial 8GB flash and 216 MHz same behavior
- Only Serial output seen is "Start playing" - never shown any trouble on SD card init.
- Install is IDE 1.6.9 with TeensyInstall 1.29b3 and related boards.txt. No other changes or signs of trouble on other sketches at any speed.
- added a PJRC volume wheel and a DigiKey winbond 16MB I didn't test yet, thought I had a mic but started without it. The same 16GB AData class 10 used with PJRC Audio Tutorial/hardware.
Code:
if ( eMs > 1000) {
eMs = 0;
qBlink();
}<edit>: GOOD: Used TeensyTransfer to format Audio Serial Flash at 24 MHz, then wrote two text files that read back at 180 MHz. Recompiled at 216 MHz and first read output was faulty - started okay - but slow - then stuttered? Subsequent reads would not repeat on either file. Reads fine at 240 MHz.
Did a longer 5+ MB dir listing into a text file - wrote that - reading it back first time gave a "teensytransfer: Communication error" after some time - did a 'reset' retrying that now saving output to a file to compare - same length and top and bottom look the same. The winbond chip says it is good for 104MHz ( RAM only 24 MHz ) - - looks like SerFlash asks for 50 MHz max?: "#define SPICONFIG SPISettings(50000000, MSBFIRST, SPI_MODE0)". Does HID transfer limit the read rate? I just changed that to 80MHz - would 90 MHz give better multiply options? Tried with 90 MHz - file read looks good.
Last edited:
manitou
Senior Member+
Question: what would I need to do to use the PTE* pins with SPI to read the microSD with the SD library ?
As noted in an earlier post (#243), I was able to do a low-level sector-read of the microSD using 4-bit SDIO on the PTE* pins, and one should be able to do SPI IO as well. (I did both on the mbed K64). PTE* are SPI1 (MUX(2))
mbed speak: SDFileSystem sd(PTE3, PTE1, PTE2, PTE4, "sd"); // MOSI, MISO, SCK, CS
As noted in an earlier post (#243), I was able to do a low-level sector-read of the microSD using 4-bit SDIO on the PTE* pins, and one should be able to do SPI IO as well. (I did both on the mbed K64). PTE* are SPI1 (MUX(2))
mbed speak: SDFileSystem sd(PTE3, PTE1, PTE2, PTE4, "sd"); // MOSI, MISO, SCK, CS
Last edited:
PaulStoffregen
Well-known member
Any chance you could retry this with a fresh copy of Arduino 1.6.9 and Teensyduino 1.29-beta3 ? And check the messages Arduino prints, you make sure it's using the audio lib from that copy, rather than one in a location like Documents/Arduino/libraries?
This sounds exactly like the problems fixed by this change which went into the audio lib right before 1.29-beta3. In particular, the #define MCLK_SRC for the 216 MHz case is critical. Without that, the 48 MHz USB oscillator is used, because 216 MHz mode can't generate USB clocking by dividing the system clock.
I'll take care of the ADC library.
I think it won't be too much work, as the registers are similar (or even the same) as in Teensy 3.1/3.2. I had a look at the technical manual and it seems pretty similar.
Robin contacted me to send me a board, but I don't have much time to work on this (soon I hope to be Dr. pedvide
).
I think it won't be too much work, as the registers are similar (or even the same) as in Teensy 3.1/3.2. I had a look at the technical manual and it seems pretty similar.
Robin contacted me to send me a board, but I don't have much time to work on this (soon I hope to be Dr. pedvide
).
KurtE
Senior Member+
I am no expert here, but have played some with SPI (more indirectly through other libraries, such as ILI9341...), but I think maybe a first step might be to create an SPI1 object in the SPI library.
It looks like there is one for the TeensyLC, so unless someone else has already done so, I might take a crack at it. Trying to decide which other library to try out with it. Was thinking maybe trying some of the stuff on the propshield. Like maybe the spiflash library.
I see there is a sort-of hard coded hack to allow usage of the library for Arduino 101. So could define some define that tells it at compile time to use SPI1 object, or alternatively add some method that you can pass in pointer to SPI object to use. Can not do that on constructor as that is part of the main source file, but could add it as another optional argument to the end of the begin, which defaults to &SPI. Might try it, but that would require indirect calls for each of the SPI functions...
Might be fun to try.
Edit: Started hacking spi library to add SPI1... Not sure about how yet to runtime set which SPI library as at least with how the LC is handled they are two distinct C++ classes with no common base class...
Last edited:
MichaelMeissner
Senior Member+
As we add more buses, etc. to the microprocessors, I really wish we could go back in time, and add the i2c/spi/etc. object to the to constructor for various things that do i2c, spi, etc. Right now, it is hard to use existing libraries with the 2nd (or 3rd) i2c bus, and now the 2nd spi bus. It would be nice if we could just change the constructor and automatically get t3_i2c support for instance, rather than having parallel libraries.
sumotoy
Well-known member
Not really, the serial remain stuck but appears correctly in arduino or terminal and, most interesting, remain stuck between restarts!
I have installed a serial analyzer yesterday to understand what's broken and the receiving part of the serial port in computer side it act like disconnected.
To resume, had to go in driver advanced parameters, change the serial port number and restart, this fixed the issue.
Anyway I've updated this morning to win 10 since it solved also the 'recompiling all annoing issue' I had with win 7.
KurtE
Senior Member+
Me Too!
Alternatively as part of a two step object setup. Example: constructor, begin(...). I often have liked two step setups as you can then control the order things done which I believe typically you can not do with constructors. Example: If I need SPI to be initialized before my display class is initialized...
I guess it is always a set of tradeoffs. Example: with SPI, my first instincts would be to create a base class: call it SPIClass and from that I would potentially create SPI0Class and SPI1Class that are both derived from SPIClass... i.e like HardwareSerial for Serial1, Serial2... Note: I use this fact with some of my own libraries and/or knowing that HardwareSerial is derived from Stream...
But this would probably involve having most all of the functions be virtual, then we can simply pass in pointer (reference) to base class and when we do something like: pspi->transfer(c);
It will use the right buss to output the character. Downside is that currently things like: SPI.transfer(c); the code is placed inline, which gives you maximum speed...
So not sure if anyone would be interested in this? Alternatively could create wrapper class something like SPIS, where potentially takes an index to which SPI object to use and have an implementation like:
Code:
uint8_t SPIS::transfer(uint8_t c) {
if (spi_index_ == 0)
return SPI.transfer(c);
else
return SPI1.transfer(c);
}Again not sure which way (if any) to go!
defragster
Senior Member+
Yes - My win 7 machine is waiting for that update - and will compile Audio sketches much faster . . .
The build window text was still there . . .
With :
#define MCLK_MULT 2
#define MCLK_DIV 42
240MHz works
Edit:
(1 / 21) gives the same but may be better (MULT smaller)
For 216 MHz:
#define MCLK_MULT 1
#define MCLK_DIV 19
sounds better.
#define MCLK_MULT 2
#define MCLK_DIV 42
240MHz works
Edit:
(1 / 21) gives the same but may be better (MULT smaller)
For 216 MHz:
#define MCLK_MULT 1
#define MCLK_DIV 19
sounds better.
Code:
#elif F_CPU == 216000000
#define MCLK_MULT 1
#define MCLK_DIV 19
#define MCLK_SRC 0
#elif F_CPU == 240000000
#define MCLK_MULT 1
#define MCLK_DIV 21
Last edited:
defragster
Senior Member+
SAME MACHINE :: Using Franks numbers edited (only) into "Output_i2s.cpp" ( do QUAD and SPDIF needs edited too? )- Just started 240 MHz playing on the same machine. It started well - did a couple K66 resets and it restarted. However it then failed to complete playing.
216 compiled : same broken pitch and quits after a few seconds. and sometimes it won't start at all and the "Start playing" text just STREAMS OUT so this line is failing :: playSdWav1.play("SDTEST2.WAV");
On my way to my proper faster desktop: IDE is NEW 1.6.9 with TeensyDuino 1.29b3 and boards text. - Update soon
216 compiled : same broken pitch and quits after a few seconds. and sometimes it won't start at all and the "Start playing" text just STREAMS OUT so this line is failing :: playSdWav1.play("SDTEST2.WAV");
On my way to my proper faster desktop: IDE is NEW 1.6.9 with TeensyDuino 1.29b3 and boards text. - Update soon
Did'nt look or test.. so i don't know.
Are you really sure that you're using up-to-date libs ?
Possible error: I noticed, that when changing F_CPU, the Teensy 3.5 need a power-off / on cycle (perhaps somthing with i2s-reset is not working) when using i2s.
so try power-off..on
- Status