Teensy 4.1 Development Board
pjrc.com
pjrc.com
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.
Don't such things solve most of these issues?
https://access.redhat.com/documentation/en-us/red_hat_enterp...
https://www.ni.com/en-us/innovations/white-papers/13/introdu...
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.
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 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.
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?
- 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
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.
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.
Implying that embedded systems get updated...
Have you looked into PJON?
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.
It mostly comes down to reading the documentation for the specific microcontroller that you're using.
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.
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
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.
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.
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.
No association with the company, just a satisfied user.
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...
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.
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.
This is where stuff like ESP8266, and the controller from the post, makes sense.
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
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.
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).
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?
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.
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.
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 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).
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.
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...
It would be nice if there was a Teensy board with analog audio output, though.
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.
[1] https://www.nxp.com/products/audio/audio-converters/ultra-lo...
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.
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?
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).
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.
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. ;-)
http://papilio.cc/index.php?n=Papilio.PapilioDUOHardwareGuid...
edit: yep...still for sale http://store.gadgetfactory.net/fpga/
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.
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 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?
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.
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.
Basically, if you want an Arduino that's roughly a thousand times faster, you want a Teensy 4.
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.
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
The Black Pill STM32 for $4 are an ever better value!
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.
Also, 100 mA current draw with the CPU at full speed. For some use cases, that is helpful...versus the RPi.
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.
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.
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.
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...
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.
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.
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.
What is out there now in open designs I have no idea as 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!
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
https://www.digikey.com/catalog/en/partgroup/can-transceiver...
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.
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?
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.
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: