teensy audio library with micropython and esp32

Status
Not open for further replies.

sfm

New member
I am looking for ways to do esp32 - teensy lc priced OTA updates. So far, it seems that esp32 should be capable of many of the audio synthesis capabilities of the teensy but so far I haven't been able to find anything as robust as the teensy audio library. So I am curious what might be involved in running Teensy audio library code on the esp32 and building it into a micropython library.
 
Why not ask the ESP folks? :)
As far I know they are working on audio things and have boards with additional DSP which allows speech recognition and muich more.
I don't think you get much support here to get this Teensy library ported to an other chip.

If I ever write code for the teensy audio lib again, it will have a license that disallows this. The last thing I want is that a china-company uses my hobby-written code for free and earns money with my work. It's my decision. If that means not to contribute code again..ok.
 
..if I were Paul i'd think hard how to get wlan/bluetooth on the next Teensy.. yes, maybe with esp32 as slave ;)
Today, everything has builtin wlan.. in connection with the fastest CPU it would be unbeatable.
 
..if I were Paul i'd think hard how to get wlan/bluetooth on the next Teensy.. yes, maybe with esp32 as slave ;)
Today, everything has builtin wlan.. in connection with the fastest CPU it would be unbeatable.
Given that NXP bought Marvel's Wifi & Bluetooth assets in May 2019, I hope that a future chip from NXP would allow future Teensies to have wifi/bluetooth directly, instead of having to depend on EPS32 chips.
 
I think it will be not that easy to get clean audio together with WiFi.. I built a webradio with ESP. Even after long experiments I can hear some artifacts..due to the pulsating power consumption., and perhaps EMI.
The filtering will be not that easy. On the other hand I'm a total noob when it comes to things like this:)
 
A ESP could do the bootloader-job... it supports secure boot. But then, it wants its own flash. No chance for the old Teensy form factor.
 
Ya, hmmm. I am long time teensy fan and customer. Not interested in taking business away from them. I have plenty of use cases where teensy is what I prefer to use and have bought hundreds of them. The possibility of saving time with OTA updates and customization with pcba is really what I am looking for.
 
Agreed... if it had wireless, with reliable software, it would be a killer. PJRC had to expand and go to china.. lol ok, he could pays dozn's of software-developers to write the needed code. Maybe a small additional chip that is used in wrist-watches?
The next planned teensy is dual-core, like the ESP32. To make such a thing really good, it would need an RTOS... but I think this is the culprit and Paul does not want it(?!?)

i had thought to prepare the core-code for the 1070. even now multithreading would be really useful, and actually it is necessary to rework at least some basic things (reentrancy etc). things like "divers" for serial, spi, or even "print"
 
Given that NXP bought Marvel's Wifi & Bluetooth assets in May 2019, I hope that a future chip from NXP would allow future Teensies to have wifi/bluetooth directly, instead of having to depend on EPS32 chips.

I keep hoping for that too. A couple years ago they were going to make Kinetis chips with Bluetooth. But apparently it went badly and every indication is they scrapped plans put it into more chips.

NXP was also really obsessed with "Thread" networking protocol for a while. I'm not sure if they're still trying to push it. A lot of people ask me to put all sorts of features into Teensy, and I do keep mental and written lists... but so far not even 1 single person outside of NXP has ever requested Thread networking protocol.


..if I were Paul i'd think hard how to get wlan/bluetooth on the next Teensy.. yes, maybe with esp32 as slave ;)

I am actually considering this, but well after RT1170... so most likely early 2022 time frame. I'm hopeful their upcoming RISC-V part will be low cost like the ESP8266, but offer both BT & Wifi.

But honestly, I'm far behind were I wanted to be on RT1170. We're running short-staffed due to the pandemic, which has made substantial dev time really scarce. :(



Agreed... if it had wireless, with reliable software, it would be a killer. PJRC had to expand and go to china.. lol ok, he could pays dozn's of software-developers to write the needed code. Maybe a small additional chip that is used in wrist-watches?

Hahaha - PJRC will suddenly grow from a tiny 4 person (3 with covid19 restrictions) company to a corporate juggernaut practically overnight!



The next planned teensy is dual-core, like the ESP32. To make such a thing really good, it would need an RTOS... but I think this is the culprit and Paul does not want it(?!?)

Indeed I'm not a big fan of segmenting RAM into lots of tiny stacks.


and actually it is necessary to rework at least some basic things (reentrancy etc). things like "divers" for serial, spi, or even "print"

Yup. The non-reentrant code & APIs are a big problem. The Wire library is probably the biggest obstacle. Maybe we should start a new forum thread about Wire lib improvements?
 
Yeah, speed up the MCU, add a resource-eating OS and make yet another new Pi.

The USP of Teensy is it's bare metal simplicity at maximum usable power. Once an OS is in, there are others already well ahead. It would be like turning around to chase the ones who went the other direction years ago. BUT WHY?
 
Yeah, speed up the MCU, add a resource-eating OS and make yet another new Pi.

The USP of Teensy is it's bare metal simplicity at maximum usable power. Once an OS is in, there are others already well ahead. It would be like turning around to chase the ones who went the other direction years ago. BUT WHY?

Because, at the end, it's EASIER to use. Your PC can do multitheading, too. Ever thought about the "why"? :)
Up to Teensy 3.6 I said the same. We don't need multithreading there.
But the T4 speed changes everything... it spends the most of the time either waiting or running through "loop()" senseless fast. But while it waits, it can do other, more useful things.
Yes, yield() is intended for this, but is very unflexible.
But you're right - perhaps it makes sense to add a switch that enables/disables multithreading(?)

@Paul: I'd begin even more basic.. with a useful stacktrace when something crashes. First, for the hardfaults, then, maybe we can try to remove -fnoexceptions?
This will make debugging much easier. The next could be wire, and adding a mechanism for timeouts/watchdogs and semaphores.. later mailboxes.. all things that we will need sooner or later. we can test these with wire :)

@Deleted User: wouldn't it be useful if the slow I2C could run "in the background", for several devices, without thinking too much about it? And at the same time doing fast USB and SPI in parallel? We will have a 2nd core for this...
If you use Audio or USB you already use multithreading. Its just called different. Interrupt. For Audio: Software-Interrupt.
 
Last edited:
If you don't like RTOS - what do you think about about a software-interrupt driven system? Depends on how many software-ints we have on the 1170... if we had one for each priority, that would be enough.
lowest prio could be a yield(), arduino-loop (which wouldn't be a loop anymore) could run on the next higher priority, above this, all other things. prio-switch is done in hardware, by the cpu.
It would all use the same stack, automatically.
edit: this needs a smart scheduler :)
 
Last edited:
If you don't like RTOS - what do you think about about a software-interrupt driven system? Depends on how many software-ints we have on the 1170... if we had one for each priority, that would be enough.
lowest prio could be a yield(), arduino-loop (which wouldn't be a loop anymore) could run on the next higher priority, above this, all other things. prio-switch is done in hardware, by the cpu.
It would all use the same stack, automatically.

RTOS integrated into Arduino ESP 32 and 8266 (with one or two cores) for the radio stack. Also the NRF52840 in AdaF units - ( 64 MHz M4 ) - builds with RTOS to allow the radio to run. So it generally works - probably not perfect or seamless - but has been in use and evolved for some time and must be generally functional. FrankB has probably worked with it more on ESPs? - it adds some overhead and oddities no doubt.
 
Yes, it works good. Had no problems. On ESP, there are core- internal timouts and watchdogs - if something takes too long, you, the guy who writes the code, will be informed about it.
Stracktraces are useful, and LOG(), overall in the core. The stacks do not hurt, as there are mechanism to measure and optimize the stacksizes. It still feels "fast" - even it has only 240MHz on a slow(er) CPU.. because there is less busy waiting. instead, it switches to another thread and uses the time more intelligent than we do now.
Edit: I did not notice much overhead.

ESP even uses malloc() extensively. And let me tell you what.. it does not hurt. If you have enough RAM (like on T4) it works wonderful. Don't forget that it gets freed(), too :)

It's time for a paradigm shift.
Like when we moved form AVR to ARM. Suddenly, we had way more FLASH and RAM and had to learn to use it.
At the beginning, all people still tried to save flash-space. They had to learn, that things work better if they don't spend time for these needless things. You got nothing for less flash-usage.
Now, we experience a similar situation. For speed (and malloc() )


I strongly recommend to use RTOS.
 
Last edited:
I2C could run in the background already, if programmed so. One can attach every function onto an interrupt, so it runs "in the background", which could anyway only really happen, if there is a CPU for every background task. If not, it always just holds the execution on one layer to go on with another. I see yield() as one of the best things for MCU, because I can then decide exactly WHEN and WHERE this happens and do not need to take care of timing, process priority levels, etc.
Sorts of a semaphore exchange, by means of objects or memory arrays, serves well.
But that should be it.
It does not make sense to have then the loop() rund to eternity while polling for semaphores... just an other way to do the same as it is done already, just more complicated and resource-consuming.
 
Status
Not open for further replies.
Back
Top