Personally I would not worry a bit about integral resampling. Heck my plan is to re-sample it on RPi and use only one clock.
I agree, adhere to keep-it-simple principles.
To those worried about resampling: The whole point of using a DSP is because we want to change something about the signal, right? So there will not be bit-accuracy anyway, so an extra resampler (which is just a FIR filter) will not ruin anything.
People,
I have done a fair bit of work with the ADAU1442, and the earlier AD1940, and the output of Sigma Studio.
You are able to reprogram all the filter parameters and delay parameters in the ADAU over SPI in real time. The broad process is:
- Use SigmaStudio to compile the code for your DSP.
- Ask it to generate the programming files.
- You get header files with the memory locations for EVERY register in the design.
- These will be:
- All the biquad values (nicely labelled as such)
- All the delay values - nicely ;abellled as sich
- etc
- You will also get the object file that you can put in the EEPROM.
When you see a frequency change event:
- You don't need to reboot the whole thing
- You just need to recalculate the biquad values and write these to the ADAU memory, and change the delay values to get the right distance delay.
- To do this:
- There are a couple of simple commands for SAFELOAD of parameters for the ADAU
- It stops the DSP, loads the parameters as a group, and restarts the DSP.
It is not actually that hard once you have untangled the output of Sigma Studio.
Additionally, it lets you do realtime control of ALL your DSP parameters:
- Corner Frequencies of crossover points
- Slopes of the crossover points
- Parametric EQ changes in realtime
- Programmable delay for each channel from zero to max...
- There is nothing in the SigmaStudio design that I have seen, that you can't reprogram. You have pretty good control of the DSP.
The code required for this is actually not that bad - a few pages of C code for pretty much everything I did - though I did not program massive DSP "IP Blocks".
You do need to convert your values to 5.23 fixed point for ADAU1442, not sure what format the ADAU1452 uses, though this will be in the datasheet.
With a little effort, you can get yourself a very (very) versatile DSP out of this.
Going back a whiles I posted all the design stuff here: http://www.diyaudio.com/forums/blogs/googlyone/932-upload-design-documentation-adau1442.html
The code for this is in many areas legacy, and not pretty, but it is very stable and will show you what you might want to o if you do this in a micro controller.
I have done a fair bit of work with the ADAU1442, and the earlier AD1940, and the output of Sigma Studio.
You are able to reprogram all the filter parameters and delay parameters in the ADAU over SPI in real time. The broad process is:
- Use SigmaStudio to compile the code for your DSP.
- Ask it to generate the programming files.
- You get header files with the memory locations for EVERY register in the design.
- These will be:
- All the biquad values (nicely labelled as such)
- All the delay values - nicely ;abellled as sich
- etc
- You will also get the object file that you can put in the EEPROM.
When you see a frequency change event:
- You don't need to reboot the whole thing
- You just need to recalculate the biquad values and write these to the ADAU memory, and change the delay values to get the right distance delay.
- To do this:
- There are a couple of simple commands for SAFELOAD of parameters for the ADAU
- It stops the DSP, loads the parameters as a group, and restarts the DSP.
It is not actually that hard once you have untangled the output of Sigma Studio.
Additionally, it lets you do realtime control of ALL your DSP parameters:
- Corner Frequencies of crossover points
- Slopes of the crossover points
- Parametric EQ changes in realtime
- Programmable delay for each channel from zero to max...
- There is nothing in the SigmaStudio design that I have seen, that you can't reprogram. You have pretty good control of the DSP.
The code required for this is actually not that bad - a few pages of C code for pretty much everything I did - though I did not program massive DSP "IP Blocks".
You do need to convert your values to 5.23 fixed point for ADAU1442, not sure what format the ADAU1452 uses, though this will be in the datasheet.
With a little effort, you can get yourself a very (very) versatile DSP out of this.
Going back a whiles I posted all the design stuff here: http://www.diyaudio.com/forums/blogs/googlyone/932-upload-design-documentation-adau1442.html
The code for this is in many areas legacy, and not pretty, but it is very stable and will show you what you might want to o if you do this in a micro controller.
Last edited:
The way I did it was to write it in C on a PIC micro.
You could equally write it on your R PI. In either case, Singma Studio generates all the header files, so you are provided the addresses of every register that you need to access on the ADAU device.
The header files initially look intimidating - here is a snippet from one:
/* Module B1_HPF0 - General (2nd order)*/
#define MOD_B1_HPF0_COUNT 9
#define MOD_B1_HPF0_DEVICE "IC1"
#define MOD_B1_HPF0_ALG0_STAGE0_B2_ADDR 48
#define MOD_B1_HPF0_ALG0_STAGE0_B2_FIXPT 0x007ED89C
#define MOD_B1_HPF0_ALG0_STAGE0_B2_VALUE SIGMASTUDIOTYPE_FIXPOINT_CONVERT(0.990985504551523)
#define MOD_B1_HPF0_ALG0_STAGE0_B2_TYPE SIGMASTUDIOTYPE_FIXPOINT
#define MOD_B1_HPF0_ALG0_STAGE0_B1_ADDR 49
#define MOD_B1_HPF0_ALG0_STAGE0_B1_FIXPT 0xFF024EC7
#define MOD_B1_HPF0_ALG0_STAGE0_B1_VALUE SIGMASTUDIOTYPE_FIXPOINT_CONVERT(-1.98197100910305)
#define MOD_B1_HPF0_ALG0_STAGE0_B1_TYPE SIGMASTUDIOTYPE_FIXPOINT
#define MOD_B1_HPF0_ALG0_STAGE0_B0_ADDR 50
#define MOD_B1_HPF0_ALG0_STAGE0_B0_FIXPT 0x007ED89C
#define MOD_B1_HPF0_ALG0_STAGE0_B0_VALUE SIGMASTUDIOTYPE_FIXPOINT_CONVERT(0.990985504551523)
#define MOD_B1_HPF0_ALG0_STAGE0_B0_TYPE SIGMASTUDIOTYPE_FIXPOINT
If you are familiar with biquad filters, you will recognise the parameters B2, B1 and B0. The file continues with A2, A1 etc...
it goes on for a lot of lines... but it correlates to each element in your sigma studio design.
So you have all the DSP elements, and the address in the ADAU memory space. Happy days.
I am not sure what your favourite programming language is, but all it needs to be able to do is write to the SPI bus connected to the ADAU.
You could equally write it on your R PI. In either case, Singma Studio generates all the header files, so you are provided the addresses of every register that you need to access on the ADAU device.
The header files initially look intimidating - here is a snippet from one:
/* Module B1_HPF0 - General (2nd order)*/
#define MOD_B1_HPF0_COUNT 9
#define MOD_B1_HPF0_DEVICE "IC1"
#define MOD_B1_HPF0_ALG0_STAGE0_B2_ADDR 48
#define MOD_B1_HPF0_ALG0_STAGE0_B2_FIXPT 0x007ED89C
#define MOD_B1_HPF0_ALG0_STAGE0_B2_VALUE SIGMASTUDIOTYPE_FIXPOINT_CONVERT(0.990985504551523)
#define MOD_B1_HPF0_ALG0_STAGE0_B2_TYPE SIGMASTUDIOTYPE_FIXPOINT
#define MOD_B1_HPF0_ALG0_STAGE0_B1_ADDR 49
#define MOD_B1_HPF0_ALG0_STAGE0_B1_FIXPT 0xFF024EC7
#define MOD_B1_HPF0_ALG0_STAGE0_B1_VALUE SIGMASTUDIOTYPE_FIXPOINT_CONVERT(-1.98197100910305)
#define MOD_B1_HPF0_ALG0_STAGE0_B1_TYPE SIGMASTUDIOTYPE_FIXPOINT
#define MOD_B1_HPF0_ALG0_STAGE0_B0_ADDR 50
#define MOD_B1_HPF0_ALG0_STAGE0_B0_FIXPT 0x007ED89C
#define MOD_B1_HPF0_ALG0_STAGE0_B0_VALUE SIGMASTUDIOTYPE_FIXPOINT_CONVERT(0.990985504551523)
#define MOD_B1_HPF0_ALG0_STAGE0_B0_TYPE SIGMASTUDIOTYPE_FIXPOINT
If you are familiar with biquad filters, you will recognise the parameters B2, B1 and B0. The file continues with A2, A1 etc...
it goes on for a lot of lines... but it correlates to each element in your sigma studio design.
So you have all the DSP elements, and the address in the ADAU memory space. Happy days.
I am not sure what your favourite programming language is, but all it needs to be able to do is write to the SPI bus connected to the ADAU.
Oh, by the way, the file includes the filter / parameter values that you had programmed in signa studio. In both fixed point and decimal value. A nice thing of them to do, as it lets you check out your fixed point to float / vice versa conversion. The first thing I did with my code was try programming exactly the original filter values into the DSP, and checked that my code came up with the same values that Sigma Studio generated.
It took a couple of rounds of debugging the first time
If I recall the code I put in my blog goes WAY back to PIC18F days, and I had to do some really UGLY coding shortcuts in calculating the biquad values.
It took a couple of rounds of debugging the first time
If I recall the code I put in my blog goes WAY back to PIC18F days, and I had to do some really UGLY coding shortcuts in calculating the biquad values.
wow, lot of good info. thank you
You mention using SPI, would you consider I2C too slow for updating the DSP configuration?
I2C should work fine. The basic principle of operation is that you write the data to nearly independent safeload registers. After writing to these registers you set a safeload flag in the core control register. As this bit is set and the dsp has enough unused clock cycles at the end of the program (this is very important!) it copies the safeload registers, one per clock tick, to the corresponding parameter RAM address. The destination address must be specified once per safeload data register in seperate registers (for better description consider the datasheet).
So as you may see, you have all the time you need to write the data and the dsp core does the rest for you.
Yes, the plan is to self-boot DSP from eeprom, and use RPI as "dumb source".
I2c and reset will be connected so anyone with enough time and skill can boot DSP from RPI.
Personally I would not worry a bit about integral resampling. Heck my plan is to re-sample it on RPi and use only one clock
There is quite some board estate in clock area on the new(eurocard format) board. So my proposal is that I would include option to populate 2nd crystal + switching circuitry + provide switch signal(logic 0=osc0, logic 1=osc1 ) from one of RPi GPIOs and I will route the signal also to one of DSP GPIos.
This should not require too much design effort and board estate. Si53360 is actually quite cheap, there is no reason to change it. I can connect two oscillators to one input of Si53360 and switch signal would just enable one whichever you want to use. Or you can reconfigure it via a jumper and switch signal changes between oscillator 1 and external input. Would this work for you? what do you think?
Pitrsek
As I previously wrote, Hifiberry already done a driver which is accessible by GIT to set Raspberry as I2S slave on their new DAC+ PRO (only the PRO version).
The PRO version has its own crystal clocked at 44 khz and the signal comes from the DAC. I think it could be a good way to study.
Yep, I've looked at this driver. Unfortunately for us, it seems the driver identifies the DAC from the EEPROM on the DAC board (according to RPi's HAT spec.), and chooses operating mode depending on if it's a pro version or not. This means that we can't easily make the DSP board HifiBerry DAC compatible. But we can use it as a basis for our own driver. I will try to dig into this deeper this weekend, see if I can wrap my head around how the audio drivers are structured in the Linux kernel. If anyone can shed some light on this matter or point me to some documentation I'd be very thankful indeed.
Pitrsek, about voltage range, standard input range is enough for me. But if it can be extended with ease that's always a nice bonus.
And I also agree I2C should be fast enough to reprogram the DSP. It wont happen that often, and I sure could tolerate some 50ms silence when it does.
Pitrsek, about voltage range, standard input range is enough for me. But if it can be extended with ease that's always a nice bonus.
And I also agree I2C should be fast enough to reprogram the DSP. It wont happen that often, and I sure could tolerate some 50ms silence when it does.
If you want to try the microcontroller route out, you could use the Arduino framework and a Atmega32u4 or Arduino pro micro board. There is so much support for the Arduino framework, it'd make it easy to do the software, and the hardware is also open source if you want to integrate it into your board.
https://github.com/NicoHood/HID <- HID usb class to transfer data requires no drivers. max 64bytes/millisecond = 64kB/s if that's ok
otherwise use the standard USB CDC (virtual com port class) to transfer data
https://www.sparkfun.com/products/12640 (buy a clone off ebay for cheaper)
The STM32 series is cheaper of course (if you're buying the raw components), but probably would be faster to develop using the Arduino platform.
You can also buy dedicated USB->I2C chips surprisingly:
MCP2221 - USB Bridge (5v, 4 gpio)
HID USB to SMBus Bridge | Silicon Labs (3.3v, 7 gpio, qfn package only)
some FTDI chips support i2c as well
https://github.com/NicoHood/HID <- HID usb class to transfer data requires no drivers. max 64bytes/millisecond = 64kB/s if that's ok
otherwise use the standard USB CDC (virtual com port class) to transfer data
https://www.sparkfun.com/products/12640 (buy a clone off ebay for cheaper)
The STM32 series is cheaper of course (if you're buying the raw components), but probably would be faster to develop using the Arduino platform.
You can also buy dedicated USB->I2C chips surprisingly:
MCP2221 - USB Bridge (5v, 4 gpio)
HID USB to SMBus Bridge | Silicon Labs (3.3v, 7 gpio, qfn package only)
some FTDI chips support i2c as well
The learning curve for STM32 is not short and opensource ide (like eclise) are not well designed for STM32.
Definitely, it is faster with arduino... But performances are lower (STM32F7 looks like a good plateform compared to arduino)
I prefer to use this one
https://www.pjrc.com/teensy/teensy31.html
Since I have a whole bunch of them lying around. Don't know how it compares price-wise, but it's pretty powerful and it's arduino compatible.
https://www.pjrc.com/teensy/teensy31.html
Since I have a whole bunch of them lying around. Don't know how it compares price-wise, but it's pretty powerful and it's arduino compatible.
It's done. Did you know that they make 50uA zeners?
I'm slowly working on the power supply - L6986 + LTC2950-1.
I have yet to sort out the self booting bug - I have equipment in my job and did not have time yet
(.STM32F446
NUCLEO-F446RE STM32 Nucleo-64 development board with STM32F446RET6 MCU, supports Arduino and ST morpho connectivity - STMicroelectronics
ST with other ARM producers have their own "easy" ARM framework
https://www.mbed.com/en/
And if audio is routed via the ARM STM32F4 chip, quite powerful FIR filters can be realised.
Then maybe KEIL or STs eclipse framework can be used.
http://www.dspconcepts.com/sites/default/files/white-papers/STM32Journal_DSPC.pdf
NUCLEO-F446RE STM32 Nucleo-64 development board with STM32F446RET6 MCU, supports Arduino and ST morpho connectivity - STMicroelectronics
ST with other ARM producers have their own "easy" ARM framework
https://www.mbed.com/en/
And if audio is routed via the ARM STM32F4 chip, quite powerful FIR filters can be realised.
Then maybe KEIL or STs eclipse framework can be used.
http://www.dspconcepts.com/sites/default/files/white-papers/STM32Journal_DSPC.pdf
I have a few spare boards of the first version of PiDSP. So if you feel like sorting out the linux/rpi side of things, let me know (Mjjg?).
If there is a Linux guru lurking with no soldering skills, I will solder it for you
Thanks, that could help perhaps. But I need a solid plan for how to proceed with the driver issues. I need to work a bit more on understanding the current driver stack, otherwise you'd just be wasting a board. Documentation is really scarce on this subject, so far. So let me get back to you on that offer in a while.
Most of theses tools are not opensource....
I already made applications on STM32.
What I can say is one of the well known opensource IDE is Eclipse. If it is pretty easy to build a STM32 app with eclipse, it is not so easy to make it 100% sharable with communauty....
For example, it is no so easy to use the STM32 cube framework under linux.
source code architecture must be portable
etc...
Last edited: