A few AS3525 questions...

Hello all.  While I am new here, I am no stranger to the world of portable electronics or integrated circuitry.  I am certainly not a professional or even a real guru, but I am familiar with how such things work and learn quickly.  Anyway, I came across an interesting article relating to the main SOC that powers our Fuze’s, the AustriaMicroSystems AS3525.  Here’s the link

Anyway, a few questions regarding the information in that article.  All of these questions are referring strictly to the hardware potential, as future FW versions or possibly upcoming RockBox builds could, theoretically, unlock any features the hardware is capable of.

  1. Does this actually mean that the chip runs Linux, or is capable of it?  Or just that the core logic is Linux-based?  What exactly do the Linux references mean, and does anyone know what benefits this may have?  Say, is there a possibility of running linux-based code, or even a simple linux build on our Fuze’s?

  2. I understand that this chip is capable of 3 different audio outputs, with one optimized for headphones (which presumably is what comes out of the headphone jack), another optimized for stereo speakers, and a basic line-out.  I’ve read some of the threads involving line-out possibilities, and I would simply like to know if either or both of the other 2 outputs is usable in any way on our Fuze’s.  Is there a pin connector allowing output of true line-out or stereo speaker optimized signal, and are these features even enabled in this application?  

2a) If so, I understand that the headphone jack is directly attached to the mainboard, is there anyway to switch outputs through the jack itself between the three?  If possible, it would be great to unlock such a feature in a future FW, allowing you to switch between headphone output, speaker optimized for a basic speaker or stereo setup, and line-out for a high quality system.  Of course I realize that this, like everything else, is entirely dependent upon hardware configuration, and honestly this possibility seems a bit unlikely…

  1. Lastly, I notice that this SOC is capable of running flash, as well as various Nintendo emulators.  I wonder if the hardware in this particular application is capable of running flash based games (maybe written for linux?) or even the Nintendo emulators (using the wheel as a d-pad, and the center and home buttons as a and b…).  

I realize that those are fairly complex questions, and being that they relate entirely to the hardware potential, not what is possible with the current firmware, I don’t expect many people to know for sure.  But if you do know or suspect anything, I’d love to hear what you think.  Or if any SanDisk employees want to share what they know or are allowed to say, I’m sure we’d all love to hear it!

All hail the AS3525!!

More details on the AS3525 can be found here.

The limitations are what is connected to the SOC pins on the motherboardand and what is programmed to operate. Lineout is available on external connector pins 27 and 28 as used by the Griffin dock, but must be hardware enabled. I’m currently working on a lineout cable to plug in without opening the player and modding it. I can get lineout with an internal pullup jump. Switching the headphone jack to lineout would require some heavy hardware modding with switching transistors and trace rerouting. I doubt the speaker out has any connections on the fuze as it would ■■■■ the battery down quickly with the 500ma output.

Would be nice if someone built a player with the full capability of this chip, but it will need well written firmware to run correctly. Maybe Sandisk can hire a firmware writer from iRiver to do it.

I am impressed. Though I know nothing about the hardware at the chip level, what OP described sounds like company

secret. If I were a Sansa employee and replied to OP, I could be fired. Good luck to your effort.

While the info is confusing and a bit hard to find, it is freely available out there on the internet.  Not to mention that the article seems to imply that HHTech, a Chinese company, commissioned Austria Microsystems to build the chip, or at least had a hand in its development, and that article is dated March of 2007.  From what I can tell, AMS marketed this chip at the component level to all manufacturers, and Sandisk simply chose it due to the fact that it has more than enough power and features for what they wanted in their next generation of PMP’s.  So any discussion of the hardware features of the chip itself should be free game for anyone.  I do understand that specific hardware and firmware kernel discussion would NOT be information employees could share, due to them not wanting their FW to be hackable or even replaceable, thanks to the DRM licensing fees they had to pay, among other things.  Yet hopefully they are willing to discuss what type of features the hardware itself is capable of, due to internal components, pinouts, etc, and would only need to be enabled through firmware.  They may not wanna get our hopes up about a possible feature that’s far off or they don’t wanna give us, so I guess we’ll just have to wait for one of them to chime in and see.

In the mean time, thanks for that link, if anyone else has any other relevant info or links pertaining to this SOC, throw it up!  I’m always very interested to know exactly how my gadgets work and what’s in them, and now I’m on a real kick about this versatile little SOC!  

And BTW, thanks for the info about the line-out, good to know that it actually is there.  So you’re saying that its active on pins 27 and 28, all you need to do is make a cable?  Or does it only work when its docked, which means its also sending it straight to the dock’s amp, so we can’t really get line out anyway?  Even if it is the second one, seems that you could simply activate those pins that signal its docked, and run the line out from there.  Alternatively, you could probably cut open the $15 Griffin dock, and separate the line-out before it goes to the amp, though this is nowhere near as convenient as a simple cable…  But definitely keep us updated on your progress!

@cruiserdude wrote:

  1. Does this actually mean that the chip runs Linux, or is capable of it?  Or just that the core logic is Linux-based?  What exactly do the Linux references mean, and does anyone know what benefits this may have?  Say, is there a possibility of running linux-based code, or even a simple linux build on our Fuze’s?

 

  1. Lastly, I notice that this SOC is capable of running flash, as well as various Nintendo emulators.  I wonder if the hardware in this particular application is capable of running flash based games (maybe written for linux?) or even the Nintendo emulators (using the wheel as a d-pad, and the center and home buttons as a and b…).  

From my knowledge of microcontrollers and the available information on the AS3525, things are as follows:

  • the AS3525 is, in principle, capable of doing these things.

  • it has, however, only 320KiB RAM on-chip. While the RAM seems to be expandable with the AS3525s built-in memory controller, I don’t think that the Fuze has additional RAM. Judging from the screenshots in AIBs Fuze Disassembly, the Fuze has only the microcontroller and one chip for the Flash memory. Without additional RAM, it seems unlikely that the Fuze can do more than run a tightly written firmware. The systems HHTech talks about probably use external RAM for the AS3525 to enable all their functionality.

  • the clock frequency on the Fuze may be lower than the maximum the AS3525 is capable of, to reduce power consumption and thus increasing running time. This would limit the ability for performing specific  tasks (running an emulator, handling 25FPS video, adequate Flash perfomance, etc.). Again, HHTech may run the AS3525 at the limit and thus make it possible to do things the Fuze simply can’t due to hardware limitations.

So I think it’s rather unlikely that we’ll ever see any of this software on the Fuze, even if the Rockbox team should reverse engineer all technical information of the Fuze.

Furthermore, the references to Linux are to embedded Linux, not any desktop Linux distribution. Embedded Linux is optimized for running on small devices and is very stripped down. It is basically only useful for running programs specially written for it, but it’s not useable as a normal Linux version. Even if you’d get embedded Linux to run on the Fuze, you’d probably only have the command line… which would be bit hard to use with the Fuzes wheel. :wink:

Message Edited by Darhak on 11-22-2008 11:03 AM

Just run Rockbox beta on it. You must have a V1 Fuze, though, or it will not work. The easiest way to check is to go into system settings, info, and the firmware should start with V01. If it starts with V02, rockbox loads, but you can’t do much with it.

The Fuze has 8MB of RAM.

8mb RAM for a player ? for a player that can read memory cards with a capacity of 8Gb ? and also videos ? In the future, they will need to add some more not to make the player freeze when reading from bigger capacities… right ? :slight_smile:

@sorinodc wrote:
8mb RAM for a player ? for a player that can read memory cards with a capacity of 8Gb ? and also videos ? In the future, they will need to add some more not to make the player freeze when reading from bigger capacities… right ? :slight_smile:

 

The old e200v1 had 32MB of RAM.  The trend is towards lower memory on embedded players, since its cheaper and you don’t really need more then 4-8MB or so for a typical color screen player like the Fuze.   

actually, if i would have a BIG database file with previous records … i would say that 8mb will not be enough for a total capacity of… let`s say 48Gb… do you agree ?

@sorinodc wrote:
actually, if i would have a BIG database file with previous records … i would say that 8mb will not be enough for a total capacity of… let`s say 48Gb… do you agree ?

No… RAM acts merely as a cache for ACTIVE information… this is the file you are playing at that second. Any further information (IE Play count) would be stored in the actual hard memory of the player just like Id3Tags, and Album Art. 8mb is more than enough. Dont forget as technology advances we will need less RAM, because the natural progression would lead to player hardware that can handle more information quickly and in turn clear the cache and refill the ram at higher rates, or not need ram at all.  

@conversionbox wrote:


@sorinodc wrote:
actually, if i would have a BIG database file with previous records … i would say that 8mb will not be enough for a total capacity of… let`s say 48Gb… do you agree ?


No… RAM acts merely as a cache for ACTIVE information… this is the file you are playing at that second. Any further information (IE Play count) would be stored in the actual hard memory of the player just like Id3Tags, and Album Art. 8mb is more than enough. Dont forget as technology advances we will need less RAM, because the natural progression would lead to player hardware that can handle more information quickly and in turn clear the cache and refill the ram at higher rates, or not need ram at all.  

 

True, but part or all of the database would be in RAM during navigation, it’s still a factor. Now that I think about it…I’d bet that the whole database is in RAM during navigation and that’s where the file limit really comes from.

@sorinodc wrote:
actually, if i would have a BIG database file with previous records … i would say that 8mb will not be enough for a total capacity of… let`s say 48Gb… do you agree ?

 

No, that doesn’t really make sense.