Teensyduino 1.37 Beta #2 (Arduino 1.8.3 support)

Status
Not open for further replies.
OK... tracked down the problem.

Was in some old code... the most basic function "fastDigitalWrite" had the SET/CLEAR values transposed... so basically set was unsetting and unset was setting.

I tested that function using leds and "blink".... which made it hard to test that HIGH->ON and LOW->OFF.

Ended up making a SoftSPI class I could drop into my main classes. It ended up worse than the SPI lib cause fastDigitalWrite is used for everything.

I'd almost guess the SPI with FIFO and from standard lib will work when I put them back in.

glitches aside, the lower clocked Teensy 3.1 @72Mhz is giving the Due benchmarks a good workout.
 
Just noticed something strange. Noticed that after I uploader some sketches early this morning my machine's fan kept spinning away. When I went to check something called teensy_reboot.exe was running and eating up CPU time. I just ended the task but forgot to check if teensy loader was open or not so not sure if the two are related. Also not sure if its related to 1.37-beta2. To be honest never saw that one before now.

Mike
 
Actually again, it would be great if you could pick up at least part of my Pull request #242 for DMA ...

There are three parts in it:
1) The DMA Channels were wrong for T3.5 for SPI1/2 - You already did this one.
2) Trying to do DMA on T-LC will often fault the processor as it was at times doing 8 bit writes to some registers that require 32 bit writes. This is Tni #241
3) DMA transfer count is broken as I mentioned in: https://forum.pjrc.com/threads/4304...ple-SPI-busses?p=142098&viewfull=1#post142098
The problem is if you call it: first with a count of 0x6 it works, then call with 0x200, it works, then if you call again with 6 it actually sets the count to 0x206... That is before it assumed if count < 512 you are using 9 bit count and rest is link field, so it leaves the upper bits including the 0x200 bit from previous count... Alternatively I may just update my SPI code to directly set BITER/CITER...

Thanks Paul
 
I replaced the wiring.h with the new one and seems to resolve the issues with min/max errors. Tried it with the EKF using Eigen lib as well as just <vector>.

Was tni referring to the c++11 version or the c++14 version in msg #17? Don't know enough why it is not recommended?
 
I tested with ILI9341 graphicstest. Seems to work fine.

Going to do some other testing with an issue on OctoWS2811, then package up 1.37-beta3 this afternoon or tomorrow morning.

If anyone seems a case where this min/max could break Arduino sketches, please speak up asap! It would be nice to also have C++ standard library headers & features work, but Arduino compatibility comes first.
 
Just a quick update... I've fallen a couple days behind. A couple internal issues here with PJRC and communication with Arduino devs have taken more time than expected.

As far as I know, issues with OctoWS2811 on newer WS2812B are the only remaining issue blocking 1.37-beta3, and hopefully a final 1.37 release soon.

If there are other urgent issues or fixes I've missed, please remind me now and I'll try to get them into 1.37-beta3, hopefully by Thursday morning.
 
Status
Not open for further replies.
Back
Top