Any Chance of a Teensy ++ 3.1?

Status
Not open for further replies.
I'm liking the IRC 48 MHz clock for crystal less usb for the MK66 and MK64! Maybe we can use the USB now when running the core clock below 20 MHz.
 
Chris O. said:
Haha Mission: Impossible - Rogue Nation (2015) :D
Click to expand...

This benchmark will self destruct in 14 milliseconds....

Code: 
//
// Pi_2
//
// Steve Curd
// December 2012
//
// This program approximates pi utilizing the Newton's approximation.  It quickly
// converges on the first 5-6 digits of precision, but converges verrrry slowly
// after that.  For example, it takes over a million iterations to get to 7-8
// significant digits.
//
// I wrote this to evaluate the performance difference between the 8-bit Arduino Mega,
// and the 32-bit Arduino Due.
//

// http://tronixstuff.com/2014/02/12/review-intel-galileo-arduino-compatible-development-board/

 
#define ITERATIONS 100000L    // number of iterations
#define FLASH 1000            // blink LED every 1000 iterations
 
void setup() {
  pinMode(13, OUTPUT);        // set the LED up to blink every 1000 iterations
  //digitalWrite(13, LOW);
  Serial.begin(9600);
  delay(1000);
}
 
void loop() {
  static int count=0;
  unsigned long start, time;
  unsigned long niter=ITERATIONS;
  unsigned long i;
  float x = 1.0f;
  float pi=1.0;
 
  Serial.print("Beginning ");
  Serial.print(niter);
  Serial.println(" iterations...");
  Serial.println();

  digitalWrite(13, HIGH);
  start = millis();  
  for ( i = 2; i < niter; i++) {
    x *= -1.0f;
    pi += x / (2.0f*(float)i-1.0f);
  }
  time = millis() - start;
  digitalWrite(13, LOW);
 
  pi = pi * 4.0f;
 
  Serial.print("# of trials = ");
  Serial.println(niter);
  Serial.print("Estimate of pi = ");
  Serial.println(pi, 10);
 
  Serial.print("Time: "); Serial.print(time); Serial.println(" ms");
  delay(1000);
}


duff said:
... IRC 48 MHz clock for crystal less usb ... Maybe we can use the USB now when running the core clock below 20 MHz.
Click to expand...

Maybe. I've always been curious if it'd work.

But my understanding is the speed limit might be due to the DMA, which needs to be able to move bytes faster than the USB packets. But in theory than should only be 1.5 MByte/sec, so unless there's a lot of overhead per byte, maybe the 20 MHz limit is overly conservative?
 
Suggestion: What about a (rough) roadmap on the pjrc website where new products are pre-announced with at least the quarter and the year when these are expected to come?
 
... And speaking as someone who has managed to consistently manage to not meet his internal deadlines re his products, I can certainly sympathize with Paul.

It's his baby, let it gestate and be as great as the other babies he's produced. You don't want PJRC to produce a stinker like the Due, just to meet a timetable that is convenient to a minority of the user base. If a project requires more power or more pins, simply start adding cores and DIY it.
 
Pensive said:
I feel that Paul has already addressed this issue...
Click to expand...

Correct,
Summary from a lot of statements (may have changed without notice)

Sequence
- prop shield (what ever that is)
- high performing teensy,
--BUT as of Dec.15:
---pinout not final, i.e. layout not final
---early prototype (larger than final) not yet in alfa,beta test version
--parallel (competing?) development of "MK64FX512" and "MK66FX1M0"
- web design (external face/image of PJRC), new forum, wiki

observation:
recent commits to Paul's github are not specific to new Teensy, but may indicate Paul is testing necessary software modification.
interesting is recent new ARM compiler work, which may be necessary for new teensyduino.

pers. conclusion:
As long as T32 keeps PJRC busy and provides income, I do not expect increased desire for pushing higher performing Teensy.

quote from Paul on 12-09-2013, 09:12 PM (post #3 of this thread)
I've actually been working on Teensy++ 3.X. It's too early to discuss the details, but I can assure you, I am indeed working on a Teensy++ 3.1 and I'm pretty sure you'll like it.
Click to expand...
so this is 2 1/2 years in the making and may never happen, at least not in the form as originally intended, or desired by us.
 
Everyone moaning in this thread is giving him more and more reason to tell us nothing at all.

Is the point I was making.
 
Pensive said:
Everyone moaning in this thread is giving him more and more reason to tell us nothing at all.
Click to expand...

Everyone bringing up this thread indicates that he has not yet abandoned PJRC and is waiting for progress in this field.
 
I can well see Paul's point of view.

But there is also the point of view of persons like me who on one side appreciate the actual Teensy product line very much and want remain loyal to PJRC (for whatever reason) and who have on the other side some projects in the pipeline which require a little more than the actual top product, the Teensy 3.2, can give. That brings up a dilemma : should I already start working around a virtual CPU to comme soon and find myself in difficulties because one year later, it isn't still on the market? Or should I rather look "if other parents have beautiful daughters, too", meaning that I would probably have to invest in a different development h/w and s/w environment include the time for the learning curve? And in the worst case to find out later that my dream-Teensy came finally out only two weeks after I decided to switch to another CPU/environment...
 
So do we, Paul!

As much as everyone says they want it now, they don't know that what they really mean, is that they want it working well, when it is ready. :D

Keep up the good work! So many cool things have happened because of it!
 
Let me add another 2 cents to the whole lot of good (and sometimes contradictory) suggestions here.

There was a suggestion to add pads for i2c pull-ups in the beginning of the thread. I second that wholeheartedly. Actually since not everybody is good with iron I'd rather see pull-ups already in place with an option to cut the jumper to disconnect them.

Adding on-board SD socket is good idea, but so is adding many other devices. That is why I think having access to more processor pins trumps arbitrary selected add-ons. In short, SD is only good if you do not have to sacrifice pins for it.

Having said that, a lot of people experimenting with balancing robots and drones nowadays. Having something like MPU-9250 and pressure sensor would turn Teensy into great control board for them. Especially since chips can be connected to SPI/I2C channels not routed to external pins. Waste not, want not!

The DFU discussion earlier on the thread certainly caught my attention. If you want Teensy to be bought in commercial quantities you want to appeal to commercial customers. For them ability to send software updates to their users is extremely important. And of course users should be able to install it without having any idea how things work. DFU can solve this.

And in another nod to commercial world the ability to protect our software is no less important than protection of Teensy firmware for you. So it would be nice to have an option for AES/DES in bootloader/compiler chain. Especially for DFU.

Finally, if you have more space on bigger board, how about beefing up voltage regulator? Or even adding another one, say to power potentiometer-based analog sensors. If there are a dozen of them in parallel the current becomes quite challenging.
 
Last edited:
wwwoholic said:
Let me add another 2 cents to the whole lot of good (and sometimes contradictory) suggestions here.

There was a suggestion to add pads for i2c pull-ups in the beginning of the thread. I second that wholeheartedly. Actually since not everybody is good with iron I'd rather see pull-ups already in place with an option to cut the jumper to disconnect them.

Adding on-board SD socket is good idea, but so is adding many other devices. That is why I think having access to more processor pins trumps arbitrary selected add-ons. In short, SD is only good if you do not have to sacrifice pins for it.

Having said that, a lot of people experimenting with balancing robots and drones nowadays. Having something like MPU-9250 and pressure sensor would turn Teensy into great control board for them. Especially since chips can be connected to SPI/I2C channels not routed to external pins. Waste not, want not!
Click to expand...

Adding resistors to the board your installing the Teensy on is very simple, why force someone to potentially damage a board by cutting on it or pulling off a pad by soldering.
The MPU-9250 would unnecessarily drive up cost, the SD socket is cheap in comparison vs the number of people that will use it.

wwwoholic said:
The DFU discussion earlier on the thread certainly caught my attention. If you want Teensy to be bought in commercial quantities you want to appeal to commercial customers. For them ability to send software updates to their users is extremely important. And of course users should be able to install it without having any idea how things work. DFU can solve this.

And in another nod to commercial world the ability to protect our software is no less important than protection of Teensy firmware for you. So it would be nice to have an option for AES/DES in bootloader/compiler chain. Especially for DFU.
Click to expand...
DFU sounds interesting but will it drive up cost? Same goes for AES/DES its not some simple thing to create and will cost time/money to implement if it can be implemented. Appeasing the Commercial guys will most likely annoy the DIYers if it drives up cost;) The commercial guys can most likely repackage and add features vs us DIYers.


wwwoholic said:
Finally, if you have more space on bigger board, how about beefing up voltage regulator? Or even adding another one, say to power potentiometer-based analog sensors. If there are a dozen of them in parallel the current becomes quite challenging.
Click to expand...

Im not sure about everyone else but I tend to avoid using the onboard supplies to anywhere near there rating. I can replace large TO220 and SO8 packages far easier and cheaper then replacing anything on the Teensy. The big thing with the Teensy is that Paul gives use a package that breaks out a good number of pins that can be bread boarded and then later on incorporated into a larger board at a later time. Without forcing a bunch of fluff onto us that we may or may not use.
 
Last edited:
All of the items on this checklist can easily be accommodated on a daughter card that the teensy can then be mounted on. Or plan on DIY a all in one solution. The boot loader chips are freely available.

It's easy to think that features you are interested in enjoy universal appeal but most Arduino hardware configurations are intentionally universal because every maker has a different set of requirements. All these add ins also add cost and complexity, reduce reliability.

There is very little spare room on a teensy 3 series and I doubt that the 3++ version will be any different. I can only imagine the engineering challenge with routing all those BGA array connections while maintaining signal integrity and so on. For example, High speed PCB design is not trivial and Paul has achieved very impressive results with the ADC on the teensy 3 series relative to pie in the sky claims from Freescale marketing.

I've been designing boards that use a assembled Teensy where possible and DIY layouts when the standard solution won't fit or work for some reason. If this manufacturing engineer can venture successfully into the lands of Eagle, Osh park, osh stencil, and beyond, then so can you.
 
Constantin said:
All of the items on this checklist can easily be accommodated on a daughter card that the teensy can then be mounted on. Or plan on DIY a all in one solution. The boot loader chips are freely available.
Click to expand...

Agreed!

@ wwwoholic, Donziboy2
After trying multiple times to provocate Paul to leak final info (i.e release date) on Teensy 3++ (or 4.0 as I prefer to call it), I would also say, that the object of this thread (high performing teensy) seems so advanced, that there is no opportunity anymore to come up with a wish list of features. Paul mentioned multiple times in this thread, what Teeensy 3++ with have, how many pins and more important what will not be supported.
 
WMXZ said:
... Paul mentioned multiple times in this thread, what Teeensy 3++ with have, how many pins and more important what will not be supported.
Click to expand...
Thank you, I was wondering if I was the only one thinking this.

I am just looking foreword to getting my hands on one of these and figure out what all I can do with it, and most likely will build my own carrier boards to experiment with.
 
WMXZ said:
Agreed!

@ wwwoholic, Donziboy2
After trying multiple times to provocate Paul to leak final info (i.e release date) on Teensy 3++ (or 4.0 as I prefer to call it), I would also say, that the object of this thread (high performing teensy) seems so advanced, that there is no opportunity anymore to come up with a wish list of features. Paul mentioned multiple times in this thread, what Teeensy 3++ with have, how many pins and more important what will not be supported.
Click to expand...

Yep, and for me I would probably just be happy with a super breakout that allows access to most of the pins. Until he releases the board and a schematic everything in this thread is fluff.
 
KurtE said:
Thank you, I was wondering if I was the only one thinking this.

I am just looking foreword to getting my hands on one of these and figure out what all I can do with it, and most likely will build my own carrier boards to experiment with.
Click to expand...

@Paul, as I'm also plan to build my own carrier board, I would be interested to know, if the bootloader chip is the MK02 or could it be something new?
 
Status
Not open for further replies.
Back
Top