Application: ARM vs Prop
Basil
Posts: 380
Hi All,
This is just a question of curiosity really.
'I had a dream' of a small mobile device with a 1.5"ish oLED display running on a lithium ion battery.
On the display would be 3d graphics, the likes of what you see on some of the new mobile phones.
Lets just say its a mobile phone without the phone bit [noparse]:)[/noparse]
The ARM CPU's are 32bit and seem widely used for this type of application, but the Prop can do more IPS. (150-300MIPSish vs 8 x 160MIPSish)
Would the prop have the same 3d processing power as the ARM CPU's used in these devices?
Im not sure, but maybe the ARM CPU's have built in 3d stuff which makes them better suited...
Could someone please clarify this for me, its bugging me
Thanks!
This is just a question of curiosity really.
'I had a dream' of a small mobile device with a 1.5"ish oLED display running on a lithium ion battery.
On the display would be 3d graphics, the likes of what you see on some of the new mobile phones.
Lets just say its a mobile phone without the phone bit [noparse]:)[/noparse]
The ARM CPU's are 32bit and seem widely used for this type of application, but the Prop can do more IPS. (150-300MIPSish vs 8 x 160MIPSish)
Would the prop have the same 3d processing power as the ARM CPU's used in these devices?
Im not sure, but maybe the ARM CPU's have built in 3d stuff which makes them better suited...
Could someone please clarify this for me, its bugging me
Thanks!
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
It's not all that hard to count the number of grains of sand on the beach. The hardest part is making a start - after that it just takes time.·· Mirror - 15 May 2007
Still, the determinisim of the prop would make it better suited for 3d than an ARM CPU wouldn't it?
Im not familiar with ARM's, just been reading the Overview on ARM's website.
This amount of memory is comparable to that available on-chip with most ARMs, but the ARMs also can run programs from on-chip flash EEPROM which the Propeller does not have (it uses its external EEPROM to load the 32KB shared memory on a restart). The ARMs also can access external memory and bring their memory bus off-chip which the Propeller does not. The ARMs have a lot of I/O devices usually integrated on-chip that can function partially autonomously from the processor. The Propeller architecture assumes that these sorts of I/O devices will actually be implemented in software running on an assigned (arbitrary) cog.
As you can tell, the Propeller and the ARMs are not easily comparable. In many ways, the ARMs are more powerful. On the other hand, the Propeller is simpler, more flexible, and cheaper. A Propeller could replace several of an ARM's built-in I/O devices and provide greater flexibility.
With that in mind you need to move from the simple spec "I want 3D in my pocket" to something more detailed, for example do the 3D objects have to be truly 3D or can they be more like animations fed from an SC card (as per recent super demo). If they are true 3D then how complex do you think the models will be, perhaps drawing something in sketchup and the counting vertices will give you a clue.
Then you can either downgrade your aspirations to match the propeller or go to another IC. Or you could start at the bottom and do some really basic stuff on the prop and get more and more complex until you outgrow it, then propeller 2 comes and you carry on. The time will not be wasted even if you then go to an ARM as you will have learnt all about 3D graphics etc.
Graham
So, the ARM has alot of hardware built in which you could replicate in software on the prop. (eg. The 3D stuff)
Thanks Mike [noparse]:)[/noparse]
Yeah, ive been thinking along the same lines.
Im not sure how far i'd even get with this project (still working on my propeller based flight controller).
That 3D demo for the Prop was very impressive! Im keeping my eye on it [noparse]:)[/noparse]
Thanks for the clarification guys [noparse]:)[/noparse]
The prop is perfect for things that *fit* in it. It's easy to use, very little support circuitry required. It's very
accessible (Spin is easy, and assembly is pretty easy). It's cheap (especially once you go the protoboard
route). The prop is deterministic (especially at the assembly code level) so you can do all sorts of bit banging
and interfacing really easily. With the DIP chip, you can just wire up your own circuitry however you want,
protoboard, breadboard, whatever. The counters and video circuitry are uniquely powerful.
ARM has a standard instruction set and memory model, so you can use a ton of existing C code.
You can get tons of memory for it, and run a full OS/TCP/IP/USB directly on the chip. So I can run a
real linux and use a standard web server or whatever I want, and it just works.
For instance, my main project right now is to build a retro microcomputer that's free. Meaning I can
build 100 of them and give them away. This means it's gotta cost me as little as possible, so that means
minimum chip count, and cheap chips. The prop, by integrating everything on one chip, makes this
possible. The ARM solution requires a *lot* more chips.
(FPGA is really optimal, except FPGAs are pretty expensive and much less accessible.)
What possibilities are there to use several propeller chips working in parallel? Given the low cost and deterministic behaviour, there must be several ways of arranging a parallel computing scheme. Would that beat the ARMs in certain applications? How would one synchronize the Props? What kind of data exchange would be best? Looking at the video output "system" (a few resistors), parallelling several NTSC/PAL channels seems to be a question of just adding the signals. Or would that attenuate the level? Would a summing amplifier be needed? Guess so.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
depends on what you are trying to use them for. While it may be possible to do something
like the ybox with the ARM, it would probably be *substantially* more difficult. Similiarly,
you can't run Windows Mobile on the Propeller in any reasonable way.
I think when you need to start putting the chips in parallel to get more "oomph", you've
already lost the game. (This is not *always* true, but it's not a bad starting point.)
Now, using multiple chips in order to modularize your device may not be a bad thing to
do, but if all you want is more MIPS, well, better to simply start with more MIPS in the
first place.
I had this picture of a number of low polygon objects with textures etc like some of the new mobile games.
Mind you, those have some fancy GPU's (i.e goForce by Nvidia) which gives them a bit of an advantage [noparse]:)[/noparse]
A large percentage of cellphones use ARM7s and now ARM9s. I spent a couple years writing software for cellphones, and its amazing (probably frightening) to see how much code there is on a cellphone. Almost all use ARMs with an external memory bus and have 16MB of DRAM and similar amounts of Flash.
Admittedly there is a tremendous amount of software bloat due to the object oriented nature of the code. For instance most phones have a small RTOS (written in C), that then runs an application API (written in C++) that then runs an interpreter that runs the user interface written in something like Pixo and others.
So basically a single chipper whether ARM or Prop is just not going to fly, especially when you factor in the slow speed of accessing external memory.
This may be off-topic, but hopefully your place hasn't been in danger from the wildfires at Tahoe.
from an ex-CA engineer,
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
h.a.s. designn
Hi Viskr,
Yeah, reality struck me on the weekend when I did a bit more research lol
I didn't realise how much CPU power some cell's use! And with a fancy nVidia chipset...crazy.
We are - as I see it - discussing affordable solutions that are powerful and yet available to hobbyists and small enterprises. A cell phone chipset is seldom available for that clientele. And, if it were available, I doubt that the development tools and software components would be available at such an affordable price. May be wrong, though. But have never considered cell phone chipsets for my applications.
For me, the Propeller is just right. I have, as of now, not had any problems with memory or speed limitations. Perhaps because my applications are mostly in instrumentation and do not need a very elaborated user interface. Which is what cell phones need and have. Control and instrumentation seems to be good candidates for a simple upgrade by just adding another Propeller. Not that I see an imminent need for it. But I see the possibility if I need it. I worked quite a lot with ARM7 (LPC2106 etc) before I found the Propeller. Of course, it isnt ARM9, but I can say that things that I deemed impossible without external hardware with ARM7 (or ARM9) are things that I do easily with the Propeller and the counters.
I may be in an extremely lucky position with "just right" applications. But I think that many guys have similar needs. At least, that is the impression I get when reading postings in the Propeller forum.
Reality checks sometimes deal with different realities...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The prop is more than enough for every application I have for it so far.
Up until now, I have not had any need to use its graphics capabilities (well I have used and LCD but thats it).
The fact that the prop does not need much external hardware to output graphics is great! And the ease at which it can be programmed is a huge plus.
I am mainly curious as to how far one could push the prop. I am not a whizz at graphics by any means which I why I am asking those who know what they are doing [noparse]:D[/noparse]