Hi there, I have been working at getting a pic16lf1936 to talk to an ADAU1401 over I2C.. Finally I managed it..
The command string addresses a single Sigma Studio on/off switch (or design element) which activates an LED.
My code is exactly the same as that sent from Sigma Studio. The design is loaded into the self-boot EEPROM..
I can only think that when Sigma Studio connects to the ADAU1401, it issues some commands that I am not seeing as this simple design runs from within Sigma Studio..
Does anybody have any ideas please.
The command string addresses a single Sigma Studio on/off switch (or design element) which activates an LED.
My code is exactly the same as that sent from Sigma Studio. The design is loaded into the self-boot EEPROM..
I can only think that when Sigma Studio connects to the ADAU1401, it issues some commands that I am not seeing as this simple design runs from within Sigma Studio..
Does anybody have any ideas please.
Hi, this is the command as displayed in the capture window of Sigma Studio
Safeload Write Time: 21:02:11 - 104ms IC: IC 1 Cell Name: Switch1 Param Name: SwitchAlg281ison
Param Address: 0x0000 Param Value: 0 Bytes: 4 Param Data: 0x00, 0x00, 0x00, 0x00
The 0X68 is the I2C address of the ADAU1401. It has to precede each segment of data being sent to the ADAU1401. The screen shot of the data stream that I put on my post is identical for both Sigma Studio and my 16LF1936.
Many thanks..
Safeload Write Time: 21:02:11 - 104ms IC: IC 1 Cell Name: Switch1 Param Name: SwitchAlg281ison
Param Address: 0x0000 Param Value: 0 Bytes: 4 Param Data: 0x00, 0x00, 0x00, 0x00
The 0X68 is the I2C address of the ADAU1401. It has to precede each segment of data being sent to the ADAU1401. The screen shot of the data stream that I put on my post is identical for both Sigma Studio and my 16LF1936.
Many thanks..
That is correct, 0x68 is the device address.
So the register address is 0x0000 and the data is 0x00000000 or 0x00000001 according to the screenshot you posted.
That means transaction should look like this:
START 0x68, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00/0x01 STOP
What you show in first post looks more like this:
START 0x68, 0x68, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00/0x01 STOP
Which does not look right.
Hi, I've looked at that screenshot again. If you look carefully, it is 0X68 followed by 0X08.
I don't blame you for not seeing that, the screenshot is not very clear.
Many thanks for giving your time to this problem.
As you can see from the subsequent screenshot I have set up a very simple test design.
This is just so that I can attempt to control a self bootload program via the I2C control port.
Not having much luck though..
I don't blame you for not seeing that, the screenshot is not very clear.
Many thanks for giving your time to this problem.
As you can see from the subsequent screenshot I have set up a very simple test design.
This is just so that I can attempt to control a self bootload program via the I2C control port.
Not having much luck though..
Hi, I've done some more investigating and found that the self-boot pin (6) is held permanently low.
I am using a ready-made experimenters board and have already had to cut track and link to achieve other functions.
The memory is probably being maintained by voltage leakage from other connected modules which I interpreted as being 'self boot'
I'll keep you updated...
I am using a ready-made experimenters board and have already had to cut track and link to achieve other functions.
The memory is probably being maintained by voltage leakage from other connected modules which I interpreted as being 'self boot'
I'll keep you updated...
I see 2x 0x68 and then 0x08. What is the register address you are trying to write in this transaction?
Hi Eclipevl, I finally understood what you were talking about.. I got rid of the second 0X068...
It made no difference. The ADAU1401 still doesn't want to party.
It made no difference. The ADAU1401 still doesn't want to party.
There was a missing 'RETURN' between two subroutines.....
But although the ADAU1014 accepts the transmission, it does not appear to execute it..
There is a lot of info about communicating with the ADAU1701 at audiodevelopers.com--see this link for a simple (hopefully) intro. The attached file has the library code for the I2C communications. Maybe it will help.
It's good practice to use the safeload registers even if you aren't processing real-time audio. That's the only way to communicate with the newer versions such as the ADAU1466.
Loading into the bootload EEPROM is tricky, as the data needs to be formatting in a specific way.
It's good practice to use the safeload registers even if you aren't processing real-time audio. That's the only way to communicate with the newer versions such as the ADAU1466.
Loading into the bootload EEPROM is tricky, as the data needs to be formatting in a specific way.
Try with the simple example, one you showed in sigmastudio. One register, simple transaction of dev address+ 6 bytes. And show the waveforms here too.
Hi Niel. Many thanks, but at the moment I only do assembler....
Maybe I should start thinking about C....
Paul.
Maybe I should start thinking about C....
Paul.
I programmed for many years in assembler and accomplished a lot with it. But with these more complicated chips, it really helps to be able to use library functions such as Wire or SPI from the Arduino IDE, or to use someone's DSP library. Sure, there is a learning curve, but the effort will pay off if you want to take advantage of the power of chips like the ADAU1701.
Hi Neil, I know I should make the effort.. I have experienced lots of problems using assembler.
Like you I have done lots of good stuff with it and generally I don't need to refer to much when writing programs.
I'm just reluctant to get into the overhead of learning 'new' stuff.
My current issue appears not to be comms but implementation of my project.
DSP is new to me. I have been building high quality DAC's for years, but they have limited functionality.
My intention is to deliver digital audio direct to my active loudspeakers.
Up until now, I have been using differential line drivers from my DAC to the speakers.
I am sure that I should eliminate the last weak (analogue) link in the chain between the DAC and the speakers.
My target is to maintain the same simple PIC-based control of the system but introduce the sophistication of DSP.
So right now the ADAU1401 ACK's every piece of data I send to the safeload addresses but when I send the IST command
nothing happens.
Please note that this is not the full data stream..
This is my test circuit, it turns a LED attached to GPIO2 on and off.
It is loaded into EEPROM and autoboots at power up.
It works fine when connected to Sigma Studio, but not when connected to the PIC chip.
The I2C traffic is identical.... I'm hoping its a case of not being able to see what's in front of my nose-itis..
No amount of treatment seems to fix that for me......
Anybody's thoughts would be appreciated.
Regards and thanks,
Paul.
Like you I have done lots of good stuff with it and generally I don't need to refer to much when writing programs.
I'm just reluctant to get into the overhead of learning 'new' stuff.
My current issue appears not to be comms but implementation of my project.
DSP is new to me. I have been building high quality DAC's for years, but they have limited functionality.
My intention is to deliver digital audio direct to my active loudspeakers.
Up until now, I have been using differential line drivers from my DAC to the speakers.
I am sure that I should eliminate the last weak (analogue) link in the chain between the DAC and the speakers.
My target is to maintain the same simple PIC-based control of the system but introduce the sophistication of DSP.
So right now the ADAU1401 ACK's every piece of data I send to the safeload addresses but when I send the IST command
nothing happens.
Please note that this is not the full data stream..
This is my test circuit, it turns a LED attached to GPIO2 on and off.
It is loaded into EEPROM and autoboots at power up.
It works fine when connected to Sigma Studio, but not when connected to the PIC chip.
The I2C traffic is identical.... I'm hoping its a case of not being able to see what's in front of my nose-itis..
No amount of treatment seems to fix that for me......
Anybody's thoughts would be appreciated.
Regards and thanks,
Paul.
Forget about safeload for now. Just do the transaction that is shown in the sigmastudio log, which is:
START 0x68, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00/0x01 STOP
START 0x68, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00/0x01 STOP
Hi there that is an instruction to turn on cell switch1.. In this test design it simply turns on the LED attached to gpio2.. Sending just that string whether the last byte is 0X00 or 0X01 turns the LED on. I cannot turn it off again.
I'm not sure what's going on, but I'll make some guesses/comments:
1) The ADAU1701 requires the right number of bytes for each register, and it will reset if there is an error. The safeload register is 5 bytes long (see Table 31 in the datasheet), and if you only sent the 4 bytes that SigmaStudio shows, it will reset the ADAU1701. Try adding an extra "00" on the front to pad the data to 40bits.
2) You must have a valid program in the Program RAM. So, you need to either load that program yourself or else store the program in the EEPROM and let the ADAU1701 self-boot. Once the program is loaded from EEPROM, you can take over the I2C bus and write to the device.
3) eclipsev1 is correct--you should be able to write to the Parameter RAM address for that cell, without using the Safeload registers.
1) The ADAU1701 requires the right number of bytes for each register, and it will reset if there is an error. The safeload register is 5 bytes long (see Table 31 in the datasheet), and if you only sent the 4 bytes that SigmaStudio shows, it will reset the ADAU1701. Try adding an extra "00" on the front to pad the data to 40bits.
2) You must have a valid program in the Program RAM. So, you need to either load that program yourself or else store the program in the EEPROM and let the ADAU1701 self-boot. Once the program is loaded from EEPROM, you can take over the I2C bus and write to the device.
3) eclipsev1 is correct--you should be able to write to the Parameter RAM address for that cell, without using the Safeload registers.
Hi there, eclipsevl...
My data stream was 1 byte too long,, the value to turn the LED on was 0 and to turn it off was 1..
With the string being too long it never saw the off value... So now I have even more to think about....
Like why 'safeload' doesn't work for me....
Many thanks,
Paul.
My data stream was 1 byte too long,, the value to turn the LED on was 0 and to turn it off was 1..
With the string being too long it never saw the off value... So now I have even more to think about....
Like why 'safeload' doesn't work for me....
Many thanks,
Paul.