Cheap ARM MCUs for RBCD audio

[abraxalito]

Now there is code up on github for using the RP2040 PIO to implement I2S : https://github.com/malacalypse/rp2040_i2s_example

Code for being an I2S transmit master looks remarkably simple (just 8 PIO instructions) so I'm wondering if one RP2040 could potentially drive up to 8 DAC chips with individual data. If only the CPUs were M4s rather than M0+s....

Mouser does have stock of RP2040 at $1.25 a pop : https://www.mouser.com/ProductDetai...neUTtPr757IDD/widVOCAPWCBi/%2BZSnDs3lyHcnhg==

 

[MarcelvdG]

Interesting, I never realized you could do a useful amount of digital signal processing with dirt cheap microcontrollers.

For your information, last year Hans Polak and I tried to analyse a scheme with two differently dithered DACs of which the outputs got subtracted. It was a side discussion in this huge thread, https://www.diyaudio.com/community/...makes-nos-sound-different.371931/post-6769819

 

[rfbrw]

Interesting, I never realized you could do a useful amount of digital signal processing with dirt cheap microcontrollers.

Not with the M0+ family to which the RP2040 belongs. I don't think it has any built-in DSP capability worthy of the name but there is always assembler.

 

[abraxalito]

M0 doesn't have the DSP optimizations that M4 has but still fairly useful for doing DSP - there's a single clock cycle 32*32 multiply in most M0 implementations I've seen though no MAC.

 

[abraxalito]

I have a PCB layout coming along (well my wife's doing the layout) that's going to sport an RPi Pico module to interface between an I2S input and an array of 4 comms DACs. The idea is to experiment with oversampling filters and kick off DSP development with the Pico. I figure its PIO peripheral should be up to the job of driving 4 channels of SPI-like interfaces up to at least 16X OS. OS is needed because comms DACs generally top-out at 14bits - they're low enough glitch and settling time though that the oversampling factor shouldn't become a limit on performance.

 

[abraxalito]

Another useful resource for running filtering algorithms on Cortex-M series MCUs : https://www.notblackmagic.com/bitsnpieces/digital-filters/. There're some handy benchmarks too, about halfway down the page.

 

[jpk73]

Teensy by PJRC has a lot of audio code for cortex M4 using i2s interface. I don't know if that is interesting for you...

 

[abraxalito]

Teensy is quite popular but the hardware isn't open as far as I'm aware. I prefer unrestricted designs wherever possible but could be their software is so useful the restrictions fade into the background. I'll take a look, thanks.

 

[jpk73]

There is a boot image which is closed source but apart from that all code is open as far as I remember...

 

[miro1360]

monoDAC prototype

Here is the first realization of an idea I've had brewing in my mind for some time - a mono DAC - i.e. just a single channel on a board. Which channel is decoded from the stereo pair is selectable with a switch as I2S sends both channels to each board. The other interesting aspect here is that its using an ARM MCU to fiddle the channels around on I2S. The filter isn't a separate board as on 'Deca DAC' rather its built-in as the intention is to have filters from now on in software rather than hardware. I've implemented a 5th order Chebyshev and eventually I'll get the MCU to do 2X OS but for now its running NOS.

The MCU daughter board on the monoDAC is a 'Blackpill' which is a cheap and cheerful Cortex M4 board using an STM32F401 (or optionally, an F411). The F401 runs at 84MHz and has a couple of full duplex I2S ports. Blackpills are available (hopefully, with the current supply squeeze on MCUs) on Aliexpress and eBay.

$3 STM32 "Black Pill" Board Features STM32F4 Cortex-M4 MCU, Optional SPI Flash - CNX Software

What's nice about the STM32F401 is its one of the lowest power M4s on the market, sipping about 140uA/MHz.

Do you have a working code for USB-I2S example which can be imported into STM32CubeIDE? (for the STM32F401 black pill)

 

[abraxalito]

Hi miro - no, I've not delved into USB at all in relation to ARM MCUs. Are you getting into the black pill board now?

 

[miro1360]

I opened it up already, it would be nice to have a working example for the black pill - really the cheapest solution. I have a few examples but only pure code - nothing in the graphic configurator for the STM (.ioc).
I also tried with PIC32 (PIC32MX270F256D) and it's harmony configurator - not worked at all (also find on the web that is does not work and everyone goes directly with code).

This is nice working atmel example: http://pavouk.org/hw/audiosystem20/en_at32uc3a3256usbi2s.html

 

[abraxalito]

I have given up with STM32Cube now as after it upgraded itself it told me it wouldn't work on my old Win7 OS. I suppose that counts as suicide for a software package - why wouldn't it check if my OS was compatible before upgrading?

The CPU for the F401 is very nice but the I2S peripherals aren't. I'm looking forward to writing some PIO code on the RP2040 now.

 

[miro1360]

You are correct, I am going to give up the STM32 and look on the RP2040. Already ordered it and I will see

 

[abraxalito]

The big advantage of the RP2040 at present is availability. Not a bad price either even though you need the external Flash.

The downside is getting I2S input needs the logic I put in post #1 of this thread. Assuming you don't use the PIO that is, I'm sure its achievable with that. But I wanna use PIO for I2S outputs.

 

[bohrok2610]

Do you have a working code for USB-I2S example which can be imported into STM32CubeIDE? (for the STM32F401 black pill)

I have developed a full-duplex USB-I2S UAC2 bridge using STM32F723. I used CubeMX just for initial configuration as the SW generated from CubeMX is just a rather useless skeleton for UAC1. I don't think ST will offer anything more complete in CubeMX for I2S/SAI anytime soon as these are general purpose MCUs.

 

[abraxalito]

The big advantage of the RP2040 at present is availability.

I fired up my STlink (which had been re-programmed to act as a Segger J-link) to talk to my RPi Pico but found it won't work. The reason being - RP2040 requires multi-drop SWD (being as its dual-core) which isn't supported by my v9 J-link. Needed to order a v11 J-link which I'll try with soon.

J-link v11 looks quite a big step-up hardware wise over v9, there's an LPC43XX in a large package on the PCB. Which presumably means high-speed USB not just full-speed as on the older one.

Another useful application for RPi Pico showed up in my inbox today - a logic analyzer : https://www.cnx-software.com/2022/07/12/using-raspberry-pi-pico-as-a-logic-analyzer/

 

[mkc]

Hi Abraxalito,

I'm not sure I fully understand. You say your STLink has had its firmware replaced to act as an Segger J-Link. I assume this means your STLink is from an Nucleo board and you have used Seggers update software for this? As far as I know this will only works as debugger for STM chips. Segger has limited this on purpose.

Although I haven't tried in using my J-Link I would assume that most J-Link debuggers will be able to work on RP2040 as dual-core should only be a matter of software.

Even a RPI Pico can be used an SWD debugger. It's a nice little board for various small projects.

Mogens

 

[abraxalito]

Hi Mogens,

I omitted to mention the message that the reprogrammed STlink gave me. It didn't say anything like 'Not an STM core'. I did a search on the error message it gave me and found that the inability to work with RP2040 was due to lack of multidrop support. Here's the post I turned up : https://forum.segger.com/index.php/...nected-JLink-does-not-support-SWD-multi-drop/

I suggest you try your J-link and get back about how you get on. Even if it is only a matter of software (which seems quite likely), I'm reliant on Segger and if they choose not to upgrade the firmware on v9 to support multi-drop then I need to go with the hardware that does support that.

 

[mkc]

Hi Abraxalito,

The post you link to seems to indicate that there is an limitation in some of the debuggers. Surprises me a bit. As said I have not yet tried to use the J-Link on the RP2040.

I will try as time permit. I have a few J-Link debuggers including the EDU model. So I should be able to try it out.

Mogens