Flash Point RamPage (FPRP) use in propgcc

martinh

Dear all,
I have at the moment a bit difficulties to figure out how to make use of the Flash Point RamPage module in propgcc
http://www.rayslogic.com/Propeller/Products/FlashPoint/FlashPoint.htm
So far I have attached it to a propeller demo board with the following pin assignments

CSN-SRAM        7
SCK-SRAM        6
SIO3            5
SIO2            4
SIO1            3
SIO0            2
SCK-FLASH       1
CEN-FLASH       0

So far I think to understand (??) that I have to use sst.cfg and adjust that to my pins, but fail to understand what in sst.cfg maps to what exactly given the settings I posted above. If someone can shed some light on that it would be great.

Rayman

I'm not sure anybody has gotten the SRAM part to work with PropGCC yet...

David Betz got the flash part working though... He posted something about it in this thread:
http://forums.parallax.com/showthread.php/142706-New-cache-driver-for-SST-SPI-flash-chips?highlight=betz+rampage

martinh

Thanks for your quick reply, I adjusted sst.cfg by changing the cache-param1/2 lines to

    cache-param1: 0x02000101 # 0xssxxccee - ss=sio0 xx=unused cc=sck pp-protocol
    cache-param2: 0x00000000 # 0xaabbccdd - aa=ce bb=unused cc=unused dd=unused

and that seems to do the job (was able now to compile, save and execute a xmmc program which was saved to the flash as it should.
This makes me already happy, of course if sooner or later the SRAM part would also be usable it would be brilliant It is a bit over my head to do it myself given the lack of deeper knowledge about the propgcc intrinsics and driver architecture I suffer from (hope that I can change that over the time).

jazzed

It's not clear to me what needs to be added. I thought we had support already ... David?

David Betz

martinh wrote: »

Thanks for your quick reply, I adjusted sst.cfg by changing the cache-param1/2 lines to

    cache-param1: 0x02000101 # 0xssxxccee - ss=sio0 xx=unused cc=sck pp-protocol
    cache-param2: 0x00000000 # 0xaabbccdd - aa=ce bb=unused cc=unused dd=unused

and that seems to do the job (was able now to compile, save and execute a xmmc program which was saved to the flash as it should.
This makes me already happy, of course if sooner or later the SRAM part would also be usable it would be brilliant It is a bit over my head to do it myself given the lack of deeper knowledge about the propgcc intrinsics and driver architecture I suffer from (hope that I can change that over the time).

I could easily make a driver that only can access the SRAM. Doing both at the same time will require some code optimization because my flash driver takes up almost all of COG memory as it is. Do you need access to both at the same time for your application? What are you planning to place in flash and SRAM?

martinh

The idea is to use the SRAM for relatively large quickly varying data buffers which need post processing and the flash for the not too small code which is needed for the logic (I think that's what xmm-split is meant for?).
Think about a small autonomous robot driving through the rooms while scanning with an ultrasound sensor (not a PING like sensor since that gives only one echo or nothing, but more like the A-scans from past ultrasound diagnostic). The scan lines along the ultrasound "ray" need to be fully stored for full sweeps of the sensor as deconvolution has to take place orthogonal to them to enhance resolution. From that deconvolved image in combination with the knowledge about its position the machine shall update a map of the flat in its long term memory to be able to remember the position of walls and obstacles and navigate in an more or less optimal way from one place to another.

What I do right now is just playing around with the possibilities to see what's possible and what not and make myself familiar with the propeller flavour of gcc.

Edit: Just to add as I said in theprevious post, I am already happy about the xmmc which I can use right now and maybe it is already enough to work with the HUB for the data if I manage to do it in aclever enough way.

jazzed

martinh wrote: »

The idea is to use the SRAM for relatively large quickly varying data buffers which need post processing and the flash for the not too small code which is needed for the logic (I think that's what xmm-split is meant for?). ...

Perhaps what you really need then is a driver that can access the SRAM for temporarily accessing information without going through the cache driver. Yes, XMM-SPLIT can be used for this purpose, but XMM-SPLIT is relatively slow, and it would be much better to use XMMC for code and have a driver to access SRAM separately.

martinh

@jazzed: That is a solution I will keep in mind.
There was a wording from my side which probably leads to confusion: The quickly varying data buffers have not to be super fast, it is more that they are repeatedly and often updated making it not too convenient to use for example flash or sd cards which suffer from wear out problems in the worst case. Of course I can work around that by for example writing the buffers every time to a new location on a uSD without care that it wastes space and only when for example 1 GB allocated for that task is exceeded starting again from the begimning of that large space.

The benefit of using xmm-split even if slower than a custom driver access to the external memory by writing my own driver (recycling rayman's spin/pasm driver) is likely to result in much cleaner C code as you just act on the buffers as standard arrays and keep the more time constrained parts in the stack (HUB) and the most time constrained parts for the data acquisition in the cogs.
The other benefit is that it is more standardized if I need other hardware for the RAM and have not to rewrite again a driver for different hardware with the same interface I used before just to reuse the code.

All this is now of course just chit chat as I have not yet the code, not even decided about the US sensor to use (or to build) and still contemplating about how to go for my (hobby) project to make it feasible at all.

martinh

@David: After thinking a while about what you wrote I have to ask you if you would be willing to make the driver which can only access the SRAM? In combination with a uSD this should still give the possibility for xmm-split if I understand how propgcc works though with the slower SD access for code instead of the fast sqi flash.
I think that would be a nice enhancement.
If you are willing to do that it's great, if not it is of course also completely ok with me since I ask you here for work on your side to reduce work on my side, I do not demand anything here and I am grateful for all what has already been done by a lot of people for this gcc environment.

To elaborate a bit - just in case somebody asks this to him/herself why I do not simply use catalina which supports both parts of that FPRP module:
The missing part in catalina is that I cannot use an equivalent to what propgcc provides as cogc to write fast C code to run in a cog instead of going down to pasm and I plan to use that functionality as much as possible to find out how far I can take it before I have to fall back to hand crafted pasm (due to speed or space constraints in the cogs).

David Betz

martinh wrote: »

@David: After thinking a while about what you wrote I have to ask you if you would be willing to make the driver which can only access the SRAM? In combination with a uSD this should still give the possibility for xmm-split if I understand how propgcc works though with the slower SD access for code instead of the fast sqi flash.

I can certainly make a version of the RamPage2 driver that works with only the SRAM but that won't let you use it in conjunction with the SD cache driver. It is only possible to use one cache driver at a time. You can either use a RamPage2 driver or the SD cache driver, not both. I'll have to look into make a combined flash/SRAM driver for the RamPage2 module. I meant to do that a while back but got bogged down with P2 work. This might be a good time to get back to it though since I'm about to start working on XMM for P2 and will have to get back into the drivers anyway. I'll let you know if I make any progress.

martinh

Thanks David and also for the answer about my misconception when the SD is used in conjunction with the extended RAM, I read again the description for SDLOAD and it is clearly described what it does, seems I mixed something together in my head which was not there.