I use the Propeller to build scientific instruments; see here for details – www.instruments4chem.com
For most of my projects, 32kB of HUB RAM has been perfectly adequate, but there are times when more memory would certainly be useful. I’ve had previous experience using HyperRAM in several XMOS-based projects. HyperRAM is low cost/MB and interfacing to it requires a minimal pin count.
Over on the P2 forum I’ve recently posted some code for a P2 FPGA emulation interfaced to an 8MB ISSI HyperRAM chip. That project provided an opportunity for me to learn how to use some of the great new features on the P2 (streamer and smart pins).
In the absence of a real P2 in silicon, however, the P1 remains my go to workhorse and I’ve leveraged the knowledge gained from previous experiences to now make available a P1 HyperRAM solution.
Here’s a summary of the hardware/software details :
HyperRAM PCB footprint is just 6mm x 8mm in a 24 pin FBGA package
Apart from that, just a couple of decoupling caps are needed
Code is written in SPIN, launching 3 COG’s running PASM to manage the HyperRAM interface
14 pins are dedicated to this interface, leaving 14 free for user applications
Data transfer rate between HUB RAM and HyperRAM is ~1.6 MBytes/sec
(that figure is based on code – see below - moving 24576 bytes between the two)
I’ve attached some images to show my setup. My initial prototype can be seen in ProtoHR.jpg. There were a few issues with this PCB that required correcting (hence the bizarre wire link, seemingly connecting Vcc and GND !!) and I’m currently waiting on a new PCB – OSHPark_HR that will address these.
Here, header J5 breaks out 3.3V, GND and Propeller pins P0-P13, and J6 : 3.3V, GND and P14-P27. I’m currently making some shields that plug into these headers but i'll say more about those in a future post.
The other two images (LabVIEW_HR and LV_HR_Expanded) show a LabVIEW screen; here my PC is interacting with the Propeller via its on-board FT232RL. Here’s what happens :
On launch, SPIN code first fills a 24576 byte array with 6 different math functions (6 x 4096 bytes).
This array is written in its entirety into HyperRAM as 1536 (Repeats16) x 16 byte buffers, then is read back into HUB RAM, then uploaded to the PC and displayed into the “HyperRAM Data” graph window. BTW I refer to each of these buffers as a “block”.
That whole process then gets repeated 340 times (the Iterations field) – resulting in a total of 8,355,840 bytes being moved back and forth between HUB RAM and HyperRAM. During such a run, the current block field is constantly incrementing by 1536 on each iteration.
Data integrity will be maintained throughout the run only if the data transfers are rock solid. I’ve used the continuous running mode in LabVIEW (its double arrow button mode) to exercise the above sequence over and over (tens of hours) and so far it’s all looking good.
A couple of other things :
The SendC field here is set to 1 the very first time this vi is run – that sets up the two HyperRAM configuration registers CR0 and CR1.
Delay/ms provides a LabVIEW delay between issuing HyperRAM write and read commands - which for 1536 of these 16 byte buffers each take a tad over 15 msec.
I’m currently working on documentation - I'll post my code here in the next couple of days.
Finally, in closing - there’s now a dual die stack 16MB version of HyperRAM (!!) ; I’ll be exploring that when I get my new PCB – but I expect it will be fairly straightforward to get working since it will have exactly the same interface.