hanzibal

The 16 bit register is divided into two bytes of 8 bits (256 steps) each, you need to set the two bytes separtely like so:

byte left_vol = 45;
byte right_vol = 90;

ushort vol = (left_vol << 8) + right_vol;

WriteRegister(REG_SCI_VOL, vol);

I'm sorry for not being of much help here but I've never dealt with that M2Mqtt.

 

Did you solve the problem eventually?

SCI_VOL is a h/w register of the vs1053b chip, so you need to write the value 0x2424 to the register. You do this using the serial command interface (hence the "SCI" prefix) over SPI.

    // Write to an  SCI register
    private void WriteRegister(byte address, ushort data, bool waitForDREQ = true)
    {
        wr_buff[0] = 2;                    // write command
        wr_buff[1] = address;              // register
        wr_buff[2] = (byte)(data >> 8);    // high byte
        wr_buff[3] = (byte)(data & 0xff);  // low byte

        SelectCommand();                   // select SCI
        if (waitForDREQ) AwaitDREQ();      // wait for dreq to go high
        spip.Write(wr_buff);
    }

    // example of setting volume
    WriteRegister(REG_SCI_VOL, 0x2424);

The code snippet above is taken from my source code (puplished earlier).

 

I would use a rotary encoder but if you want to use a potentiometer, you can set it up as a simple voltage divider GND - 3.3V and then read the voltage of the wiper using a Netduino analogue pin. You would then need to add software to continuously poll the analogue pin for any changes in voltage, executing the corresponding volume adjustments.

Great, looking forward too see the vid!

Progress has been extremely slow, it can scan and list SSIDs of available networks and also connect given the corresponding WPA2 key.

However, It can not do anything useful like accessing actual content on remote servers because of general problems reading and writing streams so there's little or no point in pblishing any code until I got those basics working.

There's probably as many recepies to writing drivers as there are chips to write them for but I think, In general the key is to read the d/s back and forth until you know your way in it, which sections contains which bits of information, where to find the info you need in various situations that you can anticipate.

Get the hang of the terminology used by the vendor and get a good feel for how the chip works and how you are supposed to use it. Ask your self the relevant questions, how can I achieve this or that required functionality and make sure you know where in the d/s the answers are.

Make up some kind of hypothetical API structure in your head and test it against what you have gathered from reading the d/s to see if your model is realistic and valid. Sometimes you can find some code for another architecture for inspiration or that you can port from but you will need to understand the chip nevertheless.

Proceed by establishing a working communication with the chip. Implement register read ops and verify by reading some expected power-on default value. Then get write ops working, verify using write and read-back testing. Write a value to some register and verify by reading back the register value to make sure it "stuck".

Come up with a programming model with some basic properties and methods supporting the model in your head. Create a class and definine the various constants, enums, register addresses and such that you will need.

Then start implementing, pick something simple like "getversion", "soft reset" or whatever is available, preferably something really simple that can be easily verified.

By now your knowledge and confidence will have grown enough to make the rest fall into place as if almost by itself.

Good luck!