MD_YX5300 Library  1.0
Library for YX5300 MP3 player IC
Message Flow Management
YX5300_Board_Layout.jpg
YX5300 Board Layout

Communications Format

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.

Sending and Receiving Serial Messages

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):

  • Synchronous: The command message is sent and the code waits for the response before returning to the calling application. This is relatively inefficient of CPU time as it involves a busy wait, but is easy to implement in the application and is good for simple applications
  • Asynchronous: The command message is sent and the library immediately returns. The response message is processed as it returns and the calling application can continue to run while this happens. Once the response is received, the calling can be notified through a callback or polled status (see below).

Independently of the sync/async mode, the application can choose to be informed received messages are ready to process either by:

  • Polling: The return status of the check() method is used as the signal that an unsolicited message has been received. In synchronous mode the return code for the method invoked will be the status of check() for that request.
  • Callback: If a callback function is defined (see setCallback()), every unsolicited message received will be processed through the callback mechanism. In Synchronous mode, both the callback and the return code for the method invoked will signal receipt of the same message, so the application code should guard against processing the message twice.