Hi Neil, Many thanks for yours, and others interest in my endeavours...
I am slowly making progress with this.. I shall take a bit of time out to digest
the information and advice that has been offered me..
I shall try out your advice to 'not leave the tank half empty' and see how far I get with that..
Regards,
Paul.
I am slowly making progress with this.. I shall take a bit of time out to digest
the information and advice that has been offered me..
I shall try out your advice to 'not leave the tank half empty' and see how far I get with that..
Regards,
Paul.
Good.
Safeload procedure requires additional things that you are not doing with your program.
Basically, you need to initialize safeload registers, then write data to the safeload registers, and after that - initiate data transfer from that safeload reg to the real register.
See example here:
https://github.com/freeDSP/TUTORIAL-I2C/blob/master/Arduino_Sketches/safeload/safeload.ino
(lines 285 - 351)
Safeload procedure requires additional things that you are not doing with your program.
Basically, you need to initialize safeload registers, then write data to the safeload registers, and after that - initiate data transfer from that safeload reg to the real register.
See example here:
https://github.com/freeDSP/TUTORIAL-I2C/blob/master/Arduino_Sketches/safeload/safeload.ino
(lines 285 - 351)
Hi there eclipsevi....
I'll go through that tutorial and hopefully gain some more knowledge on the subject.....
Many thanks,
Paul.
I'll go through that tutorial and hopefully gain some more knowledge on the subject.....
Many thanks,
Paul.
To All, Many thanks for your advice and assistance.. It has helped me realise that my PIC based approach isn't going to work.
I am awaiting the arrival of an Arduino Mega R3 plus memory expansion. I'll see if I can remember any of my old C++ skills, last used 25 years ago..
I'm sure that given what I am trying to achieve (source to destination digital audio).
I'll be knocking on your doors again.
I am awaiting the arrival of an Arduino Mega R3 plus memory expansion. I'll see if I can remember any of my old C++ skills, last used 25 years ago..
I'm sure that given what I am trying to achieve (source to destination digital audio).
I'll be knocking on your doors again.
Could be much easier if you switch to C. There are many example projects online of I2C that you can take as starting point. It would not be much different from Arduino.
https://github.com/microchip-pic-av...aster/pic16f15245-i2c-master-ph-temp.X/main.c
I had thought about continuing with a more powerful PIC chip, but I am generally based
in a country where it is far easier to get Arduino than other products. So if, the Arduino works out, I can use it as a ready made building block for my DSP based stereo system. The Arduino can be generally bought for around £20. Which is about what I would expect to pay to have PCB's made and the purchase costs of the components to build them up.
Thanks,
Paul Freed.
in a country where it is far easier to get Arduino than other products. So if, the Arduino works out, I can use it as a ready made building block for my DSP based stereo system. The Arduino can be generally bought for around £20. Which is about what I would expect to pay to have PCB's made and the purchase costs of the components to build them up.
Thanks,
Paul Freed.
The Mega R3 is a good controller, but if you intend to do a lot of real-time calculations or interface to a display, you will need a more powerful CPU. I've been using the XIAO 14-pin ESP32C3, which has a much higher clock speed (160MHz), an efficient 32-bit architecture, and it is very well supported by the Arduino IDE. You can buy them directly from SEEEDstudio for $5, and they are also available from Digikey or through Amazon. It's pin compatible with the Adafruit QT-Py board, so they are easy to get and there is a viable second source. The bonus is getting a Bluetooth and Wi-Fi radio on-board, with a software stack available through the Arduino IDE.
The Wi-Fi in the ESP32C3 is liberating, in that you can implement the user interface in a networked device. I've been using the Arduino Cloud tools, which allow controlling the CPU from a cell phone (IOS or Android) as well as from the PC. Being able to make your project a "Thing" on the Internet is pretty cool.
The Wi-Fi in the ESP32C3 is liberating, in that you can implement the user interface in a networked device. I've been using the Arduino Cloud tools, which allow controlling the CPU from a cell phone (IOS or Android) as well as from the PC. Being able to make your project a "Thing" on the Internet is pretty cool.
Hi Neil, Many thanks for all these wonderful words of wisdom....
The point that I am at is this. I have just abandoned my tried and trusted methodology of controlling DAC chips, SPDIF switches and physical I/O via small PIC chips (16f628). This formula has worked well for me over the years, but has always been limited by a lack of any form of tone controls.
So I have abandoned all that I am familiar with and have assembled enough hardware to begin to develop a new interface, which I had hoped I could have managed from my standard control setup. I have managed to get a 16LF1936 to talk to an ADAU1401 over i2c... But I have stalled at this point with the realisation that I don't know how to generate the values required to control filters and tone controls 'on the fly' over i2c using assembler.
The point that I am at is this. I have just abandoned my tried and trusted methodology of controlling DAC chips, SPDIF switches and physical I/O via small PIC chips (16f628). This formula has worked well for me over the years, but has always been limited by a lack of any form of tone controls.
So I have abandoned all that I am familiar with and have assembled enough hardware to begin to develop a new interface, which I had hoped I could have managed from my standard control setup. I have managed to get a 16LF1936 to talk to an ADAU1401 over i2c... But I have stalled at this point with the realisation that I don't know how to generate the values required to control filters and tone controls 'on the fly' over i2c using assembler.
Attachments
Generating the values for different types of IIR filters at specific frequencies and bandwidths requires using the bilinear transform (BLT). There is a link that discusses the BLT equations here: https://www.w3.org/TR/audio-eq-cookbook/. I used those equations to generate the Bilinear.cpp library files in the attachment. The ADAU1701_DSP.cpp library file uses those Bilinear routines to create filters and crossovers for specific types that are enumerated in the Shared_enums.h file. This library file also has the routine to convert the floating-point data into the numeric format used by the ADAU1701. The ADAU1701_I2C.cpp code, which I posted previously, has the logic to load the calculated biquad filter coefficients using the safeload registers.
You can put the attached folder in your Arduino library folder and then include them in your code. What's missing is how to figure out the Parameter RAM address for each of those biquads. There is a short explanation of how that is done in this article: http://www.audiodevelopers.com/4-adau1701-and-sigmastudio/. I use some additional code written with Visual Studio to process the SigmaStudio compiler output, but for simple ADAU1701 programs you can determine the biquad Parameter RAM addresses manually and type them into your code.
Yep, this is hard to do in assembly language 🙂.
You can put the attached folder in your Arduino library folder and then include them in your code. What's missing is how to figure out the Parameter RAM address for each of those biquads. There is a short explanation of how that is done in this article: http://www.audiodevelopers.com/4-adau1701-and-sigmastudio/. I use some additional code written with Visual Studio to process the SigmaStudio compiler output, but for simple ADAU1701 programs you can determine the biquad Parameter RAM addresses manually and type them into your code.
Yep, this is hard to do in assembly language 🙂.
Hi Neil, My Arduino has just arrived. It will take me a little time to get my head around the new setup. Many thanks for your time and the invaluable information that you have been drip-feeding me.. 'Baby steps' from here on in.
Regards,
Paul.
Regards,
Paul.
Hi Neil, I extracted your ADAU1701 program and dropped it into the ARDUINO IDE..
It has produced the following error, which at this stage, I am unable to decipher apart
from the observations that the compiler can't identify what type of value/integer is being used.
Sorry to be running back to for help so soon.
C:\Users\Pau\AppData\Local\Temp\.arduinoIDE-unsaved2024911-12916-ef9d62.0u31l\sketch_oct11a\sketch_oct11a.ino: In member function 'void ADAU1701_I2C::Read_block(byte, byte, uint8_t (&)[16], int)':
C:\Users\Paul\AppData\Local\Temp\.arduinoIDE-unsaved2024911-12916-ef9d62.0u31l\sketch_oct11a\sketch_oct11a.ino:17:44: error: call of overloaded 'requestFrom(uint8_t&, size_t&, bool)' is ambiguous
Wire.requestFrom(_I2C_addr, count_t, true); //request a block of bytes
^
In file included from C:\Users\Pau\AppData\Local\Temp\.arduinoIDE-unsaved2024911-12916-ef9d62.0u31l\sketch_oct11a\sketch_oct11a.ino:3:0:
C:\Users\Paul\AppData\Local\Arduino15\packages\arduino\hardware\avr\1.8.6\libraries\Wire\src/Wire.h:66:13: note: candidate: uint8_t TwoWire::requestFrom(uint8_t, uint8_t, uint8_t)
uint8_t requestFrom(uint8_t, uint8_t, uint8_t);
^~~~~~~~~~~
C:\Users\Paul\AppData\Local\Arduino15\packages\arduino\hardware\avr\1.8.6\libraries\Wire\src/Wire.h:69:13: note: candidate: uint8_t TwoWire::requestFrom(int, int, int)
uint8_t requestFrom(int, int, int);
^~~~~~~~~~~
exit status 1
Any suggestion you may have would be appreciated....
Paul.
Compilation error: call of overloaded 'requestFrom(uint8_t&, size_t&, bool)' is ambiguous
It has produced the following error, which at this stage, I am unable to decipher apart
from the observations that the compiler can't identify what type of value/integer is being used.
Sorry to be running back to for help so soon.
C:\Users\Pau\AppData\Local\Temp\.arduinoIDE-unsaved2024911-12916-ef9d62.0u31l\sketch_oct11a\sketch_oct11a.ino: In member function 'void ADAU1701_I2C::Read_block(byte, byte, uint8_t (&)[16], int)':
C:\Users\Paul\AppData\Local\Temp\.arduinoIDE-unsaved2024911-12916-ef9d62.0u31l\sketch_oct11a\sketch_oct11a.ino:17:44: error: call of overloaded 'requestFrom(uint8_t&, size_t&, bool)' is ambiguous
Wire.requestFrom(_I2C_addr, count_t, true); //request a block of bytes
^
In file included from C:\Users\Pau\AppData\Local\Temp\.arduinoIDE-unsaved2024911-12916-ef9d62.0u31l\sketch_oct11a\sketch_oct11a.ino:3:0:
C:\Users\Paul\AppData\Local\Arduino15\packages\arduino\hardware\avr\1.8.6\libraries\Wire\src/Wire.h:66:13: note: candidate: uint8_t TwoWire::requestFrom(uint8_t, uint8_t, uint8_t)
uint8_t requestFrom(uint8_t, uint8_t, uint8_t);
^~~~~~~~~~~
C:\Users\Paul\AppData\Local\Arduino15\packages\arduino\hardware\avr\1.8.6\libraries\Wire\src/Wire.h:69:13: note: candidate: uint8_t TwoWire::requestFrom(int, int, int)
uint8_t requestFrom(int, int, int);
^~~~~~~~~~~
exit status 1
Any suggestion you may have would be appreciated....
Paul.
Compilation error: call of overloaded 'requestFrom(uint8_t&, size_t&, bool)' is ambiguous
The compiler is complaining about the use of "byte" instead of "uint8_t". The ESP32 library for Wire that I use accepts either, whereas the AVR Wire library that you are using insists on uint8_t (unsigned 8-bit integer type). Years ago, I had started to use "byte" and "word" because they seemed to be the preferred way to refer to those types in Arduino, but uint8_t and uint16_t are now more widely used.
To fix this, just change the call to the Wire library to use uint8_t instead of byte. You will need to change that in both the ADAU1701_I2C.cpp and ADAU1701_I2C.h files. Or, just delete the ADAU1701_I2C::Read_block function from both files, as it isn't needed. At one time I used that function to read the EEPROM on the ADAU1701 board, which was useful in the early days of debugging the code. But I got rid of that feature many years ago. Now, it's just code that trips up people who use the AVR Wire library instead of the ESP32 Wire library 🙂.
This is an example of why I will probably never publish the ADAU1701 code that I have. It takes a long time to test the code against the various libraries and maintain it. I don't have the patience to do that, and everything I've been doing lately is based on the ADAU1467, which uses the SPI interface. If someone else wanted to "clean up" the ADAU1701 code and publish it, I'd consider the offer, but I would not want to spend more time on it myself.
To fix this, just change the call to the Wire library to use uint8_t instead of byte. You will need to change that in both the ADAU1701_I2C.cpp and ADAU1701_I2C.h files. Or, just delete the ADAU1701_I2C::Read_block function from both files, as it isn't needed. At one time I used that function to read the EEPROM on the ADAU1701 board, which was useful in the early days of debugging the code. But I got rid of that feature many years ago. Now, it's just code that trips up people who use the AVR Wire library instead of the ESP32 Wire library 🙂.
This is an example of why I will probably never publish the ADAU1701 code that I have. It takes a long time to test the code against the various libraries and maintain it. I don't have the patience to do that, and everything I've been doing lately is based on the ADAU1467, which uses the SPI interface. If someone else wanted to "clean up" the ADAU1701 code and publish it, I'd consider the offer, but I would not want to spend more time on it myself.
Hi Neil, Many thanks for your detailed reply..
I'll endeavour to leave more time before my next cry for help.
I'll endeavour to leave more time before my next cry for help.
Hi Neil, Once I put my Hogwarts 'hat of truth' on and rummaged around a bit (a lot, actually), I found that changing one statement fixed everything.
size_t count_t = count; was changed to uint8_t count_t = count; Hopefully this change won't cause problems elsewhere..
This resulted in a successful compilation.
The libraries appear to accept both forms of data type declarations 'uint8_t' and 'byte'.
The compiler seems to expect the first two values in the statement 'Wire.requestFrom(_I2C_addr, count_t, true);' to be declared in the same way.
As a complete, novice, it took me two days of investigating the problem and reducing it down to this one solution,
so I absolutely understand your reluctance to revisit old battlegrounds.
Regards and thanks,
Paul.
size_t count_t = count; was changed to uint8_t count_t = count; Hopefully this change won't cause problems elsewhere..
This resulted in a successful compilation.
The libraries appear to accept both forms of data type declarations 'uint8_t' and 'byte'.
The compiler seems to expect the first two values in the statement 'Wire.requestFrom(_I2C_addr, count_t, true);' to be declared in the same way.
As a complete, novice, it took me two days of investigating the problem and reducing it down to this one solution,
so I absolutely understand your reluctance to revisit old battlegrounds.
Regards and thanks,
Paul.