Why Teensy 3.5 or 3.6

Status
Not open for further replies.
I'm interested in floating point. For my day job, I've got a project involving a fast servo loop, and I'd like to see if the FPU helps me improve its performance. Memory will also help that project, by allowing me to store larger blocks of diagnostic data while tuning the program.

At home, I've got some insane ideas related to MicroPython, which might benefit from having a bit more elbow room.
 
Motivation for me is as below, in particular for the audio projects i play around with (i wish i had more time....) I always end up squeezing everything in smaller than i'd like.

Plus the extra pins brilliant as i tend to end up sticking analogue / digital mux boards in all over the shop to pick up all the inputs. Not needing to do this saves me more than the price uplift in cost, and a lot of effort!!!!

MichaelMeissner said:
  • Support PJRC: This forum is the most helpful of any of the electronics forums I have been on, and buying more Teensies keeps PJRC in business;
  • More speed: The 120Mhz/180Mhz clock speed will allow you to do calculations much faster;
  • Hardware single precision floating point: Along with faster cycle times, having hardware floating point will speed up certain programs;
  • More flash memory: The 3.5 has 512K of flash and the 3.6 has 1M of flash compared to 256K of flash on the 3.2, and some programs need a lot of read-only constants or instructions;
  • More SDRAM memory: The 3.5 has 192K of SDRAM (read/write memory) and the 3.6 has 256K of SDRAM compared to the 64K of SDRAM in the 3.2;
  • More EEPROM memory: The 3.5 and 3.6 have 4K of EEPROM compared to the 2K of the 3.2;
  • More digital pins: The Teensy 3.5/3.6 has 51 digital pins compared to the 34 pins on the Teensy 3.2 (I may be slightly off in terms of the total pin count);
  • More analog input pins: The Teensy 3.5/3.6 have 25 analog input pins compared to 21 on the Teensy 3.2;
Click to expand...
 
MichaelMeissner said:
  • More EEPROM memory: The 3.5 and 3.6 have 4K of EEPROM compared to the 2K of the 3.2;
Click to expand...
This is the one and only thing that made the difference for me. I have an existing project based on the Mega 2560 that has a hard requirement for at least 3kb of EEPROM. For various reasons I didn't wish to use external EEPROM, so the 3.5/3.6 boards are perfect! Granted it's meant I've had to now actually follow through on my promise to make the code portable, but it's a great step forward :)
 
1. Support PJRC!
2. On-board RTC crystal, my applications need RTC
3. More clock speed, flash, and ram though 3.2 probably had enough.
4. Floating point--for some reason I thought 3.2 had it, but I checked and it doesn't. Not sure if I need it.
5. Crypto! Cool!

SD socket is good for some things but a minus for others since it makes the board bigger. It would be nice to have versions of the board without it. Can I saw it off? Alternatively, might prefer a lipo charger there, or some buttons, or a tiny oled display, etc.

I think if raw computational speed and ram was still an issue and if I could stand the power consumption, I'd go for a raspberry pi zero or similar.
 
Last edited:
I'm new (I just ordered a 3.6 yesterday) so forgive me if this is incorrect. I would add to this list:

Drawbacks of 3.5/3.6:
*No PGA on the inputs of the ADCs

As far as I can tell from reading the Freescale manuals, the 3.5/3.6 K66 microcontroller doesn't have the programmable gain amplifiers(PGAs) on the input of the ADC like the 3.1/3.2 K20 microcontroller does. This means when trying to accurately measure small voltages, you might need to run them through an opamp first to scale them up on the 3.5/3.6 while the 3.1/3.2 had built in capability to amplify small analog signals up to 64X. Also the PGA is software programmable so you could develop an autoranging algorithm that stepped through the PGA gain settings to get maximum accuracy of the ADC based on the size of the input signal. Doing the same with an external opamp would be much more difficult. I'm using these Pololu ACS711EX Current Sensor modules and it would have been useful to use the PGA when measuring currents below a few Amps or so to get better resolution.
 
plutonic said:
1. Support PJRC! ...
SD socket is good for some things but a minus for others since it makes the board bigger. It would be nice to have versions of the board without it. Can I saw it off? Alternatively, might prefer a lipo charger there, or some buttons, or a tiny oled display, etc.
Click to expand...

The SD socket is not VOID space - fitting over quite a bit of wiring for about 2 dozen unique active I/O. That portion of the board has 10 edge pins and 10 bottom pads routed through it in addition to the 8 pins associated with the SD socket. Those unique SD pins can be repurposed with an adapter if so desired. Certainly some use cases would be fine without all those pins and be a half inch shorter . . .
 
@ eemarty. This is a good catch on your part. I guess we all assume that the newer/better parts always have more features and don't drop existing features. But,like you, I can't see any mention of the PGA in the T3.5/6's MCU. I ordered Kickstarter T3.5s for their 5V tolerance on I/O, but I guess I would lose this feature regardless of what choice I made.
I found the T3.2's PGA worked pretty well with the sigma-delta ADC. Not as good as an external Burr-Brown/TI instrumentation amp or dedicated PGA chip, but useable in many cases.
 
Skinnier form factor

Finally I can finish my 1" diameter LED "staff". I have been on the lookout for a uController that would fit inside a 1" diameter tube (and have a little room in there for the wires connected to the sides of the board).
 
Here is a "why not Teensy 3.5/3.6:" There is no PGA (i.e., Programmable Gain Amplifier) (as compared to 3.1/3.2) for the ADCs, so all those analog pins are not nearly as useful. Why did they take it out?
 
Last edited:
Wow. You people used the internal OAs!?!?

Offset, noise (reduces ENOB), and input Z problems. And a recent design had to go with an external ADC/signal conditioning and a metal shield covering the T3.2 board.

Wait, just remembered a home project (cat monitoring - do not ask) done with a T3.1 years ago that used the PGA to do a pseudo auto-range.
 
BJB said:
Wow. You people used the internal OAs!?!?

Offset, noise (reduces ENOB), and input Z problems. And a recent design had to go with an external ADC/signal conditioning and a metal shield covering the T3.2 board.

Wait, just remembered a home project (cat monitoring - do not ask) done with a T3.1 years ago that used the PGA to do a pseudo auto-range.
Click to expand...

Offset - not an issue (easy to correct in software)
Noise - not sure how bad it is internal vs. external (but, external costs money and space)
Input Z - Should be better or the same going through the PGA, no?
 
I've read a few posts on these new 3.5/3.6 boards...and my current project is using a 3.2 board but I'm thinking of upgrading it to a 3.5 (I will purchase a 3.5 anyway just to support Paul's work). My question which I didn't see anyone else ask is this: can the new 3.5/3.6 boards boot up from a sketch on the SD Card? This would make field upgrades much easier.

Thanks...
 
Why not..write a sketch that loads the file to the ram, and jump to the start.
The file must be compiled in a way that is uses a fixed start-adress.
You'll have 256K(3.6) for both (program+data) - perhaps ok for simple sketches?

But i guess, you're asking for a bootloader that flashes the file.. nope, there is no solution.
 
Don't forget to include the Flash Frank - it could have the bootstrap SD to RAM and static library functions and some data in the rest of 1MB FLASH. Assuming that should all work as the bootstrap sketch would have all the code/data it was compiled with - then you just need dynamic function pointers to the code loaded in RAM?
 
A pointer to a fixed address, where the usersketch starts.
The main problem: Best would be to create a copy of teensyduino with
- patched linker-files
- patched mk20dx20..startup
- patched platform.txt, boards.txt
- removed teensy-loader (instead, copy the created file (BIN-Format, not HEX) somewhere..)

But, still, this does not allow to use any libary from flash.. hm.. at the moment i have no idea, how.

Let's not pollute this thread :rolleyes:
 
Status
Not open for further replies.
Back
Top