App note: Porting the Helix MP3 decoder to PIC32MX microcontrollers

Posted on Sunday, March 4th, 2012 in app notes, Uncategorized by DP

Microchip shows how to port the open source Helix MP3 decoder algorithm to the PIC32MX family of microcontrollers. This algorithm was designed be used by both floating point processors, and fixed point processors like the PIC32.

Application note describes the procedure to port the open source Helix MP3 decoder algorithm onto Microchip’s PIC32MX 32-bit microcontrollers (MCUs). The source code provided with this document demonstrates a MP3 player application using the Helix MP3 decoder.

This entry was posted on Sunday, March 4th, 2012 at 9:00 pm and is filed under app notes, Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.

2 Responses to “App note: Porting the Helix MP3 decoder to PIC32MX microcontrollers”

  1. hlipka says:

    Note that this isn’t useful for the PIC32MX1xx/2xx series. They have only 32k RAM, and this decoder eats all but 512 bytes of this.

  2. mrpippy says:

    I’m not a lawyer, but in reading the RPSL I’m not totally convinced that the run-time library loading technique avoids making the entire product a derivative work. The relevant parts of the RPSL:

    You may create a Derivative Work by combining Covered Code with other code not otherwise governed by the terms of this License and distribute the Derivative Work as an integrated product. In each such instance, You must make sure the requirements of this License are fulfilled for the Covered Code or any portion thereof, including all Modifications.

    Mere aggregation of another work not based on the Covered Code with the Covered Code (or with a work based on the Covered Code) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. If You deliver the Covered Code for combination and/or integration with an application previously provided by You (for example, via automatic updating technology), such combination and/or integration constitutes a Derivative Work subject to the terms of this License.

    RTLL avoids “combining” covered code (the Helix MP3 decoder) with other/proprietary code until both hex files get programmed into flash.

    An app note certainly isn’t going to carry binding legal advice, but to me the app note is far too casual in presenting RTLL as a technique that won’t require proprietary application code to be open-sourced, without ever acknowledging that a) to the best of my knowledge, this technique doesn’t have the blessing of RealNetworks/Helix, and b) lawyers may not agree.

Leave a Reply

Notify me of followup comments via e-mail. You can also subscribe without commenting.

Recent Comments

  • Joe Desbonnet: Ya, I can recommend the low melting point solder. I used brand 'ChipQuik' and it's amazingly easy to use.
  • Jerome: I need a new BusPirate for the Fablab ;) Many thanks!
  • Max: Seems like an unexpectedly violent way to remove the chip indeed. A hot air station should of course do the job just fine, but in...
  • jose: Part removal described here is pure butchery, the cheapest hot air station will do a fast and clean job removing the QFP, heat air to...
  • Cody: Yes please