Teensy 4.0 First Beta Test

Status
Not open for further replies.
Originally Posted by mjs513
Since I was on line, gave the change a try, it worked.

same set up, his test sketch except with the change to startup, getting between 2545 and 2575 ticks.
So almost the same speed?
I would say its just about the same.
 
Kurt, SERIAL_7E1 and SERIAL_7O2 do not work.
Kurt, buffer problem...
If I use
Code:
Serial1.print("012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789\n");
 Serial1.print("012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789\n");
 Serial1.print("012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789\n");
 Serial1.print("012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789\n");
output is:
Code:
Hello world
0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234
- something is missing :rolleyes:
 
I would say its just about the same.
Yes, I thought that.. there is nothing to cache, DMAMEMORY is accessed one time. It will be the same for most, if not all DMA operations I think.
Caching makes sense if that memory is used for other purposes, too. Like a displaybuffer if you read+write the buffer, too. But then there must be a mechanism to sync the cache with the ram - Pauls cache-functions (great btw) can do that. The question is, when is it faster to use NOCACHE or to use the functions? I think the answer is: It depends.. :) maybe some things are faster with the functions, others with NOCACHE or WRITETHROUGH (<- need again extra care if reading is desired..). With very large buffers we have to take into account, that otherwise useful cache-contents can get lost. For example if a font is stored in PROGMEM.
 
Last edited:
Looks like time for some more testing...

Right now playing with Dynamixel servos. hooked up to Serial1 through a Robotis Open RS485 expansion board (also does TTL). It has the hardware setup for
TX, RX, Direction pin, plus +3.3v and 5v...

Did some initial editing of my BioloidSerial library to work with it, currently only with Direction pin, will try later with setting Serial port into half duplex mode...

Part of it appears to be working but my library is not picking up the responses... Need to debug, to see where the issue might be...

Looks like the data should be there. Looking at LA output.

screenshot.jpg
Top line is the DXL buss that the servos see and respond. Line 2 is pin 0 which should be the RX pin, I receive the data back on. Line 3 is TX pin, where the commands go out and Line 4 is the direction pin output which is driven by Serial1...

Again maybe just problem with my library... First off see if I am receiving anything... Note: I hacked up my test app, to use Serial2 for the Serial inputs and outputs instead of Serial so I could use commands... And that appears to be working fine.


EDIT: Timeout issue in the library. When the library was originally written it was for AVR 8 bit boards running at 16mhz and timeouts were done by timeout loops.
When I added support for t3.x I just changed the timeout value... But that was not caught in the #ifdef for t3.x and even if it did, would not be high enough...

Probably time to break down and use a timeout using something like an elpasedmillis...
 
Last edited:
Hooked Servo into my Combo app - the IR Receiver is triggering it seems from Servo noise - with no IR Tx buttons on remote pressed.

Mike can you put a servo with your IR receiver? Do you see odd behavior? For Demo I was going to tie buttons to Servo pos ++ and --, but IR reception is compromised getting 0xF's instead of normal button code. Is there a timer conflict on the select pins or system wide?
 
Tried SD-Library with audioshield: Does not work, or I'm doing something wrong.. I'll try to find the problem. Maybe SPI.

Edit: Sd2Card.cpp needs some love and edits.
 
Last edited:
Mike can you put a servo with your IR receiver? Do you see odd behavior? For Demo I was going to tie buttons to Servo pos ++ and --, but IR reception is compromised getting 0xF's instead of normal button code. Is there a timer conflict on the select pins or system wide?

Setting it up now - will update this post when done. Have bad cold my mind is in a fog - may take a little while :)

UPDATE:
Ok, just tested it and yeah, am seeing strange things. The servo movement seems a little more jerkier than before and the IR reading are mostly FF's or random numbers unlike in individual tests. Same effect if you are using Servo or PWMServo libraries. For ref here is the sketch:
Code:
/*
 * IRremote: IRrecvDemo - demonstrates receiving IR codes with IRrecv
 * An IR detector/demodulator must be connected to the input RECV_PIN.
 * Version 0.1 July, 2009
 * Copyright 2009 Ken Shirriff
 * http://arcfn.com
 */

#include <IRremote.h>

int RECV_PIN = 11;

IRrecv irrecv(RECV_PIN);

decode_results results;

//#include <PWMServo.h> 
#include <Servo.h>

//PWMServo myservo;
Servo myservo;  // create servo object to control a servo 
                // twelve servo objects can be created on most boards
 
int pos = 0;    // variable to store the servo position 

void setup()
{
  Serial.begin(9600);
  // In case the interrupt driver crashes on setup, give a clue
  // to the user what's going on.
  Serial.println("Enabling IRin");
  irrecv.enableIRIn(); // Start the receiver
  Serial.println("Enabled IRin");

  myservo.attach(9, 544, 2000);  // attaches the servo on pin 9 to the servo object 
  myservo.write(0);
  Serial.printf("Angle Read %d\r\n", myservo.read());
  delay(5000);
}

void loop() {
  for(pos = 0; pos <= 180; pos += 1) // goes from 0 degrees to 180 degrees 
  {                                  // in steps of 1 degree 
    myservo.write(pos);              // tell servo to go to position in variable 'pos' 
    delay(15);                       // waits 15ms for the servo to reach the position 
    if (irrecv.decode(&results)) {
      Serial.println(results.value, HEX);
      irrecv.resume(); // Receive the next value
    }
  } 
  delay(100);
  for(pos = 180; pos>=0; pos-=1)     // goes from 180 degrees to 0 degrees 
  {                                
    myservo.write(pos);              // tell servo to go to position in variable 'pos' 
    delay(15);                       // waits 15ms for the servo to reach the position 
  } 
  delay(1000);
}
 
Last edited:
Tried SD-Library with audioshield: Does not work, or I'm doing something wrong.. I'll try to find the problem. Maybe SPI.
Clock is on pin 14. Hm.. Does someone know if it is possible to use pin14 for spi-clck? I have not looked at the pin-configurations so far.

Edit: Err. wrong,the board does that :) all good with sclk.

Edit: Sd2Card.cpp needs some love and edits. Adding the #defines __IMXRT* to some other files needed.
 
Last edited:
Setting it up now - will update this post when done. Have bad cold my mind is in a fog - may take a little while :)

Just remember Servo VCC is 5V :( - I started Servo with pin #8 and moved to #2 for control - LedControl LED's are now 3/4/5. I see #22 and #23 are also open if it is a timer conflict. Even just SWEEP example with IR powered shows flicker on yellow Rcv LED.
 
Just remember Servo VCC is 5V - I started Servo with pin #8 and moved to #2 for control - LedControl LED's are now 3/4/5. I see #22 and #23 are also open if it is a timer conflict. Even just SWEEP example with IR powered shows flicker on yellow Rcv LED.
Yeah had servo on 3.3v :). Probably pulled too much power. Anyway:
1. No yellow lite flashing while servo moving for me. Using 11 for IR sensor and 9 for servo.
2. Still seeing a lot of FF's but at least the code is the same when it does the reading. If you just hold the button down it just gives ff's.
3. Now the servo is on 5v its running a lot smoother :)
 
FYI,
new T4 beta arrives (#27) to swap out with my impaired unit. New beta unit uploads properly. ;) Only differences I expect are MAC address in fuses and drift in crystals
Code:
  crystal drift (ppm)
         24MHz   32KHz
T4beta1   -3.2    -4.7   1052
T4beta1-2 -4.1    -4.3
T4beta2     1     -6     1062
T4beta2-2 -11     10     1062
T4-1      -11     -3     1062
T4-2      -10     -5
T4.0-1    -23     -0.5
T4.0-2    -26     -2.5
T4.1       -7     -2
T4.1-1    -11     -5.5
T4.1-2    -12     -3
T4.1-3    -10      1
EVK       -14    -54   1052
EVKB       -6    -52
NXP1062    -9     9
T4mm      -45    -6   sparkfun T4 micromod
Measured with GPS PPS and GPT timer clocked by either 24mhz or 32khz crystals.
https://github.com/manitou48/teensy4/blob/master/gpsgpt.ino

other MCU crystals https://github.com/manitou48/crystals/blob/master/crystals.txt
 
Last edited:
servos can need a lot of power.. more than usb allows. be careful
Frank: Yep - no argument here. Typically I power them from separate 5v, if I have a bunch of them. For one its never been on issue when I am on my desktop.:)

Tim: could be the timers, check irrecv.cpp around line 167 and irrecvint.h.

EDIT: Playing around with the lag and tolerance numbers and watching the data carefully, think the issue is if you hold the button even a fraction too long you get a false read. If I tapped it real quick I would get single reads and no ff's but if too slow to release would get the actual readings plus a ff's sometime multiple. Timing probably but have to search where - need a debouce function :)
 
Last edited:
SD: Have cardinfo() working. Will create a pullrequest tomorrow. Too late now, and I want to clean it up first, when I'm more awake :)
 
Setting it up now - will update this post when done. Have bad cold my mind is in a fog - may take a little while :)

UPDATE:
Ok, just tested it and yeah, am seeing strange things. The servo movement seems a little more jerkier than before and the IR reading are mostly FF's or random numbers unlike in individual tests. Same effect if you are using Servo or PWMServo libraries. For ref here is the sketch:

Good sketch - thanks for testing Mike- you see what I saw and with your sketch I see what you saw - except I clearly have flickers small and bigger on IR Yellow Rcv indicate LED - even with the IR LED covered. And Sermon shows phantom IR reads unless servo power removed.

Not running nut powered are my OLED ssd1306 and LedControl 8 digit and they are showing affects on the images they are holding from last run. The multiplexed LED are pulsing and a flicker scan is pulsing the OLED as the servo cycles.

PROBLEM: GND ISSUE. That Servo is pulling Gnd across breadboard. Move GND wire from open BBoard area to GND pin row - or touch USB plug and all is well. Even on the end of the wire from GND row to (-)RAIL and it show noise.
With better GND the IR receive is not throwing 0xF's like it was before!


My setup it two long BBoard together with T_4 and T_3.1 ( debug ) and T_3.6 on same hub from PC (now 5V 2.5A POWERED)- so common GND to each Teensy and from each to BBD rails. Also pulled GND from T4 end pin to far (-)Rail - common to T_3.6 - No flicker there and the Servo is moving 10° on pressing the IR Remote control buttons.
>> Gotta get to mailbox - my phone says PJRC delivered.
 
SPI DMA

My first cut at simple SPI DMA on T4, transmit only. Checked SPI clocks on scope. Data rate is close to SPI CCR clock rate.
https://github.com/manitou48/teensy4/blob/master/spidma.ino
Code:
      SPI CLOCK 4000000 CCR freq 4.0 MHz
      tx 1024 samples 1990 us  4.1 mbs   scope clock 3.97 mhz
      SPI CLOCK 8000000 CCR freq 7.5 MHz
      tx 1024 samples 1080 us  7.6 mbs  scope 7.57 mhz
      SPI CLOCK 16000000 CCR freq 15.1 MHz  
      tx 1024 samples 570 us  14.4 mbs   scope 14.9mhz
      SPI CLOCK 30000000 CCR freq 25.1 MHz
      tx 1024 samples 370 us  22.1 mbs  ? scope 25 mhz  Vpp 2.74 v
      SPI CLOCK 40000000 CCR freq 37.7 MHz
      tx 1024 samples 260 us  31.5 mbs  scope 37.9  Vpp 2v
SPI is still running, need to fix that. Add Rx DMA, try 16 and 32 bit frame size, though the clock doesn't have gaps that i can see.


At 25.1 MHz waveform is a little distorted, Vpp 2.74v. At max speed, 37.7 MHz, waveform distorted, Vpp 2v. I haven't tested with a SPI device.


EDIT: github update, simple DMA TX, polling, and SPI stops properly. also added spidma2.ino with DMA TX and RX, polling, jumper MOSI to MISO for error check.
 
Last edited:
servos can need a lot of power.. more than usb allows. be careful :)

Can confirm it was GND across BreadBoard. I do have 3 Teensy and the stuff on - inline cheap power meter says 4.88V and 0.17-0.23 Amp total - running this micro servo shows it might be peaking at 0.33A total. Plugging hub power back in goes to 5.03V and 0.00A from PC.

Now disconnected that for moving to the impressive looking breakout from PJRC - on plexiglass with rubber feet.
 
PROBLEM: GND ISSUE. That Servo is pulling Gnd across breadboard. Move GND wire from open BBoard area to GND pin row - or touch USB plug and all is well. Even on the end of the wire from GND row to (-)RAIL and it show noise.
With better GND the IR receive is not throwing 0xF's like it was before!

My setup it two long BBoard together with T_4 and T_3.1 ( debug ) and T_3.6 on same hub from PC (now 5V 2.5A POWERED)- so common GND to each Teensy and from each to BBD rails. Also pulled GND from T4 end pin to far (-)Rail - common to T_3.6 - No flicker there and the Servo is moving 10° on pressing the IR Remote control buttons.
Tim: Glad you found the problem. My ground line runs are as long as yours I don't think. Don't use the T3.2 for debug any more unless I am testing something specific. Everything goes to serial. My GND connections are typically all close to the GND pin of the T4. Maybe an a couple inches.

Frank B
SD: Have cardinfo() working. Will create a pullrequest tomorrow. Too late now, and I want to clean it up first, when I'm more awake
Nice work Frank. Looked at it a while ago, you have more patience than I do :)
 
Only difference I expect is drift in crystals

Looks like you got the later beta boards, where we were much closer with the capacitors. Earlier ones (number under 22) probably have much more error, since we were still learning which capacitors to use (and NXP's specs and examples were of little help).
 
When I looked that the Tools/Port menu it did not show any Teensy stuff in it, Nor the port associated with the Teensy.

All I did was to close down the Arduino IDE and the Teensy App, and restarted it, and it then showed the Teensy 4 (in I believe the waiting to program state). I then compiled and downloaded sketch and it worked just fine.

I've seen something like this a few times, usually after many hours of use (Linux, 64 bit). I believe there may be a bug lingering in teensy_ports, or perhaps in the Arduino IDE discovery manager code I added to talk to teensy_ports. Restarting Arduino always seems to fix it.
 
KurtE said:
Hi @defragster, - Works for me...
Note: you mentioned String.cpp... Maybe typo or wrong file? I copied the wstring.cpp that is in the cores directory. I simply copied it from the teensy3 directory to the teensy4 directory.

Yes - I believe you are right!
When I updated the above sketch to:

...

But compiles fine if I copy stream.cpp from Teensy3 to Teensy4...

Can create PR if desired. Not sure to continue it in my Core SPI fixes or it's own?

Update - Created PR #324

That was a typo - yes wString.cpp was copied and just confirmed that with Stream.cpp copied to T4 the other posted sketch works.

Problem was not getting a CLEAN build - adding that file didn't trigger - even though I did a board change with the way it now TEMPS per Board. Did a Close IDE after Stream.cpp copy build failed - then restarting built fine and runs.

Soldered pins to Audio board - I had a Vol Pot and Mic I put on too and it is working.
 
I've seen something like this a few times, usually after many hours of use (Linux, 64 bit). I believe there may be a bug lingering in teensy_ports, or perhaps in the Arduino IDE discovery manager code I added to talk to teensy_ports. Restarting Arduino always seems to fix it.

I've posted on seeing this as well - most specifically in my cases where the T4 got into odd state perhaps from interrupted startup - or quickly returning and interrupted. [ Both of my 'panics' Frank's T4 OFF testing and the mA measure going down to 300 Mhz ] - and also perhaps background upload to T_3.x's with TyComm when TT_Loader was active. In my case 'Windows' - assumed it might be the MSFT USB code misleading T_ports. Planned to look for recurrence when new T4 USB arrives.
 
Status
Not open for further replies.
Back
Top