Yeah, I decided it's best to have the example tester programs use the boot pins and built-in driver by default so then can see it working before testing new hardware.
Looks like you've found all the settings.
Driver doesn't have to be in a subdirectory. That was mainly because of multiple drivers.
The struct __using() and _sdsd_open() is the install instructions.
@evanh it might be handy to include a small readme.txt file in your zip archive stating a few things to help new users out (you might feel this is redundant if you look at that code but for new users it's important to know what to do to get started).
For example to make use of the API in your own code it's not yet built into the tools, so you'll need to create a subfolder under your own application folder called "blkdrvr" and copy the low lever driver files there. Then you can make use of the API from C (or SPIN2) in flexspin that gets used by the demo. Given it's all C based you could mention how to enable the C API calls from SPIN2 via including the libc.a and mmdrv objects, as some SPIN2 users may not yet know about much of that.
Also that you may need to customize the pins (and where you'd modify them). Plus mention any IO restrictions like having the 4 bit DAT pins start on 4 bit pin boundary (although I do see that is listed in the source code), and the difference between the 3 driver file variants in how they operate.
A brief description of the functionality and any IOCTL options available, maybe a short list of the basic APIs and one line description of what it does would be good too even if this is taken from the source.
It's just far nicer for new users to have something to initially start from rather than have to reverse engineer all from the raw code directly, as it will give people more confidence than starting out blind so to speak.
@Rayman said:
Think the 1.0 has a helpful doc that 1.2 does not..
Oh, that tiny .txt in the driver directory, it was a cut'n'paste from Eric's original plugin code for the built-in driver. And I'm not even using that arrangement in the example testers. I've forgotten why Eric did that arrangement, there was some small reason.
The Spin2 example is the best one to read if you're not C familiar already. It shows using the specific objects in Spin2. It'll align better with Basic I suspect also.
In the end though, learning libc is kind of a prerequisite since you're going to be using all the file access functionality from it at the very least. Then using stuff like printf() becomes a no-brainer.
@rogloh said:
It's just far nicer for new users to have something to initially start from rather than have to reverse engineer all from the raw code directly, ...
That's the main reason I have a driver subdirectory. So then the demo speed tester programs are the only sources present at first glance. Any driver otherwise can be right alongside the top level source.
Rayman,
Fire off specific questions in here about the Spin2 speed tester and I'll put more comments in the source code so that people reading it in the future will find it easier.
Roger,
I'll make a quick txt document listing the driver's settings and include the Obex description - which itself links to your excellent schematic for wiring up a suitable SD card slot in the opening post of this topic.
@evanh said:
Roger,
I'll make a quick txt document listing the driver's settings and include the Obex description - which itself links to your excellent schematic for wiring up a suitable SD card slot in the opening post of this topic.
Cool. It's a good way to help describe what this is for new users. I noticed a few typos/grammar errors (is/are) are still in there to clean up when you read closely through it. Although who am I to judge that with all of my later post tidy ups that I end up doing. LOL.
@rogloh said:
Cool. It's a good way to help describe what this is for new users. I noticed a few typos/grammar errors (is/are) are still in there to clean up when you read closely through it. Although who am I to judge that with all of my later post tidy ups that I end up doing. LOL.
A tomorrow job. I'm always fixing dyslexic and grammar and general readability. Most forum posts are re-edited just for this.
By the way the schematic shown here is what I used recently for FireAnt which probably includes a better p-FET for power on/off control vs the original one.
Comments
Did get it going though. Just have to change the RL basepin at the top and then comment/uncomment the correct lines here for sdsd mode:
//static struct __using("blkdrvr/sdmm.cc") DRV; // compiles to 54804 bytes //static struct __using("blkdrvr/sdmm_bashed.cc") DRV; // compiles to 56904 bytes (w/retries) static struct __using("blkdrvr/sdsd.cc") DRV; // compiles to 60596 bytes static FILE * mountsd( void ) { FILE *handle; int rc, clkdiv; uint32_t part; umount("/sd"); _seterror(0); // handle = _sdmm_open(CLK_RL, CS_RL, MOSI_RL, MISO_RL); // handle = _sdmm_open(CLK_EVAL, CS_EVAL, MOSI_EVAL, MISO_EVAL); // handle = DRV._sdmm_open(CLK_RL, CS_RL, MOSI_RL, MISO_RL); // handle = DRV._sdmm_open(CLK_EH, CS_EH, MOSI_EH, MISO_EH); // handle = DRV._sdmm_open(CLK_EVAL, CS_EVAL, MOSI_EVAL, MISO_EVAL); handle = DRV._sdsd_open(CLK_RL, CMD_RL, DAT0_RL, PWR_RL, LED_RL); // handle = DRV._sdsd_open(CLK_EH, CMD_EH, DAT0_EH, -1, -1);Guess this new way of just adding a new folder is easier than old way. Just have to find the install instructions...
Yeah, I decided it's best to have the example tester programs use the boot pins and built-in driver by default so then can see it working before testing new hardware.
Looks like you've found all the settings.
Driver doesn't have to be in a subdirectory. That was mainly because of multiple drivers.
The
struct __using()and_sdsd_open()is the install instructions.PS: You're welcome to work from the Spin2 edition of the tester. There's an updated version with ioctl() added - https://forums.parallax.com/discussion/comment/1569697/#Comment_1569697
Instructions are missing in the latest version zip…
The example source code is the instructions. It's just struct __using() and _sdsd_open(). The rest is normal C file ops, including the use of ioctl().
Or did you just mean the v1.12 zip I posted back a few posts doesn't have the example tester sources included?
@evanh it might be handy to include a small readme.txt file in your zip archive stating a few things to help new users out (you might feel this is redundant if you look at that code but for new users it's important to know what to do to get started).
For example to make use of the API in your own code it's not yet built into the tools, so you'll need to create a subfolder under your own application folder called "blkdrvr" and copy the low lever driver files there. Then you can make use of the API from C (or SPIN2) in flexspin that gets used by the demo. Given it's all C based you could mention how to enable the C API calls from SPIN2 via including the libc.a and mmdrv objects, as some SPIN2 users may not yet know about much of that.
Also that you may need to customize the pins (and where you'd modify them). Plus mention any IO restrictions like having the 4 bit DAT pins start on 4 bit pin boundary (although I do see that is listed in the source code), and the difference between the 3 driver file variants in how they operate.
A brief description of the functionality and any IOCTL options available, maybe a short list of the basic APIs and one line description of what it does would be good too even if this is taken from the source.
It's just far nicer for new users to have something to initially start from rather than have to reverse engineer all from the raw code directly, as it will give people more confidence than starting out blind so to speak.
Think the 1.0 has a helpful doc that 1.2 does not..
Oh, that tiny .txt in the driver directory, it was a cut'n'paste from Eric's original plugin code for the built-in driver. And I'm not even using that arrangement in the example testers. I've forgotten why Eric did that arrangement, there was some small reason.
The Spin2 example is the best one to read if you're not C familiar already. It shows using the specific objects in Spin2. It'll align better with Basic I suspect also.
In the end though, learning libc is kind of a prerequisite since you're going to be using all the file access functionality from it at the very least. Then using stuff like printf() becomes a no-brainer.
That's the main reason I have a driver subdirectory. So then the demo speed tester programs are the only sources present at first glance. Any driver otherwise can be right alongside the top level source.
Rayman,
Fire off specific questions in here about the Spin2 speed tester and I'll put more comments in the source code so that people reading it in the future will find it easier.
Roger,
I'll make a quick txt document listing the driver's settings and include the Obex description - which itself links to your excellent schematic for wiring up a suitable SD card slot in the opening post of this topic.
First run at the readme.
The other text file has good usage notes…
Make a folder under flexprop and copy the three files there…
The "adding a driver ..." text file has no usage at all. It has an incomplete init/mount routine.
Cool. It's a good way to help describe what this is for new users. I noticed a few typos/grammar errors (is/are) are still in there to clean up when you read closely through it. Although who am I to judge that with all of my later post tidy ups that I end up doing. LOL.
By the way the schematic shown here is what I used recently for FireAnt which probably includes a better p-FET for power on/off control vs the original one.
https://forums.parallax.com/discussion/comment/1570122/#Comment_1570122
A tomorrow job. I'm always fixing dyslexic and grammar and general readability. Most forum posts are re-edited just for this.
The original is tidier but I'll add this one too.