FSRW26 C version
Rsadeika
Posts: 3,846
I just downloaded FSRW26.zip, and to my surprise I found a C source file listing in the zip file. The first thing, I tried to compile it with ICC, which did not compile, it came up with some errors that mentions something about C++. Does anybody know anything more about this, like which compiler you need to use to make this thing work? Was there a discussion about this that I completely missed? Or, is this an evil plot by the authors to make you think that you can use C LOL.
Thanks
Ray
Thanks
Ray
Comments
For example C++ allows comments with // maybe ICC does not.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
#include <cstdio>
#include <cstdlib>
#include <cstring>
The error(s) are basically "... (The header cstdio requires C++)". As I was glancing at the listing, I did not notice the "cstdio, cstdlib, cstring" #include statements. Maybe I missed those three files somewhere in the zip file.
Ray
Ray
strawberryperl.com/
It writes to the console, so you need to use
perl ctospin.pl fsrw.c > fsrw.spin
to write the output to a file.
It's C, not C++, BTW, but I don't know what compiler was used. The include files have non-standard names.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
Post Edited (Leon) : 5/6/2010 1:42:04 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
After looking at the fsrw.c code, I did not find any place where the pin assignments for a SD card adapter were hidden. But, since this is written to run on linux, then you are dealing with an SD adapter on the linux box. So, that would be the first thing to do, pin assignments for the SD adapter card. Still not sure as to the existing functions being able to run in the ICC environment; this could really show the portability of C, if they were able to run with minor tweaking. All suggestions are welcome as to how this conversion could take place.
Since my "free" version of ICC has expired, can anybody guess as to whether the code that I would be dealing with would exceed the limits of the compiler, as it is now? I think the restriction is 4KB, if I am not mistaken. Now, before anybody says use Catalina, the object of this exercise would be, is to make it run using ICC.
Ray
#include <cstdio> #include <cstdlib> #include <cstring>is the C++ version of those files...you may get it to work by changing those to
#include <stdio.h> #include <stdlib.h> #include <string.h>The code is just for testing, so I'm sure you'd have to add some extra code and play with the defines to get the C version to work on the prop. (You'll notice some things that are explicit Spin code, embedded into the C comments.) Only the higher level code is written in C then converted to Spin. The actual block driver is hand-coded in PASM, so you'd also need to duplicate that effort in C to actually communicate with the SD card.
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
The modified fsrw.c is attached below.· I tried running it, but it requires a properly formated SD image file called memcard to run.
Dave
Dave
1. Using dd to copy a raw mounted existing filesystem on a flash card to a file, or
2. Using a loopback mount on linux to mount a file and create a FAT16 filesystem
within that file.
Wow, you're quite right of course about that missing brace. Must be a typo introduced
somehow; I'll investigate when I get time.
-tom
I didn't try the original, but Dave's modified fsrw.c compiles under Catalina (I had to make one additional change because the symbol 'fileno' conflicts with a macro in the Catalina libraries).
However, since the program internally allocates a 12Mb array, there is no way it is ever going to run on any Propeller!
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
It seems like a formated SD card would contain a lot of zeros, and even a 1G disk image would zip down to a few kilo-bytes.· Do you have a freshly formatted memcard image that you could zip up and post?
Dave
Those routines (among other things) check the consistency of the filesystem. That's why it allocates the big array.
The code is pretty short; it should be fairly clear what parts need to be on the prop and what parts don't.
I'm attaching a memory card image. I created this image with the linux command:
mkfs.vfat -F 16 -s 64 -C memcard 2000000
The -F 16 says, create FAT16. The -s 64 says use 64 blocks per sector. The 2000000 says use 2000000 blocks (which
is a lie; it actually uses 4000000 blocks; something's off by a factor of two in that program or something).
To mount the filesystem so you can play with it on linux:
mkdir mountpoint
losetup /dev/loop1 memcard
mount -t vfat /dev/loop1 mountpoint
To unmount it:
umount /dev/loop1
losetup -d /dev/loop1
To check consistency with fsrw:
./fsrw c
To list files:
./fsrw l
To create a file:
./fsrw w filename.txt < data
To show a file:
./fsrw r filename.txt
To delete a file:
./fsrw d filename.txt
To append to a file:
./fsrw a filename.txt < data
If you compile fsrw on a 64-bit machine, use -m32 to get a 32-bit compilation
(the program casts pointers to ints). Or fix the code so it casts pointers to
the appropriate type (the asint macro needs to be fixed; note that this code
is only there so we can treat a pointer as an int in C; in Spin, there is no
distinction).
Also thanks for the explanation about the 64-bit pointers.· I noticed that gcc was warning about casting pointers to ints.· Now I understand why it didn't like that.
Dave
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.