Gadget Gangster PPM ram expansion
Rsadeika
Posts: 3,837
I just noticed that Gadget Gangster may have a memory expansion module for the Propeller Platform Module (PPM) available. I hope that someone may be able to give some insight as to how this works. I will assume that the expansion module is 256KB, so that will bring the PPM up to 284KB of ram.
I assume that I can state that HUB ram will be rated at 284KB, and that the COG ram still stays the same at 496 longs? I am also making the assumption that there will be a driver provided that allows you to access the memory, in a flat memory scheme, and that you will not have to add lines of code to your main program, or will you? I do realize that the EEPROM will have to be increased, or the use of SD card will become necessary. Will there be a problem with using the Propeller IDE to use the memory expansion? Any thing else that should be anticipated?
I hope that Gadget Gangster remembers to have a matching EEPROM that will be sold with the memory module, and also have the choice of kit or assembled. I hope the module becomes a reality.
Ray
I assume that I can state that HUB ram will be rated at 284KB, and that the COG ram still stays the same at 496 longs? I am also making the assumption that there will be a driver provided that allows you to access the memory, in a flat memory scheme, and that you will not have to add lines of code to your main program, or will you? I do realize that the EEPROM will have to be increased, or the use of SD card will become necessary. Will there be a problem with using the Propeller IDE to use the memory expansion? Any thing else that should be anticipated?
I hope that Gadget Gangster remembers to have a matching EEPROM that will be sold with the memory module, and also have the choice of kit or assembled. I hope the module becomes a reality.
Ray
Comments
big arrays of byte or longs and as soon as the HUB-RAM is filled it goes on filling the external RAM
NEVER NEVER NEVER
There is simply NO 8 to n layer model of how data and program is organized in a microcontroller!
You can't insert a driver inbetween that way that the HUB-RAM is expanded to 284kB. This layer-model is PC stuff.
Except MAYBE you brake up the housing of the propellerchip and connect some hunddred 2 nanometer thin wires at the right places on the die
to extend the memory-access-logic in the right way. But don't breath near to the opened chip ! It will blow away your 2 nanometer wiring instantly !!
There has to be a driver and then OF COURSE you have to add lines of code
best regards
Stefan
Post Edited (StefanL38) : 12/13/2009 3:18:04 PM GMT
So .. any kind of external RAM will never be as fast as the internal HUB or COG-RAM.
The EEPROM size does not have to change as well. The boot-process of the Propeller can not be changed. So, even if you have external RAM the boot-program does not know anything about it and will only load 32kB.
The IDE does not know about external memory as well. So, if you want to run/compile big programs out of external RAM you have to find your own ways - currently. There are already existing techniques like the overlay-loader, which allows you to run a sequence of PASM code.
If you really need a huge program you should maybe think about easier ways. For example:
* use a controller that has enough memory
* divide the program in pieces and see if you can:
** use more than one propeller
** save the program pieces as EEPROM files and load em on request
I think that RAM is better to be used as data storage area of data that comes in over one interface and has to be processed and goes out on another interface. Maybe with a new SPIN interpreter it can be used as SLMM (SPIN large memory model) without being a to big tradeoff according to execution speed.
I hope somebody can set me straight on this, after following the threads, about expanding the ram, I figured we would be able to perform miracles with the Propeller, or get pretty close to it. I guess Leon is right, pick the right chip for the specific job.
I still think the Propeller is a very good processor, but, I guess I really have to keep getting a reality check, as to what the Propeller can really do, even with a memory expansion module.
Ray
YES.. the point is that you have to find out about the needs of your project. You need a lot of RAM for big programs and you want to store high res graphics and send it to a display : forget it ... current propeller can't handle that - it's a microcontroller!!!
Without to much tricks it's possible to have a RAM access speed of 10MB/sec with bulk access. Real random makes everything slower.
Indeed .. the propeller is an excellent controller. It's much easier to deal with different COGs which do one thing than having one processor that has to deal with different tasks via interrupts. SPIN is cool .. PASM is so different from other assembler languages and is the reason for having a SPIN interpreter that fits into 512 longs - try that with another 32 bit micro!
Reality check is the main task when developing hardware. If you start with the wrong platform you will waste a lot of time with finding a way to ship around the weaknesses. Some like to make a chellenge out of that and I guess that's what a lot of threads here are about. ZiCOG ... SID ... Linux ... just to name a few.
Don't missunderstand me ... I like those challanges as well ... but it only makes sense for hobby projects and only if you are willing to "waste" your time. For a professional approach you should know in an early phase what you need and choose your controller and/or the supporting chips based on this knowledge ...
The XMM way (an eXtended Memory Module) uses LMM to load and run programs. Catallina C supports this on some hardware. Bill's Basic should also support this. Another way to take advantage of XMM today is to write everything in LMM assembly which is a little hard to grasp at first.
Performance of XLMM compared to normal HUB based LMM could be as high as LMM MIPS / 3 using a cache scheme or 1.67MIPS at 80MHz. Normal LMM performance is on the order of 4.3 MIPS unrolled by 4 or 5MIPS*3.5/4 at 80MHz. Uncached XLMM with hardware designed for XLMM speed over pin availability can be as high as LMM MIPS / 3.37 or 1.33MIPS at 80MHz using 1 COG if my o-scope is being truthful (pin use is limited). Overclocking increases the MIPS numbers of course but restricts the type of memory.
The PSRAM at 20ns in Asynchronous SRAM mode should work fine at 100MHz without delays. The GG board design focuses more on pin availability rather than highest raw XLMM speed. With caching, performance can be marginally better.
Other ways to expand normal Propeller memory usage:
* Reload: Catalina C supports is to use what RossH calls EMM where drivers are loaded from EEPROM for example and the main program gets loaded afterwards. This allows up to 48KB of Propeller memory use. This method has been discussed several times over the years and is also available today in some of Mike Greens code.
* Emulation: the ZiCOG crew uses additional memory, but I don't know the details since I'm not interested in running Z80 CPM. I'm sure they will be happy to enlighten you (and me) with a clear statement of the advantages in this (besides being retro).
* Multiple Propellers: tie a bunch of Propellers together and have them perform distributed processing by some means.
* VMM: create a virtual memory system where SPIN or LMM for example communicates with a VM manager and the VMM loads and executes methods from media such as SDCARD or XMM. This is far more complicated and will probably make non computer science types act funny.
Processors usually do not use their pins for direct connection to what, if anything, they "control"... but instead
output a memory address and 4/8/16/32/64 bits of program/data goes either in or out through this "Bus" system.
Every instruction is like PEEK PEEK POKE (read, modify, write) to memory in a Processor. What is on a processor
bus is ROM, RAM, and stuff that the Processor sees as RAM but is really like Microcontroller Pins, and any data
there is being carried out of the system just like the usual Propeller way, to keyboards, mouse, printer, modem,
and whatever else people would connect to a computer.
Again Processor pins are a bus that just carries PEEK and POKE as in "POKE address, data" puts the address on some
pins all at the same time in binary, and data on some pins in binary. PEEK(address) would put only the address and
wait a clock for the memory to recall what is stored there, or what is coming in from something like some sensors or
push-buttons. And every memory access to a Processor is a PEEK and a POKE to that address. Another pin not yet
mentioned on a processor will output a 0 for a POKE otherwise a 1. There may be a second pin for reading memory
but read by default saves using a pin that way. Some processors have pins for indicating devices instead of memory
being accessed, which would use more pins and need special instructions to unnecessarily handle the difference, for
example PCs access real devices with IN and OUT instructions only.
Propeller has a typical or generous amount of pins, 32, which look like a Register, which is not an addressed memory
but one with a name in ASM. Changing bits in the register using (DIRA,OUTA,INA) turns on and off the pins directly.
With 20 of those bits for address, 8 for data, and 1 bit used for WRITE, you can directly access 1 megabyte of RAM
probably even faster than CogHub RAM, but you would have to also provide a means of Controlling Real Hardware since
not many pins are left. Not a problem, just do the same as for a Processor, and add chips with many pins that can
be operated like memory.
But few people are using all the pins to emulate a Processor. They are conserving pins, and using serial memory,
which is many times slower, since address and data bits go through one or two pins one at a time, not all at once,
and so it may take about 20 times longer to access a byte of serial external memory for each read and write of it.
This is OK because Propeller has speed to burn and people are often interested in fast controlling more than fast
memory. The capability of fast controlling is not as badly slowed down by the Processor Bus as memory is slowed
down by conserving pins and using serial memory though. Microcontrollers are an alternative to Processors though,
which is WHY it is silly to use a Propeller microcontroller as a Processor... Why not use a Processor? Controllers are
for adding computer brains to machines with just one major chip that has enough resources to do its real-world job.
Processors usually dream of Data and don't do anything in the real world.
Propeller is uniquely powerful enough to both control machines and process data faster and cheaper and more
efficiently than most alternative Programmable chips. It is like 8 SX or PIC chips, plus 32K of RAM, and special features
to use a TV or Monitor, and some other stuff, all on one chip. If up to 1 or 2 megabytes is enough for a Computer,
using the Propeller as a Processor (with address and data Bus) instead of Controller (direct device control)
would be a great computer like a small lapptop. Propeller 2 that is coming will process and control a lot more
memory and devices even faster.
The megabyte laptop using fast processor-like memory access is too specific an application and probably why I
haven't heard of one being made even though it is "obvious". I say again that maybe and probably the external
memory would be faster than hub RAM in that case.
I have not used any external memories except serial eeprom and SD cards which are also serial. I think that
almost all external memories are also serial although I've discussed how to use fewer pins to access more
memory only slightly slower than the "processor way" I described; a gigabyte possibly could be accessed in
just over 8 pins using multiplexed address and data bus, meaning the address is sent in groups of 8 bits then
the data is accessed afterward. That technique may not be convenient for today''s kinds of memory.
IT MAKES THE MOST SENSE TO ME THAT...
Loads of external memory are used for amazing high color graphics which are always being sent to a
monitor directly from the external memory. To access it for filling it with graphics, serial is fast enough,
but the memory itself must be constantly being read out to a monitor, which is done simply with a binary
counter connected to it which is also external. Programmable logic can probably handle gigs of external
memory being output to a monitor and being accessed serially. The serial access is probably simply
READ and WRITE Data to Address, just like Processor Bus method. It may have shortcuts to automatically
access the next byte without sending Address every time, or to change the address a little bit faster when
it is commonly done so in a certain way, such as moving forward or backward 32K, or changing between
graphics bitmap frame buffers quickly. Programmable logic may be more expensive than the Propeller and
the Memory, but still the most convenient way to maintain access to it quickly using serial methods.
...BUT I will leave it to those who are connecting megs and gigs of External RAM to explain what and how and why,
and how it works to access it.
The most obvious way to me is via READ and WRITE objects, long ago also known as PEEK and POKE,
which access Data by Address, and possibly by segmentation aka Bank Switching (or Paging?).
My brain is full of "old junk" and I just dumped some of it. It is (or was) Minimalistic, and by that I mean
a philosophy of doing more with less. I''m not sure anymore if I'm so far ahead of that game, except when
I see a Windows machine slow down and crash because it ran out of RAM and hard drive space,
trying to do less with MORE.
Post Edited (VIRAND) : 12/14/2009 1:11:40 AM GMT
I will remain skeptical until I see proof only because there are solid obstacles to achieving that level of performance. Maybe I misinterpreted what you wrote?
Sorry, Cog was a typo. Corrected. My basis for believing that external bus RAM may be faster than accessing Hub Ram
is based on the limitations of RDBYTE/WRBYTE, And Also, IIRC, that cogs have to wait for the Hub to be available.
I am probably very incorrect in the case of RDLONG/WRLONG but I haven't tested and proved the hypothesis based
on those assumptions. They are only relevant to bytes.
MAYBE, in the case of COG RAM, using counters may permit bytewise external reads comparable to PASM speed,
but I haven't tried that.
I did not actually think PASM COG RAM access could be slower than external RAM access at any point, I GOOFED!
Hmmm...
I have a 1MHz 8051 which I was able to use as a complete dumb terminal for internet access in 1998, which is in rough
shape now, but it does in fact meet the challenge of generating color video, like all 3 modes of APPLE II mixed together, which
definitely goes beyond the credible limits of an 8051... What other common Microcontroller besides the Propeller is
capable of behaving like a TVT-100 and APPLE II plus saying "YOU GOT MAIL" like AOL used to. It is on my list of
things to demo on Youtube when it is fixed up. (Or I could take it out of the box now and demo it as-is, which would
not be a collossal failure, there just wouldn't be any sound or color now because the speaker and chroma clock haven't
worked in half its age). At minimum it will look like the Apple II is hidden out of view except for minor differences.
The point is, I guess, maybe I goofed less than I thought, and who knows? And I made it just because I hated Windows
in 1998 too. It runs on a 9 volt battery and has 32K of External RAM. And I thought it would look good next to Windows 98,
or 95... because I may not have seen 98 yet but I certainly thought it was way too soon to change all of the computers.
Post Edited (VIRAND) : 12/14/2009 1:58:44 AM GMT
It seems that the best possible fetch/execute loop for external memory would be like below. The code implies that the MSB bit is used to latch an address from Propeller outputs into a "smart latch" like a secondary Propeller looking for the first occurrence of a high on the MSB ... the secondary device would have to sample and assert the address in time for the INA to happen then hold for an arbitrary time.
The 9 instruction loop compares favorably to the 15 or so instructions that are necessary for reading a long from a byte-wide bus assuming a single COG fetch/execute. Even in the 9 instruction loop, we're looking at only 2.2MIPS (80MHz) which is half of normal unrolled LMM. Of course some caching can help.
The problem is the memory is not very useful in this model. Speed is always sacrificed for functionality in some way. Having the bits mean different things for different COGs on the secondary would help with write timing or byte-lane switching. Yet another Propeller could detect a bit and have certain user features. All of this is just over-complicated speculation though. There are other sales pitches about what is possible [noparse]:)[/noparse]
dat ' .... { ------------------------------------------------------------------------------ ' XLMM32 Loop Primary } inst nop ' 0 execute instruction here nexti mov outa, _PC ' 1 set address or outa, x8000_0000 ' 2 latch with MSB mov dira, xffff_ffff ' 3 andn outa, x0fff_ffff ' 4 4 kill signal for secondary add _PC, #4 ' 5 5 secondary has address, advance PC mov dira, #0 ' 6 6 set input. secondary sets address mov inst, ina ' 7 7 get instruction jmp #inst ' 8 8 { ------------------------------------------------------------------------------ } x8000_0000 long $8000_0000 x0fff_ffff long $0fff_ffff xffff_ffff long $ffff_ffff { ------------------------------------------------------------------------------ ' XLMM32 Loop Secondary Smart Latch } mov dira, x0fff_ffff :loop waitpeq msb, msb ' 0-3 check for msb signal ' 4 wait a little more after waitpeq mov data, ina ' 5 save data just in case or outa, data ' 6 set output address nop ' 7 kill time jmp #:loop ' 8 jump to wait :loop { ------------------------------------------------------------------------------ } msb long $8000_0000I think to answer the original question of the usefulness of RAM, the LMM method or using the memory as some other temporary store has value. That's up to the user with maybe a little guidance by someone. There is certainly more than one way to do it though [noparse]:)[/noparse]
As you can see, he asked about the usefulness of external ram. I was on topic.
Yes, we're working on a Ram Expansion. It will use mctrivia's ram modules and also have some additional logic to make it all work. It should be up and available by the end of the year or thereabouts.
Personally, using external RAM is beyond my experience. I'm not sure of all the uses for external ram but I'm happy to help make a drop-in ram expansion available.
Probably not a helpful answer to your question, but I hope jazzed and virand have given you more insight on the technical side.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Forums RSS Feed!
Gadget Gangster - Share your Electronic Projects
These are interesting times, we now have at least two platforms plus a derivative, that use expansion RAM. The PPM will now be the third, which at the moment, is a very "open" platform. Since I have the PPM, I will probably get the expansion module, hopefully it will come assembled, and will not cost an "arm&leg" to get it (would make additional soldering very difficult). So, some advance information would be very helpful, I would like to see how this would fit in the scheme of things that I am thinking about doing.
All the previous posts were very helpful, and provided a technical explanation, now I am looking for some programming information, how will this RAM be used from a software perspective? How do you keep the PPM an "open" system, or is that impossible? It looks to me like it is going to need some kind of "OS", I use this term very very loosely, in order to make all this work seamlessly? If that is the case then the PPM is your own personal platform. I would like to get some responses to what I have just discussed. Basically, what can you do with it, from a software perspective?
The ram modules come fully assembled and tested. The adapter for gadget gangster does not but only took 5min to assemble.
I am in testing phase of ram modules at moment.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
24 bit LCD Breakout Board now in. $21.99 has backlight driver and touch sensitive decoder.
Burst at 20MB/s ??
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
24 bit LCD Breakout Board now in. $21.99 has backlight driver and touch sensitive decoder.
No, I was asking about your prop specific interface.
Nevermind..
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
Setup means setting start address and counters to provide clock signal.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
24 bit LCD Breakout Board now in. $21.99 has backlight driver and touch sensitive decoder.
You would need to use a counter to provide a clock.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
24 bit LCD Breakout Board now in. $21.99 has backlight driver and touch sensitive decoder.
Several drivers will likely be writer to make code easy.
As for pins it uses a lot but you can reuse all if careful.
Check "what pins best to use" for pins used.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
24 bit LCD Breakout Board now in. $21.99 has backlight driver and touch sensitive decoder.
If I may ... and please forgive if I have any of this wrong ....
From my research on the PSRAM part, there are 2 basic modes of operation: Synchronous and Asynchronous.
So, there are two parts for setup: initialize and use.
Part 1 of "setup" is "initialize" to select the mode this happens just once at startup (it does not seem to be persistent ... or is it?). If Asynchronous is selected, then the device behaves as a 20ns (or other specified) standard SRAM. This is the default mode. If Synchronous is selected, then the device uses a clock to burst data.
Part 2 of "setup" is latching a random access "use" base address. This process is almost the same for both modes. After the latching, sequential access can happen. Latching means disable PSRAM output, set latch bit for address to go into the 74**573, set address byte 1 to data, clear latch bit to make the 74**573 hold the byte provided. Repeat latching for address bytes 2, 3, 4. For synchronous mode, I hazily remember a latch signal has to be used also. This "use" setup has to occur any time the base address changes.
Once part 2 setup is done ...
In asynchronous mode, the Propeller would step the lower address bits as if they were output of a counter. A 2 bit counter like this is fast and easy. An 8 bit counter is possible with VCFG/VSEL and waitvid and can be quite fast for as many bytes as you can collect with INA.
In synchronous mode the Propeller would use a clock strobe to output data for collection with INA. Before strobing, one has to monitor the WAIT signal for the device to be ready. Once the WAIT indicates ready, it appears as though it also signals the end of data which is very nice for doing a pseudo-dma loop.
Yes, this should be done in PASM.
Hope this is helpful. Cheers.
Async is done by default and requires no setup other then setting latches when needed.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
24 bit LCD Breakout Board now in. $21.99 has backlight driver and touch sensitive decoder.
1 - Yeah, the idea is that you'll use an object to interface with the ram. From the perspective of an end-user, you don't need to worry about the pasm that gets that done. My hope is that a lot of the discussion in this thread won't be important to most users. Of course, you'll still want to understand the upside/downside of the RAM expansion approach, when it makes sense, etc.
2 - Yes, the uSD module can also fit on the RAM expander (on top of the ram expander, or below the propeller platform).
There will be more documentation available as we get closer to releasing it.
Question for Jazzed / bradc / mctrivia / et al.;
The core benefit here is more memory. how much complexity (for the person who's using some sort of pre-built object) does it add? Do you think it will be as easy as using fsrw to read an SD card?
I remember Coley (or maybe baggers?) saying something on the forums about the external ram being too slow for video usage (I could be mistaken, though). What are some typical applications (not just in making operating systems) where you're going to enjoy the additional space?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Forums RSS Feed!
Gadget Gangster - Share your Electronic Projects
I think it would be a good thing to extend the SPIN interpreter to use vMem instead of HUB-RAM - at least for the code. That would be cool. Then you could really run unlimited SPIN-programs. I think it should not slow down SPIN to much. And you have nearly full HUB-RAM for fast access. Just dreamin .... ;o)
Well ... what is external RAM good for? In the end it should be faster than an SD card. As already said it will not help for high res high color graphics, but you can use it as a buffer for graphics.spin/tv.spin to get back the faster HUB-RAM for more important things - SPIN code for example - or data that comes in faster.
Yes, allowing Spin to use virtual memory for allowing bigger programs is a great idea. I described one approach I started developing in the summer called "BigSpin". See the long entry at the bottom of the thread in http://forums.parallax.com/showthread.php?p=863357 I have other things to do now though.
Actually, Bill Henning is using external SRAM for higher resolution VGA. SRAM speed is relevant to how many cores you want to use.
If you need something stated in the simplest terms, it seems that mctrivia has a handle on that.
depends on how the ram driver is writen. the one I am working on at the moment is as easy as this:
I have no experience with the built in video generator. As far as I know it can provide only 6 bit color which is not very high. My intentions are to have the RAM itself generate the video and bursting data in and out of RAM between pixels.
Well I am going back to work on the modules. Either my code is wrong or my assembly process and I need to figure out which. I wish I had an x-ray machine. Was nice when I worked for a company that had one.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
24 bit LCD Breakout Board now in. $21.99 has backlight driver and touch sensitive decoder.
This does not sound very good. How many different RAM drivers will we be able to choose from? I think that an object would be the preferred driver format, but I may be missing something.
As for the video, maybe a RAM card with a video chip on it, then you have some RAM for the video, and the rest would be the system RAM. I do not even know if something like that would be possible or even feasible. Just thinking out loud.
Post Edited (Rsadeika) : 12/15/2009 4:50:32 PM GMT
The reason I suspect there will be more then 1 is because for different uses code can be optimized for speed or size.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
24 bit LCD Breakout Board now in. $21.99 has backlight driver and touch sensitive decoder.