[spongezone]

I'm not sure it's worth placing power efficiency as a main concern if the other goals of the project are audiophile quality and high capacity 2.5" hard drives. If it has a 2.5" hard drive in it, it's already not exactly portable or power efficient, so you might as well stick a giant (~6-8 AA) battery pack onto it and use a more powerful, more readily available CPU like an Xscale (or an older StrongARM).

Apparently my take on this project is not quite the same as most other people's.

 

[threepointone]

hm... there is definitely a bit of confusion on exactly what everyone means by DAP. I don't know about everyone else, but an audiophile quality DAP has been on my todo list for a while, and I've already been working on plans for a DAP based on the scf5250. One main reason I'm using the SCF5250 is that it was designed for audio--it has a built-in SPDIF interface, flash/ide memory interface, and CD-ROM decoding/interfacing (probably won't use this, of course). It also appears to be very flexible with the I2S clocking; the maximum frequency is 1/2 (or 1/3, but probably a typo in the manual) of the system clock, which would put the maximum I2S clock rate in the ~<10Mhz range. Correct me if I'm wrong (I haven't done too much research on I2S, I admit) but a worst-case (or "best"-case) 24-bit, 192kHz digital audio signal would only need a 4.6Mhz clock, so this is definitely fast enough.


Of course, as a group, we can create something entirely different. If this indeed is a non-portable project, there's nothing wrong with an XScale; I just personally know little about the platform.


Following what the OP said, I think we should all assume that whatever we're working on is simply an audiophile DAP without a strong emphasis on portability. I'm still not sure exactly how "non-portable" it would be--will this be completely non-portable, like a speaker amp/home cd/dvd player or will this be somewhat portable (PIMETA-ish sized, and can run off battery power if necessary?)

After we figure that out, we should probably begin to outline the basic features we'll be designing into this DAP, what software we plan to run on it, and decide on a hardware platform to work off of. So far we've got XScale, (strongARM?), ARM, ColdFire, and. . .I'm sure I missed something there.

There's also the possibility of doing the whole thing with minimal complexity in terms of software, and just make it play WAVs. We can back down to that plan if we really can't pull something cooler off

 

[threepointone]

AAAHHHHHHHAAAA!!!!!!!! Two days of searching and I've finally found it.
DIY Coldfire BDM programmer for <$250 (or rather, <$10!!!)

http://forums.freescale.com/freescal...=624&jump=true

Looks like I'm really going to get this project soon (at least mine; as I explained above, my own project isn't necessarily what everyone else has to do). I'm stuffing some new ICs into the eagle library and starting to remember why I hate eagle so much. . .

btw, this also means that if any of you have bricked your iriver with rockbox, it just got a whole lot cheaper to repair it =)

 

[Cauhtemoc]

Quote:

Originally Posted by threepointone hm... there is definitely a bit of confusion on exactly what everyone means by DAP. I don't know about everyone else, but an audiophile quality DAP has been on my todo list for a while, and I've already been working on plans for a DAP based on the scf5250. One main reason I'm using the SCF5250 is that it was designed for audio--it has a built-in SPDIF interface, flash/ide memory interface, and CD-ROM decoding/interfacing (probably won't use this, of course). It also appears to be very flexible with the I2S clocking; the maximum frequency is 1/2 (or 1/3, but probably a typo in the manual) of the system clock, which would put the maximum I2S clock rate in the ~<10Mhz range. Correct me if I'm wrong (I haven't done too much research on I2S, I admit) but a worst-case (or "best"-case) 24-bit, 192kHz digital audio signal would only need a 4.6Mhz clock, so this is definitely fast enough.

Remember that you have to transfer two channels. You would need at least 9.216 MHz for 24 bit/192 kHz audio.

Quote:

Originally Posted by threepointone After we figure that out, we should probably begin to outline the basic features we'll be designing into this DAP, what software we plan to run on it, and decide on a hardware platform to work off of. So far we've got XScale, (strongARM?), ARM, ColdFire, and. . .I'm sure I missed something there.

You need to make your own software. Porting an already working firmware is way more complicated than creating something from scratch. Trust me, I've done it.

Quote:

Originally Posted by threepointone There's also the possibility of doing the whole thing with minimal complexity in terms of software, and just make it play WAVs. We can back down to that plan if we really can't pull something cooler off

You are all underestimating the effort needed for a project like this. You should start with something as simple as posible and move up FLAC once you have something that works.

Quote:

Originally Posted by threepointone AAAHHHHHHHAAAA!!!!!!!! Two days of searching and I've finally found it. DIY Coldfire BDM programmer for <$250 (or rather, <$10!!!) http://forums.freescale.com/freescal...=624&jump=true Looks like I'm really going to get this project soon (at least mine; as I explained above, my own project isn't necessarily what everyone else has to do). I'm stuffing some new ICs into the eagle library and starting to remember why I hate eagle so much. . . btw, this also means that if any of you have bricked your iriver with rockbox, it just got a whole lot cheaper to repair it =)

That programmer is of little use to you. The embedded series of ColdFire processors (SCF5250 is part of this series) does not require a programmer per se, they have an instruction cache and run all code from an external EEPROM. Any serial EEPROM programmer would work (for example this one costs a whooping $5).

 

[threepointone]

I'm reading about the instruction cache right now, but I'm quite amazed that the rockbox dev team didn't even think of doing that and instead dumped their money on a $250 BDM. Actually, now that I think of it, the <$10 BDM has debugging capabilities, which is something I think would be quite necessary for the development process.

I admit, I do have a tendency to underestimate things, but I still think it's better to try porting the rockbox. First of all, rockbox is a very unique piece of firmware: the development process has always been "backwards," in a sense, as rockbox has always software designed to work on hardware, the other way around. Additionally, rockbox has six years of code behind it--the first couple years, of course, were relatively quiet but the iriver port (based on the scf5249) still started in 2004, three years ago. It would take a very, very long time for us to start a piece of software from ground up to reach the abilities of the rockbox.

Porting will definitely take quite some work--I'm expecting it to take up to the whole summer and a bit more. I still think it should be much easier porting the rockbox on a scf5250 platform, which it already runs on, than writing an entirely new firmware--looking at the project history for the iriver h3xx porting, it appears that many of the basic rockbox software components were successfully ported without any modification. Of course some of the software components which relate to the new external hardware had to be modified, such as the new color LCD. A significant portion of the initial development time for rockbox involved identifying all the components on the board and figuring out how everything was interconnected (on a 4+ layer board. . .not easy) and then trying to obtain all the datasheets. Now, however, we will know everything about the hardware, which should again reduce the amount of time it will take. In the end, I think it's more worth it to try porting the rockbox.

 

[Danielj]

As for form factor... i was thinking last night and looking at my 120gig portable IOmagic HDD which case dimens of about 3x5x.5 inches AS for our dap I was originally thinking something along the lines of mac mini size or the other small form factor min pcs. Looking around the house, trying to visualize a form factor for a laptop sized drive, I spotted a pile of vhs tapes next to my dvd player.. Yes I thought, this is the right shape; easy to throw in a bookbag or suticase. Could be layed flat or on its side for usage; external walwort powered. Course the actual vhs tape size may be a bit too thin and not quite wide enougt to place a drive in. But i like the form factor.

3.1 is this something too small for what you are planning? Around 5x8x1.5 in....about four times the size of the ipod.

 

[threepointone]

size seems workable. I haven't figured out exactly what DAC/power supply design this thing will use, though, and as with everything audiophile, they might take up quite a bit of space.

What kind of display should be used? nice & simple monochrome graphic LCD, something simpler, or something better?

I did a lot of research on this last year online, and here's a general idea of how easy for DIYers to obtain various LCDs (just a little note: by small, I mean small enough for to be portable, as I was thinking in terms of a portable DAP while I was looking)

monochrome character displays: really easy, they're everywhere, and easy to find. There's some pretty nice ones with inverted colors, blue blacklight, etc. . . Generally, they're pretty big for a portable DAP, but I'm sure they should fit snugly on this DAP. Not very high resolution density, however.
monochrome graphics displays: somewhat more difficult to obtain. Pretty much the same as above.

tft color displays: usually difficult to find, especially for smaller sizes (including as small as our DAP). DigiKey sells a couple, but they're overpriced and a bit too big for 1.5". Sparkfun also sells a nice PSP LCD, but it's also too big. After that, there's pretty much the cellphone displays and camera displays. The only (possibly) stable source for these displays is sparkfun (http://www.sparkfun.com/commerce/pro...oducts_id=569), which has a 1.2"x1.2" nokia display with data. I think a slightly wider display would be nicer, however. The only other sources for color LCDs would be ebay or old cellphones, which we can't rely on.

OLCDs: even though they're new, it turns out that they can be a bit more accessible than color LCDs. Digikey stocks them at reasonable prices (most expensive I saw was $30, most of them ~$10 ea) Sparkfun also has an OLCD which seems to fit and is higher resolution than any of those digikey stocks (http://www.sparkfun.com/commerce/pro...roducts_id=712) Unfortunately, it seems to have been OOS for a while.

Note that I haven't gone over the driving requirements of all the display types yet.

 

[louilouinovo]

I am not for a portable Dap, I would prefer for a desktop Digital "audiophile" player
with HDD and USB.

In my opinion, no need to include a DAC, however the system must have connector to connect an external Dac or an nternal alien dac inside the enclosure fro example. It can ba a choice for the diyer.

Quote:

Originally Posted by threepointone /img/forum/go_quote.gif the MCF5250 happens to come in a LQFP package

There is a LQFP 144 Universal prototyping boards for sell at http://www.poscope.com/ (click on product PoTQFP)

You have mentionned the MCF5250, it seem that it is no longer manufactured (?), but the Sfc5250 can handle Flac and has USB.
http://media.freescale.com/phoenix.z...794&highlight=

 

[labmat]

I think thats the perfect size for a first generation Audiophile DAP; It makes perfect sense to start a little larger and less portable and then pair down the size of the player with subsequent design revisions. I would think the the first generation could operate similarly to a PPA wallwart power with a separate battery pack at first and then migrating to an internal Lion battery and charger later.

Quote:

Originally Posted by Danielj /img/forum/go_quote.gif As for form factor... i was thinking last night and looking at my 120gig portable IOmagic HDD which case dimens of about 3x5x.5 inches AS for our dap I was originally thinking something along the lines of mac mini size or the other small form factor min pcs. Looking around the house, trying to visualize a form factor for a laptop sized drive, I spotted a pile of vhs tapes next to my dvd player.. Yes I thought, this is the right shape; easy to throw in a bookbag or suticase. Could be layed flat or on its side for usage; external walwort powered. Course the actual vhs tape size may be a bit too thin and not quite wide enougt to place a drive in. But i like the form factor. 3.1 is this something too small for what you are planning? Around 5x8x1.5 in....about four times the size of the ipod.

 

[labmat]

Quote:

Originally Posted by threepointone /img/forum/go_quote.gif OLCDs: even though they're new, it turns out that they can be a bit more accessible than color LCDs. Digikey stocks them at reasonable prices (most expensive I saw was $30, most of them ~$10 ea) Sparkfun also has an OLCD which seems to fit and is higher resolution than any of those digikey stocks (http://www.sparkfun.com/commerce/pro...roducts_id=712) Unfortunately, it seems to have been OOS for a while.

I vote for one of those

 

[threepointone]

Quote:

Originally Posted by louilouinovo /img/forum/go_quote.gif I am not for a portable Dap, I would prefer for a desktop Digital "audiophile" player with HDD and USB. In my opinion, no need to include a DAC, however the system must have connector to connect an external Dac or an nternal alien dac inside the enclosure fro example. It can ba a choice for the diyer. There is a LQFP 144 Universal prototyping boards for sell at http://www.poscope.com/ (click on product PoTQFP) You have mentionned the MCF5250, it seem that it is no longer manufactured (?), but the Sfc5250 can handle Flac and has USB. http://media.freescale.com/phoenix.z...794&highlight=

You're right, sorry about that, I can't ever get scf and mcf straight! I mean scf5250, and if I slip up again and say mcf5250, i still mean scf5250 =)

I haven't gotten to review the details of the USB built-in to the scf5250 (I really can't stand reading datasheets online, and I'm waiting for freescale to ship them on paper), but I get this feeling it only has low-speed USB. We might need an external chip to handle the hard drive access (I know most of the dap schematics I looked at used one).

I'll look into that prototyping board and I'll see if it's necessary. I'm currently working on a high speed, high accuracy pcb etching system, so I might even make a prototyping board myself =) BTW, sparkfun just posted a tutorial on surface mount. Watch the video; these guys are amazingly fast! scroll to the bottom with the qfp(?) IC

Since the scf5250 has a built-in SPDIF out, a digital output would be relatively easy to implement, if desired. I'm don't know about the audiophile design constraints when it comes to SPDIF, however, and I suspect an onboard SPDIF transceiver might not be good enough.

Also, a side note--currently, if we're going to use the scf5250 chip, since the bdm module is so cheap, I might be able to design it onboard--that way, you can easily plug in the DAP and reflash the firmware if something seriously goes bad or even debug/customize/modify/create your own firmware.

just caught an error from before--if anyone wants to be nitpicky, I meant OLED, not OLCD

 

[error401]

Quote:

Originally Posted by threepointone /img/forum/go_quote.gif I haven't gotten to review the details of the USB built-in to the scf5250 (I really can't stand reading datasheets online, and I'm waiting for freescale to ship them on paper), but I get this feeling it only has low-speed USB. We might need an external chip to handle the hard drive access (I know most of the dap schematics I looked at used one).

The SCF5250 doesn't have USB at all (host or device), though it does have pretty much everything else that would be required. There's an onboard ATA controller (for CF or IDE) that just needs a bus buffer, so hard disk access should be relatively trivial. Flash is easy too: there's an onboard SD/MS controller. Toss in a few DMA channels, a fast 68K CPU, tons of available GPIO and possibly built-in I2S and this looks like the perfect chip for this application. You'll probably need external RAM though, but with 16MB costing around $2 I don't think this is a big deal, aside from the extra routing/difficult soldering required.

Even though this sounds simple, I don't think it will be. You've still got to integrate quite a few major components (at the very least, SoC, storage and DAC) off-chip, as well as figure out all the onboard components.

I'm not so sure that starting from scratch is the best way to go about the software though. RockBox is all C except for the optimized decoders (and I believe there are C fallbacks for architectures that don't have optimized code), and thus should be relatively easy to cross-compile. It's also (now, anyway) well set up for porting, from what I've seen it's fairly easy to add a new arch. The biggest problems seem to be getting the data format for the LCD correct, the rest mostly seems to be just mapping the registers in the header files.

Another option would be to start with uClinux and write drivers for all the integrated hardware that isn't already supported (and that's needed, which shouldn't be much, it looks like most of it already works). This really shouldn't be too hard to do, and you then have access to most Linux software. Implement /dev/dsp, and you're set as far as basic functionality goes. Then you just need to write a user interface, profile code and rewrite the core decoder loops in 68k assembly and you're golden.

Quote:

Also, a side note--currently, if we're going to use the scf5250 chip, since the bdm module is so cheap, I might be able to design it onboard--that way, you can easily plug in the DAP and reflash the firmware if something seriously goes bad or even debug/customize/modify/create your own firmware. just caught an error from before--if anyone wants to be nitpicky, I meant OLED, not OLCD

As was mentioned, this chip can boot directly from attached memory on the bus, or even from IDE. Probably a bit of extra work to figure out how the image needs to be configured, but likely worth it for ease of testing. You'd have to read the programming manual to decide if this is feasible or not, but I suspect it is. Much cheaper to mass produce with a little ROM bootloader that boots from Flash than it is to program the big SoC for every unit sent out.

 

[threepointone]

Quote:

Originally Posted by error401 /img/forum/go_quote.gif As was mentioned, this chip can boot directly from attached memory on the bus, or even from IDE. Probably a bit of extra work to figure out how the image needs to be configured, but likely worth it for ease of testing. You'd have to read the programming manual to decide if this is feasible or not, but I suspect it is. Much cheaper to mass produce with a little ROM bootloader that boots from Flash than it is to program the big SoC for every unit sent out.

I thought this was more of a DIY project rather than a complete ready-made product. The built-in BDM was really kind of in the DIY philosophy--allow anyone to easily modify the firmware as they wished without hardware getting in his/her way. Of course, to lower costs, not everyone has to install the ICs for the BDM if they didn't want to, and I could send off boards with preflashed EEPROMs (ROM seems so. . .anti-DIY, and I don't know if we'd ever have enough volume for a custom ROM to be worth it) so that no programming is necessary at all.

 

[error401]

Quote:

Originally Posted by threepointone /img/forum/go_quote.gif I thought this was more of a DIY project rather than a complete ready-made product. The built-in BDM was really kind of in the DIY philosophy--allow anyone to easily modify the firmware as they wished without hardware getting in his/her way. Of course, to lower costs, not everyone has to install the ICs for the BDM if they didn't want to, and I could send off boards with preflashed EEPROMs (ROM seems so. . .anti-DIY, and I don't know if we'd ever have enough volume for a custom ROM to be worth it) so that no programming is necessary at all.

Oops, that wasn't what I meant at all, sorry to be unclear. I was just trying to infer that it should be easy to boot from an EEPROM. Since it would be cheaper to use a preprogrammed ROM on the assembly line than programming every ColdFire there must be a facility to do so. I think the benefits translate to DIY as well, though if the BDM is indeed that simple, it may make sense to include it.

 

[louilouinovo]

Quote:

Originally Posted by error401 /img/forum/go_quote.gif The SCF5250 doesn't have USB at all (host or device),

Doc AN2645 (freescale) explain how "Interfacing the Philips™ ISP1362 USB OTG
Controller to the MCF5249, SCF5249, SCF5250"