Microduino style packing

Teensy has always used this "style", a small board with pins on 3 sides.

Maybe you're asking if PJRC will change the shape to 1.1 by 1.0 inch? That's pretty unlikely.
 
Teensy has always used this "style", a small board with pins on 3 sides.

Maybe you're asking if PJRC will change the shape to 1.1 by 1.0 inch? That's pretty unlikely.

I thought the idea that the hardware to communicate
with the processor could be detached after programming was interesting.

Smaller foot print aside, if you are thinking of embedding a Teensy3 inside a product
that doesn't need to communicate with the outside world, removing that hardware
might save a few bucks.

Thanks
Bill
 
Seems like there is minimal room taken up by the USB connector as it is. Pauls solution re: the Teensy 3 requires an additional external chip, making it that much harder to produce a board much more compact than the Teensy 3, unless you want to start orphaning pins the way the SAM 3X processor does on the Due board. Your sum total savings (see the schematics published here) are pretty sparse.

Another issue is that the Teensy 3 MCU has far more pins (and hence a bigger footprint) than the 328P or 32u from Atmel. As I see it, the microduino saves space over a standard 328P simply by stacking vertically that which is normally stacked side by side. So, this is a Nano that is vertically dense. Excellent idea for space-constrained applications but not so great for bread-boarding...

Nor would I understand why Paul would allow boards that separate the K20 and Mini54 chips from each other. That would allow someone to buy just one "official" lower board with a Mini54 on it, then program as many boards with K20's as they like while not paying any royalties. This would likely make Pauls business model unworkable.

That is, unless he's implemented some sort of check into the T3 microcode that looks for the presence of a Mini54 and bricks if it's not there. :p
 
Last edited:
What I like about the microduino is the smart use of what looks to me like machined headers. This allows for a very small stack height as compared to the normal headers.
 
We do sell a Mini54 chip separately for people who want to make their own boards. It's normally used as a stepping stone to volume production, where you're making enough of whatever you've designed with Teensy3 that buying the PCB from PJRC isn't feasible, but not yet enough to invest the time/effort to some other programming solution (eg, buying something from P&E Micro or writing your own programmer using EZ port or some other way).

The Teensy3 code in Teensyduino, the part that actually runs on the MK20, doesn't depend on the Mini54. And even if it did, that code is all open source, so you can modify it to suit your needs.

In theory, it's probably possible to separate Teensy3 into 2 circuit boards. But the USB connects to the MK20, not the Mini54, so the board-to-board connector would need many pins for the all the signals between the chips and also the USB. The wires and connectors would need to be capable of 12 Mbit/sec USB. That's probably more cost and complexity that the meager savings from not having those other boards on every board.

I also personally like having the board "just work", well, with the right USB cable and a computer. At least for now, I'm not very keen on the idea of a 2-board solution.

I do have some ideas about low cost solutions. I can't talk about details now, but when/if that ever happens, it'll be designed to preserve the usability and ease-of-use people expect with the Arduino software.
 
Pauls solution re: the Teensy 3 requires an additional external chip, making it that much harder to produce a board much more compact than the Teensy 3
The K20's lack of a built-in bootloader such as in the NXP and other ARMs, may be only part of the story. Anti-piracy may be the other part. With the ethics as they are in China, who can blame him.

Next-gen? I'd hope it's not Freescale because of their inadequate and non-concise ARM documentation. And cheesy shortcuts like the lack of FIFOs in all the UARTs. But that's just my own opinion, coming from Atmel AVR and NXP ARM history.
 
Last edited:
Paul,

My concern is simply that if your K20 doesn't handshake with the mini54 on every boot, that someone could simply source one Mini54 (either buying it from you or taking it off a existing Teensy 3 board with a SMD rework station) and then burn as many K20's for specific applications as they like (i.e. where no frequent reprogramming is expected) without paying you royalties.

There are a couple of pin connections (10?) needed, but nothing that you couldn't fit on a daughterboard that simply slips into a designated header. As an added bonus, the lack of a USB interface (I'd mount it on the daughterboard also) would reduce cost and make it even harder for others to break into the finished device.

Since your royalty program depends on the sale of the Mini54 chip, I would reconsider your approach to avoid the above. Otherwise, you potentially spare folk the need to go down the EZ port route, while not paying your a royalty for the privilege. Something as simple as the K20 asking the Mini54 for a handshake and the Mini54 responding properly could do the trick. But maybe I'm overcomplicating things here and EE's like you don't consider these sorts of DRM speed bumps worthy of your time because workarounds are too easy to implement. Who knows. I simply want to ensure that your business stays viable because I value the Teensy's you produce as much as I do.
 
Back
Top