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.
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...)
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...
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.
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.
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.
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.
No association with the company, just a satisfied user.
Don't such things solve most of these issues?
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.
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)
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.
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.
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.
Implying that embedded systems get updated...
Have you looked into PJON?
Although I'll add that Linux has it's fair share of networking bugs and quirks (less now than before, but still plenty.)
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.
Is the main advantage the pin count?
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.
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?
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.
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.
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?
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.
It was really easy to setup and start pushing code to it
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.
Basically, if you want an Arduino that's roughly a thousand times faster, you want a Teensy 4.
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.
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.
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.
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 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.
I'm genuinely curious.
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.
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.
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.
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.
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.
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.
Paul. Paul is the reason to buy a Teensy.
His dedication and support is inspiring. Phenomenal.
https://www.youtube.com/watch?v=IH-grgRmClY
https://forum.pjrc.com/threads/54995-Zeus-Commander-SPS-16-M...
The idea is to run these 3phase AC motors off DC
Torque control is more complex than just simply running 3ph AC motor off DC.
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.
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."
> 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
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.
https://www.digikey.com/catalog/en/partgroup/can-transceiver...
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
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?
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...
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:
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.
That's the end goal yeah, but ofc I need to learn the platforms first.
