baldram/ESP_VS1053_Library

Improvement: introduce a new lightweight method to check if the VS1053 chip is connected

wmarkow opened this issue · 3 comments

I propose to introduce a new method that will check if the VS1053 chip is connected and able to exchange data to the microcontroller. I know about testComm(const char *header) but this seems to do a bit more that just checking if the chip is connected.

I propose a new method as below:

bool VS1053::isChipConnected() {
    uint16_t status = read_register(SCI_STATUS);

    if(status == 0 || status == 0xFFFF)
    {
        return false;
    }

    return true;
}

It just reads the STATUS register. If the chip is not connected correctly then SPI will mostly read (according to my current expeirence with various boards) either zeros or ones (it depends on the platform I think). According to the VS1053 this Sparkfun datasheet the STATUS register after reset will have value different than 0x0000 and different that 0xFFFF and probably in 99.9% have - during the normal operation/configuration by the end user- also a value different than 0x000 and 0xFFF.

The idea is: when STATUS register is 0x000 or 0xFFFF then we have some hardware failure (the chip is not correctly powered up, not correctly connected and so on).

Hi @wmarkow! Thanks for feedback!

A good idea, why not to add such method. I would suggest to add a proper comment in code describing a purpose of this new functionality.

For sure the SCI_STATUS const doesn't exist yet and would need to be created.
The code above can be simplified:

bool VS1053::isChipConnected() {
    uint16_t status = read_register(SCI_STATUS);
    return !(status == 0 || status == 0xFFFF);
}

I'm currently involved in several other projects. It's hard to split between different topics. I don't have enough spare time at the moment and it may take longer to handle your requests. Especially when it's about testing changes before releasing...

Would you like to provide a pull request to solve this issue?

I don't have enough spare time at the moment and it may take longer to handle your requests.

That's not a problem. Take your time. In the meantime I will use in my project my own repository (that is froked from yours) which contains all of proposed fixes.

Would you like to provide a pull request to solve this issue?

PR already provided.

Approved and merged, thanks!