Files

Dr_Acula · 2012-05-11 04:34

Sorry to be firing off lots of questions here.

Is there a demo for working with files?

I am assuming when you open a file it opens something on the sd card, not eeprom or anywhere else. In the code below, the file does not exist yet and it is being opened for writing. I'm getting an error back saying "can't open file". ... see below for more commentary

#include <stdio.h>
#include <propeller.h>
#include <string.h>
#include <stdarg.h>
#include <stdlib.h>

typedef unsigned char UCHAR;
typedef unsigned long DWORD;
typedef unsigned long UINT;

static char    a[2048];
static int     z;
static FILE   *fp1;

char*   BCX_TmpStr(size_t);
char*   str (double);

int main(int argc, char *argv[])
{
strcpy(a,"Test");
if((fp1=fopen(a,"w"))==0)
 {
fprintf(stderr,"Can't open file %s\n",a);exit(1);
 }
}

I found Dave Hein's code http://code.google.com/p/propgcc/source/browse/demos/c3files/src/filetest.c?r=5cbec3c195d78d733040ab6a814fb8f3953bfe23

but it says it can't fine dfs.h

Is this an essential part of file handling?

addit - found dfs.h and dosfs.h with a google search http://code.google.com/p/propgcc/source/browse/demos/c3files/src/dosfs.h?r=5cbec3c195d78d733040ab6a814fb8f3953bfe23

Getting an error now

if (dfs_rmdir(argv[i]))

saying this has not been declared, plus about 10 other errors.

Any simple file handling demos available - eg open a file, write a couple of bytes, close the file.

mindrobots · 2012-05-11 06:09

Fire away! I'm trying to help document things, so any questions you have are questions others will have. The bad part of your "pioneer" role is sometimes there isn't anything to offer you as a solution.

I haven't played with the SD and file I/O yet. There is a demo for the C3 using the SD and file I/O but there needs to be more for folks unfamiliar with C file I/O and/or Propeller SD support.

As I write this, I'm wondering what the minimum hardware configuration to support SD is and if we need another one of those matrices showing what memory models/hardware/features are compatible.

Sorry I can't help but hopefully the smart guys will be along soon.

Please keep trying things and asking, all these threads are valuable to the documentation/tutorial efforts!!

Dave Hein · 2012-05-11 06:37

There's a c3files demo under propgcc/demos. It supports the C3 board by default, but it includes SD pin settings for other boards also. The version of this demo that's included with the SimpleIDE may be called filetest. Using the file I/O routines requires that you explicitly include the file driver in the driver list. Look at filetest.c to see how it's done.

There have been some recent changes to the file I/O startup, but I don't think that's in the SimpleIDE yet.

Dr_Acula · 2012-05-11 07:12

Yes it looks like there is some code for the C3. The hardware I have should be even simpler - just 4 pins to an SD card and those pins do nothing else and are not shared or multiplexed in any way.

So whatever setup people have - if you have an SD card then it ought to be possible just to change the pin numbers.

I am using XMM which is caching off the SD card so there is always the possibility of a conflict there but I'm sure that has been thought of.

jazzed · 2012-05-11 10:02

Dr_Acula wrote: »

Yes it looks like there is some code for the C3.

There are #defines for other boards in c3files.

You can read pin from the .cfg files now with config variable patching, but I don't have an example ready yet.
There is also an improvement coming in sdcard variable patching that reduces the memory footprint.

We have thought of the conflicts in a few different ways. You can use a lock, or you can use HUBTEXT.

Dr_Acula · 2012-05-16 21:26

I'm working on simplifying the problem as much as possible. So with some removal of code and #includes I have it small enough to fit in LMM. That eliminates any caching conflicts as the problem.

I know the SD card is working because downloading large programs to the SD card work.

I'm still not entirely sure of how these config files are working. It seems there is a starting file but then it creates other files the first time you do a XMM download. But it seems to edit the original file. So I am not really sure if this is downloading in XMM or LMM. I think it is LMM because it is a lot faster to download and less messages come up.

So this is the config file

# [propboe]
# IDE:SDXMMC
    clkfreq: 80000000
    clkmode: XTAL1+PLL16X
    baudrate: 115200
    rxpin: 31
    txpin: 30
    cache-driver: eeprom_cache.dat
    cache-size: 8K
    cache-param1: 0
    cache-param2: 0
    eeprom-first: TRUE
    sd-driver: sd_driver.dat
    sdspi-do: 24
    sdspi-clk: 25
    sdspi-di: 26
    sdspi-cs: 27

and this is my C file. The file is being opened for "write" so it does not exist yet. Is the C code correct?

#include <stdio.h>
#include <propeller.h>
//#include <string.h>
//#include <stdarg.h>
#include <stdlib.h>

typedef unsigned char UCHAR;
typedef unsigned long DWORD;
typedef unsigned long UINT;

static char    a[80];
static FILE   *fp1;

//char*   BCX_TmpStr(size_t);
char*   str (double);

int main(int argc, char *argv[])
{
strcpy(a,"Test");
if((fp1=fopen(a,"w"))==0)
 {
fprintf(stderr,"Can't open file %s\n",a);exit(1);
 }
}

jazzed · 2012-05-16 22:57

Hi Dr_Acula,

Your example is missing a mount which would not have worked ... until SimpleIDE v0-6-11 with PropellerGCC v0-3-1 that is.

David Betz recently added a feature that lets the file-system automatically mount using the .cfg file properties. That is, you no longer have to be concerned with calling dfs_mount, etc.... You only need to make sure you select the right .cfg file.

Download the SimpleIDE v0-6-11 package and retry your example. I produced a "tvkbfile" example that does something similar, but it is much more complicated (and it fits in HUB RAM with LMM mode). Your example should be relatively small.

SimpleIDE will only do XMM stuff if you select one of XMMC, XMM-SINGLE, or XMM-SPLIT memory models for your build.

--Steve

Dr_Acula · 2012-05-17 01:01

Thanks ++ for the quick reply. I'll download the new version and check it out

Here is another reason to get into C++ - a .jpg decoder

http://olickspulpit.blogspot.com.au/2010/04/simple-jpeg-encoder.html and click on the link in post #2 (too big to post on the forum).

Decoding .jpg files is a big part of the html viewer I want to get working on the touchscreen as not many sites use .bmp files.

Dave Hein · 2012-05-17 11:34

Dr_A, I ported the IJG JPEG encoder and decoder to the C3 board several months ago. The IJG is highly portable, so it wasn't too difficult to get it to run. I had to run it in XMM mode, it was very slow. It took around a minute to decode a small image of around 128x128 in size. The inverse DCT takes quite a few cycles. I've looked at faster algorithms that replace the multiplications with shifts and adds, but I haven't coded it in PASM yet. That's one of the things on my TODO list.

The Prop is limited in the size of the image it can handle because of it's 32K RAM. You will need a buffer that is 16*3*W in size, where W is the image width. If you used the entire RAM for this buffer the maximum image width would be 672 pixels.

One thing you might consider is to just decode the DC portion of the image. This would give you an image that is one-eigth the size of the original image, and wouldn't require a DCT. A 1024x768 image would yield a 128x96 thumb-nail image. It might be suitable for small low-res displays.

Dr_Acula · 2012-05-17 17:28

I've looked at faster algorithms that replace the multiplications with shifts and adds, but I haven't coded it in PASM yet. That's one of the things on my TODO list.

I know the feeling - my propeller "to do" list is getting longer and starting to interfere with the honey do list.

Is it possible to split it up into smaller chunks? I don't know much about the jpg algorithm. With the fast transfers to and from external ram in the touchscreen driver it is pretty easy to move a chunk of data into and out of hub. Fill the hub in under 10ms. So then if a cog could be fired up and process that chunk, then move it back out to external ram.

But does every pixel depend on every other pixel? Or are they 8x8 blocks? Reading this at the moment... http://en.wikipedia.org/wiki/JPEG

Would the pasm version use a cordic algorithm to avoid the need for multiplies?

jazzed · 2012-05-17 22:31

Dr_Acula,

I'm a little confused by this thread and another where you said you have problems with files. But in another post you said everything was working. Follow up?

Thanks,
--Steve

Dr_Acula · 2012-05-18 06:55

Yes sorry about that, when I said it was working, I meant the XMM with the SD cache was working. That meant that the SD pins etc were correct.

However, I am still stuck writing a C program that can access the SD card.

#include <stdio.h>
#include <propeller.h>
//#include <string.h>
//#include <stdarg.h>
#include <stdlib.h>

typedef unsigned char UCHAR;
typedef unsigned long DWORD;
typedef unsigned long UINT;

static char    a[80];
static FILE   *fp1;

//char*   BCX_TmpStr(size_t);
char*   str (double);

int main(int argc, char *argv[])
{
strcpy(a,"Test");
if((fp1=fopen(a,"w"))==0)
 {
fprintf(stderr,"Can't open file %s\n",a);exit(1);
 }
}

I downloaded the latest 113Mb file from http://code.google.com/p/propgcc/downloads/list and copied all files over the existing files. However that package did not seem to include the latest SimpleIDE program. The one I have is 0.6.8. Do I need to update the SimpleIDE program as well in order to get the above program to open the SD card? If so, is there a link somewhere for the latest SimpleIDE program?

Many thanks in advance.

David Betz · 2012-05-18 07:01

You need to put something like this in your program if you want to access the filesystem. I'd like to make this happen automatically but it isn't possible given the current device driver architecture. If you don't include the FileDriver then fopen will fail if you try to open or create a file.

extern _Driver _SimpleSerialDriver;
extern _Driver _FileDriver;

/* This is a list of all drivers we can use in the
 * program. The default _InitIO function opens stdin,
 * stdout, and stderr based on the first driver in
 * the list (the serial driver, for us)
 */
_Driver *_driverlist[] = {
  &_SimpleSerialDriver,
  &_FileDriver,
  NULL
};

jazzed · 2012-05-18 08:45

Dr_Acula wrote: »

Yes sorry about that, when I said it was working, I meant the XMM with the SD cache was working. That meant that the SD pins etc were correct.

Ok, guess I missed the context. Sorry about that.

Looks like David pointed out the key requirement your code is missing for the file-system.
That code can be put into a separate file included in the project.

Dr_Acula wrote: »

I downloaded the latest 113Mb file from http://code.google.com/p/propgcc/downloads/list and copied all files over the existing files. However that package did not seem to include the latest SimpleIDE program. The one I have is 0.6.8. Do I need to update the SimpleIDE program as well in order to get the above program to open the SD card? If so, is there a link somewhere for the latest SimpleIDE program?

SimpleIDE 0-6-11 has the latest propeller-gcc compiler.
You can find it here: http://code.google.com/p/propside/downloads/list
I'll be updating the SimpleIDE packages again next week to version 0-7-0.

Dave Hein · 2012-05-18 09:30

Dr_Acula wrote: »

Is it possible to split it up into smaller chunks? I don't know much about the jpg algorithm. With the fast transfers to and from external ram in the touchscreen driver it is pretty easy to move a chunk of data into and out of hub. Fill the hub in under 10ms. So then if a cog could be fired up and process that chunk, then move it back out to external ram.

But does every pixel depend on every other pixel? Or are they 8x8 blocks? Reading this at the moment... http://en.wikipedia.org/wiki/JPEG

Would the pasm version use a cordic algorithm to avoid the need for multiplies?

The buffer size I described was to hold 16 lines of a 3-component image. It's possible to get by with a 16x16x3 buffer. JPEG images are coded in small 8x8 blocks. The chroma components are normally half the resolution horizontally, and usually half the resolution vertically. This requires a 16x16x3 block of memory to hold the red, green and blue components when they are converted from YUV (or more precisely YCrCb).

The DC coefficients of each 8x8 block are differentially coded based on the previous 8x8 block. So you need to decode all of the prior DC coefficients to be able to decode a particular DC value. The AC coefficients are self-contained in each 8x8 block.

The pasm version would be more efficient using hard-coded shifts and adds versus a multiplier or cordic algorithm.

Dr_Acula · 2012-05-19 17:23

Hi David,

I tried this code - the behaviour is now a little different as it hangs at "try opening a file" whereas before it was saying that it could not open the file. It doesn't get any further though - no message about either the file being open or not being open.

I'm running back in XMMC as the additional code pushed it back over the threshold for LMM. In an ideal world I'd like to debug using LMM as that will remove the variable of the cache driver interfering with file access. Not sure if this code can be shrunk much more though.

I'm sure this is just my lack of understanding of C. Many thanks for all the help here - I'm sure we will get there.

#include <stdio.h>
#include <propeller.h>
//#include <string.h>
//#include <stdarg.h>
#include <stdlib.h>

extern _Driver _SimpleSerialDriver;
extern _Driver _FileDriver;

typedef unsigned char UCHAR;
typedef unsigned long DWORD;
typedef unsigned long UINT;

static char    a[80];
static FILE   *fp1;


char*   str (double);

/* This is a list of all drivers we can use in the
 * program. The default _InitIO function opens stdin,
 * stdout, and stderr based on the first driver in
 * the list (the serial driver, for us)
 */
_Driver *_driverlist[] = {
  &_SimpleSerialDriver,
  &_FileDriver,
  NULL
};

int main(int argc, char *argv[])
{
strcpy(a,"Test"); // open a file for writing
printf("Try opening file\n");
if((fp1=fopen(a,"w"))==0)
 {
fprintf(stderr,"Can't open file %s\n",a);
 }
printf("File is open\n");
while(1);
}

jazzed · 2012-05-19 18:06

Your program works for me on C3.

What board type do you have set?
You should consider adding a waitcnt(CLKFREQ+CNT); before output for terminal connect time.

Can you copy paste your load output here?
Right click Build Status window, Select All. Right click Build Status window again Copy.

Here's what I get for XMMC.

Project Directory: C:/gccdev/propside/MyProjects/DrAFile/
propeller-elf-gcc.exe -o a.out -Os -mxmmc -I . -Wall -fno-exceptions DrAFile.c
propeller-elf-objdump -h a.out
Done. Build Succeeded!
propeller-load.exe -I C:/propgcc/propeller-load/ -b C3F -p COM16 a.out -rLoading the serial helper to hub memory
9528 bytes sent
Verifying RAM ... Patching __cfg_sdspi_config2 with 19080005
Loading cache driver 'c3_cache_flash.dat'
1468 bytes sent             
Loading program image to flash
30572 bytes sent             
Loading .xmmkernel
1724 bytes sent

Here's what I get for LMM.

Project Directory: C:/gccdev/propside/MyProjects/DrAFile/
propeller-elf-gcc.exe -o a.out -Os -mlmm -I . -Wall -fno-exceptions DrAFile.c
propeller-elf-objdump -h a.out
Done. Build Succeeded!
propeller-load.exe -I C:/propgcc/propeller-load/ -b C3F -p COM16 a.out -rLoading a.out to hub memory
29592 bytes sent
Verifying RAM ... Patching __cfg_sdspi_config1 with 090a0b13
Patching __cfg_sdspi_config2 with 19080005
OK

In both cases I get "File is open" on the terminal and no "Can't open file ...".

Dr_Acula · 2012-05-20 03:06

Hmm - mine looks shorter than that (XMMC that is, as LMM is still too big to compile). How do you copy the build menu again? If I right click copy I can only copy one line. If I right click and select "select all" it then grays out the "copy" option.

average joe · 2012-05-20 06:23

I have been following along, and I'm stuck where Doc is... Same board, same configuration. Here's the board config

# [dracTouch]
# IDE:SDXMMC
    clkfreq: 80000000
    clkmode: XTAL1+PLL16X
    baudrate: 115200
    rxpin: 31
    txpin: 30
    cache-driver: eeprom_cache.dat
    cache-size: 8K
    cache-param1: 0
    cache-param2: 0
    eeprom-first: TRUE
    sd-driver: sd_driver.dat
    sdspi-do: 24
    sdspi-clk: 25
    sdspi-di: 26
    sdspi-cs: 27

and the C code:

#include <stdio.h>
#include <propeller.h>
//#include <string.h>
//#include <stdarg.h>
#include <stdlib.h>

extern _Driver _SimpleSerialDriver;
extern _Driver _FileDriver;

typedef unsigned char UCHAR;
typedef unsigned long DWORD;
typedef unsigned long UINT;

static char    a[80];
static FILE   *fp1;


char*   str (double);

/* This is a list of all drivers we can use in the
 * program. The default _InitIO function opens stdin,
 * stdout, and stderr based on the first driver in
 * the list (the serial driver, for us)
 */
_Driver *_driverlist[] = {
  &_SimpleSerialDriver,
  &_FileDriver,
  NULL
};

int main(int argc, char *argv[])
{
strcpy(a,"Test"); // open a file for writing
waitcnt(CLKFREQ+CNT);
printf("Try opening file\n");
if((fp1=fopen(a,"w"))==0)
 {
fprintf(stderr,"Can't open file %s\n",a);
 }
printf("File is open\n");
while(1);
}

For the board type, I copied the Dracblade.cfg and changed the pins for the SD card. HelloWorld runs fine. For LMM the build window is:

Project Directory: C:/Users/Joe/Documents/test/


propeller-elf-gcc.exe -o a.out -Os -mlmm -I . -fno-exceptions -Dprintf=__simple_printf test.c -s
propeller-elf-objdump -h a.out
Done. Build Succeeded!

propeller-load.exe -Dreset=dtr -b DRACTOUCH -p COM21 a.out -rLoading a.out to hub memory

30260 bytes sent
Verifying RAM ... OK

and for xmmC:

#include <stdio.h>
#include <propeller.h>
//#include <string.h>
//#include <stdarg.h>
#include <stdlib.h>

extern _Driver _SimpleSerialDriver;
extern _Driver _FileDriver;

typedef unsigned char UCHAR;
typedef unsigned long DWORD;
typedef unsigned long UINT;

static char    a[80];
static FILE   *fp1;


char*   str (double);

/* This is a list of all drivers we can use in the
 * program. The default _InitIO function opens stdin,
 * stdout, and stderr based on the first driver in
 * the list (the serial driver, for us)
 */
_Driver *_driverlist[] = {
  &_SimpleSerialDriver,
  &_FileDriver,
  NULL
};

int main(int argc, char *argv[])
{
strcpy(a,"Test"); // open a file for writing
waitcnt(CLKFREQ+CNT);
printf("Try opening file\n");
if((fp1=fopen(a,"w"))==0)
 {
fprintf(stderr,"Can't open file %s\n",a);
 }
printf("File is open\n");
while(1);
}

I'm pretty clueless here, but thought I'd give it a try. Program hangs after

printf("Try opening file\n");

I'll check out the file system? Works fine in FSRW and KYE's driver though?

jazzed · 2012-05-20 06:58

average joe wrote: »
I have been following along, and I'm stuck where Doc is... Same board, same configuration. Here's the board config

For the board type, I copied the Dracblade.cfg and changed the pins for the SD card. HelloWorld runs fine. For LMM the build window is:
Project Directory: C:/Users/Joe/Documents/test/


propeller-elf-gcc.exe -o a.out -Os -mlmm -I . -fno-exceptions -Dprintf=__simple_printf test.c -s
propeller-elf-objdump -h a.out
Done. Build Succeeded!

propeller-load.exe -Dreset=dtr -b DRACTOUCH -p COM21 a.out -rLoading a.out to hub memory

30260 bytes sent
Verifying RAM ... OK

I'm not seeing some critical information in your dump. It should show a line like this:
Patching __cfg_sdspi_config2 ...

Seems that you don't have SimpleIDE 0-6-11. What's the version in the Menu->Help->About ?

average joe · 2012-05-20 07:15

I noticed that was missing. SimpleIDE is 0-6-11. In the PropGCC folder I have a "propgcc_v0_2_3.txt" file. Not sure if that's up to date... I might try another re-install?
Looks like 0-3-1 is current? I'm updating to this and will try again!

jazzed · 2012-05-20 07:32

average joe wrote: »

I noticed that was missing. SimpleIDE is 0-6-11. In the PropGCC folder I have a "propgcc_v0_2_3.txt" file. Not sure if that's up to date... I might try another re-install?
Looks like 0-3-1 is current? I'm updating to this and will try again!

Actually, you might have propgcc version 0-3-1 already. It should be installed with 0-6-11.
Can you open a command window and type propeller-elf-gcc --version?

I get this:

> propeller-elf-gcc --version
propeller-elf-gcc.exe (propgcc_v0.3.1) 4.6.1
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

average joe · 2012-05-20 07:44

Yep, that's what I get. Next thing to check?
I ?think? it has something to do with the board configuration. I made no changes other than the pin numbers for the DracTouch.cfg

I appreciate all the help!

jazzed · 2012-05-20 08:18

average joe wrote: »

Yep, that's what I get. Next thing to check?
I ?think? it has something to do with the board configuration. I made no changes other than the pin numbers for the DracTouch.cfg

I appreciate all the help!

Thank you for trying!

Can you do use your command line window to try the propeller-load separately from SimpleIDE?

That is:

Start->Run->cmd (winXP) or Start->Search->cmd (win7)
cd C:\Users\Joe\Documents\test
dir - make sure you have a.out that should be 30260 bytes as you reported for LMM
propeller-load -r -t a.out -b DracTouch
copy/paste the output here.

My propeller-load command output looks like this:

>propeller-load -r -t a.out -b c3f
Propeller Version 1 on COM16
Patching __cfg_sdspi_config1 with 090a0b13
Patching __cfg_sdspi_config2 with 19080005
Loading a.out to hub memory
30284 bytes sent
Verifying RAM ... OK
[ Entering terminal mode. Type ESC or Control-C to exit. ]
Try opening file
File is open

If you don't see "patching" messages, there is something wrong with your copy of the distribution.
If you do see the "patching" messages, then I have more IDE work to do and there is a board config issue.

Thanks,
--Steve

/**
 * @file DrAFile.c
 * This is the main DrAFile program start point.
 */
#include <stdio.h>
#include <propeller.h>
extern _Driver _SimpleSerialDriver;
extern _Driver _FileDriver;
typedef unsigned char UCHAR;
typedef unsigned long DWORD;
typedef unsigned long UINT;
static char    a[80];
static FILE   *fp1;
/* This is a list of all drivers we can use in the
 * program. The default _InitIO function opens stdin,
 * stdout, and stderr based on the first driver in
 * the list (the serial driver, for us)
 */
_Driver *_driverlist[] = {
  &_SimpleSerialDriver,
  &_FileDriver,
  NULL
};
/**
 * Main program function.
 */
int main(int argc, char *argv[])
{
    // pause a moment for terminal to open.
    waitcnt(CLKFREQ+CNT);
    strcpy(a,"Test"); // open a file for writing
    printf("Try opening file\n");
    if((fp1=fopen(a,"w"))==0)
        fprintf(stderr,"Can't open file %s\n",a);
    else
        printf("File is open\n");
    fclose(fp1);
    while(1);
}

average joe · 2012-05-20 08:42

Ooook, here's what I get. "a.out" is 31,084 ? SimpleIde status bar reports Code Size 30,260 bytes, (31,124 total)
I have something wrong with distro apparently?

C:\Users\Joe\Documents\test>propeller-load -r -t a.out -b DracTouch
Propeller Version 1 on COM21
Loading a.out to hub memory
30260 bytes sent
Verifying RAM ... OK
[ Entering terminal mode. Type ESC or Control-C to exit. ]
Try opening file

jazzed · 2012-05-20 09:01

average joe wrote: »

Ooook, here's what I get. "a.out" is 31,084 ? SimpleIde status bar reports Code Size 30,260 bytes, (31,124 total)
I have something wrong with distro apparently?

I'll recheck some things and post again later.

Thanks,
--Steve

jazzed · 2012-05-20 10:01

Hmm. Looks like there is a distribution problem. I haven't figured it out yet. Thought it was a loader issue - scratching my head now.

Thanks,
--Steve

average joe · 2012-05-20 10:50

Very strange. I tried your loader and there's no patching. I'm wondering what would disable patching?

OK, I think I've figured something out. I don't get the patching, because my catching isn't "c3_cache_flash.dat", it's "eeprom_cache.dat"
I'm wondering about these stock dat files. What would need to be changed?

jazzed · 2012-05-20 13:10

average joe wrote: »

Very strange. I tried your loader and there's no patching. I'm wondering what would disable patching?

OK, I think I've figured something out. I don't get the patching, because my catching isn't "c3_cache_flash.dat", it's "eeprom_cache.dat"
I'm wondering about these stock dat files. What would need to be changed?

The cache thing is a red-herring for this particular issue. At some point another cache driver will be necessary, but for a 64KB eeprom, the eeprom_cache.dat is fine. If your eeprom is 32KB, that's a separate issue.

This issue is more than a loader problem, it is a windows package issue. I'm building a new package, but I need time. I'll post a new package later.

Thanks,
--Steve

average joe · 2012-05-20 13:23

Well if having a 32k eeprom has anything to do with it, then that's part of the problem. I'm curious if you could point me in the direction of building a cache. I'm way out of my comfort zone here so not trying to be a pest, just trying to get things figured out!
Thanks again!

jazzed · 2012-05-20 13:40

No problem Joe.

Here's the code for eeprom_cache.spin Click View raw file on that page to download. It is a write once (by loader) read many implementation for xmmc model.

Here's the code for dracblade_cache.spin Click View raw file on that page to download. This is a write/read implementation and can use xmmc or xmm-single models.

Files

Comments