Any Chance of a Teensy ++ 3.1?
- Thread starter melstav
- Start date
- Status
manitou
Senior Member+
I've run a few tests on the crypto unit (see post 411 in this thread, https://forum.pjrc.com/threads/24633-Any-Chance-of-a-Teensy-3-1?p=84807&viewfull=1#post84807). Seems to speed things up by a factor of 2 or 3 over straight C for hashing, and 10 times faster for AES.
Last edited:
MichaelMeissner
Senior Member+
For a single feature perhaps. But if there are 20 such extra parts, each of which need to be designed into the pcb you get into the area where tradeoffs have to be made and return on investment calculations have to be done. For example, having the JST connector for the charging port makes it slightly taller. For many users, that might not be an issue, but some are trying to fit Teensy's into rather tight physical spaces. Also adding the connector means you probably lose the space to bring 2-4 more pins out for general use.
Quotes from SparkFun:
"Hate to rain on your parade, this board doesn’t have the Lipo charger (just the full sized version). We’re updating the description now."
"Honestly I have no idea where we’d put it. That is a pretty tight little board and is already 4 layers. I’ll pass on the suggestion though."
So, no, that board doesn't have a Lipo charger and it won't anytime soon.
vitormhenrique
Well-known member
As cartere said it was a typo on sparkfun website, so i was looking the incorrect part number... ops, my bad!
Nevertheless, if teensy 3.x++ has the space, I think it would be a nice feature!
PaulStoffregen
Well-known member
Any word on this tiny 10 cent charger chip?
manitou
Senior Member+
Any progress with flash memory faults? Does disabling MPU (MPU_CESR=0) help?
Last edited:
Constantin
Well-known member
Perhaps it's time we pooled our collective resources and hired a local priest, shamen, rabbi, or similar religious representative to perform a exorcism....?
While I would love to see an STM32 Teensy, I have to imagine the amount of work required to port all the libraries and things and get everything working nicely makes it not worth it. I would think the F7 for a teensy++ device and an L4 for the standard teensy though. One can dream. Hope everything is going well though Paul.
The ST HAL libraries are quite extensive. So a Teensyduino can be wrapper APIs, and that's been done by some. Does greatly reduce the extent of DIY code. Hugely. And normalizes the API for simple chip-family targeting of apps. The F7 is too "fat". The 1MB M4 is what I'd like to see, in a 100pin package so more peripherals can be had.
The future for Freescale/NXP is a big question too.
Unlikely to see ST here though.
The future for Freescale/NXP is a big question too.
Unlikely to see ST here though.
Last edited:
PaulStoffregen
Well-known member
I agree. ARM clearly intended Cortex-M7 for higher performance silicon, like 45 and 65 nm. At 90 nm, it's huge (expensive).
The next Teensy will use Freescale K66, as we've discussed.
Cortex-M7 is in the future, but when the semiconductor vendors move to more advanced processes for microcontrollers.
onehorse
Well-known member
Perhaps off topic, but I designed a Teensy-sized STM32L4 following STs reference design that breaks out most (22) of the GPIOs. I find this much harder to use than the Teensy, of course. Other than mbed (which is also not that easy to use) is there an easier way to program these things? ST claims their embedded bootloader allows flashing of new programs via USB (and I2C, SPI, and UART). But I haven't seen a good tutorial on how to do this. There seems to be a giant gulf between Arduino programming and the traditional adult tool chain methods. Too bad. Maybe I'll just have to wait for the K66...
DFU... industry standard.
"Device Firmware Update"
iPhones, WiFi routers, etc.
The newer embedded gizmos have DFU... like the Particle.io Photon board. To re-flash it, you put the device in DFU mode with some button pushing or cooperating firmware, then run software on the PC (built into the IDE) that runs DFU over USB. High speed firmware update.
Most ARMs also have SWD (single wire debug) for flashing, controlling the ARM core for stop, breakpoint, trace, etc. The SWD is just 3 wires: clock, data, ground. I used it all day every day in my work. So much better than ye ole JTAG. Many low cost boards have an SWD on-board - it's just a standard USB capable microprocessor for SWD on one side and USB on the other. SWD is very fast. The ST demo/eval boards mostly have a low end USB capable MCU just for SWD - usually the same ARM processor family but low end.
And most all ST and most Freescale have a traditional bootloader in ROM (not flash). ST's can self-discover and use UART, SPI, I2C, CAN and so on. And these are often DFU protocols. I suspect Freescale has something competitive.
Developers tend to use SWD for breakpoint debugging and testing. I for one would not want to do without it. It makes a huge positive difference.
DFU is a way for consumer or end user devices to get a major firmware update that cannot be done via a download.
If your work with the STM32 is old school, i.e., not using ST's CubeMX and Hardware Abstraction Library, and their good API documentation, it'll be like bare metal microprocessor programming was 10-20 years ago. It's probably not for the casual user though, as it does require an investment in time to learn how to use these tools. That done, it is so much faster - and most of your time is on the application work, not the tools and struggles with DIY libraries for drivers and commonplace high level functions like SD flash, FSMC flash (I'm doing that now), PWM, pulse capture, A/D and D to A, FATFS, LCDs, DMA for any I/O.
Freescale has something similar to ST but I found it to be far less comprehensive, much less user friendly, etc. But to each, their own.
"Device Firmware Update"
iPhones, WiFi routers, etc.
The newer embedded gizmos have DFU... like the Particle.io Photon board. To re-flash it, you put the device in DFU mode with some button pushing or cooperating firmware, then run software on the PC (built into the IDE) that runs DFU over USB. High speed firmware update.
Most ARMs also have SWD (single wire debug) for flashing, controlling the ARM core for stop, breakpoint, trace, etc. The SWD is just 3 wires: clock, data, ground. I used it all day every day in my work. So much better than ye ole JTAG. Many low cost boards have an SWD on-board - it's just a standard USB capable microprocessor for SWD on one side and USB on the other. SWD is very fast. The ST demo/eval boards mostly have a low end USB capable MCU just for SWD - usually the same ARM processor family but low end.
And most all ST and most Freescale have a traditional bootloader in ROM (not flash). ST's can self-discover and use UART, SPI, I2C, CAN and so on. And these are often DFU protocols. I suspect Freescale has something competitive.
Developers tend to use SWD for breakpoint debugging and testing. I for one would not want to do without it. It makes a huge positive difference.
DFU is a way for consumer or end user devices to get a major firmware update that cannot be done via a download.
If your work with the STM32 is old school, i.e., not using ST's CubeMX and Hardware Abstraction Library, and their good API documentation, it'll be like bare metal microprocessor programming was 10-20 years ago. It's probably not for the casual user though, as it does require an investment in time to learn how to use these tools. That done, it is so much faster - and most of your time is on the application work, not the tools and struggles with DIY libraries for drivers and commonplace high level functions like SD flash, FSMC flash (I'm doing that now), PWM, pulse capture, A/D and D to A, FATFS, LCDs, DMA for any I/O.
Freescale has something similar to ST but I found it to be far less comprehensive, much less user friendly, etc. But to each, their own.
Last edited:
onehorse
Well-known member
Yes, I use 2-wire SWD to successfully program the nRF51822, I am struggling to do the same with my STM32L4 board but I had a trace error on the boot pin so that could be why I had so much trouble (fixed now so I will give it another go this weekend).
/Whine begin/But what I am really whining about is the expense and difficulty of using powerful toolchains like Crossworks or Keil. It is very confusing to a dummy like me to learn to use them well ... I want to use these processors in my projects but the tool chain is the barrier that makes it very slow and hard slogging. STMCube makes it easier and there are a lot of examples but still I struggle. At least the first time or two or ten, I need someone to spell it out so I can understand it. I guess I am spoiled by the Arduino experience./End of Whine/
/Whine begin/But what I am really whining about is the expense and difficulty of using powerful toolchains like Crossworks or Keil. It is very confusing to a dummy like me to learn to use them well ... I want to use these processors in my projects but the tool chain is the barrier that makes it very slow and hard slogging. STMCube makes it easier and there are a lot of examples but still I struggle. At least the first time or two or ten, I need someone to spell it out so I can understand it. I guess I am spoiled by the Arduino experience./End of Whine/
Not sure if appropriate or useful but there is an Arduino-like environment for STM32 at http://www.stm32duino.com/.
Yes, and it's focused on son-of-Maple boards using the very low end STM32F1xx.
- Status