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

Thread: Teensyduino 1.50 Released

  1. #51
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,564
    I will connect the scope this evening.
    The speed on atmega or such can't be much higher than 4MHz I think.
    Maybe we should limit it to 10MHz?
    Or less??

    The mentioned library does not work now on T4 so we need a solution.

  2. #52
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,564
    Ok.. managed to kill the display.. lol, no idea, how
    I will stop bothering you and put this on pause until i have a replacement for the display.
    Last edited by Frank B; 02-10-2020 at 09:08 PM.

  3. #53
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    6,354
    Hi @Frank, sorry to hear about your display...


    FyI I ran the LCDemo7Segement on A T2... (Don't have many of these) This one was part of my XV Lidar Controller V1.2 of GetSurreal.com...

    The only thing I did was to connect it up to Logic Analyzer...

    You can see the pulse widths/spacing hopefully in this one:
    Click image for larger version. 

Name:	screenshot.jpg 
Views:	14 
Size:	26.3 KB 
ID:	19017

    This is part of an output of 4 16 bit outputs... There is a gap of about 22us between the words...

    And this repeats maybe every .25 seconds...

  4. #54
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,564
    I'm using a 8 digit 7-segment display.
    it worked with this replacement for shiftout up to 960Mhz:
    Code:
    static const int maxSpeed = 10000000ULL; //10 MHz
    static const int maxSpeedBeforeDelay = 392000000ULL; //max F_CPU_ACTUAL before doing delays (measured for 10MHz, -O2)
    
    void shiftOut_msbFirst(uint8_t dataPin, uint8_t clockPin, uint8_t value)
    {
        uint32_t mask;
        
        if (F_CPU_ACTUAL > maxSpeedBeforeDelay) {        
            uint32_t cycles = (F_CPU_ACTUAL / 3 / maxSpeed);
            uint32_t t = ARM_DWT_CYCCNT;
        
            for (mask = 0x80; mask; mask >>= 1) {
                digitalWrite(dataPin, value & mask);
                do {;} while(ARM_DWT_CYCCNT - t < cycles);        
                t += cycles;
                
                digitalWrite(clockPin, HIGH);
                do {;} while(ARM_DWT_CYCCNT - t < cycles);
                t += cycles;
            
                digitalWrite(clockPin, LOW);
                do {;} while(ARM_DWT_CYCCNT - t < cycles);
                t += cycles;
            }
        }
        else
        for (mask = 0x80; mask; mask >>= 1) {
            digitalWrite(dataPin, value & mask);
            digitalWrite(clockPin, HIGH);
            digitalWrite(clockPin, LOW);
        }
    }
    The numbers can be optimized somewhat, maybe.
    Goal is to reach the maxSpeed as close as possible (but not higher) for every f_cpu_actual.
    Note, it is a 1/3 - 2/3 cycle (25%/75%) - not sure how to come 50/50 closer. But it was OK for the MAX7219.

    Edit: It takes the data at the rising edge of clk - but i noticed, the data-bit needs to be set some time before. (Datasheet says 25ns)
    But we should'nt optimize for THAT chip... on the other hand, the MAX should work...

    feel free to play with it

    good night.

    Edit: For better code see pullrequest in the next post.
    Last edited by Frank B; 02-12-2020 at 06:31 PM.

  5. #55
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,564
    Got the new displays.

    so, finally:
    https://github.com/PaulStoffregen/cores/pull/433/files

    Its now nearly 50% clock ratio.
    Runs fine for every F_CPU_ACTUAL.
    Last edited by Frank B; 02-12-2020 at 06:54 PM.

  6. #56
    Junior Member
    Join Date
    Mar 2017
    Location
    Australia
    Posts
    13
    For what it's worth, https://www.pjrc.com/teensy/td_download.html is displaying some older 1.49 information:
    Teensyduino 1.49 supports Arduino versions 1.8.5 and 1.8.7 and 1.8.8 and 1.8.9 and 1.8.10 and 1.8.11.
    Future versions of Teensyduino will drop support for Arduino 1.8.7 and 1.8.8 and 1.8.10

  7. #57
    Just tried using V 1.50 of Teensyduino with Arduino 1.8.11 on an old Raspberry Pi Model 3B (not plus), which I use from time for time for testing my Teensy project on. (I compile and develop mostly on Windows). Anyway, I haven't used any Raspberry Pi's in a while and especially not this old box, but what a failure!

    First, it seems Arduino.1.8.11 and a fresh copy of the latest Raspbian Buster OS (I think released a few days ago) do not get along at all. The IDE is super slow, basically unusable. Then after installing the Teensyduino 1.50 to the machine and launching the IDE with a previously compiled Teensy program running on a Teensy 3.2, that dumps sensor data (several numbers per line) to the serial monitor repeatedly in a 100 uSec loop (or as fast as the serial I/O can keep up). This type of thing runs fine in Windows 10, but on this old Raspberry Pi 3B, it filled a page or two of the Serial Monitor and then locked up, forcing a reboot. Same thing when dumping said data to the Serial Plotter.

    So I erased the SD card on the Pi and installed fresh copy of the latest Raspbian Buster OS and tried Arduino.1.8.10 with Teensyduino.1.50. Now my Teensy program can dump lots of data to the Serial Monitor/Plotter just fine. So clearly there are serious issues with Teensy 1.50/Arduino 1.8.11 on a Raspberry Pi 3B.

    I haven't tried this on newer Raspberry Pi boxes (3B+ and 4) nor with the Teensy Beta 1.51/Arduino.1.8.12. Is Arduino 1.8.11 well-known to being problematic on Raspberry Pi's and is everyone moving quickly away from it?

  8. #58
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    21,480
    Quote Originally Posted by Bryan42 View Post
    Is Arduino 1.8.11 well-known to being problematic on Raspberry Pi's and is everyone moving quickly away from it?
    Yes, seems so. Arduino 1.8.11 uses AdoptOpenJDK Java, which causes trouble on some systems.

    Arduino 1.8.12 was recently released, reverting back to Oracle Java. Please give 1.8.12 a try, using Teensyduino 1.51-beta1.

    https://forum.pjrc.com/threads/59566...no-1-51-Beta-1

  9. #59
    Quote Originally Posted by PaulStoffregen View Post
    Yes, seems so. Arduino 1.8.11 uses AdoptOpenJDK Java, which causes trouble on some systems.

    Arduino 1.8.12 was recently released, reverting back to Oracle Java. Please give 1.8.12 a try, using Teensyduino 1.51-beta1.

    https://forum.pjrc.com/threads/59566...no-1-51-Beta-1
    Will do. Thanks for the fast response.

  10. #60
    Have confirmed with a quick test that the Arduino 1.8.12 and Teensyduino 1.51beta combination works fine for my Teensy 3.2 application on a Raspberry Pi 3B.

Posting Permissions

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