Peer into the mind of Dan as he tries to build an MP3 Player for his PDA and searches for the next thing in his life be it an electrical engineering job or graduate school.
Well thanks to bit of reading I was able to compile a short program for the AVR based on a sample I got from www.avrfreaks.com. It seems my first attempt was missing the definitions file "8515def.inc". Without this, you'd have to manually enter in all the addresses of the ports and stuff. I'm also starting to finally understand why there's C code with the YAMPP project. Apparently there's a C compiler called avr-gcc (courtesy of avrfreaks.com) that allows you to write C code and it will compile into an assembly file. I'm not sure how fast this would be in comparison to straight assembly. But running at 8Mhz, simple instructions shouldn't lag you down too much.
Writing C code has its advantages, such as being able to create for loops or possibly even nested loops. I haven't found out too much. I'm still trying to weigh the pros and cons of writing "it" in Assembly versus in C. I understand both languages, and it doesn't seem too difficult to do it in Assembly (I'm one of those nuts). Writing the C code doesn't seem too bad. I can see the advantage is probably readability and that you can modularlize all the code.
I'm also trying to understand exactly how the mp3 is streamed to the VS1001K chip. If remember, the data flowed into the AVR and then out to the VS1001K. Its interesting because I'm not sure I want to do it that way.
Well, all blogger problems were finally resolved. It seems as if the pages take some time to reload or to store (like a couple minutes). I thought it would only take a couple minutes. Obviously not :P
I finally finished the first set of photos for the ECHO group. Its quite a lot of work, but then its supposed to be. Removing the backgrounds is easy when its uniform, but unfortunately it wasn't quite uniformed... more speckled than anything else. It took a while but I finally managed to get all the members done. Its quite amazing, these days I can add missing parts to a person's head and unless you knew where to look, you wouldn't notice it. Or cleaning up some simple things. It shocks and amazes me at how much 'power' you can have. At the same time I was thinking, about the possible responsibility and balance between making someone look perfect and someone realistic.
Realistically people are not perfect, at least I know I'm not. Some people can come close in certain departments but not all. So where do you draw the line? Do you erase all their blemishes and have a perfect picture? Is that too much? I want people to be happy with their pictures but at the same time, people should be happy with who they are. There should be an inner contentment and peace that comes from knowing that God loves us all as we are. Besides, if you want this perfect picture, then you have to ask yourself, what kind of blemishes do you see in yourself. Are they hidden deep within you, that are completely obvious to you? Are they shallow and on the surface that all can see, but are a part of you? Does this make any sense at all. I'm not sure. ;)
I seem to be having some problems publishing, as in blogger is not connecting itself to the FTP server. Hmm...
FEEBIE!?! What the heck is a FEEBIE?
Well my observant reader and future self-reader, a FEEBIE is a quantity of money exchange for some goods or service. FEEBIE is the currency used on the planet XC-455, by the Quafifi. Its extremely popular over there and is giving paypal a run for its money.
Either that, or its FREEBIE spelled incorrectly. You pick.
At this time, I would like to point out another fact that I printed, 100 000 read/write cycles may seem like quite a lot, almost too much. Yet this is the lifecycle of the EEPROM on the AT90S8515 and NOT the lifecycle of the Programmable Flash Ram which is closer to 1 000 read/write cycles. Still quite a lot.
I finished building the simple AVR programmer, plugged my cable into the computer, and the chip into the socket AND... nothing. Hmm... according to the YAAP programmer, which I used to quickly detect the AVR, its not there. It failed to detect it, and asked if it was powered. I checked, and of course it wasn't powered. Now that I thought about it, the PIC programmer I used last year had a power adapter plugged into it along with a serial cable. Power... that's what I forgot, power! Now, how much power is enough, and how much is too much? Back to the datasheets...
For some reason or another I couldn't log on to Blogger yesterday night. So I'll just post my stuff this morning!
I got most of my programmer's parts yesterday! The only component that was slightly expensive was the AVR microcontroller itself coming in at $10 a piece.
I got a few other things such as two 27pF capacitors ($0.40/each) and I'm currently looking for the 7.3758MHz crystal. That may have to come from Active. I need the crystal to provide a clock signal for the AVR. Without it, the AVR won't execute its instructions at any regular rate. I n fact I'm inclined to believe it won't even run. So yeah, the clock is kind of important for testing, but not for programming.
I sort of realized that this whole weblog sound pretty dry and boring, i.e. nothing "juicy" but that may change. I'm not sure how, or when but I'll figure out something. I'm not apologizing for it, but I just realized that if someone were to look at this and not know who I was they'd probably think 'wow this Dan guy sure is dry'. Well BLEH to you :P just kidding. For the record though, the main purpose of this weblog is to document the "problems" I encounter while working on whatever projects. I personally don't think anybody outside of the people I know, would appreciate reading about what my friends and I did. Hmm... if there was enough interest I could probably setup a "private" weblog. Maybe later.
I'm still continuing my work on the ECHO CD booklet. The deadline that I sort of set for myself is next Friday, but that includes the whole printing business. I think I've received all the notices as to which pictures to use and which ones not to use-there weren't many don'ts and I'm not going to put horrible pictures of people on there-not on purpose anyways. The toughest part is trying to get inspired to fill up 14 slots of paper. At the same time, you want to meet with the objectives and balance what you want with what they want. I was told to make it simple and elegant design, not overly complex. I have a few ideas but creating the 'right' sort of ripples on a white background is more challenging than I first thought! If I'm allowed to, I'll post it up on the web when I'm done.
That's about it, if you noticed, I'm trying to markup my entries, hopefully to give you a better reading. So far, its very simple markups such as paragraph tags and list tags. Really that's almost all you need to know for learning how to do HTML. Well, that and the link tag, but that's also pretty easy to grasp. the harder parts come from making your design look like the same way you want it to look on EVERYONE's browser. With any luck, time, and patienc, that will eventually happen with the use of stylesheets. Goooooo Stylesheets!
I think I've finally found the right balance between using Dreamweaver (my favourite web design program) and the use of blogger. It wasn't that hard, but I just wanted to get it right. So that all the templates would work properly. I guess this is the main problem with not using frames, or php, or dynamic based content. Technically this is "dynamic" in the sense that I change this weblog everyday but at the same time its not dynamic in the sense that I can change things on the fly. Dreamweaver allows you to use what's called templates. Very handy thing, especially if you combine it with the use of stylesheets you get one giant one-two combo. anyways off to bed.
I was looking at the VS1001K datasheet and found that in their Application note, they built an MP3 player using the AT90S8515. It seems that from the datasheet this little thing can handle 100,000 Write/Erase Cycles. This ought to be more than enough for playing around and then for the actual application. It also has an 8K Programmable Flash RAM which means I can store approximately up to 8K worth of instructions.
Reading further, the AVR device itself uses 3mA on Full Load. Combine this with the VS1001K 40mA full Load, and given a battery source with 1700mA/h I could run these two (with the proper voltage) for close to 40 hours straight! This definitely outlasts the average PDA battery-life of 8 hour. No need to worry about lack of power.
Great! Now, the AT90S8515 from here on in referred to as the "AVR", costs approximately 7.74 USD (quoted from digikey). With our
These are the different types of AVR the simple avr programmer can program AT90S1200 ATtiny12 ATtiny15 AT90S2313 AT90S2323 AT90S2333 AT90S2343 AT90S4414 AT90S4433 AT90S4434 AT90S8515 AT90S8535 ATmega103 ATmega161 ATmega163 Now to find out how many times it can be reprogrammed
Just found out that Digikey doesn't have the FT8U232AM, but they do have a TUSB3410VF which is TI's version of a USB to Serial (90 page spec sheet!).
K so it seems like I've made a few big decisions: 1)Using the VS1001K mp3 decoder ... $25 2)Using an AVR microcontroller ... $3 3)Using the FT8U232AM USB to UART IC ... $8? Hopefully I plan to connect the cable to the FT8U232AM, and from there connect that to the VS1001K decoder chip, and connect the AVR to the decoder chip as well. Not to mention all the other resistor/capacitor/crystals "junk". I think that's all the hardware planning I need to work on for the next few weeks. Software will take more time.
From what I understand, there are a few 'available' mp3 decoder chips that are within the financial grasp of the hobbyists. There's the STA013, the VS1001k, and the MAS series. On the mp3projects.com discussion board, and the YAMPP forum there seems to be a lot of people experiencing difficulties using an STA013. There are many things that seem to detract from its use, such as the fact of needing to transfer a 4K byte file to initialize the chip. With the lack of output ports on the PDA (or PEO as Sony likes to call it) I rather just let the PDA handle the mp3 stream and only the mp3 stream. If I start adding control information such as volume, initialization file, etc. and having the microprocessor route that information I may be over estimating the speed. On the other hand now that I decided to use the USB port to handle the mp3 data stream, I could use the serial port to handle the control information. I think that can be implemented later without affecting the design too much. My current plan is relatively simple. All mp3 streaming comes from the PDA direct to the MP3 decoder and the microprocessor will handle the initializing. That being said, I think that rules out the STA013 for now. That leaves us with the MAS or the VS1001K. The VS1001 has a self-contained DAC, SPI and seemingly everything I need all in one chip. I just need to plug in a few resistors, and capacitors and that seems to be it. The real trick will be to convert the USB stream to a serial stream. I hope this can be done using the USB chip (FT8U245AM) I found earlier. I probably should look at that datasheet. I love my Panasonic KX-p7100 printer-not only is it a laser, but it does 'duplexing' meaning it prints on both sides for you automatically! I can reduce a 60 page spec to around 8 pages :) I just ran into a problem... well not really a problem more of an issue than anything else. The FT8U245AM USB chip transfers a USB stream to Parallel Datastream. This would be good if the any of the above mp3 chips took in a parallel data stream but unfortunately they don't. In fact it seems like the only stream they take is a serial with a clock so... incomes the MAX1661/2/3 chips. A quick google search shows that these chips can change a serial to parallel and vice versa. They also seem to be cheap. I'm wondering how the YAMPP project dealt with the USB data. What exactly are they sending. That's something to look into. I just found that the same company that makes the FT8U245AM also makes a chip FT8U232AM which transfers USB data to a serial or UART data stream. Cool! now if only I can find a distributor...
Since the microprocessor is such a crucial element in controlling the mp3 chip. I have to start turning my attention towards how to properly program such a chip. My current experience in RISC is with a PIC 16XXX series chip. Since PIC programmers seem harder to come by than Atmel (AVR). I think I've decided to go ahead with the AVR type microprocessors. I'm told some AVR chips can be reprogrammed up to 1000 times. Things that I believe I will probably need as a 'just-in-case' measure: *"Brownout detector" this is a simple switch that will only allow current to flow when the voltage is above a safety limit. This is to prevent the microprocessors (and other ICs) from working at voltages below their specified requirements. This prevents "misfirings" and other nasty things. *"Bridge Rectifier", this is a set of diodes configured to prevent someone from "accidentally" connecting the power source in the wrong way i.e. flipping the battery, changing the polarity of an adapter, etc. This is probably just a safe thing to do cause no one likes to smell burning ICs late at night (or early in the morning). So in short current goals: Find a suitable AVR programmer/AVR chip Build the programmer. Code a Test Program to light up a few LED in some pre-specified sequence Run the test. Start to investigate into MP3 chips.
Just saw on the yampp project page that they have a model called the yampp3/USB version which allows you to connect their mp3 player via the USB link. They use a FT8U245AM IC to control the USB link. Definitely worth looking into and seeing how to use it. I just downloaded the spec sheet and I'll look over it. They also have other USB chips Philips ISP1181 or PDIUSBD12 ir PDIUSBD1 which I should also take a look at. I just (finally) came across a simple microcontroller programmer. http://www.myplace.nu/avr/yaap/index.htm Here's the skinny. I'll use a microcontroller to initalize the mp3 decoder chip, and to do whatever I need to do with the USB data stuff. I think it should be fast enough to handle it. I hope. If there's any room left then I'll use it for volume, and bass boost. http://www.mysunrise.ch/users/pfleury/avr-starterkit.html
I can never get used to writing these things-I'm not sure who to address it to but anyhoo on with the show. The first thing to do is to draft a list of "the project's goal". This is the roadmap which I'll be planning on following and perhaps tweaking just a bit. For the most part though the main focus of the project will be for me to build an attachment for my Sony Clie S320 PEO that will decode the mp3 data stream from the PDA and output 'analog' sound. Sounds simple enough doesn't it? I'm planning on dividing the project into two major components: software on the palm, and the hardware. The software will basically search for new mp3's stored on the PDA's memory and then stream it to the output port. The hardware will take the output stream, decode it into audio through an mp3 decoder chip. Right now my main concern is the streaming of the mp3 data to the chip. Palm devices only have a serial output (and also a USB port in my case). Most MP3 designs I have seen on the net use a Parallel port to stream the 8 bits all at once. I'm not sure the serial port can handle it. I think one of the 'intermediate' steps to test the hardware is probably to use the computer's serial port as a test, see if I can stream it fast enough. A quick off-the-top-of-my-head calculation should prove. Typically I can see that my serial port runs at 9600 baud, that's roughly 9,600 bps. A typical respectable mp3 is roughly 128 kbps definitely not nearly enough. I guess that means I'll have to use the USB... darn. Well its not like I'm 'afraid' per se to use USB, its just I have less experience dealing with USB stuff. I know its been done before so it can't be out of my reach-not that I know how to do everything. I'm mainly worried about how to access the protocols on the Palm Pilot to send stuff through the USB port. The next step is to think about how to take in the datastream hardware wise from a USB port.