Has anyone been using the latest FastSPI_LED2 library with a teensy 3.1? I have a strip of ws2801’s (strip of 12) that worked with a teensy 3.0. Now with a teensy 3.1 no leds in the strip work. I did have to go into the library and add new ifdefs for the teensy 3.1 (anywhere I saw an ifdef for a teensy 3.0 I added support for the 3.1).
There’s other work that needs to be done to make the 3.1s work - I have a set of 3.1
but for a variety of not fun reasons haven’t had a chance to even unpack them.
Thanks, for the response. Any pointers you could give me of what I need to change in the library would be helpful if possible. I figured since the 3.1 was very similar to the 3.0 it would be just a matter of making sure all the teensy specific code was compiled in for the 3.1 just like the 3.0.
I haven’t had a chance to go through the full data sheet to see what have changed - I don’t believe pin accesses have - but spi port access may have. I also need to validate instruction timings on the new chip.
The Teensy 3.1 benchmarks faster when overclocked from 72 to 96 MHz than the Teensy 3.0 overclocked from 48 to 96 MHz (perhaps because of faster fetching from the flash memory), so indeed those instruction timings might be off if they matter.
Yeah - they do - I want to change how i’m doing the timings for the teensy anyway - it looks like there’s a clock cycle counter that I can use to get the timings that I need, at least close enough - which should do better than trying to do instruction cycle counting - which can get thrown off by memory fetch times.
Good idea. We seem to be migrating our microcontrollers back up the complexity ladder that larger computers took decades ago, eg with ARMs and then faster ARMs. If so, deterministic instruction timing gets dicier.
Even the very simplest of caches - like fetching a double word from Flash because the CPU needs memory faster than flash can deliver so we get two words and usually use both before the next fetch - can start throwing the timing off. So if there’s a way to get fast absolute clock timing on the Teensy, that would be good. Of course if you have to test and loop much to use it, that might not work when code is already close to the limit of getting things done in time, but if you have plenty of cycles to burn - as the faster systems will tend to give us - such approaches become both neccessary and sufficient.
Yup, very aware of that - in fact the prototype code I have for the due is already doing this.