Adding Ram to the propeller
lukesmith
Posts: 6
Hi,
I'm new here and new to hardware though I am a software developer. I love the idea of making a basic computer with a propeller. I want to make a basic operating system with functions such as opening and displaying pdf files and possible html files (browser).
Though I think I would be limited by the amount of ram available. Is there any way to increase the amount of ram in the propeller? I have seen projects where DIP SRAM chips were added. Is this the answer to my problems, are there any resource on doing this?
Thanks for any advice you guys can give me.
I'm new here and new to hardware though I am a software developer. I love the idea of making a basic computer with a propeller. I want to make a basic operating system with functions such as opening and displaying pdf files and possible html files (browser).
Though I think I would be limited by the amount of ram available. Is there any way to increase the amount of ram in the propeller? I have seen projects where DIP SRAM chips were added. Is this the answer to my problems, are there any resource on doing this?
Thanks for any advice you guys can give me.
Comments
One very clever solution is to use slower SPI serial ram, and use caching to make it appear faster, and write your code in C. Then you can write programs that can be hundreds of kilobytes (megabytes even) in size, and have speed that is almost the same as Spin.
The up side is you have tremendous flexibility and can emulate almost any computer you want.
Someone will probably post links to the threads shortly, and you can search for ZiCog or ZOG,
Welcome to the forums and the Propeller world. Where, as you will find, the impossible is done every day.
Just for info:
ZiCog is a Z80 emulator that uses external RAM for the Z80 address space.
Zog is an implementation of the ZPU instruction set for which there is a C compiler zpugcc. Again using external RAM for the ZPU address space.
However these were created in the early days of people experimenting with RAM expansion for the Prop and I suspect things have moved on a lot. Especially in the area of using serial access RAM and FLASH devices giving large external space and using few Prop pins. Also in the use of caches in the Props HUB to speed overall access.
I would advise checking out the new GCC for the Propeller, propgcc, see the beta test thread in this forum.
propgcc supports compiling C code to native in COG instructions for maximum speed. Or compiling to "Large memory model" (LMM) where instructions are kept in HUB but fetched into COG for execution. Or XMM where instructions and/or data can be fetched from external RAM devices.
The later will be of interest to you and propgcc supports XMM on many configurations of parallel and serial access devices. It has support for many boards that exist with these devices. Or you can easily cook up your own.
As a bonus propgcc now supports CMM or Compact Memory Model where rather than compiling to the 32 bit instructions of the propeller it compiles to a compressed version. That enables more code to fit in the limited HUB space but may also help exection from external devices as less code has to be fetched.
Whilst propgcc is still in beta test it has been working very well for many for a while now.
The propeller is a mikrocontroller and it's purpose is controlling and not running heavy weight programs like PDF readers or browsers. I love the propeller, but I'd never try to use it for such things! Because of the limitations you have to deal with a lot problems that you won't have if you'd pick an architecture that is a better fit - in this case I's suggest to use an ARM. (for example the raspberry pi - you don't have to install a linux image, you can write your own OS). Or if you are not in a hurry wait for the propeller II.
My expectation is, that the code of a PDF reader as well as the code of a browser will already exceed the RAM available in the propeller.
What are your goals regarding the display? Resolution? Number of colors? ... Depending on that you need enough RAM for a screen buffer and fast enough to allow refreshing the display meanwhile allowing access for preparation of the next screen.
PropGCC did not work for me so far (Win 7). Compile seems to do something, but writing the binary to the propeller gives the error message that a.out can't be found.
Good points. Even as I suspect anything we say that is impossible on the Prop will get done, to some degree or other, it surely is not a basis on which to build heavy weights like PDF viewers and WEB browsers.
That's not to say that bolting on a RAM and putting large chunks of code out there is a bad idea. It may not be anywhere as fast as you might expect if you are used to ARMs and such BUT you still have seven other COGs play with. They can be used for high speed bit banging that you can only dream of if you are Pi user, for example.
Shame you are having trouble with propgcc on Win 7. (Do you mean propgcc or SimpleIDE?) Seems you have lost the a.out in some directory or other. People always seem to have trouble figuring out where their files are written to by Windows apps.
If it would be my project I'd put it back until Prop II is there.
I installed SimpleIDE. a.out can not be found anywhere on the drive! Don't want to hitchhike this thread, but I think that GCC & stuff should be out of beta-phase before suggesting it to newbies.
I guess thats the best idea to build the system first and see how many pins are left.
@MagIO2
Yeah the idea was really just to do it for the sake/fun of it.Thats an excellent idea that you mentioned about 'bare metal programming' the pi. Thanks!
lukesmith introduced himself as a software developer so naturally I suggest C even though it is beta.
Can you please post details of this problem to the propeller-gcc beta forum ?
Usually not finding a.out would mean the compile/link process failed.
Regardless, we need to understand your problem.
I agree. Given lukesmith's description of what he wanted to do, I think his best option would be Catalina, using a board that already comes with some kind of XMM RAM "built in". I think the C3 might be a good overall choice. GCC also supports the C3, so if he wants to he can move to that compiler when it is no longer beta.
Ross.
A PDF viewer will require a post script interpreter, which must be a fairly huge piece of code, and a big pile of space to render the output into. Not to mention the neeed for some high res graphics to display the result.
HTML might be reasonable to some limited extent, think of text based browsers like Links. Still huge though.
All in all a Raspberry Pi would be a more suitable choice.
Hi Heater,
I didn't want to be quite so indelicate as to bring this up on a Parallax site, but since you have now pointed out the obvious "elephant in the room"
Also, if I wanted to program in GCC, then this would have to be the obvious choice since it comes fully equipped with all the necessary dev tools running under Debian Linux.
Ross.
Yep. And you can develop C or Spin code for the Propeller on your Pi with propgcc and SimpleIDE all working on ARM quite easily.
Let the Prop do hardware bit twiddling and the Pi the heavy code lifting. A perfect match.
I guess Catlina could be built in the Pi as well.
Of course! And then you could run Code::Blocks on there as well and you would have the best of all possible worlds
But only the lunatics in these forums would ever even contemplate doing this. If you are a newbie and just want to program, why on earth would you want to tackle any of that complexity? Why not just use the Pi? It's faster, cheaper, more suitable, has better peripherals than most Propeller boards and is probably better supported.
Lets' face it - if the Pi fulfils even a fraction of its potential, it is not only an Arduino killer, it's also a Propeller killer - at least for the kind of application lukesmith had in mind!
But perhaps this is not such a bad thing. Let the Propeller be used for the type of applications the Propeller is good at. Let's stop leading newbies up the garden path by pretending that the addition of XMM magically transforms the Propeller from being a specialist microcontroller with a novel architecture to being a general-purpose microprocessor. It doesn't. The Propeller is simply not suitable for this kind of application. The Pi is.
Ross.
One thing you can do is add an SD and treat that as RAM. You can have chunks of code and assembler routines on the SD. As long as you keep the chunks + application under 32k, you can swap stuff in off the SD all day long and never run out of space. You just have to be careful with your design.
Some folks might advise that using SD as RAM is too slow, but consider that the overhead of managing external RAM chips also has a cost in overhead. It turns out that external RAM chip are very expensive in terms of overhead and what they get you. So with careful design, the SD as RAM trick can be just as good or better, and is much simpler and cheaper.
Yep, Code::Blocks runs on the Pi just fine. This lunatic is not just contemplating it but is doing it:)
I don't think the Pi is an Arduino or Prop killer. Not enough GPIO for starters and what it has cannot be driven at speed in any kind of deterministic manner. Especially if there multiple tasks wanting to do so.
As you say, leave the AVR's and Props etc to do what they are best at in the hardware interfacing realm and use a Pi or such for the heavy code lifting and big data.
Putting a Propeller and Pi together is my current interest.
Braino, Indeed you can. Problem is that at the end of that day you still won't have rendered that PDF document:)
Well, I didn't want to single out anyone by name, but since you have outed yourself ...
Ross.
This can be the good thing. Prop as something you can program as you want. Pi as a powerful worker to do fast computation work and external memory source for the Propeller.
There is another way of enhancing the Propeller capabilities - add an FPGA board to it. They are available @ ~60$ for students (Altera DE0 nano). It can provide a memory source for the Propeller and any digital external circuit one want to have.
We're using a Pi to do all the "workstation" type functions that the prop does not do well (large memory, user GUI, float number crunching, communication with more powerful nodes over internet), and using the prop for all the "microcontroller" things that the Pi doesn't do well (deterministic execution with very small time window for many task, talking to peripheral with software interfaces, reprocessing data stream, and 'reflex' control of local actuators). With this configuration, the prop application thinks it has workstation abilities and the pi application thinks it has microcontroller abilities. Its really nice, but we cheat and do it the easy way, with propforth and go language. Its just a case of sizing the solution for the application: Right tool for the right job.
Another simple example of Prop/Pi application : MIDI machine
The Propeller can do all MIDI stuff with minimal delay. Pi cannot do it. It has multitasking, non-real-time OS
The Propeller cannot display advanced graphic stuff because of lack of RAM. The Pi of course can do it.
So let put them together and we have a machine which can process MIDI streams with small, constant delay and then visualize it with good GUI application..
I just confirmed that Catalina compiles and runs perfectly well on the Raspberry Pi - I just used my Pi to compile and download programs to my C3, and it works really well.
You can build it yourself from the Catalina sources, but If there is enough interest I will post a "Pi" package in addition to the Windows & Linux packages. I'll put a message to this effect on the main Catalina thread.
Ross.