Please give this simpler USB fix a try. It makes USB work at 180 and 216 MHz.
https://github.com/PaulStoffregen/cores/commit/7a2c0037b81a6221e15502a99a39bdc6ffe970f7
OMG..that was enough ?
Please give this simpler USB fix a try. It makes USB work at 180 and 216 MHz.
https://github.com/PaulStoffregen/cores/commit/7a2c0037b81a6221e15502a99a39bdc6ffe970f7
you might be able to get 1 second timing from thisIs there a way to get second or subsecond interrupt timing feedback from the independent RTC time crystal hardware? My glance at the FM didn't suggest there was.
you might be able to get 1 second timing from this
https://github.com/manitou48/teensy3/blob/master/rtc.ino
I measure less than 10ppm drift on both MCU and RTC crystals, but lacking a BOM, I don't know what the crystal parts or specs are ...
EEPROM sketch reads EEPROM, but hangs in write() ???? works on teensy 3.2
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..
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;
}
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.
Does Audio work ?
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.
.
The DMASPI example does not work.
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
Updated Post#3 up to Post#288
Question: Will the faster clock speed allow for higher resolution PWM at higher frequencies than the Teensy 3.2? (https://www.pjrc.com/teensy/td_pulse.html)
Noticed that SPI performances vs CPU clock are not as I expected, for example 180Mhz has better performances than 192Mhz
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
.
.
.
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.
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)
Good news
But which rate times ?