Rotary Encounter Write with MCU not working

Hello Stomper85,

I have been working on this today but have not been able to complete the solution. 

I will continue with this effort and hope to have a solution for you soon. 

Dave T

Hi Dave,

this is very much appreciated you are the best!

If there is any other workaround... no problem. The rotary encounter is the Bluetooth volume knob for my I2S signal over bt.

But if the user sends the an "absolute volume change" command (changing bt volume on android phone) I want the volume to be changed in the dsp. 

This is the background for what I am about to do.

Looking forward to your answer. 

Chris

Hello Chris,

This took a while to work out the details. It was looking like there was a bug in the software but it was a small detail I was doing wrong. 

Here is what I came up with. I documented what to do in the notes in the project. 

It is a little tricky but ended up being fairly simple to do. 

There are two DC cells that you write to when you want to change the volume. When they are set the same then the encoder can change the volume level. There is also a readback cell off the screenshot that the controller can read so it knows the current volume setting.

I have to run, I am multi-tasking right now....

Dave T

ADAU1701 Rotary Encoder with extras.dspproj

Hello Dave,

you are great! I will try this as soon as possible as currently there popped up a problem in another project. 

Looks way more complicated than I thought it could be... but I understand your solution. Nice!

You doing such a great work man! This helps me out for the product and it will be a nice benefit for the user to only have one BT volume on the device and mobile.

On studying other products I realized that most of the manufacturers have daisy chained the local volume and the remote volume but not synced. 

But as we want to come up with a pretty high priced premium FRFR guitar Amp hand made in Germany I want to push it to a very nice user experience. 

Now I can see the finish line... :-) 

Best regards

Ok, this worked! 

However... i changed your solution a little bit:

This is a little easier for my software as the InterfaceWrite block simply puts the table index into a register. No need of init write and bit shifting or scanling.

This works like a charm now :-)

Thanks!

Hello Stomper85,

You are the brilliant one! I spaced on this and I think this is a good place to go over the history and details of the interface read/write block. 

The ADAU1701/1401 parts have eight registers that are used starting at address 0x0800 going up to 0x0807. The datasheet has some cut and paste errors in that they are all labeled as Interface 0 register when it is 0-7. The number follows the address as you would expect. So 0x0801 is for Interface register 1. 

The number is a 28 bit number right justified in the register so the top four bits are always zero. 

So what happens when a block uses the interface read/write GUI objects? 

The block will read the register location and pick up the value. Then it will increment it or decrement if needed or it will simply not change it at all. Then it will write out to the register the new value or the old one if it did not change. 

The purpose of these registers is in the event of power loss, you can trigger the Writeback function where these eight registers are written to the EEPROM. Then when the part selfboots the next time it will pick up these values and remember where the controls are set. How to do the Writeback is a subject that is covered in other posts and not here. 

Sotmper85, you are correct in that you can read the register to know what the setting is. this is good and you do not have to use the Readback that I had in my project and save the MIPS. 

The issue is that the hardware does not allow you to write directly to these memory locations from the SPI/!2C slave port. So you cannot update the setting manually! I tried it using the sequencer and it did not work. So using my method with the ABCD block allows you to insert a new value into the cell so it is picked up as the value during the next sample period and saved. 

There are 8 of these registers. If you ever need more than 8 then use my trick of using a feedback cell but if you use a feedback cell then you must use the Readback cell to read the current value. It is not possible to read the memory location of the Readback storage. 

After we designed the Sigma100 cores, ( the 1701/1401) we put out the Sigma200 cores. Then the Sigma300 cores. None of these newer parts have any interface registers at all. None. The Sigma300 can write to the EEPROM so there are some different blocks for that. However, we still maintained the Interface Read and Interface Write blocks and required them for many blocks. These are just memory locations that you cannot read directly and behave just like the FeedBack blocks I used. The other bad thing is that there is a limitation of eight interface blocks even though there is not a limitation with memory! The software from the 1701 was just ported over and maintained like it was. So the little old 1701 can do something that all the newer ones cannot do! It actually has interface registers that will writeback to EEPROM when triggered. For the Sigma300 you have to use the blocks inside of the Master Port blocks in the library. Those do work. For the Sigma200 parts you cannot writeback to EEPROM. You must have a controller keep track of the settings. 

Here is my project changed to use the Interface read and write: If you use the Writeback feature you should do it this way.

Thanks for keeping me straight and reminding me about the interface registers. I am not used to using them since the others do not have them. 

Dave T