release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide



Search | Go
Wiki > Main > RockboxPlayer > LyrePrototypeB (r31)

about

This is an alternate version of the RockboxPlayerPrototype? that will be a circuit board design from the beginning.

Discussion of the project goals and design specifics should be held in this forum instead of on this page. A talk page would be ideal for the discussion, but Take Five Wikis seem not to have those (there is a comments plugin, but I think it would always show the discussion at the bottom of the page and I'd rather hide the discussion from this main page and have it linked instead.)

goals

The goals of the RockboxPlayerPrototypeB? project are the same or nearly the same as the ones for the RockboxPlayerPrototype?.

We seek to design a circuit board whose design is freely available (creative commons by-nc-sa 3.0) that can, once populated, run Rockbox and do most of the things that Rockbox can do on other platforms. With this design in hand, it should allow all of the following:
  • An advanced electronics hobbyist could make a music player for himself (it will require soldering 0.5mm pitch packages).
  • We could fabricate a bunch of boards and ask sparkfun.com or store.makezine.com or someone else to sell the bare boards for us.
  • We could sell a kit with the board and all the necessary parts so that all you'd need is a soldering iron and some patience (and maybe a microscope).
  • We could sell a populated board with Rockbox loaded on it so that anyone who wants to take a working music player and put it in a case of his own choosing with a battery of his own choosing would be able to do so.
  • Finally, we could sell a finished mp3 player with a battery in a nice case with rockbox already loaded. See below for a discussion of a couple hurdles for this version. With this one, we could optionally include an x gig SD card loaded with creative commons licensed music (one source for such music is Jamendo).

For each device that's sold, some (We don't know how much yet) $ will go to the rockbox project and some will go to fund more rockbox player development.

The non-commercial part of the creative commons license is so that Big Company X can't take our freely available designs and make a player based on them and sell it cheaper than we can and not give any proceeds back to the project. We can always license a company we choose to manufacture the devices for us later. Also, one of the main developers is greedy and wants to make money off the project. smile

DaveChapman - As I'm sure you know, Rockbox is GPL'd, a license which allows commercial use, and for good reasons. I don't think the fact that a commercial company may not donate cash back to the project is a good reason to prevent them from using (and potentially contributing) to your design. I would have thought that the fact that users would be able to buy a player at a cheaper price, and the possibility of the contribution of professional engineers would be of greater benefit.

block diagram

2008-02-03-arm9-oled-music-player-block-diagram-75dpi.png

In this block diagram, red lines mean analog signals.

components

  • arm9 microcontroller
    • Atmel AT91SAM9260?: 208 pin qfp, ~$17, asked for samples 2007-08-27 and received them 2007-09-04
  • organic led display, color
    • Univision UG-2828GFEFF01: 128x124, 18 bit color, 30 pin connector, 16 brightness settings (settable via software), ~$37, only available through sparkfun (so probably no free samples)
  • stereo DAC (twi or spi or ssc/i2s)
    • Ti TLV320AIC23B: 28-TSSOP, ~$7, asked for samples 2008-02-02
      • there's the question of whether to support 44.1kHz sampling or 48kHz - page 30 of the pdf datasheet shows that they can't both be generated from the same clock (and usb mode doesn't generate either frequency exactly) The 12MHz clock mode (i.e. USB mode) should be used, since all sampling rates (8K, 8.021K, 32K, 44.1K, 48K & 96KHz) can be generated. No other mode supports all rates. There will be a slight frequency error fof about +0.038% for 44.1KHz, but it is not noticeable. -- RogerQuadros - 7th Feb 2008
  • stereo headphone jack, through-hole for stability (which is very important for the headphone jack, because it'll get inserted/removed most frequently)
    • Cui SJ-3505: stereo, through-hole, dual switches, 10,000 cycle life, ~$2 (N/A on digikey)
    • Cui SJ-3524-SMT: stereo, SMT, single switch, 5,000 cycle life, ~$0.9 (thin design-saves board space, black finish)
  • mini-usb connector, through-hole for stability
  • ambient light sensor
    • TLS250
  • sdram (32 bit wide)
    • possible 16-bit wide candidate part: MT48LC32M16A2P? - SDRAM 512MB 133MHZ 54-TSOP - cost 18,82 in Digikey.
    • possible candidate part: MT48LC4M32B2P?-7:G: 128Mbit (16MiB) SDRAM, TSOP-86, ~$7, micron doesn't do free samples
  • spi flash (dataflash, 8 pin soic)
  • 2 SD/SDHC card slots - the main reason for this is to share music; the secondary reason is so that you can have twice the currently available SD card size worth of music available at one time, or, so that you can upgrade player capacity by buying a new card and just using it without having to throw the old one away
    • possible candidate parts: probably something from molex, because I asked them for free samples of 4 different SD card slots and they sent me everything I asked for
    • One problem with using the 2 built-in sd card interfaces on the AT91SAM9260? is that one of them shares pins with the zeroth SPI port, which we need for dataflash. (pdf, page 35 and 567)
    • The other problem is that the AT91SAM9260? only supports the SD spec v1.0, which means it doesn't directly support SDHC. (pdf, page 567)
    • This means bit-banging (or, I suppose, nibble-banging, since it's 4 bits wide), which isn't so much slower as using the built-in interface, but it requires the processor sit there and execute instructions for a block copy instead of letting the built-in peripheral do it in the "background." The benefit of doing it this way is that we can be sure that SDHC will be supported (just as soon as we write it). I don't know anything about the SD spec, so I don't know if the built-in controller can be made to work with SDHC. That would be the ideal thing, really.
  • lithium ion or lithium ion polymer battery (charges via usb)
  • battery charge controller (detects when the device is plugged in and charges the battery with a Li-Poly charge profile)
    • Maxim MAX1811: li-ion or li-poly, soic-8, ~$3 to $4 - but nobody has these for sale (digikey, mouser, newark, avnet, arrow), maxim's site sells these directly - but that's a pain for just one part, requested samples on 2007-08-30 and received them on 2007-09-04
  • system power controller (decides whether the device is powered from usb or from the battery)
  • DC-DC converters
    • we have 2.7V-4.25V from the battery OR ~5V from usb
    • we need 3.3V for most things
    • we need 1.8V for ARM9 core
    • we need 7V-18V for OLED display (I've tried 13.5V and 16.35V and the higher the voltage, the brighter the display)
    • somebody probably has a DC-DC converter designed to handle li-poly voltage as the input voltage for each of the desired output voltages we need
  • buttons

The design is not finalized at this time, so a few things are still optional / unknown at this point:
  • touch/click wheel:
    • there is a source for ipod nano clickwheels ($16), but their supply would probably not last into the commercial phase.
    • Alternately, quantum research group sells a (~$6) controller for proximity/touch sensing and the only requirement for the touch wheel is that it be a circuit board trace a couple mm behind a plastic case (neat!) product page with link to datasheet. Not ideal, because it's a QFN package, but maybe another manufacturer has something similar that's hand-solderable. QFN is hand solderable. In fact, it is easier to solder QFN than QFP because there is lesser chance of forming solder bridges between adjacent pins. QFN is also quite compact!! -- RogerQuadros - 7th Feb 2008.
  • size/shape of final player - depends partly on battery size/shape
  • to get truely low power when the device is in pause mode, it needs mobile sdram which is only available in BGA packages (tell me if I'm wrong about this!)
    • BGA has pretty much been ruled out at this point (2008-02-02):
      • It would probably require more than a 4 layer board to route all the wires to it.
      • Assembling the boards even if routing can be accomplished is still a problem:
        • Can't be done by a hobbyist
        • Might still be difficult even if you had a machine to do it (as I do)
        • Professional board assembly is expensive - I mean like several hundred dollars per board expensive which is much more than the parts and the board will cost
    • there are a couple options to get around this:
      • a power switch so that the device is actually off - not as elegant as just hitting pause on your music player and having the battery last a week in that mode, but then there's a better interface for putting it in "hold" mode - it's actually off, so the buttons don't do anything
      • make sure all the i/o pins going to the device are low and use an FET to turn off it's power - the i/o pins can power the device even if you just turn off its power pins
      • the atmel arm9 supports a "backup" power mode where the processor can be off and the core powered down completely, but it'll produce a wakeup signal when certain (configurable) pins change (ie, the buttons), so that shutdown/wakeup signal can drive the main dc-dc converter directly so that most of the processor is powered down (except for the "backup" supply that powers this shutdown/wakeup function) as well as the ram and the flash and the DAC, etc. The backup supply draws 5 microamps @ 1.8V. Very low power indeed.
  • spi flash size (maybe 4MiB or 8MiB)
  • ram size (maybe 16MiB)
    • Again, through the grapevine, it's been said that 8MiB of ram would be enough. Anyone with an intimate knowledge of rockbox care to confirm this? Yes, it will be enough for a flash based player, but not for hard disk. -- LinusNielsenFeltzing - 03 Feb 2008

NOTE: The following list is NOT final yet!!! This link will show you a list of parts that will be used on one of these boards so you can quickly add them to an order from Digikey. Don't order anything yet!!!

operation

Rockbox will be stored in SPI flash and be copied to ram upon bootup.
  • Anyone with knowledge of the inner workings of Rockbox know if this is feasable? We can always slightly modify rockbox so that it saves configuration changes (or possibly a database, but that should probably be stored on the SD card in question instead) to the serial flash after a config change. The point is that there's no file system on the spi flash, so will Rockbox work? We could have the Rockbox bootloader at the start of the serial flash and another binary chunk that's an image of a FAT filesystem that contains the rest of Rockbox (besides RoLo) and then just pretend that the block of RAM that's a copy of this image is equivalent to the mass storage device that the Rockbox files would normally be served from. Easy / difficult to implement this way?

The 2 SD cards will show up on the computer as usb mass storage devices.

hurdles

  • One hurdle to overcome is that right now, the main developer is using the freeware version of Eagle which is limited to 2 layer boards. He has access to a copy of the licensed version, but he's not sure whether it's the 2-layer version or the 4-layer one.
  • For the finished, commercial mp3 player version, we would need to send a couple to the FCC (along with some $) and get them tested for radio emissions before this step, at least in the USA.
  • Also we would probably have to license thompson's/frauhoffer's mp3 codec patent to do this without fear of lawsuits (although we could work around this by offering a version of the player that doesn't include the mp3 decoder plugin).

developer profiles

MattAndrew is the Rockbox fan who is undertaking the design (schematic capture and board layout) and fabrication and assembly of this circuit board as the final project for an electronics class (Spring, 2008). He read this post in the forums 6 months ago and the ideas slowly seeped into his brain and this project is the result. As a precursor to this project, MattAndrew's last semester's project was a clock based on an arm7 and an oled display. pictures and code and blog

JorgePinto - EXPERIENCE: I work in a small company that develops simple electronics circuits with LEDs and AVR 8 bits. I CAN HELP IN: I have some limited knowledge in analog electronics and in GCC-AVR for 8 bits, I will be able to do some drivers for hardware. MOTIVATION: I love music, I use Rockbox and love it wink smile I would like to have a fully Free/Open hardware player for Rockbox, without DRM; I would like to have a player for quick and simple share music files with my friends; I want to learn working with 32 bits systems with GCC.

Some parts of the basic design itself (like the audio CODEC for instance) were chosen by others, and the discussion in the forums/IRC/instant messaging has helped this project immensely.
Edit | Attach | Print version | History: r33 | r32 < r31 < r30 < r29 | Backlinks | View wiki text | More topic actions...
r31 - 10 Feb 2008 - 02:05:31 - MattAndrew

Parents: RockboxPlayer
Copyright by the contributing authors.