After thinking about it for a while this could be fixed by allowing sd_mount to have a variable number of parameters. If four parameters are specified it would configure for a simple interface like it currently does. If 6 parameters are specified it will configure for a serial SD interface, and if 7 parameters are specified it would configure for parallel. If no parameters are specified it would use the configuration set by the loader. Doing it this way will allow sd_mount to be backwards compatible with the current use for a simple serial interface.
Yes, sd_mount is in the simple tools library. On my Windows machine it is in Documents/SimpleIDE/Learn/"Simple Libraries"/Utility/libsimpletools/source/sddriverconfig.c. I've attached it below. I think my previous post explained what the problem is.
After thinking about it for a while this could be fixed by allowing sd_mount to have a variable number of parameters. If four parameters are specified it would configure for a simple interface like it currently does. If 6 parameters are specified it will configure for a serial SD interface, and if 7 parameters are specified it would configure for parallel. If no parameters are specified it would use the configuration set by the loader. Doing it this way will allow sd_mount to be backwards compatible with the current use for a simple serial interface.
How do you do variable numbers of parameters in C? I know you can do it in C++ by having default values or just alternate versions of functions with different signatures but I think the only way to do it in C is something like the way printf works. You have one parameter that gives cues as to how many additional parameters to expect. Also, if you do it that way, you don't get any error checking on the optional parameters because they occur after the ... in the prototype. Or is there some new feature of C that I'm not aware of?
Yes, variable argument list is done like printf using va_list, but I now realize that the function can't directly determine how many arguments were passed. So it would require at least one argument to indicate the number of arguments passed. The first argument could be an enum that would indicate single, serial, parallel or none. It would then be followed by 4, 6, 7 or 0 additional arguments. This no longer makes is backward compatible with the current sd_mount, so we might want to use a different name.
The other possibility is to always pass 8 arguments, and not bother with variable argument list. So a mount for a simple SD interface would look like sd_mount(SD_Simple, DO, CLK, DI, CS, 0, 0, 0). A mount using the loader configuration would be sd_mount(SD_None, 0, 0, 0, 0, 0, 0, 0). If we would use variable argument lists this would be sd_mount(SD_Simple, DO, CLK, DI, CS) and sd_mount(SD_None). This could be done in C. I think overloading would require C++.
Yes, variable argument list is done like printf using va_list, but I now realize that the function can't directly determine how many arguments were passed. So it would require at least one argument to indicate the number of arguments passed. The first argument could be an enum that would indicate single, serial, parallel or none. It would then be followed by 4, 6, 7 or 0 additional arguments. This no longer makes is backward compatible with the current sd_mount, so we might want to use a different name.
The other possibility is to always pass 8 arguments, and not bother with variable argument list. So a mount for a simple SD interface would look like sd_mount(SD_Simple, DO, CLK, DI, CS, 0, 0, 0). A mount using the loader configuration would be sd_mount(SD_None, 0, 0, 0, 0, 0, 0, 0). If we would use variable argument lists this would be sd_mount(SD_Simple, DO, CLK, DI, CS) and sd_mount(SD_None). This could be done in C. I think overloading would require C++.
Why not separate functions? sd_mount (same as now), sd_mount_serial, sd_mount_parallel, etc?
Yes, that was one of my suggestion in post #15. That's probably the cleanest way to do it. It doesn't break the current functionality and adds support for serial/parallel SD interfaces.
Yes, that was one of my suggestion in post #15. That's probably the cleanest way to do it. It doesn't break the current functionality and adds support for serial/parallel SD interfaces.
Ya, it would be silly to change the current function definition. Adding a new one wouldn't hurt at all.
I'm not sure why you aren't able to get filetest working on the C3. Here is the output that I got when I tried running it in XMMC mode using the C3F cache driver under release_1_0.
propeller-load -bc3f filetest.elf -r -t
Propeller Version 1 on /dev/cu.usbserial-A8004ILf
Patching __cfg_sdspi_config1 with 090a0b13
Patching __cfg_sdspi_config2 with 19080005
Loading the serial helper to hub memory
10392 bytes sent
Verifying RAM ... OK
Loading cache driver 'c3_cache_flash.dat'
1620 bytes sent
Loading program image to flash
38556 bytes sent
Loading .xmmkernel
1736 bytes sent
[ Entering terminal mode. Type ESC or Control-C to exit. ]
Commands are help, cat, rm, ls, ll, echo, cd, pwd, mkdir and rmdir
> ls
propsd ~1.tra test2.bas trashe~1 spotli~1
blink.bas test.bas autorun.pex
> cat blink.bas
10 high(15)
15 for x=1 to 10
20 toggle(15)
30 pause(500)
40 next x
>
Can you try this again using the current src tree. Using xmmc and c3 I get an I/O error. (I've checked the uSD on a different machine
its ok)
dolly:filetest petry$ make MODEL=xmmc
propeller-elf-gcc -mxmmc -Os -mfcache -c filetest.c -o filetest.o
propeller-elf-gcc -mxmmc -fno-exceptions -fno-rtti filetest.o -o filetest.elf
dolly:filetest petry$ propeller-load -bc3 filetest.elf -r -t
error: opening serial port '/dev/cu.usbserial-000042FD'
Error is : No such file or directory
dolly:filetest petry$ propeller-load -bc3 filetest.elf -r -t -p /dev/cu.usbserial-0000101D
error: opening serial port '/dev/cu.usbserial-0000101D'
Error is : Resource busy
dolly:filetest petry$ propeller-load -bc3 filetest.elf -r -t -p /dev/cu.usbserial-0000101D
Propeller Version 1 on /dev/cu.usbserial-0000101D
Patching __cfg_sdspi_config1 with 090a0b13
Patching __cfg_sdspi_config2 with 19080005
Loading the serial helper to hub memory
9808 bytes sent
Verifying RAM ... OK
Loading external memory driver 'c3_xmem.dat'
956 bytes sent
Loading program image to flash
39812 bytes sent
Loading .xmmkernel
1984 bytes sent
[ Entering terminal mode. Type ESC or Control-C to exit. ]
Commands are help, cat, rm, ls, ll, echo, cd, pwd, mkdir and rmdir
> ls
./: I/O error
> pwd
/
There seems to be a need for a lot of documentation cleanup with the cache-drivers to xmem-drivers
migration. One that was very helpful in the past, but needs updating is propeller-load (loader.pdf V.1)
Is there a headsup that is planed for folks using SimpleIDE?
There seems to be a need for a lot of documentation cleanup with the cache-drivers to xmem-drivers
migration. One that was very helpful in the past, but needs updating is propeller-load (loader.pdf V.1)
Is there a headsup that is planed for folks using SimpleIDE?
Thanks,
Mike
Yes, documentation needs to be updated before we are ready to make a release from the default branch. At this point I don't believe there is any plan for when to move the default branch into production. One problem is that it supports generating code for the P2 and that instruction set is not yet stable.
Comments
I'll talk to Andy about this suggestion.
Can we use the weak binding attribute to overload the function? I'd rather not use varargs.
The other possibility is to always pass 8 arguments, and not bother with variable argument list. So a mount for a simple SD interface would look like sd_mount(SD_Simple, DO, CLK, DI, CS, 0, 0, 0). A mount using the loader configuration would be sd_mount(SD_None, 0, 0, 0, 0, 0, 0, 0). If we would use variable argument lists this would be sd_mount(SD_Simple, DO, CLK, DI, CS) and sd_mount(SD_None). This could be done in C. I think overloading would require C++.
Can you try this again using the current src tree. Using xmmc and c3 I get an I/O error. (I've checked the uSD on a different machine
its ok)
dolly:filetest petry$ make MODEL=xmmc
propeller-elf-gcc -mxmmc -Os -mfcache -c filetest.c -o filetest.o
propeller-elf-gcc -mxmmc -fno-exceptions -fno-rtti filetest.o -o filetest.elf
dolly:filetest petry$ propeller-load -bc3 filetest.elf -r -t
error: opening serial port '/dev/cu.usbserial-000042FD'
Error is : No such file or directory
dolly:filetest petry$ propeller-load -bc3 filetest.elf -r -t -p /dev/cu.usbserial-0000101D
error: opening serial port '/dev/cu.usbserial-0000101D'
Error is : Resource busy
dolly:filetest petry$ propeller-load -bc3 filetest.elf -r -t -p /dev/cu.usbserial-0000101D
Propeller Version 1 on /dev/cu.usbserial-0000101D
Patching __cfg_sdspi_config1 with 090a0b13
Patching __cfg_sdspi_config2 with 19080005
Loading the serial helper to hub memory
9808 bytes sent
Verifying RAM ... OK
Loading external memory driver 'c3_xmem.dat'
956 bytes sent
Loading program image to flash
39812 bytes sent
Loading .xmmkernel
1984 bytes sent
[ Entering terminal mode. Type ESC or Control-C to exit. ]
Commands are help, cat, rm, ls, ll, echo, cd, pwd, mkdir and rmdir
> ls
./: I/O error
> pwd
/
There seems to be a need for a lot of documentation cleanup with the cache-drivers to xmem-drivers
migration. One that was very helpful in the past, but needs updating is propeller-load (loader.pdf V.1)
Is there a headsup that is planed for folks using SimpleIDE?
Thanks,
Mike