Teensy 4.1 Development Board
pjrc.comPSA: Networking on microcontrollers is a giant pain in the ass.
Don't get me wrong, boards like this (and ESP/Realtek boards with WiFi) are great for hacky prototypes. But if you're building an embedded device that will be deployed in any sort of volume, a small application processor running Linux will make your life dramatically easier. You can keep it asleep most of the time if your power budget is tight.
The hard part is not cramming in an Ethernet PHY or a 2.4 GHz radio, it's the mountain of software that you need to run on top of it to get the kind of reliable, secure communications channels that we've come to expect. Bare metal networking stacks like LwIP have a reputation for being buggy, and are nowhere near as battle-tested as the Linux/BSD networking stacks security-wise. Some of the more memory constrained devices can barely fit a complete certificate chain. Are you really prepared to roll out updates on a system like this when the next Heartbleed comes along?
Also, the layers tend to pile on, so while you might get away with a bare-bones wire protocol initially, you'll be starting your project close to the limits of what is practical. Somebody will eventually ask you if you can connect to a websocket. I know buildroot and yocto look a little scary at first, but they're better than designing yourself into a corner before you even get off the ground.
That's a matter of opinion.
If you don't know jack about network programming, then of course you can retreat to Linux. But Linux is not an edge / IoT platform by any stretch of the imagination. Micro RTOS is closer, but still overkill for embedded Wi-Fi.
Specifically for Wi-Fi, LWIP is -the- stack to use for embedded TCP/IP. It is under 30K with full TCP/IP and offers everything you need. Then there is COAP or MQTT, which are miniscule compared to HTTP. mbedTLS adds another 80K for full TLS compatibility on 40MHz processors. On top of this every major wifi vendor has an SDK that fits nicely into LWIP (some even ship it), some are small (CC5000) some are larger (like the WF200), but the APIs are pretty straightforward. Now, leaving TCP/IP and 802.11 will add headaches (BLE, ZigBee, Zwave) due to additional learning curves, but only because most people in embedded networking already understand TCP/IP and 802.11 phy.
If you want to play in the embedded space, you gotta learn about it. Running back to linux might work in some cases, but not constrained IoT space.
EDIT: I had my #s reversed, LWIP is under 30K, mbedTLS is around 80K, TLS is most of that (esp. RSA stuff, I could have disabled everything I didn't need [mbed has highly granular config] based on the ciphersuite and shrunk it considerably since ECC is smaller and faster than RSA). Just checked my map file, and I was in -O0 optimization mode.
EDIT2: On second thought: if people want to complain that they need linux to do networking on the edge, please complain! I'll interview after you and demonstrate MQTT with TLS v1.3 running off an MCU with a 2032 coincell for months (eh, I'm weirdflexing a little, but still...)
I think it's less a matter of opinion and more a question of expectations around the device you're building.
To illustrate, let's say we build the embedded device your way. Six months later, we get a support request from a customer that needs to get the device onto the captive portal at a hotel. The portal is a javascript monstrosity full of CORS failures.
What is your immediate response?
a) Oh, shit, I didn't think of that. I can probably come up with a workaround, but I'll need at least a month, and it'll end up being a huge hack that involves tethering with a phone or laptop (but not via WiFi, since the radio we're using can't do AP and STA modes simultaneously), and the UI will be such a disaster that the customer is immediately going to want to find a better product.
or
b) This is an industrial CNC controller... WTF are you doing on a hotel WiFi network?
If your answer is (a), then your approach is almost certainly the wrong one. If your answer is (b), your approach might be reasonable, but there are still other factors to consider.
It's possible to know everything there is to know about network programming but still not want to debug or re-implement 30 years worth of accumulated cruft around firewalls, MTU sizes, MS-CHAPv2 bugs, malformed packet crashes, anything IPv6, etc. And that's just the table stakes... leaky abstractions mean that sooner or later, everything connected to the internet is going to need to do something higher up the stack that's just barely out of reach for your microcontroller, even one that's beefy enough to run Windows 95. What are you going to do when there's some new web standard where the only implementation is in the Chrome source code as of three months ago?
You'll be able to make it work, but it'll take thousands of person-hours to make it work well. Or you can just "run back to Linux."
Separately, if you're running a company that builds embedded devices, do you want to pay your engineers to fix network stack bugs that were solved in 1999, or do you want to pay them to develop your company's value-add? Weirdflex all you like, it's still (usually) a terrible business decision. I don't think pennypinching on the BOM is a valid justification when things like [1] exist.
[1] https://www.seeedstudio.com/MT7688AN-BIT3-1-Module-p-4011.ht...
True. Software is soft for a reason. There's always a new requirement or vulnernability waiting to be exploited that needs to be updated.
That Mediatek module is nice! Thanks for that, and for the wisdom.
You're very good at inventing creative scenarios. Well done.
I don't really know where to start, you clearly want to defend your comfort zone. So I will be supportive: go work on projects that require Linux. It will be much more rewarding to you than working on constrained edge devices that are more challenging due to resource constraints.
You're also free to pretend that you can just swap in platform that requires watts of power in a scenario that requires an edge device to last a year on a battery.
Look, if you really need to get a coin cell onto the internet, then go for it. But I don't think your comments on this thread represent good advice for most engineers building typical devices. Insinuating that anyone who doesn't agree with your view is technically challenged is also kind of pathetic.
Expectations around what an internet connected device should look like and be capable of changed permanently with the launch of the iPhone in 2007. There will always be special cases like yours, but they are increasingly (sadly?) relegated to smaller corners of the internet.
I did it your way for years. Every company I've ever worked for that started off with a microcontroller based networking solution eventually migrated to an application processor because users and non-technical management kept demanding iPhone-like behavior that was either too difficult or too time consuming to deliver any other way. People expect a lot more functionality than just TCP sockets and web interfaces nowadays.
I'll add that it's not just capabilities that matter, but also the open Internet gets more and more hostile over time. In the absence of proof otherwise, eventually someone is going to transmit something that makes your device misbehave.
There are devices where both BOM and size constraints matter. Do you want to run Linux on every smart power socket, smart light switch, smart light bulb in your house? A light bulb in particular has tight volumetric and thermal budgets.
This is where stuff like ESP8266, and the controller from the post, makes sense.
I don't own any smart bulbs, but yeah -- this is a good example of a case where using a microcontroller is probably reasonable. I can't imagine people enjoy paying >$25 per bulb, and there's evidence that users are willing to put up with some truly appalling UX to get those things connected [1].
Amusingly, the most reliable smart outlet I own runs Linux on that MediaTek SoC I linked above (~500 MHz MIPS, 32MB RAM). I mean, power is definitely not a constraint when you're an inch away from the prongs, right? ¯\_(ツ)_/¯
[1] https://www.belkin.com/us/support-article?articleNum=116178
I completely agree, it depends on your expectations.
With the caveat that it's not a one-way trade-off of "better" vs. "good enough for the expectations". If your customer calls you and says "My industrial CNC controller crashed and ruined a $20k prototype, is this my fault or yours? Here are the logs." and your answer is "the browser was running bad javascript that locked up too many threads for too long so it stopped counting the encoder for 20 ms", they're going to tell you that a servo amplifier has no business doing any of that stuff.
Some devices do need to be on the Internet and should therefore be running general-purpose operating systems. They may need to interact with other devices that run real-time operating systems (or bare metal, like the Teensy). Some IoT devices try to bridge the gap. Knowing and deciding which side you're on is critical.
And I think the best answer to pennypinching on the BOM is to separate your concerns into separate devices/apps. Make the CNC HMI handle the Internet connectivity. Give it one NIC that hooks up to the Wifi, let it run whatever Javascript you want. On a separate NIC, talk whatever flavor of industrial protocol you prefer on the machine. Do not bridge the two. In the servo amp, use a bare-metal/RTOS microcontroller. That device doesn't need to be burdened with Linux, and in fact is made worse by it: Let it be what it is and no more. In 20 years, it should still run reliably, regardless of whatever newfangled holographic VR HMI is loading in motion profiles.
Exactly, use the right tool for the job.
FPGAs and microcontrollers are really good for meeting (and verifying that you're meeting) hard real-time constraints.
Network connectivity (by definition) can't be real-time, so you wouldn't want to run a network stack on the real-time core anyway, even if you could.
Instead of adding another non-real-time microcontroller for networking and making it sweat, go with an application processor and just treat it like a dumb modem that happens to know how to handle VPN traffic without exploding.
There are application processors like the i.MX7 and the STM32MP1 that combine a Cortex-M4 and a Cortex-A7 on the same die for precisely this reason (and similar FPGA fabric + PowerPC / ARM Cortex-A? products from Xilinx and Altera for even longer).
Is that why they say the S in IoT stands for Security?
On a similar note, does anyone know of good resources for beginners for prototyping all the way through small-scale manufacturing of an embedded device?
As a web & backend developer who likes to tinker with Arduino/Teensy style projects, I've always been curious what all would be involved in actually getting some units manufactured, like for a small kickstarter run or something. It seems pretty doable these days to get pcb boards printed and even assembled once you have a final design. What I haven't been able to find much of, is advice along the lines of going from a prototype board like an Arduino or Teensy system, to a productionalized system in terms of both the software and hardware - what platform is easiest to build on (like this advice to use a Linux-based system if you need any networking), how to hook up a bootloader, how to build a system that allows users to update firmware for future bugfixes or features, etc. plus I'm sure there are a million other unknown unknowns I would never even think of.
I made a video course for getting up and running with KiCad, the open source electronics CAD program: https://www.youtube.com/playlist?list=PLy2022BX6EspFAKBCgRuE...
If you're looking at broader focus on building hardware, Contextual Electronics helps to fill out some of the other elements you're looking to do. As luck would have it, I just started a new course today (no joke) where I'm showing how I'm designing a Raspberry Pi HAT with cellular and Bluetooth capabilities, which I'll be selling and using as a reference design for my hardware design consulting business.
How does KiCAD compare to Eagle? I find it being built in to Fusion 360 now (since Autodesk bought it) pretty compelling, but I haven't actually used any schematic/PCB CAD software since that I don't think.
I think they have been keeping apace for the most part, but the integration of F360 is a really nice feature if you do a lot of mechanical/electrical integration. I think it might be a bit overplayed, since my designs are usually, "Here's the mechanical space you're allotted, it's probably not going to change", but that's not the case for everyone.
As for KiCad, the most recent release (5.1.x) have been really stable and introduced a ton of features over the series 4 release. Like anything, once you're used to the methods, it's hard to get an objective look on how things work but I can tell you that I use KiCad for all of my professional design work and it has served me very well.
One thing I continue to be excited for is the extensibility of KiCad, since Python scripting is a main feature of KiCad (though the program is written in C++). This has developed a wide range of user plugins and scripts that have opened up some awesome new features.
One of my favorites is the Interactive BOM plugin, it's really quite amazing. Here's a user showcasing it on twitter: https://twitter.com/arturo182/status/1254376168322670593
Chris, I love your work and the AmpHour podcast! Thanks for working to share your knowledge with others, I especially enjoy the episodes where you spend the entire episode interviewing someone in the industry
Glad to hear it! I love making The Amp Hour and am flattered the people listen on a regular basis. Thanks for being part of the community!
Take a look at Particle. They sell dev boards, but also have excellent documentation on how to scale (at least they used to, I'm not sure where it's gone now - have a look in the datasheet section) - obviously they want to get you into their cloud fleet management platform, but it would be a tempting solution for me. For example, you buy the dev board (fairly cheap), they also sell the SoC (cheaper when you buy in bulk) and have design guidelines for making your own boards.
The boards themselves are quite nice. It's an Arduino-like stack and you can always code in C++ if you need the STM32 capability underneath. The main stack is also open source I think.
Doesn't really cover much on the mechanical side, e.g. enclosure design. That's a whole different game and that's where people lose a lot of money - if you mess up an injection mold for example.
I've done a small run of ~100 devices.
It was basically the same process as looperhacks: hook stuff up on a breadboard, turn that into a prototype PCB design, iterate on prototypes if there are problems, then just put 100 on the order form instead of 5 when you send it to the manufacturer.
You asked in the other comment about flashing and that depends. For me, my project was basically just a motherboard for an ESP32 dev board, which would serve as the logic controller. Since it has a micro-USB port and there were only 100 of them, I just flashed it from my laptop the same as any dev board.
For larger scale manufacturing, you can have the flash written in advance, before manufacture or put some exposed contacts on your board that can be reached with pogo pins and write your flash through those pins.
You can also outsource all of this to a contract manufacturer like Seeedstudio [0].
As for updates, the ESP32's software has built in OTA functionality that you can configure however you please. My boards are connected with MQTT over WiFi anyway so I added a simple "update now please" command that triggers the OTA. Aside from that you could add a USB port or stream the OTA over bluetooth from a smartphone.
Lately I've been prototyping a small board with my goal of maybe 10 units built. For me, the process is literally putting it together on a breadboard to check if it works, then design a PCB and send it to a Chinese manufacturer. Repeat if your PCB design is faulty. (Do double check your design though, you don't want to pay for new boards and shipping every other week)
I guess one big gap for me is just the build process of how to even load code onto the device to be executed, and what type of EEPROM or flash storage or other components are required for that, once you've removed the training wheels of the plug and play dev environment.
It really depends on what you're using. Most microcontrollers don't require external memory to store their program because it's stored in on-chip flash memory. Additionally, you can generally order microcontrollers from a distributer that are already flashed with your program. Though this may require ordering 1000+ units. If that isn't an option then you'll have to ensure that the pins used for programming are exposed in some fashion and then you'll flash it. The exact details are dependent on exactly which microcontroller and toolchain you're using.
It mostly comes down to reading the documentation for the specific microcontroller that you're using.
The power budget isn't the only reason you go for an MCU. Often you're doing it for the real-time guarantees or the hardware qualification (e.g. for applications where you need something with a safety rating). That said, yes... TCP/IP based networking in the traditional embedded world isn't comparatively pleasant.
Look at the NetBurner products. For the most part they Just Work, and their uCos-derived OS is a pleasure to use. It has a distinctly simplistic old-school vibe, but they have updated it to support WebSockets and numerous other new(ish) features. The end result is a good compromise between LwIP and full-blown Linux/BSD.
No association with the company, just a satisfied user.
How are things on the commonly used RTOSes? I'm not really into hardware much, only fairly recently learned basic electronics as a hobby, but I've seen ARM push their "mbed" (https://os.mbed.com/) thing in many places recently (most recently saw their logo printed on a nRF52 BLE dev kit). I've also seen Amazon get more involved with (in charge of?) FreeRTOS (https://aws.amazon.com/freertos/) quite some time ago.
Don't such things solve most of these issues?
The RTOS world is much less of an 'operating system' and more so a bare-bones task scheduler. It's not like a POSIX environment at all.
Right, but doesn't it also provide some very basic level of abstraction that things like network stack implementations can target? And then many projects also come with their "standard" (not bundled, just designed for) set of basic libraries? That's the impression I'm getting from skimming through the docs. (https://docs.zephyrproject.org/latest/guides/networking/net-..., https://www.mbed.com/en/technologies/security/mbed-tls/, https://docs.aws.amazon.com/freertos/latest/userguide/freert..., etc.)
You are correct.
that's not really true anymore. it may apply to things like pharlap or vsworks, but there are more modern options that give you a nice real-time linux environment.
https://access.redhat.com/documentation/en-us/red_hat_enterp...
https://www.ni.com/en-us/innovations/white-papers/13/introdu...
Linux with RT patches isn’t exactly RTOS, it’s Linux with such patches.
how is it not an RTOS?
and national instruments and red hat are both large companies that would seem to disagree with you. national instruments has completely replaced pharlap and vxworks in their newer products with their linux real-time OS, so them and their users writing real-time applications would also disagree with you.
See how Red Hat words it? “Red Hat Enterprise Linux for Real Time” not “RHEL RTOS” as if they don’t think Linux is technically not an RTOS. Or maybe they do think that way.
And see that chart down that page? Shows RHEL for RT achieve 3.5 to 85uS variance. I don’t know what application needs it but 80uS is 24km at the speed of light.
LabVIEW is NI’s bread and butter and LabVIEW connects to peripherals via cables and buses. NI not opting for conventional RTOS just means that 80uS errors are probably good enough for their usage.
RTOS also often refers to specific group of lightweight OS and libraries more so than capabilities. People want small no-bullshit runtime, not always a precision scheduler. From that point of view, Linux is just a bloatware towards extreme side so don’t qualify as one.
Overall, no, I still don’t think Linux is RTOS, I don’t think Red Hat says it is, and I think NI just don’t care.
I wonder what's your use case for RTOS? I don't really know any problems that couldn't be solved with micros communicating with linux. Seems like even SpaceX gets away with it.
I mean there seem to be the market so clearly there are some people who need it, I just would like to learn more about where is it really needed.
SpaceX uses FreeRTOS and VxWorks for chips that need hard real time guarantees from what I've heard.
It's not that the problems couldn't be solved that way, it's that they don't necessarily get any simpler. Adding an external micro and all the support it needs is added cost, maybe added real estate, power budget and very often, it makes the solution more complex and less reliable.
RTOS are mainly for micros communicating with Linux.
Lots of time they are just a giant C library that goes into the same a.out, that for devs look close enough to let himself pretend there will be an OS running his code.
Stuff powered from a coin cell battery?
From coin cell battery you can power a microcontroller that is sleeping most of the time, not a real-time operating system.
You can do exactly this with an ESP32. It's got an RTOS (FreeRTOS) which will spend most of its time sleeping https://learn.circuit.rocks/esp32-deep-sleep
Debatable. Personally I would not try to do a project that uses wifi on a cell battery. And if you don't need wifi then you have much better options that use low current not only while sleeping (e.g. nrf series)
But my main point which I should have included in the previous reply was - what does real time OS have to do with the project being run from a cell battery?
So my assumptions in the original question a number of comments above (in the context of the comment above it) were:
- something running regular Linux would be too heavy (though I don't know if that's really the case, especially if you only turn it on a few times a day on average for a little bit)
- adding the "OS" abstraction would presumably result in access to higher quality ecosystem of libraries than whatever is available on bare metal directly (as I assume some of those libraries depend on the "OS" for event handling etc.) - which was the complaint in the comment I was replying to
But like I said, I know very little about this area, so if any of this doesn't make sense, just ignore my comment :D
It has a 32 bit processor and at least 1 MB of RAM and 8 MB of flash. This makes it considerably more powerful than the first PC I owned. Could it run Minix 3?
Yes. And in fact a 32 bit microprocessor with a meg of flash and 256K of RAM can run a number of useful OSes that have networking capability.
What I find interesting about the situation is the Arduino environment. The Teensy originated as an "Arduino" type dedicated controller board. The Arduino environment originated on something that had 32K of flash memory and 2K of RAM. (Think Altair 8800 or IMSAI 8080).
It was designed so that people new to embedded controllers could get something running quickly on a very simple processor.
The Cortex-M architecture (which the Teensy uses, as does the STM32 parts) is somewhere between the 68000 and the 80286 in terms of its capability (no MMU though).
On at $30 dev-board (STM32F429-DISCO) from ST-Micro I've run a full shell/loadable program environment with networking based on a FreeRTOS kernel and a shell of my own devising.
It is the Arduino environment that cripples these things, if they ran the equivalent of MS-DOS none of these complaints would make any sense at all. (and they are very capable of running that level of OS)
as I recall, PCs from the 90s also had extremely poor networking support.
> But if you're building an embedded device that will be deployed in any sort of volume, a small application processor running Linux will make your life dramatically easier.
Can you name some? I think of most embedded network stacks as being easier than raw socket APIs on Linux or Windows.
Programming network on Linux only looks that easy because of megatons of ready to use abstraction libraries available.
I was puzzled finding a good linux board for cheap device. Decent linux is like 10$ price minimum and you probably need something better. It could easily sky rocket to 30$ and this is out of budged of almost any devices. 30$ makes your device retail cost ~100$ already.
While you can get M4 for under a 1$ having all built in and very power efficient.
Also no need to hustle with linux deployment and update rollouts.
There are several vendors of embedded RTOSs that will give you a decent TCP stack. Especially on the lower end, Linux is not a good option.
But what to use? The Pi Zero can't be used for mass-production, because you can't get it in quantity. Other options exist, but they are even more expensive, or obscure chinesium for which you can't get documentation or someone to talk to.
If you want an decently peforming SBC that can match the Pi Zero in price, unfortunately you're out of luck. But if you're willing to put in a bit of work, make your own board and suffer most things not working out-of-the-box, you have a wide variety of cheap SoCs and MPUs. E.g. the STM32 MPU line, which has a decent enough ecosystem and plenty of devboards available, and has some chips under $5/unit in bulk.
None of which have wifi, as far as I can see?
The original ESP8266 ESP-01 was among such devices to add Wi-Fi to host CPU over SPI or UART...
You need an external module for WiFi, but the standard Linux networking tools and drivers work.
Development kits like the Pi Zero are usually intended solely for development and experimentation. When it comes to production, you either take the product the dev kit is wrapped around or there's some kind of module you can use.
For example Raspberry Pi has the Compute Module, ESP32 comes as a solderable module and for the Teensy I suspect you'd just put a IMXRT1062 in your design.
Is particle.io considered one of the more expensive ones? I've used them for one-off projects but it looks like they do volume discounts.
Yes, this is a very good point. Low-end application processors capable of running Linux are also very cheap now and it is easy to build a minimal system for around a few bucks (eg. Allwinner F1C100s, although it does not have an Ethernet MAC built in). Not great for hard real-time stuff, but if the requirements there are limited a separate microcontroller could work.
>Are you really prepared to roll out updates on a system like this when the next Heartbleed comes along?
Implying that embedded systems get updated...
Lots of them do. I have a bigass board right next to me with a couple dozen wires sticking out that can get updates by flash drive. We ship tons of hardware that gets updated over Ethernet or OTA.
> The hard part is not cramming in an Ethernet PHY or a 2.4 GHz radio, it's the mountain of software that you need to run on top of it to get the kind of reliable, secure communications channels that we've come to expect
Have you looked into PJON?
I totally get what you're saying.
Although I'll add that Linux has it's fair share of networking bugs and quirks (less now than before, but still plenty.)
Instead of that, how about an nRF5340 running Linux Foundation's Zephyr Project OS on its application core?
The Teensy line is great for folks like me, who are doing one-off projects and who know more about software than hardware. There are good libraries, a helpful developer, and a supportive community. I've used Teensies to make millisecond-accurate camera controllers, radar-triggered music/light-show devices, and burning-man style LED hats. If I were doing production, they'd probably be overkill (and too expensive), but they save me time and effort and are easy to use.
Yup. I love Teensies for building USB input devices. It's trivial to get something basic working and not much harder to tweak it if you want to appear differently to the system or use a higher refresh rate for lower latency gaming.
They're breadboard friendly, as easy to use as an Arduino, etc. For one-off builds that need lower power or tighter timing than I can achieve with a Pi I pretty much default to looking at the Teensy line unless I need some kind of wireless communications, in which case an ESP variant is usually my choice.
Genuinely curious, what kinds of projects are better suited to a Teensy than an Arduino, ESP32 or some form of Raspberry Pi?
Is the main advantage the pin count?
I've used both extensively as "daughterboards" to big control circuits. The main advantage of the Teensy to me is that the hardware is better than Arduino was at the time. It is also, well, Teensy compared to most Arduinos so it takes up less real estate.
Now that Arduino is running an ESP32 or ARM chip or has FPGA acceleration and such I'd say the difference is mostly just size. I do think some of the core libraries for the Teensy are better written though, the Arduino authors don't seem to focus as much as Paul does on optimizations. Paul also frequently posts in the forums to respond to questions, which is unusual in my experience.
Edit: In response to the Raspberry Pi, it's just a totally different beast. The Teensy is probably not well suited to run much of an OS (nor is the Arduino). Both are better suited to things that require more pins available; embedded controllers rather than computer substitutes.
> Now that Arduino is running an ESP32 or ARM chip or has FPGA acceleration
I recently used a Teensy for exactly the reasons you gave, but I'm not familiar with Arduino's with ARM or FPGA. That sounds very interesting, do you have some links where we can learn more?
Arduino has had ARM-based boards for years, starting with the Arduino Due in 2012; most of their newer boards use ATSAMD MCUs rather than the AVR8 parts they started out with. There's also a pretty active community supporting STM32 ARM hardware at https://www.stm32duino.com/.
The "FPGA acceleration", on the other hand, is pretty limited. Arduino has one board -- the MKR Vidor 4000 [1] -- with an onboard FPGA. The FPGA can be configured with one of a couple prepackaged bitstreams to add I/Os or perform some specific video processing tasks; it does not accelerate processing on the Arduino MCU. The documentation for the board is minimal, and support for generating your own bitstreams is basically nonexistent. The whole thing has a half-baked feel to it; I'd avoid it.
Thanks for the link to the Vidor, unfortunate it wasn't more functional. It'll happen someday and when it does I'll be very excited, I know that there are already hybrid FPGA/microcontroller chips as an alternative to putting a softcore microcontroller on the FPGA itself (and wasting a lot more space and speed than needed).
I await the day when I can be like "nah, pin 2 will be a 16-bit 10MHz PWM output controlled by this register and pin 7 will be a frequency counter" and then access that with code on the microcontroller as if it was a built in peripheral.
I'm kind of skeptical I'll ever really get into FPGAs otherwise, my use case for them is always so simple, at the level of... well... PWM outputs and PID loops. But a microcontroller is fast enough for most PID loops so really to me the advantage is customizable function-pin mappings. I can't imagine trying to implement something like an ethernet stack on an FPGA though, although I guess you can run DOOM on one so maybe there will be a compiler from C++ to FPGA somehow that's not comically bad. ;-)
There was the papilio duo too which had the Spartan 6 LX9 FPGA with an ATmega32U4 on the bottom. Not sure if they are for sale anymore though. I backed the kickstarter (and work with a company which made some of the wings for them) but I never really got into using them. I still have mine around and plan on using it for some project in the future though.
http://papilio.cc/index.php?n=Papilio.PapilioDUOHardwareGuid...
edit: yep...still for sale http://store.gadgetfactory.net/fpga/
I hate to just direct you to arduino.cc, but there's so many boards I can't really answer this in a more reasonable way.
The Arduino Due has been around for probably seven years and runs on ARM. There are many other versions now that are all ARM. The FPGA coprocessor one... hmm, I don't see it so maybe I just read it in the news or got confused by the Portenta that is supposed to be released about now.
The ESP32 one... I thought Arduino was moving to that for the RF capabilities but might be wrong, I can't find one for that either anymore. I know for sure you can get a ESP32 dev board and program it with the Arduino IDE and their Arduino-IDF libraries compile nearly Arduino-identical code with a few limitations (relative to the Teensy, which I think is basically perfect library API duplication).
I've used the Teensy 3.1 and it's more or less an Arduino (including uses the Arduino IDE) but lower cost and more powerful processor. There is also a way to build C/C++ code and run it on the Teensy. ESP is similar but has WiFi built in and Raspberry Pi is closer to a full blown general-purpose computer than an embedded platform. Software on the Teensy runs on bare metal, software on the Raspberry Pi usually runs on an operating system (Linux) and is not real-time.
To be fair you can also build C/C++ code on an arduino. Although if you want to move away from the Arduino IDE/language, probably an Arduino is not the best platform for you anyway!
The standard Arduino "language" is really C/C++, is it not? (as well as all the C/C++ libraries that extend it) I suppose the "Arduino language" itself could be described as a library as well, or at least a C/C++ helper/wrapper abstraction for common tasks.
You are correct, the "Arduino language" is just C++ with some special libraries, macros, added types, and an IDE that enforces some limitations on the programmer (though you can use the Arduino library without the IDE).
In practice using this library/ecosystem/whatever is different enough from "normal" embedded C/C++ libraries that to me at least to me it does feel like a different language.
I think most people call it a language out of ignorance or laziness though.
I thought they insisted on calling it "Processing"?
I just write standard C++ or C code and it compiles fine. Hard to complain about that too much if I don't care to use the extra features. You can just access registers directly even if you use the Arduino IDE and configure things yourself if you want.
But yeah, I'd personally use visual studio code if I wasn't going to want to use the arduino libraries anyway. It's not a great editor. VS Code probably isn't that great either, but it's good enough for the little coding I do (I mostly design circuit boards that frequently use these little boards as brains).
The Arduino IDE is certainly a fork of the Processing IDE. The language is different: Arduino is C/C++, Processing is Java. But Arduino did take a bunch of UX (or call it "DX") from the Processing lang.
Just use platform io... it works inside VS Code and lets you use arduino and other frameworks if you want to do so.
I think the main selling point of Arduino is the "batteries included" approach if you're not familiar with embedded programing. Personally I never use Arduino because of the weird header spacing (I get it's sort of a trademark at this point but it's just annoying to work with).
If you don't care about premade environments then yeah, it's mainly about which pins and embedded peripheral the board supports. Pin count is not everything, nobody wants to bitbang USB or even high-speed SPI. For instance I see that this teensy board supports up to 18 analog inputs when Arduino supports between 6 and 15 according to this: https://www.arduino.cc/reference/en/language/functions/analo...
Basically the choice of controller should be the last step in your design: first thing about your inputs and outputs, then find a controller with suitable I/O and processing power (and preferably with standard header spacing).
RPi is more like a mini-computer than a controller, it's a lot more powerful and comes with massively more overhead. You program something like a teensy on "bare metal" with only a very minimal runtime. On an RPi you'd typically run a full blown OS. That opens up many possibilities but it's also generally more expensive and more power hungry. If you just want to drive 5 GPIOs it's completely overkill.
Teensy has a great library ecosystem too, so it can be a serious contender regarding "batteries included"
Agreed, plus a very responsive and helpful developer.
Teensy has a nice audio library if you're interested in real-time sound synthesis and stuff like that, as well as MIDI-over-USB support. Along with a fast processor and a tiny footprint, it's pretty useful for making musical instruments.
There is even a hearing aid using teensy board and the modified version of teensy audio library[1]!
Wouldn't you also need an ADC/DAC to interface with analog signals (e.g. for a custom Eurorack module)?
I don't know about Eurorack stuff, but yes, for analog audio output, Teensy sells an audio adapter board with line-level output and a headphone jack [1] and that's what I'm using. The audio data is sent digitally using I2S. The audio library also supports cruder ways to do DAC yourself if you don't need it to be as high quality.
It would be nice if there was a Teensy board with analog audio output, though.
Depends on how you mean. My modular synth has many Chord Organ and Radio Music modules, by Tom Whitwell of Music Thing Modular. They're all Teensy 3.1 and the audio's taken off an extra pin (not in the DIP configuration, and I've forgotten to include it before) and buffered with simple TL07* op amps. It's mono, I think it's 44.1k and effectively 12-bit, and I suspect it needs the op-amps for buffering and boosting, but it's absolutely there and that's the 'cruder ways' and though it's primitive and mono it absolutely works, and works surprisingly well with filtering/reverb/etc.
What I'd like is a Teensy board with SERIOUS analog output that still works with my Chord Organ firmware. Like 192k (or indeed 96k) and 24 bit… but I could get a lot of use out of even low-bit at elevated sample rates, because one of my options for coding stuff on the firmware and Tom's eurorack module hardware is using the Teensy's library to produce multiple square waves.
If I'm outputting square waves I can use almost arbitrarily low-bit word length, but high sample rate will greatly reduce aliasing, and not just for high frequencies. The Teensy raw audio stuff has a characteristic grunginess on squares and saws that is mostly or entirely about aliasing.
I’d be interested to discuss this: tom@musicthing.co.uk
Teensy audio adapter has SGTL5000[1] running on the board and in my opinion it is highly customizable. It provides up to 96KHz sample rate (44.1 KHz with teensy's clock I guess) with 16bit sample size for ADC and DAC so I don't think it's low quality.
[1] https://www.nxp.com/products/audio/audio-converters/ultra-lo...
Yep. I have a teensy+codec for the express purpose of experimenting with audio DSP filters.
As an anecdotal example, Teensy is often found in custom built mechanical keyboards and mechanical keyboard kits. Form factor and library support are two primary reasons as far as I've understood in my occasional bouts with hobbyists.
And their official software to flash the firmware is excellent. I've had severe issues with cheaper controller boards where the pain isn't worth the price difference in my opinion.
I pick teensy for mine. Is null-issues and so easy to flash.
Also exist a neat workflow where you design your keyb on http://www.keyboard-layout-editor.com and then import it on https://kbfirmware.com and you get your keyb up and running very fast.
Well, there was that short lived issue where the Teensy 3.5 or 3.6 wouldn't boot right without an extra capacitor soldered on the reset line.
But it's also very encouraging that on the Teensy the issue was identified and a solution provided so quickly.
On the responsiveness note, I found a typo in the ESP32 datasheet and reported it to them through the forum. They responded very quickly and noted that it was indeed a typo (their chip as described didn't have a ground pin) and promised to fix it.
So on speed that's great. But their most recent datasheet had the same typo so...
As a hobbyist embedded developer, I personally view the Arduino and Teensy as being suited for the same class of applications: doing one or two low-level things reliably and predictably, while serving as an abstraction layer to a general purpose computing platform, like a Raspberry Pi or other computer.
IMO, the Teensy boards have historically not only completely duplicated the functionality of most Arduino boards (including supporting the Arduino IDE), they've also provided additional features/peripherals not present on most Arduino boards. (Increased RAM, flash, CPU, peripherals like onboard CAN controllers, ability to enumerate as a variety of USB devices, and yes, more available pins)
I've also felt that that the Arduino boards are engineered (physically and feature-wise) to sell their branded daughtercards (Arduino "shields"). This is not necessarily a bad thing for beginner-level classroom environments. However, if you're looking to do something practical, it's a lot easier to throw a Teensy into a breadboard.
I wouldn't see it as an Arduino competitor as they're different beasts mostly aimed at different use cases.
The Teensy also has a DSP on board which can be useful in many applications, from music to signal processing. Here's a SDR radio built around a Teensy some years back. http://theradioboard.com/rb/viewtopic.php?f=4&t=6641 Does anyone know of any kits like that around?
Ah - we asked the same question: https://news.ycombinator.com/item?id=23144432
I can see why the Raspberry might not be a good replacement for Teensy - power hungry (ESP32/STM32 have fantastic ULP/Deep sleep) and/or form factor.
> pin count?
maybe but there are ultra cheap analog and digital multiplexers available.
multiplexers are fine if you're either doing slow signals or uniform outputs. They're not worth the hassle if you want multiple high-speed connections.
Not only that, also a full bloated OS wasting CPU cycles.
RPI straddles the gap between regular computers and embedded systems. It can perform some of the duties of each, but the drawbacks become clearer the further away from the middle ground your use case gets.
Exactly. When you want a powerful processor that is going to basically do one thing very well, use a Teensy. When you don't need the power, use Arduino.
About 7 years ago it was the most affordable USB controller that identify them self as a HID device that I could find to brute force the EFI lock on a MacBook Pro https://orvtech.com/atacar-efi-pin-macbook-pro-en.html
It was really easy to setup and start pushing code to it
The main advantage for the Teensy 4.x is the performance. 600Mhz Arm M7 with LOTS of RAM and Flash. So anywhere where a microcontroller is better suited than an RPi (hard real time, etc), but performance matters.
Running large scale LED matrices with good animation frame rates was at least at one time WAY more performant on a teensy. Not sure if that's still true today.
Teensies range from 16 MHz AVR chips to this 600 MHz Cortex M7. Arduinos cover a variety of platforms as well. ESP32 is if you want WiFi integrated. Raspberry Pi is a full blown computer. This is a full gamut of capability. What you choose for a project depends on your requirements.
Automatic window blind opener? Teensy 2.0 if you like AVR, Teensy LC if you like ARM.
Camera watching your 3d printer using computer vision to detect if it catches on fire? Raspberry Pi.
The Raspberry Pi Zero W is great for tasks that need wifi too (window blinds, etc). At $10 it's cheap and it's really nice to write your programs in python. I've got plenty of experience with microcontrollers and C++ but I find python just so much nicer to use when I can. You can even host a web page from it for a quick and easy GUI control (use Flask for a pure python implementation).
As skybrian says, Teensy has a lot to offer for audio/DSP work. The Teensy 4 generation runs like a bat out of hell compared to an Arduino or ESP32, but it's a much lighter-weight development platform than a RPi or BeagleBone.
Basically, if you want an Arduino that's roughly a thousand times faster, you want a Teensy 4.
> better suited to a Teensy than an Arduino
In my experience, all projects I would do with an Arduino. Thus far, it's just been LED stuff. On Arduino I very quickly ran out of resources, then had to redo my entire project wiring to switch over to a Teensy.
Example project: https://luftdaten.info/laermsensor-bauen/ (only German and French translation ATM)
Years ago, in 2013 or so, I recall the Teensy was better suited for my application due to the higher clock speed.
Teensy became popular for a few reasons: it's small, cheap, has lots of IO and dead-simple USB HID support.
No, it would be performance - for example regarding clock speed and RAM size.
Arduino you write bare metal firmware, raspPi you write software on a host OS
firmware does not have the overhead of a host OS. super low power modes, instant sleep/wake, exact control of instructions/clock, far fewer security issues.
Teensy and ESP32 are just souped up Arduinos.
> Teensy and ESP32 are just souped up Arduinos.
Cheaper, more powerful, more feature-rich Arduinos, if you squint. I'm not sure why you would actually use an Arduino™ unless they've really improved their lineup since I last looked.
I use Arduino Nanos as modules in larger systems. I can buy them for $2.50 each, which is far less than it would cost me to build them.
If you can get them for $2.50, then yeah that's competitive, but the official site lists the Arduino Nano at $20.70 and it appears to be weaker than the Teensy-LC at $11.65, or ESP 8266 series at <$5 for a 5-pack (why Amazon only seems to sell them in bundles is beyond me). And the Teensy has a better chip and can do USB mouse/kb emulation, and ESPs all do wifi. If you can get them for $2.50 and don't need more power or features then yeah that's a good pick, but I maintain that official Arduino™ boards are not an obvious first pick.
Oh, I definitely agree with you on that. Unless you're a school or similar institution that needs to go with the safe choice, I really don't understand how Arduino™ makes any sales.
The clones are so much less expensive than the official Arduinos that there's no comparison. Even the versions that Adafruit makes that IMHO, improve the design cost less than the official arduinos. So it's not a surprise that the Chinese clones will be dirt cheap. I'm not complaining though. I have a board where the Nano (clone) itself is by far the cheapest "chip" in the BOM. Precision analog devices are expensive and my 50 or so boards sold each year can't compete with the Shenzen manufacturers' economies of scale.
The Adafruit “Arduinos” are pretty great.
Hand wiring a mechanical keyboard.
Cortex-M7 @ 600MHz, pads for PSRAM(8MB or more), microSD, wait, isn’t this thing Linux Kernel compatible at that point?
μClinux, since there's no MMU.
μClinux is a variation of the Linux kernel, previously maintained as a fork, that targets microcontrollers without a memory management unit (MMU).
SOURCE: https://en.m.wikipedia.org/wiki/ΜClinux
——————————-
How uClinux provides MMU-less processors with an alternative https://www.eetimes.com/how-uclinux-provides-mmu-less-proces...
I've worked with all the various Arduino and other MCU boards as well as Pis. My preferred chip is still an Arduino Nano in a screw terminal carrier (just today I wired up one to make a rotating stepper that rotated in sync with a camera trigger, to do 3D scanning for Meshroom).
I love the old Uno, it's solid as a rock but of course has very limited CPU and memory. I would only use an Uno if I had a specific shield that fit the Uno and needed 100% compatibility. The dupont connectors are too loose for permanent projets that get shaken around... it's 5V, which makes working with some hardware easier (although most things "kinda work" with 3.3v MCUs, some stuff doesn't).
The Nano is like the UNO but smaller, although you can get nice little screw terminal carriers that make permanent connections more reliable.
The Teensy is a faster arduino with some very good support libraries. It Just Works, most of the time. But I haven't ended up using it for anything; I've replaced it with Nanos or ESP8266 or ESP32.
The ESP2866 and ESP32 are great systems, truly amazing what they can do even if they're just emulating an Arduino. however, there is a fair amount of compatibility problems with the 32 (for example, I have a sketch for a self-balancing robot, it works fine on Nano and ESP2866, but hangs on the '32). But the 32 has a special trick up its sleeve: the arduino functionality is really just an emulator that runs inside an RTOS. I started to play with FreeRTOS on ESP32 (https://docs.espressif.com/projects/esp-idf/en/latest/esp32/...) and was really impressed. It feels a lot like my days using a 286- no virtual memory, a few megs of RAM, and basic networking.
With the supercheap sub $5 ESP32/STM32 boards (both have Arduino core support) and their equally cheap add onboards for camera, ethernet or USB OTG - who exactly are using the Teensy line today and why?
I'm genuinely curious.
For me it is rock solid USB and known quality. I use them as a bridge between analog/ADC board and USB, doing some buffering and signal processing for my spectroscopy projects.
Think of it as an ARM prototyping tool.
You would switch to the bare chip for production. [1]
Of course, for low production runs, you could stick the Teensy board in your product.
The $5 boards aren't 600MHz M7's with loads of SRAM and Flash.
Maybe, but what scenarios are there where you'd want that, be willing to spend 30 dollars on your microcontroller solution and not benefit from a more capable linux SOC? (With an optional $3 M0/M3 for realtime if required)
Yes, it's not needed for every use case. There are some obvious places where 600MHz helps, either for input sample rate or output waveform. The Teensy 4.0 is $20, with the same processor as the 4.1.
Also, 100 mA current draw with the CPU at full speed. For some use cases, that is helpful...versus the RPi.
Would this Teensy be suitable for real time audio processing? I mean little-to-no latency.
> little-to-no latency
I don't follow Teensy deeply but both the ESP32/STM32 are being used for real time audio processing.
I'm using it to decode DTMF without using a one more DIP IC.
I'm sure there's some latency involved but for my use case, the bang for the buck is great.
These are substantially more powerful than both of those families.
Also substantially more expensive, especially compared to the likes of the banana pi zero, which gets you four cores at 1.2Ghz, 512MB RAM, Linux and a GPU for 35% cheaper. Pair that with a Blue Pill STM32 for $3 if you need realtime and you still have money left over.
That looks like a great stack!
In the "Pi" family, for a Linux SBC, which pi/clone gives a good bang for the buck?
banana pi zero has shown up multiple times but since you are in the know, I wanted to ask what's a good SBC to run OpenWRT on, for example
> Blue Pill STM32 for $3
The Black Pill STM32 for $4 are an ever better value!
What is your point? This is more powerful than all of the ones on your linked page.
Marginally. The STM32H7 series offers Cortex-M7 cores at up to 480 MHz, with a Cortex-M4 coprocessor on some parts at 240 MHz. It's not quite as fast as the i.MXRT1052, but it's damn close.
The posted coremark scores do not support your claim that NXP iMXRT1062 is substantially more powerful. If I take these numbers at face value, then STM32 promises up to 45% more perf.
Generally a very nice addition to the lineup. I'm personally fascinated by the support for soldering on an additional RAM chip; depending on how painful it is to actually access that memory, the extra 8MB could finally be enough to run uclinux.
The ESP32 can do that too. Note that PSRAM is a lot slower than the embedded SRAM, so if you need to access that memory a lot, you're going to have a bad time.
Rest assured, when I'm trying to figure out whether I can coerce Linux into running on a board that was never meant to support such a thing, "slow" is a secondary concern:)
Well in that case... http://dmitry.gr/?r=05.Projects&proj=07.%20Linux%20on%208bit
Apparently it's as simple as using a different offset in pointers when enabled!
I wish Teensy was open source, it is not. It is amazingly well engineered including the bootloader, just that it's all closed source.
huh? the only thing closed is the bootloader, which is ok-ish I think. Everything else in the toolchain is open source. Paul is a terrific guy and provides great support in the forums. You can find the schematics, gerber files, etc in the webpage as well. What part would you like to be open source specifically?
I think releasing the source code and open-source are 2 different things. Paul is an amazing guy, I absolutely cannot argue - he is super cool.
Open-source means I have the license to use it in ways that are defined in an agreement outlined in the specific open source license (say MIT license). Paul provides a bunch of stuff for their users, but I cannot copy his designs and bootloader (which is closed) in a commercial project without taking on liability.
The problem is a philosophical one as well - Half-open or "visible source" projects exploit benefits of the open-source community (engagement, contributions, feedback, etc.) without giving anything back to the community (license to reproduce freely). I have a problem with this. Either make something completely closed source (totally fine) or make it completely open source. Another example is Numworks calculator ("visible source" under CC license, wtf is wrong with these people) : https://github.com/numworks/epsilon/issues/38
The Numworks guys are just getting free labor which is all the enthusiasts working on the code without paying anything back to the community! Completely abhorrent behavior and should be exposed.
100% agree with you, but in this case, I believe most (if not all?) the code is under a bsd-like license. Take a look at the top of this file: https://github.com/PaulStoffregen/cores/blob/master/teensy4/...
also, the design is encouraged to be used in commercial projects. Paul even sells the bootloader chip programmed for your own designs. There’s a specific section in the forum for those use cases.
Isn't the bootloader chip the only not-open thing?
Do I get a license for hardware schematics and board layout and other aspects besides the bootloader? Where can I find a license in writing? If a license is not provided, I can't do anything with it besides hobby work.
Here is the schematic page but no mention of a license: https://www.pjrc.com/teensy/schematic.html
This is NOT open-source. It is visible-source.
Please note, I am not demanding an open-source license. Closed source projects are totally fine, I feel absolutely no entitlement to get stuff for free. I am just pointing out projects that are closed-source but disguised as open-source, thereby taking advantage of the hobbyist community. Paul may be a cool guy, but objectively that doesn't change anything.
True, board layouts aren't either, forgot about that. The circuit itself can't be copyrighted, so you do not need a license to make your own board with the same components.
I personally quite like the approach of using the bootloader chip as light DRM: The majority of the value is in software you can freely use, with licenses provided. Prototyping with a Teensy and then making a product using the same parts and the libraries, not a problem. Just if you want to provide the same easy dev-board experience you need the bootloader chip (which you can buy and use for your own design) or invest your own development of an alternative.
Yep, I really like how the bootloader works - upgrades are drag and drop. I'll write to Paul if he is open for selling the bootloader license to me for commercial use. I am sure we can come to an agreement.
He sells the chip pre-programmed for the older versions: https://www.pjrc.com/store/ic_mkl02.html
Support for the chip used in Teensy 4 is apparently coming in the near-ish future: https://forum.pjrc.com/threads/57132-Bootloader-Chip-For-Tee...
The ARM Cortex-M7 architecture is not open, not sure if that’s what the OP was referring to. RISC-V would be an example of an open architecture.
That's true, at some point in the abstraction layers from Teensy to the silicon atoms, the concept of "open-source" disintegrates. But to clarify, I am mainly concerned with the top layer - gerber files, schematics, bootloader, etc.
Does this one have the JTAG/SWD pins available? I know that the teensy bootloader is one of its USPs, but not being able to connect a debugger is kind of a dealbreaker for any sort of complex project.
It does not.
This has been a longstanding issue with all of the ARM-based Teensy boards, and it's really the main reason I'd hesitate to recommend them.
Many Arduino compatible boards support hardware debugging. For example the Adafruit Feather series have connectors for a J-Link debugger. The Arduino Nano 33 BLE and Sense have pads on the botom to solder the leads of a J-Link cable. STM Nucleos even have the debug probe built in accessible over the same USB port.
PlatformIO https://platformio.org/ is the preferred Arduino IDE (a plugin for VS Code). It has support for hardware debugging, C++ code highlighting, code completion and Intellisense.
Yeah this is why I have 4 of the last revision sitting in a bag on a shelf. I got tired of print debugging, if you look in the forums there is some discussion on how to modify the hardware, but it is not easy.
These are great little boards, and they already have support in the latest beta of CircuitPython! https://circuitpython.org
If you're interested in this and based in the UK then we have stock coming shortly and you can sign up for notification here: https://shop.pimoroni.com/products/teensy-4-1
To answer the frequent question about Teensy.
Paul. Paul is the reason to buy a Teensy.
His dedication and support is inspiring. Phenomenal.
Having raised this question [1], I am impressed at how well written the software is!
If you want to see a cool project done with Teensy check this custom midi controller/sequencer interface with motorized sliders
https://www.youtube.com/watch?v=IH-grgRmClY
https://forum.pjrc.com/threads/54995-Zeus-Commander-SPS-16-M...
I remember using Teensy based on AT90USB1286 microcontroller for 4 quadrant 3phase AC motor torque control. Worked like a charm. Glad to hear they're stilll in business.
Have you been keeping track of the 4 quadrant 3phase AC motor torque control using STM32?
The idea is to run these 3phase AC motors off DC
I am not sure I understand the question. I already stated the controller type. I have not done anything with STM32 but if it does have proper PWM and timers I assume it can bee done just as easy.
Torque control is more complex than just simply running 3ph AC motor off DC.
> Torque control is more complex than just simply running 3ph AC motor off DC.
Fair enough, I got a bit too greedy with my wants.
Right now, I'm interested in running 3ph AC motor (or brushless DC motors) off DC using STM32 but having a hard time finding good open designs with affordable (DIY) feedback systems.
I can't really help you much here. When I first needed it few years ago I did google search and found bunch of articles on motor control (from Microchip I believe) that also had some designs, Once I understood basic theory I then designed my own circuit that after few tries worked fine. It is highly specialized for my particular product.
What is out there now in open designs I have no idea as I do electronics extremely rarely. I am developing mostly software products.
> I do electronics extremely rarely. I am developing mostly software products.
Ah got it!
I do mostly software products as well with electronics a near and dear hobby. Would love to be in touch!
Sounds cool. What did you need 3 phase 4 quadrant for, if I may ask out of curiosity?
The product is known enough to reveal my identity unfortunately ;)
That's okay, I don't mind. :-)
Just out of curiosity, what could be a use case for this thingy?
Their blog (when it loads) gives some great examples: https://www.pjrc.com/blog/
It can be used for just about anything you can use a microcontroller for, but it seems particularly popular for art or music-related projects. For instance, audio synthesis, controlling large numbers of programmable LED strips, custom MIDI controllers, and so on.
I've used mostly the Teensy LC, 3.2 and 3.6 boards. I use them as kind of a cross between a GPIO and a data acquisition board. For instance it's easy to plug one into USB and write a program that lets you talk to it, e.g., from Python, to read voltages, turn things on / off, etc.
From there, it's not a huge quantum leap to program some lengthy sequences of operations into the Teensy itself rather than in Python, e.g., averaging 1000 consecutive analog readings, or interfacing with some interesting chip via SPI bus. Migrating this functionality onto the Teensy reduces the amount of USB traffic needed to implement a function, so the "system" as a whole becomes more efficient.
Also, the Teensy can do stuff in real time based on its internal clock, that can be difficult on a modern operating system.
The T3.6 has built-in floating point, which makes some kind of programming easier.
So far I haven't created any stand-alone uses to speak of. I'm mainly interested in stuff that extends the functionality of my regular PC. I've even created such mundane things as a USB temperature sensor. While not the cheapest or most elegant way to do it, I was able to spin it up in no time flat for something that needed it.
Amateur spy tools, DIY IoT devices, etc :)
The Teensy line just keeps getting better and better with each release.
I've been playing around with boards like this that keep getting smaller and smaller. Do people generally prototype something using these boards and then go directly to manufacturing? I imagine you'd want to have a smaller package than use these types of components as part of you larger product right?
I wouldn't hesitate to do so. It all depends on what kind of price / volume you're trying to target. For very short run, garage-shop types of operations, not only is handling surface-mount a headache, but there's a learning curve to getting any kind of circuit boards manufactured.
In addition to these microcontroller boards, you can find "breakout" boards for a variety of sophisticated components, and combine them on a carrier board that can be basic 2-layer hand soldered. It's quite a practical way for getting something simple out the door.
There's a lot of garage shop types of businesses that combine small scale manufacturing with customer support, and are not looking to get into high volume consumer market. For instance a friend of mine develops industrial solutions, where the customer might buy 10 to 1000 modules for their own use, or to support a product, such as some kind of weird agricultural machinery. These folks make their money by being local, easy to deal with, and willing to listen and understand the customer's need.
This is a clear case of "do things that don't scale."
Do these people write about what they do? Make and Hackaday are great for fun one-off projects, but I don't really know much about the world of small-scale commercial like this. Make went bankrupt because they couldn't support operations on a hobby budget... I'd love to know what the next step up looks like, especially if it's some large esoteric agricultural machine.
They rarely blog about it. Many of them are old school engineers, some are retired from engineering careers.
many synth kits use a teensy or a similar board for their CPU so that the builders don't need to do the SMD soldering but can still use high speed CPUs
Taking a look at this. It looks like it only supports ICMP and UDP? https://forum.pjrc.com/threads/60532-Teensy-4-1-Beta-Test?p=...
That was the low-level access. Below that they talk about porting a LWIP:
> I developed test sketches for NTP, DNS, multicast, web server, web client, httpd with SD or SdFat-beta lib, tfttp server (SD, SdFat-beta, or SPIFFS), ftpd (get/put) with SD lib, and TCP/UDP client/server
You need a TCP implementation. A few posts down shows someone using lwIP.
Woah, Ethernet is nice to see on a Teensy!
What would it take to make CAN work with this? https://en.wikipedia.org/wiki/CAN_bus
It is supported in hardware for multiple protocols: CAN1.0, CAN2.0, and CANFD. I'm pretty sure there are 3 ports that can be used simultaneously and independently. I only use 2 with CAN1.0.
Edit: By hardware support I mean that a CAN transciever connects to two GPIO pins with access to CAN chip hardware. No SPI interface needed.
Do you need a CAN controller and a CAN transceiver or just a transceiver?
A CAN transceiver? A few dollars + an SPI bus at a glance.
https://www.digikey.com/catalog/en/partgroup/can-transceiver...
Do you need a CAN controller and a CAN transceiver or just a transceiver?
I'd likely buy a small CAN chip and just connect over SPI. CAN as a protocol is a complicated mess, so having HW support is important.
Every time I ran across these boards, I always think of "Apollo Guidance Computer"[1] which is used on Apollo spacecrafts.
They have 16KB ram 2000MHz cpu freq so I feel like I can build a spaceship witha couple of teensies :D
[1] https://en.m.wikipedia.org/wiki/Apollo_Guidance_Computer
One note: they had a 2.048 MHz CPU, not a 2000 MHz CPU. 2000 MHz only slightly below modern clock speeds.
No JTAG, not interested. JTAG is essential for being able to properly utilize chips like these. They need to pin it out.
This is fantastic, especially with functional wired ethernet at such a price point. This is a lot of customizable horsepower in a small form factor with great peripheral support!
I've been playing around embedded stuff and hardware design recently and mostly started with arduino's and esp8266/32's, but have wanted to play around with both FPGA's and ARM boards for designing more complex things.
I'm kinda lost on what ARM board to get though. This thing seems pretty cool, and others have recommended an STM32 board, but theres dozens of those in various form factors and chip features and I'm just not sure.
Anyone know a good comparison of ARM based dev boards that gives a good description of the differences and maybe recommended applications?
I recommend the BeagleBone as a better starting point than STM32s. It combines an ARM processor core capable of running linux with microcontrollers so you can run Linux on the CPU and realtime firmware on the MCU cores.
If you want to get into FPGA development, I would recommend a ZYNQ based board [1] which is similar to the BeagleBone except instead of microcontrollers, ZYNQ chips combine an ARM CPU with an FPGA. I'd recommend something like the Analog Discovery 2 [2] for data capture since 90% of FPGA development is test benches and validation.
[1] https://store.digilentinc.com/cora-z7-zynq-7000-single-core-...
[2] https://store.digilentinc.com/analog-discovery-2-100msps-usb...
The thing with microcontrollers in general is that they tend to come in MANY variations to support all the various use cases out there. So, it really comes down to your use case. Once you have that figured out, it's much easier to pick an ARM platform.
Most of the time people are taking about the M-series, so you want an M0, M3 or an M4. I'd recommend an M4 if you don't have something specific in mind.
The STM discovery series is an easy place to start:
https://www.st.com/en/evaluation-tools/stm32-discovery-kits....
I'd also recommend checking PlatformIO: It's a great project that streamlines development and abstracts a lot of the details:
To answer your question directly, here's a good start:
https://developer.arm.com/ip-products/processors
And here:
"The Amazing $1 Microcontroller" is a great place to start. It covers the main ARM micro families. Essentially you're looking for differences in peripherals, since the CPU is the same for any given Cortex M0, M3, etc.
https://jaycarlson.net/microcontrollers/
Edit: I guess if you're looking to move to "more complex" things you may be beyond the $1 chips that this site reviews.
> I guess if you're looking to move to "more complex" things you may be beyond the $1 chips that this site reviews.
That's the end goal yeah, but ofc I need to learn the platforms first.