Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Teensy 4.1 Development Board

pjrc.com

Post reply on HN
Print view View original

181–190 of 211 posts

Re: Teensy 4.1 Development Board

#181

Post by funkaster »

fermienrico wrote: post #104
funkaster wrote: post #55

Earlier quoted context omitted.

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

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

Re: Teensy 4.1 Development Board

#182

Post by funkaster »

fermienrico wrote: post #104
funkaster wrote: post #55

Earlier quoted context omitted.

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

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.

Re: Teensy 4.1 Development Board

#183

Post by yjftsjthsd-h »

HeyLaughingBoy wrote: post #123
yjftsjthsd-h wrote: post #58

Earlier quoted context omitted.

> 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 obvious first pick.

Re: Teensy 4.1 Development Board

#184

Post by nine_k »

ohazi wrote: post #178
freefriedrice wrote: post #173

Earlier quoted context omitted.

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

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…

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.

Re: Teensy 4.1 Development Board

#185

Post by nikofeyn »

numpad0 wrote: post #168
nikofeyn wrote: post #138

Earlier quoted context omitted.

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.

Re: Teensy 4.1 Development Board

#186

Post by ohazi »

nine_k wrote: post #184
ohazi wrote: post #178

Earlier quoted context omitted.

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…

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

Re: Teensy 4.1 Development Board

#188

Post by LeifCarrotson »

ohazi wrote: post #160
freefriedrice wrote: post #155

Earlier quoted context omitted.

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

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…

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.

Re: Teensy 4.1 Development Board

#189

Post by ohazi »

LeifCarrotson wrote: post #188
ohazi wrote: post #160

Earlier quoted context omitted.

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…

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

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

Re: Teensy 4.1 Development Board

#190

Post by numpad0 »

nikofeyn wrote: post #185
numpad0 wrote: post #168

Earlier quoted context omitted.

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.

Post reply on HN