![]() |
MD_YX5300 Library
1.0
Library for YX5300 MP3 player IC
|
The MP3 module communicates using asynchronous RS232 serial communication at 9600 bps, 8 data bits, No parity, 1 stop bit, no flow control.
Flow control is implemented using a serial RQST/RESP protocol based on data packets with the following byte format:
|Packet Format (bytes) ||||||||| |----—|------—|-----—|------—|-------—|-----—|-----—|------—|------—|--—| | Start | Version | Length | Command | Feedback | DataHi | DataLo | [ChkHi] | [ChkLo] | End |
Byte | Value | Description |
---|---|---|
Start | 0x7e | The start of each packet, used for synchronization. |
Version | 0xff | Always the same value in this implementation. |
Length | 0x06 | Number of bytes between Start and Chk. |
Command | 0x?? | Command code for required action. |
Feedback | 0x01 | Set to 1 for protocol feedback, 0 for none. |
DataHi | 0x?? | Length-4 data bytes = 2 in this implementation. |
DataLo | 0x?? | |
ChkHi | 0x?? | Optional checksum for bytes between Start and Chk. |
ChkLo | 0x?? | |
End | 0xef | The end of each packet. |
The message flow between the device and MCU is be displayed on the Serial Monitor by the library when the C++ macro define LIBDEBUG is set to 1 in the main code file.
The checksum is optional in the protocol packet. The library will use the checksum field if the C++ macro define USE_CHECKSUM is set to 1 in the header file.
This library manages the serial interface to the TX5300 by taking care of sending and receiving the serial messages. The MP3 Player responds to command requests but it also sends unsolicited messages when certain events occur (eg, TF card removed or inserted). These unsolicited messages may be important to the application so the library implements mechanisms that allow the application to process the relevant notification data by placing it in a cbData structure.
How the cbData structure is received by the application is flexible and depends on the setSynchronous() setting and whether a callback is defined. This is summarized in the table below and explained in the text that follows.
Callback | Polled | |
---|---|---|
Sync | unsol: callback | unsol: check() |
resp: ret status | resp: ret status | |
Async | unsol: callback | unsol: check() |
resp: callback | resp: check() |
The first choice is whether to process the message in line with the calling sequence (synchronous) or separately (asynchronously):
Independently of the sync/async mode, the application can choose to be informed received messages are ready to process either by: