Teensy Clone without MINI54?

Status
Not open for further replies.

bogasaur

Member
Is there any analogous/feasible chip other than the MINI54 that could serve as the bootloader chip for the MK20 processor? Would loading a bootloader directly onto the processor be an option (at the expense of boot-up time of course). I apologize for any mistakes and naivety. Thanks very much and best regards.
 
Yes, yes and yes - however, anybody who likes PJRC as much as I do shouldn't rush into helping with this; certainly not publicly at the very least.

If it is just for your little project then why not just use Paul's hard work? If it is for a profit then putting in the hard yards Paul did isn't uncalled for, when you are finished (and you have one as good as Paul's) you will probably see why not to just hand it out in a form that doesn't at least give you a penny each time.
 
Thanks robsoles.

I love Paul's work as well, because what he's done is absolutely massive. I was simply curious why the MINI54 was chosen, and what other chips would be good alternatives. Also, I would like to "put in the hard yards" myself, not necessarily for profit, but just for in-depth knowledge since I'd like to achieve an intimate understanding. Thanks again.
 
At the time, only 2 Cortex-M0 chips were on the market available in such a small package. One was the Nuvoton Mini54. The other was a chip from NXP. I seriously considered the NXP part, but nobody seemed to have stock and I couldn't even get a reliable quote with lead time for quantity from any distributor. The Nuvoton part was in stock (small qty) and they gave a competitive quote. Initially they gave a very long lead time, but later revised it to several weeks, which worked out well for the Teensy 3.0 release schedule.

So, between only 2 parts at the time (early 2012) that met the small size requirement, one that didn't seem to really exist, the choice to go with the Mini54 seemed pretty clear. Today many more parts exist, but if you want to understand the original design decision, you really have to understand what was available in late 2011 to early 2012, when Teensy 3.0 was originally designed.

Later this year, we're going to switch Teensy 3.1 to the same MKL02Z32 chip used on Teensy-LC.
 
will the freescale MKL02Z32 have the canbus as the current ? I haven't seen it on freescale datasheet....keep a can bus capable unit, teensy 3.1 is the only small form factor prototyping board with integrated can bus with cortex power at great price. I would suggest to add a trasciever solder pads !
Thanks for your hard work paul.
 
Hi Paul,
from the standpoint of compatibility I now understand why, I think that's interesting. Thanks for the input, means a lot. Regards.
 
But with more flash & RAM than the LC?

Sorry Steve, I probably wasn't very clear. The user visible RAM and Flash and everything else will remain the same, because the MK20 chip isn't changing on Teensy 3.1. What's changing is the bootloader chip, from Mini54 to MKL02.

This change is mostly motivated for PJRC inventory management and improving manufacturability. We're currently buying 2 different chips to do basically the same thing on 2 different boards. The newer MKL02 chip uses standard 0.5 mm pitch pins, which our contract manufacturer likes quite a bit better than the 0.4 mm pitch on the Mini54. So it makes a lot of sense to use only 1 part rather than 2.

From a product feature set point of view, this is a pretty boring change. It really doesn't change anything for normal usage.
 
Ah, good.
With a four layer board,
Can the T3++ be a 100 pin chip? More peripherals, fewer pin mapping conflicts.
 
What's changing is the bootloader chip, from Mini54 to MKL02.

If one is creating an embedded teensy 3.1 like design (layout starting tomorrow) and planning on using your boot loader, would it be best to design it with the MKL02? Can I test it by taking the MKL02 off of a LC?
 
Last edited:
Later this year, we're going to switch Teensy 3.1 to the same MKL02Z32 chip used on Teensy-LC.

Brings up an interesting question... the MCU on the 3.1 has a number of additional connections per the schematic with the Mini54 vs. the LC with its MKL02...

For example, I presume that the I2C connections on the Mini54 are for updating the bootloader chip? If a custom Teensy derivative didn't anticipate bootloader updates, could the I2C connections be omitted even for the Mini54? (i.e. only connect the RESET, SWD-DIO, and SWD-CLK connections, just like the MKL02Z)

I also presume that the Mini54 P0.0 to MK20 PTA1 connection is only really needed for USB-host operation and could be normally grounded if that mode is not needed?
 
For example, I presume that the I2C connections on the Mini54 are for updating the bootloader chip?

No. They're for an old idea I had early in Teensy3's development, more than 3 years ago, for eventually supporting USB host mode using another Teensy to act as the loader.

If a custom Teensy derivative didn't anticipate bootloader updates, could the I2C connections be omitted even for the Mini54?

Yes, you can omit those 2 connections. That feature was never implemented and never will be.

When USB host is fully supported, in the not-soon future, a different mechanism will be used for loading code. Those 2 connections will never be used.
 
Hi Paul,

Many many thanks for your answers... I have two more questions re: the Teensy 3.1 schematic, if that's OK.

From what I understand, the connection from pin 4 on the USB connector to P0.0 on the Mini54 and PTA1 is to enable USB host mode (presumably via the Teensy grounding the pin). If I have no interest in host mode, can I leave pin 4 floating on the USB connector and only connect P0.0 on the Mini54 to PTA1 on the MK20?

If I remember right, all pins on the MK20DX256 are in a high-Z state by default when the chip powers up. Would it hence be permissible to run the connection from PTA0 on the MK20 (pin 24) through the D24 signal pad (i.e. pin 27) to the Mini54? Running the connection this way would allow me to avoid vias for any signal between the two chips now that SCL and SDA have been eliminated.

Many thanks again! Constantin
 
Status
Not open for further replies.
Back
Top