Propeller External Memory Hardware Survey
jazzed
Posts: 11,803
Please help determine which external memory hardware solutions should be added to the initial Propeller GCC release. Hardware developers can easily add their own solution, but we need a minimum set for testing.
The number of entries allowed by the survey tool is limiting, and I don't want to seem biased. Please just mention the hardware you have in a reply. We already have drivers for C3, SpinSocket-Flash, DracBlade, and SDRAM.
The number of entries allowed by the survey tool is limiting, and I don't want to seem biased. Please just mention the hardware you have in a reply. We already have drivers for C3, SpinSocket-Flash, DracBlade, and SDRAM.
Comments
I don't know how they compare to the other flash chips you're using. I do know these require a full sector (4KB) to be erased at a time.
Duane
SpinSocket-Flash (SSF) currently uses those chips.
I could easily add the ST chips Rayman uses.
Here's SSF the pin-out:
P0..7 Data
P26 SPI Clock
P27 SPI Chip-select
I believe Ross just about has them work with Catalina now.
I'm hoping that the 4-bit bus on RamPage will make for an easy addition to any Prop system without using very many pins and giving 2MB of program space.
Supporting developers by making it very easy to add new hardware is important to Parallax Propeller GCC.
For flash boards, all we need to do is add flash erase, program, and read functions to a PASM driver skeleton.
You don't need to know anything about GCC beyond the driver API (in most cases) and how to add a board to the loader config.
In GCC we identify the external memory device driver to load by a name. Do you have a short name preference?
Any device can be selected at load time without recompiling for a given memory model.
I have a few of the FPS modules. Maybe I'll take a stab at making a GCC XMM driver for one. Is there any reference code I can start from? I don't have the FPRP module but it looks nice.
What do you require for testing (please note I no longer have TriBlades available and only 1 myself). I could provide a RamBlade2 for testing.
I already have a RamBlade1 that I can use for testing. Do you have reference read/write code for the SRAM?
http://www.rayslogic.com/Propeller/Products/FlashPoint/FlashPoint.htm
There is a scrolling map example here in the forum that may have used a 2-cog driver....
I really need to spend more time with this and make it better. What I'm going for is a unified driver for 0, 1, 2 or 3 cogs.
Started working on a file system for flash and got bogged down...
But, I think for this application you don't need a file system, or maybe you guys have your own ideas on that.
So, perhaps I should shelve the file system idea...
Let me know if the bitmap viewer examples have what you need...
All external memory drivers have the same interface and will run in a COG separately from the main XMM VM. Embedding hardware access directly in the XMM (external LMM VM) will not be officially supported; however, nothing will stop the adventurous from doing that on their own.
In a normal setting, a knowledgeable solution developer should have full control of their own schedule and products without requiring a third party to do it for them. This is a goal of Propeller GCC XMM. There should be no reason at all to ask a compiler developer (or Parallax for that matter) to do any of this work for a knowledgeable developer, but the team is available short term to verify these concepts. I will PM you details about team availability.
Well, this is mostly correct. The driver really has to be written in PASM with a specific mailbox interface. It can't be written in Spin.
IIRC my TriBlade and RamBlade were really the first boards to introduce useful SRAM (together with microSD) to the propeller. I provide pasm drivers for both boards which also includes block functions, and ZiCog accesses SRAM directly together with the microSD. All are published MIT licence.
RossH has TriBlade drivers for Catalina. Unsure about RamBlade although they are similar and simpler.
I do not know what is required for GCC and AFAIK you have not published anything that might help me.
David: Here are the latest drivers for both RamBlade and TriBlade. If you have any questions please do not hesitate to ask.
TriBlade_RamBlade_zicog_rr145.spinRamBlade_203_005.spinTriBladeProp_Blade2_203.spin
I was explaining what will nominally happen for new hardware. Your software skills are up to the task when documentation is available. You of all people should have no problems with this.
I'd suggest we all stick to using the same short names.
Catalina currently uses the following short names, each of which represents a different XMM implementation:
- TRIBLADEPROP CPU_1
- TRIBLADEPROP CPU_2
- RAMBLADE
- MORPHEUS CPU_1
- MORPHEUS CPU_2
- RAMPAGE
- SUPERQUAD
- DRACBLADE
- HYDRA or HYBRID (HX512 *)
- C3
- CACHED **
NOTES:I suppose one day we may all agree on a single "best" XMM implementation .... but given the size of some of the egos in this forum, I won't be holding my breath
Ross.
Thanks! It's been far too long since I bought my RamBlade and would love to have a reason to power it up! Unfortunately, I won't be able to do anything for the TriBlade since it isn't available anymore. In fact, I had wanted to buy a TriBlade back when I bought my RamBlade and they weren't available then either. Are you thinking of reintroducing them at some point?
These parallel RAM solutions are nice but they all seem a bit heavy weight, consuming too many pins. Begins to not make much sense for an MCU that is supposed to be controlling stuff in the real world. This situation will look much better for the Prop II with all it's extra pins.
Yes, I know what you mean. Sometimes it seems like we spend too much time trying to make the Propeller look like a desktop PC and too little using it to control interesting stuff!
A task which it fulfilled very well in the end but it's not what the Prop was invented for.
Now I have to find time to look into the various serial memory solutions that are emerging. I still think there is a case for fetching byte codes from such devices, ZPU or Java or whatever. Resulting in big slow code but still free pins and COGs for the fast stuff.
I have a RamBlade - it works a treat, and is the fastest XMM board I have.
I only have one PropPlug - I connected it (once!) to the programming pins to program Catalyst into EEPROM, then moved it permanently to the comms pins and now use a serial terminal. I load any programs I want to run from the SD Card using Catalyst.
Ross.
I have a new design you might want to add - 24 propeller pins to a 512k sram with one HC374 latch. Blocks of 4096 bytes. I have a schematic and the working code. I'm posting this from work so when I get home I'll post both the schematic and the code. I have it on a breadboard at the moment and some Gadget Gangster PCBs are in the pipeline. I don't have a name for this design though - maybe for the moment it could be called SlingleLatchRam or something? It is similar to Cluso's designs and ought to run very close to the speed of the ramblade.
Re heater's musings above regarding pins, at the moment I've pushed video to the limits with the 256x224 full color driver and that consumes everything the prop has so I'm thinking now of using two of these boards - one does the C and one does the video, and a fast (?4mbs or more) link between the two. Move a lot of the low level graphics things into the video prop like loading fonts, scrolling text boxes, re-drawing the mouse. Then C can run a high level GUI at a decent speed.
Yes I know there are other solutions that involve an SD card but I'd rather have a mechanism that doesn't require moving the SD card from the PC to the RamBlade and back for every code recompile.