Cluso99: Your plan sounds reasonable, and I'd definitely be in for fixing spin2cpp problems, but managing forum members is probably going to be a bit harder than herding cats .
hehe, yes...
What we've found works well, is to have just a couple: one focuses on code, and one focuses on testing.
Different time zones can even help here...
Sounds like you and Cluso have that covered ?
(unless it removes Cluso from getting SD boot into P2 ... )
No. It won't stop the SD boot. I thought I made that clear.
I found an interesting quirk on one of the SD drivers yesterday - a bug I have been chasing sparingly interspersed with my Windows/Outlook email problem (which MS now acknowledges and I have a poor workaround - use a metered connection and manually perform send/receive throughout the day - at least it works).
The bug reset CSn=1 between the CMD55 & CMD41 sequence. Not surprisingly, some cards don't like this, but others work fine.
We can't engage in a multi-player project on this, unfortunately. I wish we could easily manage it, but we can't. It's looking like we'll have one, maybe two parties involved but we're still waiting for Friday to come before we arrive at some conclusions.
The discussion in the meanwhile is very helpful, very appreciated, and can go on as long as you are all happy to share. Ultimately it makes the project a bit easier and of more benefit to the whole community.
You are correct of course that the stack requirements may differ between Spin and C, so that's something else that anyone porting the code will have to watch out for.
If there is no Spin code launched with COGNEW or COGINIT then I guess stack size is less of a problem. However, I wonder if spin2cpp should recognize some stylized comments to indicate where values differ between code intended to run on the Spin VM and code to be translated to C. If you don't embed that information in the sources somehow then keeping the master source in Spin and auto-translating whenever the Spin code changes doesn't work as well. The resulting C code would have to be tweaked each time.
I'd say the simplest way to handle that would be:
con
#ifdef __SPIN2CPP__
stksize = 16 ' stack needed for C version
#else
stksize = 20 ' stack needed for Spin bytecode
#endif
...
long mystack[stksize]
The __SPIN2CPP__ symbol is always defined by spin2cpp when compiling C or C++ code (and __SPIN2PASM__ is defined when compiling assembly code). As long as none of the other Spin compilers define those symbols we should be fine .
Note that since C does not store variables on the stack, and does not require the stack for arithmetic, it may not need as much stack space as Spin. This will be quite code dependent.
Eric
The only problem I can see with that approach is that it won't compile with the Propeller Tool since it doesn't support a preprocessor.
Dave,
When you say the demos easily fit into hub ram, I presume you mean the compiled C version?
How much space is available?
Remember, some kids/adults may make rather large demos once they get used to the S3. There does need to be lots of expansion room for the user.
The scribbler_rundemos.binary file size is 18,384 bytes. So that leaves more than 10K for extra code. The Spin binary is 14,036 bytes, which is about 4K less than the C version. I don't know how much space is needed by the user, but it seems like 10K should allow for quite a bit of extra code. As I suggested in a previous post, we could free up another 3,000 bytes if we put the cog images in the unused half of the EEPROM.
We can't engage in a multi-player project on this, unfortunately. I wish we could easily manage it, but we can't. It's looking like we'll have one, maybe two parties involved but we're still waiting for Friday to come before we arrive at some conclusions.
The discussion in the meanwhile is very helpful, very appreciated, and can go on as long as you are all happy to share. Ultimately it makes the project a bit easier and of more benefit to the whole community.
Ken Gracey
That's fine Ken. Thanks for letting us know.
I/we need to understand more about the requirements.
Looks like it's going to be tight, if not impossible to get the scribbler_test.spin compiling in C because it seems that there is no chance it will fit and run in the hub space. My expectation as a user would likely be that I would want to be able to write a quite complex S3 program (in C if that's the case, perhaps via Blockly since that is part of what I understand) at least equal to the test program in capabilities.
Presuming I am correct in my assumptions, then what are Parallax's requirements regarding the C/pasm code all fitting into hub ???
I guess we've all been assuming that you will want to continue to support the Spin code once the C version is in place. Is that correct? And both will be maintained in parallel going forward?
I just realized that another possiblity for doing this would be to use my spinwrap tool and leave most of the code in Spin with wrappers so you can call it from C. I've never tried it on this big a project though.
I guess we've all been assuming that you will want to continue to support the Spin code once the C version is in place. Is that correct? And both will be maintained in parallel going forward?
Sure. We're looking for the same functionality in C, and the Spin code would continue to be used in the S3 Graphical User Interface.
There's lots of talk about how the spin2cpp output either barely fits, or doesn't fit at all. Don't forget that re-writing from scratch is still an option. And if its re-written from scratch, it may be possible to create a design that makes better use of C as a language and PropGCC as the compiler, rather than trying to carry forward Spin concepts that don't fit very well.
The main utility section (ie "scribbler.spin" and its' objects) only use to ~$24C8 in hub, plus the spin stack space.
BUT, I see the real problem in trying to convert the scribbler_test and/or scribbler_default spin files.
These are the ones that take the real space, driving the S3 around. If it were my S3, I would be taking that code and modifying it to do other things as well, using that code as the base. That is how I think to start with, rather than starting from scratch.
This is where I see the real code size problem lies.
I am not yet sure how much those files can be simplified, if at all. And we do know very well that spin translates to much, much larger memory usage.
You could try using XMM using the EEPROM external memory driver. Not sure if the performance would be adequate though.
Unfortunately the S3 code seems to rely on running Spin methods on other cogs, which in C terms means running C code on another cog. We can't do that in XMM using the SimpleIDE version of PropGCC, although we can with more recent versions of PropGCC.
Eric
That brings up an interesting question. How do you handle stack sizes when translating Spin to C? When you call cognew in Spin you pass in a stack but the size of that stack is probably different in the C translation. It will certainly be bigger if you use XMM since the cache is taken out of the stack space.
My suggestion to use XMM was based on a misreading of a previous post that said that the S3 has a 512K EEPROM. Somehow, I read that to mean 512K bytes. Of course it is really 512K bits which is only 64K bytes. That isn't really enough to provide much more space than CMM in hub memory since XMM code is far less dense than CMM code. Maybe the S3v2 will have a SPI flash chip in it! :-)
It seems like the size problem is only with the test portion of the code. The demo portion fits in memory with room to spare. I think actual user code will be more like the demos instead of the tests. Once the code is running we'll have a better idea if there is enough spare room left. It would be good to have some sample Spin code of real applications, and see how well they convert into C.
One thing I noticed in scribbler.spin is that the cog images total up to 2,904 bytes. The tone queue is 2,400 bytes, and is a separate array. So we could save 2,400 bytes by re-using the cog images for the tone queue. This might provide enough stack space for the test code to run. The only drawback is that the cog images will be wiped out, and cogs can't be restarted again. However, I doubt if this is a real problem. If the cog would need to be restarted we could reload the cog images from their location on EEPROM.
I also thought of a way that tests and demos could be combined together. The demos program could be written in the lower half of EEPROM, and the tests program in the upper half. If the demos program detects that the user want to run the tests it would just load the hub RAM from the upper EEPROM and start it. Of course it would be easier to just have the user load the test program in RAM when he wants to run it. He will need a serial connection to the Scribbler anyhow, so that might not be too bad of an option.
I was trying to figure out why the C code doesn't run on the Scribbler, and there are several potential problem. The compiler could be optimizing things in a way that is different than how the Spin code runs. Another thought I had is that scribbler.spin contains multiple cog images. I thought I read somewhere that only one cog images is supported per file. I'll have to try a simple test program to see if multiple cog images works OK. Does anybody know if this could be a problem?
The scribbler_test.spin is quite large, but I invision it only to be run to diagnose problems on the S3. It would be replaced by scribbler_default, and users would add their code to that.
The scribbler_test.spin is quite large, but I invision it only to be run to diagnose problems on the S3. It would be replaced by scribbler_default, and users would add their code to that.
So what would be wrong with splitting it into two sets of tests in two separate programs?
The scribbler_test.spin is quite large, but I invision it only to be run to diagnose problems on the S3. It would be replaced by scribbler_default, and users would add their code to that.
So what would be wrong with splitting it into two sets of tests in two separate programs?
From what I have ran, There is a Test program, and a Production test program. They can probably be split up to fit two C programs.
I tried a test with multiple cog images in one source file, and it worked OK when the PASM code is assembled into a single dat array. However, if I used the --gas option to generate inline assembly the compiler complained that I was "attempting to move .org backwards" for the second cog image. It seems like the solution would be to create a .S file for each cog image.
How do any of you propose to make the scribbler_default.spin program converted to C and fit it into the prop?
The scribbler_default.spin program calls the scribbler_test.spin as an object. A user is going to expect that program to run on the S3 in C ???
It barely fits now using SPIN and PASM. How will it fit with C that requires a lot more code space?
Have any of you seriously considered how you are going to fit this in with C and make it run. And that is before the user attempts to add his/her own C routines to it!
Conversion is the easy part. Making the code fit and work is the difficult part.
How do any of you propose to make the scribbler_default.spin program converted to C and fit it into the prop?
The scribbler_default.spin program calls the scribbler_test.spin as an object.
That seems odd. I would think there would be a core object that exposes the S3 functions and that both scribbler_default.spin and scribbler_test.spin would call it as an object. Why would a user program need the test code? Could the Spin code be refactored?
scribbler_test.spin can run by itself without having any dependencies on scribbler default. I think it should be removed from scribbler_default to leave some room for user programing.
It would save ~ 4000 LONGS in scribbler_default.spin.
IMHO I don't believe it's possible to quote until Parallax/Ken explain how they expect to overcome the fact that the C code required will not fit.
The "default" code supplied on all S3 scribbler is the minimum requirement IMHO, and without direction, I cannot see how Parallax wants it implemented. Sure there are ways around the problem, but they need to be addressed now.
This is the complex part of the job, not the C conversion. There is the upper 32KB EEPROM, but does any of that store the variable parameters?
For example, you split the 8 possible tasks that the "default" code can run. The user decides add C code to
1. Draw a figure 8
2. Move some Distance
3. Goto 1. (Repeat process)
This is simple enough. But if you implemented the "default" conversion as 8 separate sections in EEPROM, the how long will the S3 pause between each step? Will this be acceptable to Parallax? Will this be acceptable to the user?
None of this.has even been discussed, nor indeed really thought about.
I for one, cannot quote on a huge unknown solution in the suggested timeframes.
Unfortunately I am away for 2 days. I rushed a reply off to Ken with some size figures for the existing compilations before I left.
I think someone already mentioned that a hand translation might achieve better code density although that's probably a long shot and would also involve considerable extra effort.
I'm a bit confused about what is actually needed to run the S3 code. Ken posted a link to a github repository that seems to contain lots of drivers but there don't seem to be any references to them in the Scribbler Default code base. Are these just included as COG images in scribbler.spin?
In looking at this a bit more, one option might be to wrap the code in scribbler.spin using spinwrap and rewrite the other code in C either by using spin2cpp to translate it or by hand translating. This might allow the code to fit because the bulk of the code will still be in Spin
Ken: Would this approach satisfy Parallax's requirements? Is the idea to show all of the code in C for learning purposes or just to allow users to write C code to control the S3 functions without necessarily understanding how those are implemented?
I'm a bit confused about what is actually needed to run the S3 code. Ken posted a link to a github repository that seems to contain lots of drivers but there don't seem to be any references to them in the Scribbler Default code base. Are these just included as COG images in scribbler.spin?
I'm a bit confused about what is actually needed to run the S3 code. Ken posted a link to a github repository that seems to contain lots of drivers but there don't seem to be any references to them in the Scribbler Default code base. Are these just included as COG images in scribbler.spin?
Yes, of course I looked at the code and found what you describe. My confusion is over why all of the other Spin code is in the repository and whether any of that needs to be ported even though it isn't actually used by the Scribbler code.
Cluso, you seem to be concerned that scribbler_default won't fit in memory, and you are correct that it won't fit without modification. I have already stated that the demos fit with room to spare. The demos are just scribbler_default minus the references to scribbler_test. scribbler_default actually has 8 different demo mode, which include line following, object detection, object avoidance and scribbling. So it seems like there should be enough room available for the user to do some pretty complex things. As I mentioned before, it would be nice to try porting some actual user code that contains a fairly complex application to see if it will fit.
Cluso, you seem to be concerned that scribbler_default won't fit in memory, and you are correct that it won't fit without modification. I have already stated that the demos fit with room to spare. The demos are just scribbler_default minus the references to scribbler_test. scribbler_default actually has 8 different demo mode, which include line following, object detection, object avoidance and scribbling. So it seems like there should be enough room available for the user to do some pretty complex things. As I mentioned before, it would be nice to try porting some actual user code that contains a fairly complex application to see if it will fit.
This sounds like a good approach. Even if Parallax wants to ship the S3 with both the default program and the test program in EEPROM, the test program could be written to the high 32 of EEPROM being careful to avoid overwriting the few variables that the S3 code stores there. I think the switch from the default code to the test code and back are big enough mode transitions that it wouldn't be a problem for there to be a bit of a delay while code load from EEPROM.
Comments
I found an interesting quirk on one of the SD drivers yesterday - a bug I have been chasing sparingly interspersed with my Windows/Outlook email problem (which MS now acknowledges and I have a poor workaround - use a metered connection and manually perform send/receive throughout the day
The bug reset CSn=1 between the CMD55 & CMD41 sequence. Not surprisingly, some cards don't like this, but others work fine.
We can't engage in a multi-player project on this, unfortunately. I wish we could easily manage it, but we can't. It's looking like we'll have one, maybe two parties involved but we're still waiting for Friday to come before we arrive at some conclusions.
The discussion in the meanwhile is very helpful, very appreciated, and can go on as long as you are all happy to share. Ultimately it makes the project a bit easier and of more benefit to the whole community.
Ken Gracey
I/we need to understand more about the requirements.
Looks like it's going to be tight, if not impossible to get the scribbler_test.spin compiling in C because it seems that there is no chance it will fit and run in the hub space. My expectation as a user would likely be that I would want to be able to write a quite complex S3 program (in C if that's the case, perhaps via Blockly since that is part of what I understand) at least equal to the test program in capabilities.
Presuming I am correct in my assumptions, then what are Parallax's requirements regarding the C/pasm code all fitting into hub ???
Ray
I guess we've all been assuming that you will want to continue to support the Spin code once the C version is in place. Is that correct? And both will be maintained in parallel going forward?
Sure. We're looking for the same functionality in C, and the Spin code would continue to be used in the S3 Graphical User Interface.
Ken Gracey
The main utility section (ie "scribbler.spin" and its' objects) only use to ~$24C8 in hub, plus the spin stack space.
BUT, I see the real problem in trying to convert the scribbler_test and/or scribbler_default spin files.
These are the ones that take the real space, driving the S3 around. If it were my S3, I would be taking that code and modifying it to do other things as well, using that code as the base. That is how I think to start with, rather than starting from scratch.
This is where I see the real code size problem lies.
I am not yet sure how much those files can be simplified, if at all. And we do know very well that spin translates to much, much larger memory usage.
One thing I noticed in scribbler.spin is that the cog images total up to 2,904 bytes. The tone queue is 2,400 bytes, and is a separate array. So we could save 2,400 bytes by re-using the cog images for the tone queue. This might provide enough stack space for the test code to run. The only drawback is that the cog images will be wiped out, and cogs can't be restarted again. However, I doubt if this is a real problem. If the cog would need to be restarted we could reload the cog images from their location on EEPROM.
I also thought of a way that tests and demos could be combined together. The demos program could be written in the lower half of EEPROM, and the tests program in the upper half. If the demos program detects that the user want to run the tests it would just load the hub RAM from the upper EEPROM and start it. Of course it would be easier to just have the user load the test program in RAM when he wants to run it. He will need a serial connection to the Scribbler anyhow, so that might not be too bad of an option.
I was trying to figure out why the C code doesn't run on the Scribbler, and there are several potential problem. The compiler could be optimizing things in a way that is different than how the Spin code runs. Another thought I had is that scribbler.spin contains multiple cog images. I thought I read somewhere that only one cog images is supported per file. I'll have to try a simple test program to see if multiple cog images works OK. Does anybody know if this could be a problem?
From what I have ran, There is a Test program, and a Production test program. They can probably be split up to fit two C programs.
The scribbler_default.spin program calls the scribbler_test.spin as an object. A user is going to expect that program to run on the S3 in C ???
It barely fits now using SPIN and PASM. How will it fit with C that requires a lot more code space?
Have any of you seriously considered how you are going to fit this in with C and make it run. And that is before the user attempts to add his/her own C routines to it!
Conversion is the easy part. Making the code fit and work is the difficult part.
It would save ~ 4000 LONGS in scribbler_default.spin.
The "default" code supplied on all S3 scribbler is the minimum requirement IMHO, and without direction, I cannot see how Parallax wants it implemented. Sure there are ways around the problem, but they need to be addressed now.
This is the complex part of the job, not the C conversion. There is the upper 32KB EEPROM, but does any of that store the variable parameters?
For example, you split the 8 possible tasks that the "default" code can run. The user decides add C code to
1. Draw a figure 8
2. Move some Distance
3. Goto 1. (Repeat process)
This is simple enough. But if you implemented the "default" conversion as 8 separate sections in EEPROM, the how long will the S3 pause between each step? Will this be acceptable to Parallax? Will this be acceptable to the user?
None of this.has even been discussed, nor indeed really thought about.
I for one, cannot quote on a huge unknown solution in the suggested timeframes.
Unfortunately I am away for 2 days. I rushed a reply off to Ken with some size figures for the existing compilations before I left.
Ken: Would this approach satisfy Parallax's requirements? Is the idea to show all of the code in C for learning purposes or just to allow users to write C code to control the S3 functions without necessarily understanding how those are implemented?
scribbler_default.spin calls Objects..
scribbler.spin
scribbler_test.spin
scribbler_music.spin
scribbler_test.spin calls Objects...
FullDuplexSerial.spin
scribbler.spin
scribbler_music.spin
PWMx8.spin