Teensy 4.0 First Beta Test

Status
Not open for further replies.
Let's ask another question: If Arduino sells a cpu with double-precision fpu in the future: will they use single-precision-consts?

Somehow I doubt they even consider these sorts of performance questions....

I'd be really surprised if they did anything other than just going with the compiler default. In fact, I'd be surprised to hear they ran any float vs double benchmarks. This just isn't the sort of thing they've ever seemed to have any concern.
 
To me, I think the focus should be on users getting expected behaviour rather than performance. I think this is doubly important with Arduino users, who may not be digging into compiler flags. There are use cases where double precision is necessary (i.e. using latitude and longitude) and, for example, the expectation would be that defining a constant PI/180 to convert between latitude in degrees and radians would also be treated as a double.

Placing additional burden on extracting performance (i.e. being meticulous about defining float constants correctly) seems reasonable to me. But of course, the core would need to be solid on defining constants correctly.
 
I'd be really surprised if they did anything other than just going with the compiler default.
I think the same, but that would mean t4 will be incompatible and some will say it's "not as exact as the (hypothetical) brand new arduino".

otherwise, i' love more speed, too.. but if I want to port libraries from PC, it will be a pain with double precision calculations and single-precision consts.
 
The Updated T4 Servo.cpp seems to work the same as the version in 1.45b5 on T_3.1 and T_3.6 and the same on T4.

I can't find another servo - the one I have does something odd at 180° - maybe I don't know servos enough.

The servo I have sweeps smooth into and out of 0° - but goes full to 180 even if I mod the sweep to go to 160°, and jumps on the way back down. And with loop() below and 1.5 sec pause between dir change the motor goes quiet at 0 but still driven at 180/160?

Code:
void loop() 
{ 
  for(pos = 0; pos <= 160; 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 
  } 
    delay(1500);                       // waits 15ms for the servo to reach the position 
  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(1500);                       // waits 15ms for the servo to reach the position 
}
 
@defragster - copy the updated pwm.c file with the analogRes update. Then try pwm servo but fiddle with the limits. Start with the typical values:
Code:
myservo.attach(9, 1000, 2000)
- that may get rid of your problem if not you can play with the max and mins - I do it all the time with some servos to get the right 0 and 180 deg positions. This is why I pretty much switched to using PWMServo. Some work better than others with servo.
 
A restart would not good either because it would heat the chip again (what we don't want(!?)) What exactly does happen ? If the CPU stops, all is ok, I'd say But these are decisions that belong to Paul..

Edit: i can help with the handling of reset-reasons in startup.c, if required.
Well you got your wish - thought it was automatically resetting but wasn't - forgot I commented out some lines and hid the issue. For some reason on the EVKB when the panic temp is hit it will do a reset (I confirmed it). For the life of me can't figure out why panic bit is never tripped as it should.
 
that may get rid of your problem if not you can play with the max and mins

Maybe we should update the examples with better min & max timing?

Sadly, it seems early in Arduino's history the Servo library was published with not-so-great default range. Now it can't be fixed, because so many people have written code with workarounds to deal with the usable portion of the range.
 
@defragster - copy the updated pwm.c file with the analogRes update.
...

Not sure where that got to - will wait to try on next TD beta.

If Servo lib was committed odd (per Paul notes) on range that might explain - Since I see same across Teensy boards with Prior and updated Servo.cpp so it seems to be a valid safe update to start with.

KurtE is a ServoMan [hardware on hand and exp++] so he might try on next TD beta release.

<edit> if I MAX at 152 on both directions it doesn't sweep quite 180 - but almost, but no chatter. If I use 153 I get chatter and that last degree seems to show up in fact it goes over 180 if my tape on the gear is right.

Paul - changing that range in SWEEP.ino might be right - my Servo body was getting HOT from the motor spasms with the chatter.
 
Last edited:
Not sure where that got to - will wait to try on next TD beta.

If Servo lib was committed odd (per Paul notes) on range that might explain - Since I see same across Teensy boards with Prior and updated Servo.cpp so it seems to be a valid safe update to start with.

KurtE is a ServoMan [hardware on hand and exp++] so he might try on next TD beta release.

<edit> if I MAX at 152 on both directions it doesn't sweep quite 180 - but almost, but no chatter. If I use 153 I get chatter and that last degree seems to show up in fact it goes over 180 if my tape on the gear is right.

Paul - changing that range in SWEEP.ino might be right - my Servo body was getting HOT from the motor spasms with the chatter.
Problem I Tim depending servo and range of the servo (0-90) or (0-180) the min-max settings may be different for the HS645MG the range is 553-2520μsec but it has a 197deg range out of the box. Not sure of a standard range for 0-90. Maybe KurtE can add.

EDIT: You made me look at servo library again. I forgot about the other command formats in servo. For attach I found:
servo.attach(pin, min, max)
Parameters
servo: a variable of type Servo
pin: the number of the pin that the servo is attached to
min (optional): the pulse width, in microseconds, corresponding to the minimum (0-degree) angle on the servo (defaults to 544)
max (optional): the pulse width, in microseconds, corresponding to the maximum (180-degree) angle on the servo (defaults to 2400)
So with the servo lib you can tune the min/max to your servo (0-180 deg).

You can also do writeMicroseconds. Here is some more numbers for ranges. Geez its all coming back now:
Writes a value in microseconds (uS) to the servo, controlling the shaft accordingly. On a standard servo, this will set the angle of the shaft. On standard servos a parameter value of 1000 is fully counter-clockwise, 2000 is fully clockwise, and 1500 is in the middle.

Note that some manufactures do not follow this standard very closely so that servos often respond to values between 700 and 2300. Feel free to increase these endpoints until the servo no longer continues to increase its range. Note however that attempting to drive a servo past its endpoints (often indicated by a growling sound) is a high-current state, and should be avoided.
Tim, note the highlighted comment - what we are talking about I believe.
 
Last edited:
Actually it has been a long time, since I did anything with RC servos. As mentioned you can configure the library for your servos.
Back when I was using RC servos, the majority of the time, I used either an arc32 or an ssc32 (as mentioned earlier today in a different thread).

But will try to take a look soon!

Right now still just trying to figure out why I am not getting any inputs from my Hardware Serial code. ...
 
@defragster: Yes the servo-endpoints were always a problem. that's not a problem with the library, it's a servo-problem. some can do >180°, some less.
My old 40MHz remote-control had an option to configure this, too. Part of the problem was (ok, decades ago that i used them) cheap analog electronic and potentiometers, or just the mechanic.
 
Yeah - I wish I could find the other couple of servos I know I have. I could tear apart an plane or car …

This has been running w/153° sweep and almost warm not as over warm as last night in shorter time - and less spastic.

But the new T4 drop from Paul works T4 and is as good on other Teensy.

Paul - Did the update post on Serial USB Blocking execution ring a bell? When buffers are filled with no SerMon no code runs until SerMon returns?
 
Often I use analogWrite rather than the servo library. Noticed that the servo library would issue commands round robin, which old receivers would also do, but means a lot more delay if you are using lots of servos. analogWrite issues all of the channels at once and allows different frequencies (some servos now go up to 1 kHz!).

Common issue needing slightly different endpoints. Depends on the servo and often the installation.

My biggest wish list item for all of the libraries would be some way to sync the PWM command to the analogWrite or servo methods, it can be up to a full frame delay for the updated pulse width to show up in the waveform and the servo often also takes up to a full frame delay before it starts moving, so potentially up to 40 ms of latency just in issuing the PWM command.
 
Well that doesn't look right. What do you get with "ls -l /dev/ttyACM0".

Should be like this.

Code:
crw-rw-rw- 1 root dialout 166, 0 Jan  2 09:17 /dev/ttyACM0

If not, maybe the udev rule file isn't installed properly?

I just installed 1.8.8 1.46-beta5 on mac os. I still have to push the program button after an upload!
 
Code:
	if (bits < 1) {
			bits = 1;
		} else if (bits > 16) {
			bits = 16;
		}
I usually use constrain when I write similar code :)
Code:
constrain(bits, 1, 16);
 
@PaulStoffregen
For the Servo and PWMServo libraries is there any other testing you would like to see done with the libraries. Was thinking testing the ranges for final verification. Or would you like all the functions tested?

v/r
Mike
 
This has been running w/153° sweep and almost warm not as over warm as last night in shorter time - and less spastic.

But the new T4 drop from Paul works T4 and is as good on other Teensy.

The goal is to get exactly the same output as Servo gives on all other boards.

Those RC servo motors take a pulse input where the width of the pulse tells the motor what to do. By default the Servo library pulse ranges from 544 us (for 0 degrees) to 2500 us (for 180 degrees). Not all servo motors use that wide range. Some respond use 1000 us to 2000 us. Servo offers a special constructor where you give it the range your motor needs. See msg #305. You should probably use that with your motors.

The Servo library examples probably ought to show & explain this in commented out code. The Arduino devs love to keep their examples very short and simple, which has a lot of benefit for beginners.

A narrower default range might have been a better design choice for beginners. Then they could use the 3-arg constructor for motors able to handle more. But the very early versions of Servo "standardized" on 544 to 2500, and tons of code has been written to use whatever set of angles actually work with specific motors. Obviously Servo's default range can't be changed now without breaking mountains of existing projects!

So the goal here is not to revisit Servo's old and forever-fixed design choices. The goal is only to make sure it's doing exactly the same behavior as it does on all other boards.


Did the update post on Serial USB Blocking execution ring a bell? When buffers are filled with no SerMon no code runs until SerMon returns?

Honestly, I couldn't parse that message. Was going to ask you for more detail in a few days. Rough plan is 1 more session fixing "small" libraries and adding just a couple missing bits of infrastructure (especially the D-cache maintenance functions) and then release beta6. Then I'm going to focus on the audio lib. After audio is running (hopefully this weekend), I'm going to dive into the USB stuff. So far, all the non-control transfer code is really just a quick hack to get things started. I'm planning to rewrite it all next week. Will definitely need this sort of testing and feedback then.
 
For the Servo and PWMServo libraries is there any other testing you would like to see done with the libraries.

Maybe check the motor goes to the same physical position with the same program on Teensy 3.x and even regular 8 bit Arduino.

Sounds like we've covered this servo stuff pretty well. Unless any problems turn up, probably time to move on.
 
For the Servo and PWMServo libraries is there any other testing you would like to see done with the libraries.
Understood - will test with a Uno, T3.2, T3.5 and the T4. Think that will cover the range of boards. Will work on that tomorrow for sanity sake - almost time to sleep.

Sounds like we've covered this servo stuff pretty well. Unless any problems turn up, probably time to move on.
Agreed. Pretty much covered all that in my post with defragster.
 
The goal is to get exactly the same output as Servo gives on all other boards.
...

Noted a couple times the T4 update works the same so that is good then. I'll play with Freq range when I can find a second servo to compare. Found one - of course it was there because it has stripped gears.

Honestly, I couldn't parse that message. Was going to ask you for more detail in a few days. Rough plan is 1 more session fixing "small" libraries and adding just a couple missing bits of infrastructure (especially the D-cache maintenance functions) and then release beta6. Then I'm going to focus on the audio lib. After audio is running (hopefully this weekend), I'm going to dive into the USB stuff. So far, all the non-control transfer code is really just a quick hack to get things started. I'm planning to rewrite it all next week. Will definitely need this sort of testing and feedback then.


The initial post had unrelated code but was current sample - minimized in this shorter follow up -

opps_CommErr :: Try Blink_SerFast

No Servo - No Interval Timer. USB Ser blocks when sketch starts with Serial ( required in that sketch ) - then kill SerMon and Blink and Debug output halts until SerMon returns.

Below is a sketch. Upload to T4. When SerMon presents Serial it will begin and print. Watch the prints and see the LED blink on output - watch the digit after the @ symbol - it is a counter.

Close SerMon - LED will stop blinking - confirm watching a couple of seconds … no blink [ ON WINDOWS ]

Open SerMon - blinking resumes and the SerMon output picks up where it was when SerMon disconnected.

PROBLEM: T4 blocks sketch execution when Serial.print is used and SerMon goes away. Similar issues when the setup() { while ( !Serial ); is commented out

Code:
void setup() {
  pinMode(LED_BUILTIN, OUTPUT);
  while ( !Serial );
}
int ii = 0;
bool flip = true;
void loop() {
  if ( !(millis() % 1000) ) {
    Serial.print( "123456 @" );
    ii++;
    Serial.println( ii );
    digitalWrite( LED_BUILTIN, flip );
    flip = !flip;
    delay( 5 );
  }
}

Maybe that is what this TODO is about:
//if (count > 50) break; // TODO: proper timout?
// TODO: check for USB offline
 
Noted a couple times the T4 update works the same so that is good then. I'll play with Freq range when I can find a second servo to compare. Found one - of course it was there because it has stripped gears.
Hi Tim, what servos are u using, I have mostly gws and hitec servos. Going get another tomorrow to play with as well. Have to dig it out, at least I know where they are.
 
Hi Tim, what servos are u using, I have mostly gws and hitec servos. Going get another tomorrow to play with as well. Have to dig it out, at least I know where they are.

They didn't have room for the word 'Jenerick' perhaps - it just says 'Analog Servo'.

>> This seems to work perfectly 0 to 180° :: I finally found a pair of Tower Hobby : Tower Pro Micro - Micro Serv 9g
Nice and smooth and quiet!

T4 is Running 1.5+ MBytes/sec USB Serial and 498142 Interval Timer Interrupts per second and [on two elapsedMillis] the Servo on 15 ms update with 1 sec blink toggle.

But as reported before it all HALTS when SerMon closes.
 
From top (closest to pin 23) to bottom (closest to pin 2):

GPIO_SD_B0_04_DAT2
GPIO_SD_B0_05_DAT3
GPIO_SD_B0_00_CMD
3.3V
GPIO_SD_B0_01_CLK
GND
GPIO_SD_B0_02_DAT0
GPIO_SD_B0_03_DAT1

It seems that you allow the option to mount uSD directly to bottom of the PCB (if there where not the bypass Cs and the missing case-ground pads)
would it be possible?
 
Status
Not open for further replies.
Back
Top