Teensyduino 1.50 Released

Status
Not open for further replies.
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.
 
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:
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:
screenshot.jpg

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...
 
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:
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?
 
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.
 
Status
Not open for further replies.
Back
Top