@ersmith said:
... so at least in theory someone could hook up multiple SD cards to a single P2.
I've done it. I've bulk copied files from one card to another as one of my test programs ... Or at least I tried, it was a while back and I don't remember the outcome to be honest.
EDIT2: Err, maybe this is all a rubbish idea? I see the struct __using("filesys/block/sdmm.cc") *SDMM; is located in _sdmm_open() function. That's where things are different.
Ada/Eric,
Just thinking about the recent relocation of _sdmm_open() and co. for init of the inbuilt driver. In my driver, I've been happily placing that functionality all directly into the driver source file. It feels tidy to me ... I'm thinking the same could be done here as example for any future third-party driver endeavours. Then all drivers internally get the same API layout.
Only different becomes the whereabouts a driver gets loaded. With third-party it is explicitly a struct __using() in the user code as opposed to buried in the headers.
EDIT: On achieving identical API, splitting off _vfs_open_sdcardx() from _sdmm_open() would be in order. While _sdmm_open() would go into the driver, the legacy functions of _vfs_open_sdcard() and _vfs_open_sdcardx() could go back where they came from. And sdmm_vfs.c would be no more.
Eric,
In the 4-bit SD card driver, in the name of performance, I'm thinking about the idea of patching the presets directly into the hubRAM stored __asm volatile {} code section. This is instead of the current approach of prefilling a structure and then copying the presets from there to cogRAM upon each inline entrance.
I'm not seeing any way to do it without throwing away all locality. Also, I need to keep parameter passing feature of function calling so can't use a global __pasm code section.
EDIT: I guess, what I really need from the parameter passing is its efficient register passing. A global __pasm section could probably be coded to be loaded like fcache and also use a specific set of registers for parameters too ...?
On that note I've never seen how to define a __pasm code section in C. There's no examples that I've seen and the docs don't say much I don't think.
@evanh said:
Eric,
In the 4-bit SD card driver, in the name of performance, I'm thinking about the idea of patching the presets directly into the hubRAM stored __asm volatile {} code section. This is instead of the current approach of prefilling a structure and then copying the presets from there to cogRAM upon each inline entrance.
I don't think there'd be much advantage to that, would there? a SETQ / RDLONG will fetch the parameters at 1 cycle/long once it gets going, the same as the time taken to load them with the FCACHE invocation.
EDIT: I guess, what I really need from the parameter passing is its efficient register passing. A global __pasm section could probably be coded to be loaded like fcache and also use a specific set of registers for parameters too ...?
On that note I've never seen how to define a __pasm code section in C. There's no examples that I've seen and the docs don't say much I don't think.
I see you did figure out how to get __pasm going; it is pretty straightforward, and I think there are examples in the flexprop samples directory. It is an area where we could use more documentation.
Comments
I've done it. I've bulk copied files from one card to another as one of my test programs ... Or at least I tried, it was a while back and I don't remember the outcome to be honest.
EDIT2: Err, maybe this is all a rubbish idea? I see the
struct __using("filesys/block/sdmm.cc") *SDMM;is located in _sdmm_open() function. That's where things are different.Ada/Eric,
Just thinking about the recent relocation of _sdmm_open() and co. for init of the inbuilt driver. In my driver, I've been happily placing that functionality all directly into the driver source file. It feels tidy to me ... I'm thinking the same could be done here as example for any future third-party driver endeavours. Then all drivers internally get the same API layout.
Only different becomes the whereabouts a driver gets loaded. With third-party it is explicitly a
struct __using()in the user code as opposed to buried in the headers.EDIT: On achieving identical API, splitting off _vfs_open_sdcardx() from _sdmm_open() would be in order. While _sdmm_open() would go into the driver, the legacy functions of _vfs_open_sdcard() and _vfs_open_sdcardx() could go back where they came from. And sdmm_vfs.c would be no more.
Eric,
In the 4-bit SD card driver, in the name of performance, I'm thinking about the idea of patching the presets directly into the hubRAM stored
__asm volatile {}code section. This is instead of the current approach of prefilling a structure and then copying the presets from there to cogRAM upon each inline entrance.I'm not seeing any way to do it without throwing away all locality. Also, I need to keep parameter passing feature of function calling so can't use a global __pasm code section.
EDIT: I guess, what I really need from the parameter passing is its efficient register passing. A global __pasm section could probably be coded to be loaded like fcache and also use a specific set of registers for parameters too ...?
On that note I've never seen how to define a __pasm code section in C. There's no examples that I've seen and the docs don't say much I don't think.
Never mind, I took a stab and got it right. Tested and working as expected.
__pasm { testpasm mov pr0, #456 ret }Used an inline call to branch ...
... pr0 = 123; printf("testpasm=%d\n", pr0); __asm { call #testpasm } printf("testpasm=%d\n", pr0); ...Terminal output:
Here’s a crazy question …
Would it be possible to mix spin2 and basic code within one c file?
Sorta like the way you have pasm blocks?
Just wondering how impossible that would be…. Or, maybe already possible?
Guess could include as objects and be sorta the same thing?
That's what you need to do. Can't have different languages in the same object for various reasons.
I don't think there'd be much advantage to that, would there? a
SETQ / RDLONGwill fetch the parameters at 1 cycle/long once it gets going, the same as the time taken to load them with the FCACHE invocation.I see you did figure out how to get __pasm going; it is pretty straightforward, and I think there are examples in the flexprop samples directory. It is an area where we could use more documentation.
Things can get complicated with pasm in c…
Think sometimes gets loaded into cog first and other times just run via hubexec right?