Maker Faire: Make open source MP3 player & more
Recent Entries
- BlueSMiRF found in credit card sniffer
- Mystery iPhone musical instrument - World's most expensive ocarina
- Stained glass d20s
- CRAFT Thanksgiving roundup
- 3D renderings of the Mandelbrot set
- New in the Maker Shed: Microbe Motel kit
- Science through graphic novels
- Tiny solar-powered brass engine in a wineglass
- Maker Shed kiosks at Fry's
- New hackerspace in Chicagoland: Workshop 88
Comments
Oldest comments listed first.
Leave a comment
Subscribe to MAKE Magazine!
Subscribe today, save 42% and get web access to MAKE free. MAKE Digital Edition is available only to subscribers.
$34.95 / 1 year
(4 Quarterly Issues)







































The Daisy MP3 player is pretty cool, it was easy to build. However, the source code is open but not accessible. It's pretty disorganized and apparently not designed with much modification in mind...especially since it's written in a version of C that requires a commercial, non-free compiler. That's probably why I can't find an example of one person who's actually modified the firmware for it. I'd try, but I don't have the time to reverse engineer everything.
Reply to this comment
@GarrettM - eventually i think we'll move to avr or something else, but for now this is what we have. if you have any questions about the code or other things you can email me and we'll get you going.
Reply to this comment
That's good to hear, Phillip; I'm turning into a pretty big fan of the AVR chips since I use them every day. There's a full-featured GCC for them, and the programming hardware can be a few wires + DB25 connector. They're great microcontrollers to use with a Linux development platform. It should be pretty easy to reconfigure the PCB layout for a similar AVR IC, maybe throw a real open-source Daisy project on Sourceforge.
As far as the current Daisy code goes: the above comment was just my opinion, and others may have a different perspective. I happen to have CCS compiler but I don't really have questions about the code, I can read it and see what's going on; it just doesn't seem very compartmentalized to the point where you can change one thing or add something without having to rewrite significant portions of existing code. Again, only my opinion.
Reply to this comment
all good, we had to start somewhere, we'll always work to improve.
Reply to this comment
Hi folks, this is Raphael, the Daisy designer. I just wanted to give some illumination to why I chose to do things the way I did.
I chose the PIC because that's the most popular chip on the market by a huge margin, and also because (at the time) I found it easier to work with. The PIC has got a lot more horsepower than the AVR. An AVR can't run nearly as fast at 3.3 volts. I know it's supposed to run 1 instruction per clock while the PIC takes 4 clocks, but most of the instructions are useless alone, so most of the speed gains that were promised just don't materialize. Also the PIC allows me to keep the circuit simpler because I didn't need to add level shifting electronics to the board.
The next gripe is that I used a commercial compiler. CCS is the cheapest one available for a PIC, and I think it's really good. There are lots of useful libraries and it's pretty much bug free. It was a judgement call I had little chance of avoiding. (Can somebody please write a nice GCC for the pic already? What's taking so long?)
Now my code sucks, huh? Well, gimme a break! I went to art school! I didn't even finish! Ok, really I wouldn't mind doing a complete rewrite. I think it's getting to be about time. The code works very well and is fast, functional and free. But it's kind of insanely laid out, I admit. Somebody do a better job than me and I'll put it up on my site! Show me the light! And I know you didn't say it "sucks", I'm just being dramatic... I'm sensitive!
Sourceforge is like a big scary cave of mystery to me. Please somebody explain to me how that thing works.
Now, having covered my ass, the big statement:
I WILL do an AVR version!
OK already! Before this winter. It will be faster, better, cheaper. I'm going to kick it like NASA in the 90's! But instead of exploding on the launch pad it's going to ROCK! BE AMAZED!
Anyway, thanks for the comments GarrettM. Sometimes it takes a few bits of constructive criticism to get a lazy maker going. I won't let you down!
-Raphael
Reply to this comment
Hi Raphael. :)
Don't get me wrong, the code is functionally great. The Daisy offers a lot of built-in features that commercially-available players will never offer. A lot of people will use the Daisy and never need to change the firmware beyond what it already offers. And it's much more than I would have completed, much less attempted, if I'd studied art instead of engineering. Cheer up...it works! And the fact that you readily admit it could be organized differently is encouraging.
In my own experience and based on some testing I've seen around the internet, I'm not convinced that PIC is unilaterally faster than AVR at 3.3 volts. Regardless, I'm certain that any speed difference will be slight enough to be unnoticeable in the current function, which is a user interface processor and data arbitrator for SD and the MP3 decoder.
Sourceforge is easy, you work on the files normally, but everyone can see what you've saved. It also helps organize the files, lets you mark various revisions and creates a sane way to track parallel development paths. If you get a Sourceforge project going for the new Daisy, I'll be sure to drop in.
Want some fun ideas for Daisy 2? OTOH...LCD interface (Nokia graphics LCD, character LCD), USB Mass Storage support (check FTDI Vinculum...I have a dev unit a sales rep loaned me at Maker Faire, very cool stuff), RS232 control and filename/ID3 readback, Ethernet web radio streaming (Lantronix Xport?), realtime clock and scheduled playback, etc. Probably none of this is practical to include in the base MP3 player, but are examples of what can be done when the development path is opened up a bit.
Reply to this comment