Are you using the RamPage2 or will this run on a stock QuickStart? I'de like to check the code out once you are ready. I'm actually more interested in a C version of the Paint program as I would like to use my QMP as a touch-screen bot controller.
Are you using the RamPage2 or will this run on a stock QuickStart? I'de like to check the code out once you are ready. I'm actually more interested in a C version of the Paint program as I would like to use my QMP as a touch-screen bot controller.
Thanks,
dgately
I think he's using both the QMP and the RamPage2.
Ray: Do you have any plans to make a RamPage2 card that can be sandwiched between the QuickStart and the QMP? Or, better yet, a new QMP with at least the flash chips on it? :-)
Maybe I should have put pads on the QMP for flash chips...
I do have an RP2 sandwiched between QMP and Quickstart, but it's a very, very tight squeeze and RP2 actually has to be at an angle for it to work...
But, there are stackable headers. Or, RP2 can mount under Quickstart.
You don't really need XMM mode for QMP though. In cmm mode, there's plenty of space for something...
I do have plans to make a GUI framework for QMP (that will also be common with VGA and DVI graphics shields and 4.3" touchscreens).
Been waffling for a long time on whether to do it in C or Spin.
But now, I'm leaning towards C (or C++ really)...
I do have plans to make a GUI framework for QMP (that will also be common with VGA and DVI graphics shields and 4.3" touchscreens).
Been waffling for a long time on whether to do it in C or Spin.
But now, I'm leaning towards C (or C++ really)...
I've been wanting to do a small, generic GUI framework for a while. I have some GUI primitives already if you want to have a look. Most of it is straight C right now, and not very generic. Would be nice to define a hardware abstraction layer. Probably some experimenting required. Want to collaborate? Maybe setup a google code project with svn?
I'm afraid I'd be a bad partner... My "plans" are usually wishful thinking at best... Maybe I'll ask for advice when and if I ever make any progress...
Decided to take the rose-colored glasses off for a second and do a real speed comparison between Spin and C++ in xmm mode...
Here's the time to complete the demo loop:
//50 seconds for xmm-split
//48 seconds for xmm-single
//42 seconds for xmmc
//30 seconds for spin
//45 seconds for cmm
So, in reality xmm modes are slower in this instance, but not too bad.
xmm-split is really the dream mode for me where I can run basically any size program I want.
Having this at 60% of Spin speed isn't so bad...
Tried to do this for cmm mode, but after switching from FSRW to stdio for sd card access, the program is now just a hair to big to run.
At least, I think so. It ran fine and then froze when trying to load an image.
HUB bytes of code is 32,700 something, so I think that's why.
Decided to take the rose-colored glasses off for a second and do a real speed comparison between Spin and C++ in xmm mode...
Here's the time to complete the demo loop:
//50 seconds for xmm-split
//48 seconds for xmm-single
//42 seconds for xmmc
//30 seconds for spin
So, in reality xmm modes are slower in this instance, but not too bad.
xmm-split is really the dream mode for me where I can run basically any size program I want.
Having this at 60% of Spin speed isn't so bad...
Tried to do this for cmm mode, but after switching from FSRW to stdio for sd card access, the program is now just a hair to big to run.
At least, I think so. It ran fine and then froze when trying to load an image.
HUB bytes of code is 32,700 something, so I think that's why.
It's odd that xmm-single and xmm-split give you different numbers. I guess that must be because of cache collisions since data and code start at different addresses in xmm-split mode rather than being intermixed at a single address like with xmm-single. I guess we could try a separate cache for flash and SRAM to see if that improves the xmm-split performance.
Just did CMM mode on the this graphics demo and got a little puzzling results...
The very raw output of Spin2Cpp is very, very slow because of the C replacement for "?" (random number).
Replacing that with rand() gives:
26 seconds for CMM
So, that's faster than Spin.
But, this version doesn't run in XMM mode.
The version that I further modified to run in XMM mode gives:
45 seconds for CMM
Some of this difference I can tell is due to the sd driver being noticeably slower, but that's only about 2 seconds.
I think either I did something I don't remember that slows this version down.
Or, the HUBDATA and volatile and HUBTEXT things somehow make it slower...
Just did CMM mode on the this graphics demo and got a little puzzling results...
The very raw output of Spin2Cpp is very, very slow because of the C replacement for "?" (random number).
Replacing that with rand() gives:
26 seconds for CMM
So, that's faster than Spin.
But, this version doesn't run in XMM mode.
The version that I further modified to run in XMM mode gives:
45 seconds for CMM
Some of this difference I can tell is due to the sd driver being noticeably slower, but that's only about 2 seconds.
I think either I did something I don't remember that slows this version down.
Or, the HUBDATA and volatile and HUBTEXT things somehow make it slower...
HUBTEXT will certainly not slow down the code. It should make it significantly faster. Same applies to HUBDATA. I guess volatile could slow things down because it reduces the amount of optimization that the compiler can do. However, since I think you only added volatile to mailbox variables, I wouldn't expect that the program would run at all without it.
What optimization options are you using for the C/C++ code? CMM mode is usually significantly faster than Spin, unless optimization is turned off. You mentioned that you've added volatile to the mailboxes, so it's probably safe to use -Os or -O2 even on spin2cpp output.
I see what was slowing the xmm version down now...
Was copying 10 longs of parameters to the assembly driver to a local buffer before sending a command to that driver...
I changed the code so it doesn't have to do this and now the two cmm versions are the same speed.
Comments
http://www.rayslogic.com/Propeller/Products/QMP/QMP.htm
Only difference is that the random colors are different (because using srand) and it may be a hair slower in xmm-single/split modes.
Are you using the RamPage2 or will this run on a stock QuickStart? I'de like to check the code out once you are ready. I'm actually more interested in a C version of the Paint program as I would like to use my QMP as a touch-screen bot controller.
Thanks,
dgately
Ray: Do you have any plans to make a RamPage2 card that can be sandwiched between the QuickStart and the QMP? Or, better yet, a new QMP with at least the flash chips on it? :-)
Maybe I should have put pads on the QMP for flash chips...
I do have an RP2 sandwiched between QMP and Quickstart, but it's a very, very tight squeeze and RP2 actually has to be at an angle for it to work...
But, there are stackable headers. Or, RP2 can mount under Quickstart.
You don't really need XMM mode for QMP though. In cmm mode, there's plenty of space for something...
Ah, that's all I needed as I have built that in C (CMM mode version). Now just need to see if you can squeeze in the touch-screen stuff
dgately
Been waffling for a long time on whether to do it in C or Spin.
But now, I'm leaning towards C (or C++ really)...
I've been wanting to do a small, generic GUI framework for a while. I have some GUI primitives already if you want to have a look. Most of it is straight C right now, and not very generic. Would be nice to define a hardware abstraction layer. Probably some experimenting required. Want to collaborate? Maybe setup a google code project with svn?
Here's the time to complete the demo loop:
//50 seconds for xmm-split
//48 seconds for xmm-single
//42 seconds for xmmc
//30 seconds for spin
//45 seconds for cmm
So, in reality xmm modes are slower in this instance, but not too bad.
xmm-split is really the dream mode for me where I can run basically any size program I want.
Having this at 60% of Spin speed isn't so bad...
Tried to do this for cmm mode, but after switching from FSRW to stdio for sd card access, the program is now just a hair to big to run.
At least, I think so. It ran fine and then froze when trying to load an image.
HUB bytes of code is 32,700 something, so I think that's why.
The very raw output of Spin2Cpp is very, very slow because of the C replacement for "?" (random number).
Replacing that with rand() gives:
26 seconds for CMM
So, that's faster than Spin.
But, this version doesn't run in XMM mode.
The version that I further modified to run in XMM mode gives:
45 seconds for CMM
Some of this difference I can tell is due to the sd driver being noticeably slower, but that's only about 2 seconds.
I think either I did something I don't remember that slows this version down.
Or, the HUBDATA and volatile and HUBTEXT things somehow make it slower...
Was copying 10 longs of parameters to the assembly driver to a local buffer before sending a command to that driver...
I changed the code so it doesn't have to do this and now the two cmm versions are the same speed.
30 seconds Spin
27 seconds CMM mode for Spin2Cpp version (with rand() fix)
34 seconds CMM mode for above version adapted to allow XMM mode (and using stdio for uSD instead of FSRW)
39 seconds XMMC mode
48 seconds XMM-Split mode
43 seconds XMM-Single mode