"Fast" SPI flash cache driver

David Betz · 2012-09-30 14:47

I've just pushed a revision of the spi_flash_cache driver, the one that is configurable for boards using a SPI flash chip. This is the driver that is used by the DNA board configuration as well as the new PKS board configuration for Rayman's Propeller Keychain System. It can also be used by the C3 or any board that has a SPI flash chip on it.

The revision makes use of the very clever counter-based code that Jonathan "lonesock" Dummer wrote for FSRW. To use this version of the driver instead of the original slower SPI code you just need to change one line in your board configuration file.

If you're using a board with an Atmel or Winbond SPI flash chip

Change this:

    cache-driver: spi_flash_cache.dat

To this:

    cache-driver: fast_spi_flash_cache.dat

If you're using a board with an SST flash chip

Change this:

    cache-driver: sst_spi_flash_cache.dat

To this:

    cache-driver: fast_sst_spi_flash_cache.dat

None of the standard configuration files make use of this driver currently since it is new and relatively untested.

Bill Henning · 2012-09-30 15:13

Nice work David!

10mbps read/write or 20mbps write / 10mbps read?

David Betz wrote: »
I've just pushed a revision of the spi_flash_cache driver, the one that is configurable for boards using a SPI flash chip. This is the driver that is used by the DNA board configuration as well as the new PKS board configuration for Rayman's Propeller Keychain System. It can also be used by the C3 or any board that has a SPI flash chip on it.

The revision makes use of the very clever counter-based code that Jonathan "lonesock" Dummer wrote for FSRW. To use this version of the driver instead of the original slower SPI code you just need to change one line in your board configuration file.

If you're using a board with an Atmel or Winbond SPI flash chip

Change this:
    cache-driver: spi_flash_cache.dat
To this:
    cache-driver: fast_spi_flash_cache.dat
If you're using a board with an SST flash chip

Change this:
    cache-driver: sst_spi_flash_cache.dat
To this:
    cache-driver: fast_sst_spi_flash_cache.dat
None of the standard configuration files make use of this driver currently since it is new and relatively untested.

David Betz · 2012-09-30 15:23

Bill Henning wrote: »

Nice work David!

10mbps read/write or 20mbps write / 10mbps read?

The later. Apparently, the fast read isn't necessarily reliable with all pin combinations.

Heater. · 2012-09-30 17:09

Any chance of getting these .dat files built with spin2cpp in the propgcc loader build system. I can't use BSTC on the Raspberry Pi or other ARM boards.

David Betz · 2012-09-30 17:27

Heater. wrote: »

Any chance of getting these .dat files built with spin2cpp in the propgcc loader build system. I can't use BSTC on the Raspberry Pi or other ARM boards.

Here are the .dat files.

David Betz · 2012-09-30 18:44

Bill Henning wrote: »

Nice work David!

10mbps read/write or 20mbps write / 10mbps read?

Bill,

Did you ever get a chance to try the PropGCC cache drivers with any of your boards that support SPI flash? There is support for the SPI addressing mux you described to me once but I've never been able to verify that it works.

Thanks,
David

Bill Henning · 2012-09-30 20:55

Not yet, but it is high on my list... I could really use about 4x the hours in the day

I have a lot of boards to try it on...

David Betz wrote: »

Bill,

Did you ever get a chance to try the PropGCC cache drivers with any of your boards that support SPI flash? There is support for the SPI addressing mux you described to me once but I've never been able to verify that it works.

Thanks,
David

Heater. · 2012-09-30 21:10

Thanks David,

Recently I have been building the tools on ARM processor boards, Raspi and IGEP, and I copy the .dat and .binary files over from a build on my PC. That gets old when there updates comming. Ultimately those files need to be created by an open source tool to keep things building nicely on non-Intel platforms.

David Betz · 2012-10-01 04:41

Heater. wrote: »

Thanks David,

Recently I have been building the tools on ARM processor boards, Raspi and IGEP, and I copy the .dat and .binary files over from a build on my PC. That gets old when there updates comming. Ultimately those files need to be created by an open source tool to keep things building nicely on non-Intel platforms.

I've been considering converting all of the cache drivers to gas so that I can create a cache driver library with things like the tag handling code and low-level SPI and I2C functions taken from a library rather than being duplicated across numerous drivers. Another possiblity would be to use Roy's Spin compiler but I don't believe it handles the #ifdef, etc preprocessor directives yet. A third option might be to use spin2cpp. I think I read recently that it can assemble PASM code and write it to a .dat file like bstc.

Heater. · 2012-10-01 06:42

Sounds like the gas solution is the best in the long run. Seems a bit odd and inelegant to have to use some other tools when you are working with the GCC tool chain.

David Betz · 2012-10-01 06:50

Heater. wrote: »

Sounds like the gas solution is the best in the long run. Seems a bit odd and inelegant to have to use some other tools when you are working with the GCC tool chain.

Yes, I think the gas solution is probably best. I've been getting some resistance to going in that direction though. It seems there are people who don't want to let go of every detail of the PASM syntax. Gas does have a few differences from PASM that take a bit of getting used to.

Heater. · 2012-10-01 07:20

So what we need is for spin2cpp to be able to output the PASM sections as GAS syntax assembler rather than as binary. Tha way Spin/PASm users are happy and we can work from the source to create the drivers.

David Betz · 2012-10-01 07:23

Heater. wrote: »

So what we need is for spin2cpp to be able to output the PASM sections as GAS syntax assembler rather than as binary. Tha way Spin/PASm users are happy and we can work from the source to create the drivers.

Or PASM users can take 10 minutes to get used to the slightly different gas semantics. :-)

Heater. · 2012-10-01 07:30

Actually, yes.

ersmith · 2012-10-01 10:59

Heater. wrote: »

So what we need is for spin2cpp to be able to output the PASM sections as GAS syntax assembler rather than as binary. Tha way Spin/PASm users are happy and we can work from the source to create the drivers.

I guess the spin2cpp release notice got buried somewhere in the traffic on the forums, but yes, it can do that:

spin2cpp --dat --gas foo.spin

will produce foo.S, a GAS syntax version of the DAT section; or, you can embed the GAS version of the DAT section into the output .cpp or .c file by just saying --gas (without the --dat).

It's still pretty experimental, so it may not work for all cases.

Martin Hodge · 2012-10-01 14:07

David, did you test this on a DNA board? I haven't been able to get ebasic to load with the fast driver.

David Betz · 2012-10-01 14:43

Martin Hodge wrote: »

David, did you test this on a DNA board? I haven't been able to get ebasic to load with the fast driver.

I use Rayman's PKS to test it. I'll try DNA later. Sorry if it isn't working for you!

Martin Hodge · 2012-10-01 20:03

No worries. I just figured I was doing something wrong.

David Betz · 2012-10-01 20:13

Martin Hodge wrote: »

No worries. I just figured I was doing something wrong.

Actually, I can't try it on the DNA board because I don't have any single bit SPI flash chips. Isn't the one that comes with the DNA-RTC a quad SPI chip?

Martin Hodge · 2012-10-01 20:39

It'll do quad or single. Just unplug it from U12 and move it to U9. Then in propeller-load use "-b dna" instead of "-b dna:sqi"

David Betz · 2012-10-01 20:51

Martin Hodge wrote: »

It'll do quad or single. Just unplug it from U12 and move it to U9. Then in propeller-load use "-b dna" instead of "-b dna:sqi"

Can you remind me of what's on which pins? I can't seem to find my DNA schematic and I couldn't find it on your site. Anyway, you're right that the DNA board doesn't seem to work correctly with the "fast" cache driver. I guess I must have a bug in the Winbond version of the code since the PKS uses an SST chip.

Thanks,
David

David Betz · 2012-10-01 21:03

David Betz wrote: »

Can you remind me of what's on which pins? I can't seem to find my DNA schematic and I couldn't find it on your site.

Never mind. I found it on the Wiki.

David Betz · 2012-10-02 06:10

I looked into the problem with the DNA board a little this morning and I'm not sure why this wouldn't work. The non-Fast version seems to work fine and the only difference between the two are the low-level spiSendByte and spiRecvByte functions and those seem to work on the SST chips. Anyone have any idea what might be going wrong here? I'll attach the driver code to this message in case you have time to look it over. The counter-based code is enabled by defining the preprocessor symbol "FAST".

Edit: I forgot to mention that this FAST mode is working fine with SST SPI flash chips so I believe the send/recv byte functions work.

Rayman · 2012-10-11 10:22

I'm curious how the .dat files work in PropGCC...

Are these the same as the binary data you get when doing Spin2Cpp on the PASM part of a Spin program?

David Betz · 2012-10-11 10:33

Rayman wrote: »

I'm curious how the .dat files work in PropGCC...

Are these the same as the binary data you get when doing Spin2Cpp on the PASM part of a Spin program?

Yes, they are. The loader loads the appropriate .dat file based on the board type you select.

Dr_Acula · 2012-11-07 23:04

Have any of the GCC boffins got samples of the 23xx1024 1 megabit spi ram chips from microchip? I think they are still sampling and the price is listed at $1.73 which would work out very nice in terms of pins used and cost. Anyone used these?

jazzed · 2012-11-07 23:45

Dr_Acula wrote: »

Have any of the GCC boffins got samples of the 23xx1024 1 megabit spi ram chips from microchip? I think they are still sampling and the price is listed at $1.73 which would work out very nice in terms of pins used and cost. Anyone used these?

I ordered some but haven't had time to play yet. Did you have something special in mind?

The SpinSocket boards have 2 QSPI footprints (P0..7) so there are lots of opportunities there.
I'd like to try making a fast 256KB VGA buffer with 2 chips ... some day.

Dr_Acula · 2012-11-08 00:25

Thanks jazzed. I'm looking at replicating the Gadgeteer socket standard and one is a standard SPI socket. The other option is the quad spi. The gadgeteer uses 10 pin headers and 3 are for power so lots of things are multiples of 7 which is a little unusual. So you might end up with 3 bits instad of 4??

http://gadgeteer.codeplex.com/wikipage?title=.NET%20Gadgeteer%20Socket%20Types

Or... you could use a "S" SPI header and a "Y" GPIO header and that would give you 8 bits.

The gadgeteer socket system gives you lots of flexibility and you can reconfigure the hardware quickly.

I'll probably just stick with a standard SPI port for the moment. Good to hear these chips do exist and you can get samples. That makes it worth making a board.

Dr_Acula · 2012-11-09 00:15

There is nothing particularly clever about this board attached except that
1) it is using a 10 way gadgeteer header which makes mixing and matching peripherals a lot easier and
2) The pinouts for the 32k, 64k and 128k chips are all the same so once the chips become more widely available it is very easy to upgrade ram.

jazzed · 2012-11-09 12:08

That's neat. I have a simple SOIC -> DIP design that would work with that. TSSOP -> DIP would be easy too.
You could probably add a footprint to your board just as easily.

Dr_Acula · 2012-11-09 21:27

Thanks jazzed. I added that footprint to the design - I found a pad in the Sparkfun library for Eagle. See attached pictures (the SPI ram is in the second picture).

These give a bit of an idea what I'm trying to do, and it ties in with this thread with fast SPI.

These are all experimental boards but you can see the sorts of prices BatchPCB charges and it is possible to put those on the BatchPCB marketplace so others can use them. But I'd prefer to test them first! (almost sent off one board with the keyboard socket the wrong way round for instance).

The motherboard is a propeller with a bunch of sockets with pins in groups of 7, and other sockets in groups of 4 (for SD and SPI) and also groups of 2. So lots of flexibility to plug things together in different ways.

I added a screenshot of the Gadgeteer system for C#. You have pictures of boards on the screen, plug them together and then it writes the skeleton code in C. So if you add an SD card, it adds the SD driver with the correct pins already in code. Not hugely complicated and it greatly simplifies building things. If you add a ram board, it knows how much ram you have and can give a warning if almost full. Ditto if you plug boards in that use the same propeller pins.

Behind the scenes, what I want is a touchscreen and external ram and an SD card running off one propeller. I think I can do this as the touchscreen uses 14 pins, the SD card 4, the touch SPI 4, the external ram 4, and there are 2 spare for audio or a serial board, and there is also the I2C bus. But what I also want to do is quickly change it so it runs with a TV. Or a VGA screen etc.

So the idea to run up the flagpole is to ask whether SimpleIDE could incorporate pictures of boards with little wires joining them, and behind the scenes, add the appropriate #include files and put in the correct pin numbers?

"Fast" SPI flash cache driver

Comments