Forum Rule: Always post complete source code & details to reproduce any issue!
Page 2 of 2 FirstFirst 1 2
Results 26 to 35 of 35

Thread: Teensyduino 1.37 Beta #2 (Arduino 1.8.3 support)

  1. #26
    Member
    Join Date
    Oct 2015
    Location
    Mt Beauty, Aus
    Posts
    23
    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.

  2. #27
    Senior Member
    Join Date
    Jan 2013
    Posts
    843
    Is there a reason Teensy LC still has broken DMA?

    https://github.com/PaulStoffregen/cores/pull/241/files

  3. #28
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    3,227
    Quote Originally Posted by tni View Post
    Is there a reason Teensy LC still has broken DMA?

    https://github.com/PaulStoffregen/cores/pull/241/files
    Yes please - I will probably pull my semi duplicate (242) as the second half of it was already done (correct DMA channels for T3.5)

  4. #29
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    536
    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

  5. #30
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    3,227
    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/43048...l=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

  6. #31
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    16,243
    Quote Originally Posted by mjs513 View Post
    @PaulStroffregen. Just remembered that I had a sketch that uses the Eigen library (right now I have 3.25) for a Kalman filter that I use in conjunction with the FreeIMU library. I figured I would give that one a try and received numerous errors associated with min/max:
    Ok then, let's give tni's suggestion from msg #17 (which he doesn't recommend) in 1.37-beta3.

    https://github.com/PaulStoffregen/co...30126705b555e6

  7. #32
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    536
    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?

  8. #33
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    16,243
    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.

  9. #34
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    16,243
    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.

  10. #35
    Administrator Paul's Avatar
    Join Date
    Oct 2012
    Posts
    272
    1.37-beta3 is available. Closing this thread. Please comment on 1.37-beta3.

    https://forum.pjrc.com/threads/44904...no-1-37-Beta-3

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •