Skip to main content ↑ ↓
Topic: openHiFi - high grade home music player (Read 49932 times) previous topic - next topic

Re: openHiFi - high grade home music player

Reply #60 –
Is there a big difference between A and M: yes. Read the wikipedia page on ARM at the very min.

NEON is like 3DNow or SSE1/2/3 were for x86.

As for getting a chip that just runs RockBox ASM code. ARM9s would but they mostly are done with external flash for booting. ARM7TDMI probably would but it is dead and probably not a great idea for new designs...
The other general issue is that very very view chips have I2S on them that aren't BGAs.

As I said it is already fast enough :-) I will port it when I have the time. Even if I wanted a full music player I would think only really AAC, MP3, FLAC, OGG, WAV very relevant. I guess some people have things in WMA also.

Thumb is basically 16 bit overhead. If you can get 32-bit ALUs at 16-bit cost why wouldn't you use it? Cortex M0 is targeted at the 8/16 market. Just look at the kill your old micro get a free M0 that LPC is running right now...

Here is a press release stating exactly what I said: http://www.nxp.com/news/content/file_1642.html

0.65 in volume... Yes a ultra tiny PIC/AVR with no SRAM and 6 pins is cheaper in volume still but we are talking about LDO type volume cost here... There is a point were it almost does not matter except ultra high volume.

Windows 8 will be released on ARM... The only real question is where the line between x86 and ARM will end up in complexity. There are perhaps 2 semiconductor process nodes left before CMOS is no longer worth shrinking. At that point Intel's advantage of manufacturing smaller first will be gone. ARM might become ubiquitous (It already is really), but x86 software legacy in business at the very least will maintain it for decades. It will be interesting to see what Intel is like as a company after 2020.

Re: openHiFi - high grade home music player

Reply #61 –
Let me add there would be a ton of options if I could do BGAs but I find fine pitch xQFP hard enough... I can't imagine doing a BGA

EG: SAM9261 would be a great chip to use. But only available in BGA.

The Cortex M4 is pretty much perfect for this application I think but the question is who will release them and when NXP is first in line I think: LPC4327 is quite nice, but it is still in sampling and not production (who knows what it costs...)

Re: openHiFi - high grade home music player

Reply #62 –
http://www.electronicsweekly.com/Articl ... pliers.htm

Very interesting. I would expect 6 months min before tools and channel availability for anything announced now. This sort of thing will probably have to wait for Rev 2. Code other than peripheral code would be comparable if these turn out to be awesome as M4 is like M3 is thumb2. It will cost more though... So if it can be done on the M3 that is still the lowest cost game in town. ARM9 and M4 and all of the A/R will be more money for the same amount of stuff.

There are two companies with M4s detailed. Freescale and NXP... NXP has a M0+M4 while Freescale is just a single M4. Ti has M4s in a A15 SoC, but nothing alone. If Ti releases libraries as nice as for M3 for an M4 implementation more like Freescales that would be amazingly nice to use for any audio application.

The problem is outside of Keil and maybe IAR tool support will be slow to come.

Re: openHiFi - high grade home music player

Reply #63 –
[quote author="brian"]The other general issue is that very very view chips have I2S on them that aren't BGAs.[/quote]There's the rub, then.  I2S and non-BGA are the constraining factors, I'd agree.

Quote
Thumb is basically 16 bit overhead. If you can get 32-bit ALUs at 16-bit cost why wouldn't you use it? Cortex M0 is targeted at the 8/16 market. Just look at the kill your old micro get a free M0 that LPC is running right now...
My interpretation is that a 32-bit CPU with a 16-bit or 8-bit memory interface is not very efficient because it takes at least a couple of memory cycles for every instruction.  32-bit instructions are great if you have 32-bit memory, but you're probably stuck with BGA for 32-bit memory.  It's the external memory interface, not the ALU, that determines the efficiency of the instruction set.  So, Thumb goes hand in hand with the other realities of embedded systems.  If ARM had been able to predict way back in 1983 that they would take off in the embedded world (perhaps on the way to dominating the desktop), then they might have started with Thumb from the beginning.

Quote
Windows 8 will be released on ARM... The only real question is where the line between x86 and ARM will end up in complexity. There are perhaps 2 semiconductor process nodes left before CMOS is no longer worth shrinking. At that point Intel's advantage of manufacturing smaller first will be gone. ARM might become ubiquitous (It already is really), but x86 software legacy in business at the very least will maintain it for decades. It will be interesting to see what Intel is like as a company after 2020.
Don't start counting your "Windows 8 on ARM" eggs just yet.  Windows is complete dog crap, and so are the programs that share that ecosystem.  I don't want to go off on too much of a tangent from the topic of designing a hardware music player, but I want to share some of my experience.  Way back in the early nineties, IBM had desktop PowerPC computers while I was cutting my teeth on the NeXTdimension (with Motorola 56000 DSP sharing the board).  Around that time, I looked into a contracting opportunity to port Windows software like Word and Excel to the PowerPC.  I decided to pass because of the nature of the contracting offer, but I kept an eye on the project.  After approximately two years of effort, they finally gave up without releasing anything.  Windows and its prominent programs are not written to be portable at all.  I suppose some of the bad habits may have been broken since that time, especially since Microsoft was keen on running on PowerPC, but do you see Windows on anything but x86 and x86 clones?  Right now I say Microsoft is just blowing a lot of hot air and making wishful statements.  Do you remember how many times they promised that the next version of Windows would no longer be based on DOS?  They just kept postponing that upgrade, and they'll do the same after they discover that they can't get Windows to run on ARM.

As a comparison, NeXTSTEP supported as many as 5 or 6 processor platforms over time, and a huge graphics program like PageMaker was ported from one processor to another in only 2 weeks.  Not only was the porting task not abandoned in frustration, but the product shipped and made money.  This shows how much the OS and the programming environment and community fosters portability.  OSX inherited NeXTSTEP, and that's why Apple has been able to transition from PowerPC to Intel to ARM and actually ship products.  In fact, until Snow Leopard, both PowerPC and Intel were supported.  Theoretically, the ability to host 6 or 7 different processor types on the same OS is still there.  Apple will ship OSX on ARM before Microsoft ships Windows on ARM.  I guess Apple already is doing this, if you count iOS as similar, but even if they wanted to move their A4 chip to the desktop, they'd have a much easier time than Microsoft.

Re: openHiFi - high grade home music player

Reply #64 –
I think you should read about Thumb more. My understanding is it is the exact backwards of what you think. The instructions are 16-bit and the execution and buses are 32-bit. By making the instructions smaller you compact the code which gives it the ability to fit programs into a 8/16 bit kind of size... Most of the die size being flash and all...

I don't generally think it is a good practice to make blanket statements like "all programs that run on windows are dog crap". I can't say I agree with much you said, but I will leave it at that. I don't think you would listen to anything I would say and it would go even more off topic. I will say one thing though Windows NT ran on Alpha, and Windows server runs on IA64.

Re: openHiFi - high grade home music player

Reply #65 –
[quote author="brian"]I think you should read about Thumb more. My understanding is it is the exact backwards of what you think. The instructions are 16-bit and the execution and buses are 32-bit. By making the instructions smaller you compact the code which gives it the ability to fit programs into a 8/16 bit kind of size... Most of the die size being flash and all...[/quote]You're talking about internal execution and buses, which are surely 32-bit.  The EPI (External Peripheral Interface) can operate in 8-bit, 16-bit, or 32-bit mode.  Looks like SDRAM is limited to 16-bit.  Host Bus is limited to 8-bit/16-bit.  Looks like the only thing 32-bit is the GPIO for interfacing to CPLD or FPGA.  This is all from the Texas Instruments LM3S9B90 data sheet.  Basically, GPIO defaults to something other than EPI, and if you want external memory you have to trade GPIO for EPI.  The less you use for external memory, the more GPIO you have remaining for other uses.

But, you're right that Thumb is mostly about making the code smaller.  This is even though the internal Flash memory seems to be 32-bit.  I think here it's more of a loose correlation between limited pins, limited external bus widths, limited memory sizes, and smaller instruction widths.  I don't think that's exactly backwards from what I said, but it's probably not as directly tied as I implied.

Re: openHiFi - high grade home music player

Reply #66 –
I thought we were talking about the Thumb/Cortex M in general.

If you read the manuals on M3:
http://infocenter.arm.com/help/topic/co ... gahha.html

You will see it is as I said 32-bit bus. Luminary simply choose to support a narrower bus to save pins/reduce package size I expect.

Thumb itself is just an ISA simplification over regular ARM code for compact flash use. It probably simplifies the decode front end on the CPU also, hence the thumb2 only designs in hardware with the M series.

Re: openHiFi - high grade home music player

Reply #67 –
As you suggested, I revisited the Wikipedia article on the ARM architecture.  Under Thumb, it states:
Quote
In situations where the memory port or bus width is constrained to less than 32 bits, the shorter Thumb opcodes allow increased performance compared with 32-bit ARM code, as less program code may need to be loaded into the processor over the constrained memory bandwidth.
That's basically all I was trying to say, but I emphasized it a bit too much.

[quote author="brian"]Luminary simply choose to support a narrower bus to save pins/reduce package size I expect.[/quote]My point is that even when the chip does have the pin count to make a 32-bit bus possible, practical embedded designs often benefit from reducing the bus width anyway, because it reduces the size of the board, reduces the chip count, and/or allows cheaper chips to be selected for external memory.  In other words, a general rule of embedded design is that narrower buses have benefits, and since ARM is catering to the embedded market it makes sense to use Thumb.  Although Thumb is primarily concerned with reducing the code size regardless of bus width, that still goes hand-in-hand with working efficiently on narrower buses.

Quote
Thumb itself is just an ISA simplification over regular ARM code for compact flash use. It probably simplifies the decode front end on the CPU also, hence the thumb2 only designs in hardware with the M series.
I disagree with this statement, if I understand what you wrote.  ARM was originally designed after reading some of the early RISC papers.  One general attribute of RISC is a rather wide instruction word so that every part of the control system has a dedicated bit in each opcode.  In other words, the ideal RISC removes the instruction decoding process completely, by allocating instruction bits to directly control the execution unit.  Thumb adds a layer, so it is the opposite of simplification.  e.g., Thumb only allows some instructions to be conditional, not all of them, because there are no longer dedicated condition bits in the opcode.  Only Thumb instructions need to be decoded, ARM instructions should not need to be decoded.

I suppose in one respect, you could call Thumb-only a simplification compared to an ARM+Thumb implementation, because the combination requires additional circuitry to allow the original ARM instructions to directly control the execution unit when running in ARM mode.  In other words, if you need Thumb, but you don't need ARM, then Thumb-only is a simplification compared to ARM+Thumb.  However, if you compare ARM-only to Thumb-only, then it seems that the only possibility is that ARM-only is simpler than Thumb-only.

Getting back to the topic and your challenges, I sure don't envy your task of finding a chip that has all of the necessary hardware features (I2S, non-BGA) plus has support for the existing FLAC code so that you don't have to port ARM code to Thumb-only.

Re: openHiFi - high grade home music player

Reply #68 –
I think I get most of your points. Thanks for making them more clear.

Thumb-2 isn't Thumb so you know. I think the peripheral bus datawidth for M3 is 32-bit based on the ARM documentations I referenced.

In any case to the main point. USB HOST + I2S + lots of SRAM + not BGA was the task. I looked and looked and looked before I started anything. I had a STM32 based version of this project going, the connectivity line was the only line that had USB Host, and the RAM capped at 48 KB I think, and there was no external memory bus that would map to the CPU address space. The performance line would do that but not the connectivity line. The top of the performance line (XL series) had I2S and more RAM but no USB host!

Atmel had nothing with I2S except ARM9s which were expensive and no longer in production except BGA versions. Freescale had the i.MX233 which seemed perfect for this, until you read the docs carefully. TQFN doesn't have the I2S on it just the BGA!!!! Grrrr. (Plus the i.MX233 is really designed by the looks of it to run an OS not do bare metal development).

It was at this time I found Luminary parts. I had no idea it existed because NXP(LPC)/STM32 ARM chips dominate the enthusiast market and the places I looked for development boards (Olimex etc) with a smattering of AD and Atmel boards. I forget how I even found them. It might have been from looking at the board support in OpenOCD actually because I figured I would need that to do development.

I got a LM3S9B92 board and was amazed by how much simpler it was to write for than STM32. It had Ethernet, USB host, I2S, external memory if you couldn't do it in 96 KB. In short it had everything I was looking for. For now I am using that board to do development, I think the lack of ASM optimization for FLAC is a bump in the road. It will just be more fun. All of the RockBox codecs are done as best they could in C and then if someone wanted to write ASM for some chip it was added (ColdFire and ARM are the only two I have seen).

I expect M4 based media players to be released. This may mean there will be ports of other codecs to Thumb2 within the year...

Re: openHiFi - high grade home music player

Reply #69 –
[quote author="brian"]Thumb-2 isn't Thumb so you know. I think the peripheral bus datawidth for M3 is 32-bit based on the ARM documentations I referenced.[/quote]Thumb-2 is an extension of Thumb, not an unrelated instruction set, so I was just being lazy and typing fewer characters.  As for bus width, it's great that the chips all have 32 data bit pins, but there will always be an advantage in embedded systems to have compatibility with 16-bit and 8-bit memory - fewer chips, cheaper chips, less board space, fewer placement costs, etc.  My point all along is that 16-bit opcodes, while primarily reducing total code size, also make it more reasonable to deal with embedded limitations efficiently.  I think the Wikipedia articles support everything I've been saying.

Quote
In any case to the main point. USB HOST + I2S + lots of SRAM + not BGA was the task.
Thanks for the reminder of the complete list of requirements.  I don't know what the exact threshold for 'lots' might be, but I can certainly see how everything you listed is necessary.  Although it's possible to add a second chip for the USB Host feature, it sure would be a pain to write two different firmwares.  Way better to have one chip that does everything.

I'm currently working on a custom TMS320VC5506 board that I designed around this chip, because it has USB and DSP capabilities.  I could have thrown a cheap PIC on the board with a high-speed serial link to a non-USB DSP, but then I'd be dealing with developing two sets of firmware, plus the added issues of timing between two chips.  Despite the fact that USB is awkward on a 16-bit DSP, it's probably still less trouble than separate chips.

Quote
... I think the lack of ASM optimization for FLAC is a bump in the road. It will just be more fun.
Right on, man!  That's the attitude.  I'm sure you'll learn a great deal about ARM and FLAC, and then I'll be jealous.  Both are technologies that I'd like to learn in depth.  My FLAC coding has only been above the library level, not the interior.

Re: openHiFi - high grade home music player

Reply #70 –
Lots of RAM means enough to buffer a frame of any format I want to support.

Cortex M4 would gives you some DSP stuff plus HS USB for data typically. The only chips in distribution channels are Freescale parts at the moment though (BGA version). In a year they probably will be commonplace. I think people are realizing there are lots of SoC like applications that don't require the full power of what is now in smartphones, and are more cost sensitive. To me it looks like LPC's designs recognize this fact. I will be very interested to see what Ti and Atmel do with it.

Optional things I also was looking for in a chip were: Ethernet/IP and external RAM interface. I can imagine lots of things that you would want internet access for. Having effective unlimited if slightly slower memory is nice :-)

Re: openHiFi - high grade home music player

Reply #71 –
Did you see this section in the FLAC Documentation, 1.2.1?

Embedded Developers

libFLAC has grown larger over time as more functionality has been included, but much of it may be unnecessary for a particular embedded implementation. Unused parts may be pruned by some simple editing of src/libFLAC/Makefile.am. In general, the decoders, encoders, and metadata interface are all independent from each other.
It is easiest to just describe the dependencies:

  • All modules depend on the Format module.
  • The decoders and encoders depend on the bitbuffer.
  • The decoder is independent of the encoder. The encoder uses the decoder because of the verify feature, but this can be removed if not needed.
  • Parts of the metadata interface require the stream decoder (but not the encoder).
  • Ogg support is selectable through the compile time macro [tt:]FLAC__HAS_OGG[/tt:].
For example, if your application only requires the stream decoder, no encoder, and no metadata interface, you can remove the stream encoder and the metadata interface, which will greatly reduce the size of the library.

Also, there are several places in the libFLAC code with comments marked with "OPT:" where a #define can be changed to enable code that might be faster on a specific platform. Experimenting with these can yield faster binaries.

Re: openHiFi - high grade home music player

Reply #72 –
Yes I did, I refer to this section in my post at Fri Feb 25, 2011 12:35 pm.

The automake file is undocumented except for inline comments all of which I read.
Stripping OGG support reduced the library by ~20 KB only out of I think 300K with a full decoder weighing in at 700+ KB without encoder support as well. Basically I spent many hours looking to strip it down and got about 40 K out of 700 out of a functional decoder. I presume that half of the size comes from the linked math library to implement functions like log. In FFMPEG log is done via a look-up table which is much more efficient both in code and memory for number sizes used.

RockBox FFMPEG decoder: ~20 KB library, it is 10-20x smaller. Full program with file system and decoder < 32 KB. Which is less than 1/10 of that of just the libFLAC library. I am sure there is a way to strip it down more but I was tired of wasting my time on it.

And let me assure you it is a total waste of time to use libFLAC. Why? Because FLAC was one of the main reasons a lot of people cared about RockBox, and the decoder was added in 2005. If you look at the change log and bugs you will see there is basically only one, which was 24 bit compatibility with FLAC 1.2.1 in 2007!

I frankly don't see why you seem hung up on using libFLAC, when there is a much better solution for an embedded target in existence...

The *only* reason I will make any attempt to use libFLAC is to avoid LGPL, I'd rather use BSD, but that is the only reason, and right now that reason isn't worth any of my time, as I can link to LGPL just fine and I have made no code changes to the decoder itself.

Re: openHiFi - high grade home music player

Reply #73 –
[quote author="brian"]I frankly don't see why you seem hung up on using libFLAC, when there is a much better solution for an embedded target in existence...[/quote]
I'm not hung up on using libFLAC, it just seems that way to you.

I'm really only interested in making sure you have more options open rather than fewer.  I happened to be writing a utility to use libFLAC and had to dig into the documentation and sources to get some answers, and I noticed a few things that I wanted to pass on in case you missed them.

After seeing the documentation about the OPT comments, I randomly came across an example in the libFLAC source.  The unfortunate fact was that the code uses an #if 1 ... #else ... #endif construct which cannot be used from the command line.  This sort of coding requires the source to be altered, rather than allowing the compiler command-line to select different behavior.  Now that I've seen such an example, I must say that I am a bit disappointed.  It's nice to have a // OPT: comment in the source explaining the two code paths, but it would have been nice to see a little more effort so that this could be accessed without diverging the source.  This last bit is something that I discovered after my last posting, so it makes the situation less ideal than it appears when I read the documentation.

I'll keep listening to hear your progress, and I certainly wish you luck whichever direction(s) you take with the FLAC support.

Re: openHiFi - high grade home music player

Reply #74 –
Thanks RSDIO. You just kept bringing it up :-)

I am pretty happy with the what things are progressing. Having written decode that is doable in less than real time already I am def going to do this project to completion at some point. It probably won't get a board until summer though.