Live data from Hacker News

Teensy 4.1 Development Board

pjrc.com

141–150 of 211 posts

Re: Teensy 4.1 Development Board

#141

Earlier quoted context omitted.

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. [1] https:…

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.

Re: Teensy 4.1 Development Board

#142
post #42

Earlier quoted context omitted.

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…

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…

Just use platform io... it works inside VS Code and lets you use arduino and other frameworks if you want to do so.

Re: Teensy 4.1 Development Board

#144
post #82

PSA: 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…

> 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.

Re: Teensy 4.1 Development Board

#145
post #82

PSA: 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…

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.

Re: Teensy 4.1 Development Board

#146
post #12

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."

Re: Teensy 4.1 Development Board

#147
post #129
post #82

PSA: 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…

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)

Re: Teensy 4.1 Development Board

#148

Earlier quoted context omitted.

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 g…

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 Ra…

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

Re: Teensy 4.1 Development Board

#150

Earlier quoted context omitted.

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.

Post reply on HN