What I did was plug QMP into the Quickstart's main connector and then plug Rampage2 into the second connector.
But, this is a little tricky because RP2 had to be in at an angle and it's also hard soldered, so it can't be removed.
Maybe it would be better to solder a female header under Quickstart and then solder male header pins to top of RP2 so it can plug in underneath of Quickstart.
Another way would be to use those stacking connectors for Quickstart and plug both boards into the main connector of Quickstart.
I guess I'm out of luck because I already have connectors soldered onto the RamPage2 board and I'm really bad at unsoldering. I'll try to look over the code to see if I can find anything obvious that might be causing trouble. Out of curiosity, why do you want to convert this code to C anyway? Are you expecting better performance than the Spin code?
I think you can replicate the problem with just the Rampage2 installed (I'll check this).
One thing I did was put a printf statement in one of the calls and you can see it stop outputting when in single mode...
It seems to do all the pixels and then hang upon leaving the loop. It doesn't get to the printf "Lines" statement.
BTW: Besides just playing around, I have a notion of creating a common gui interface designer for QMP, VGA Graphics, DVI Graphics, 4.3"&5" LCDs.
I'd also like these to work for both P1 and P2.
The xmmc mode may be enough for this, so I'm happy with that.
xmmc mode looks a hair faster than Spin and allows virtually unlimited size data.
But, I have some other ideas (Like chess and Nethack) that need more memory.
It seems to do all the pixels and then hang upon leaving the loop. It doesn't get to the printf "Lines" statement.
BTW: Besides just playing around, I have a notion of creating a common gui interface designer for QMP, VGA Graphics, DVI Graphics, 4.3"&5" LCDs.
I'd also like these to work for both P1 and P2.
The xmmc mode may be enough for this, so I'm happy with that.
xmmc mode looks a hair faster than Spin and allows virtually unlimited size data.
But, I have some other ideas (Like chess and Nethack) that need more memory.
Are you planning to rewrite the code in C or C++ or will you leave it in Spin?
I don't really see anything wrong with the code at this point. Is there any possiblity that whatever the display driver is doing with the pins might be confusing the SPI devices? Can you move either to other pins?
You might be right about that... If I don't start the QMP display driver cog, it doesn't get stuck...
I'll take another look at the driver for problems...
Here is what I get when I run your sample code. I commented out the printf that displays each command since it generated way too much output. It looks like it makes it through numerous iterations of the loop.
propeller-elf-gcc -o qmp.elf -Os -mxmm-single -I . -fno-exceptions -fpermissive *.cpp
propeller-load -b rampage2x qmp.elf -r -t
Propeller Version 1 on /dev/cu.usbserial-A900L016
Loading the serial helper to hub memory
9568 bytes sent
Verifying RAM ... OK
Loading cache driver 'rampage2_xcache.dat'
1936 bytes sent
Loading program image to RAM
13740 bytes sent
Loading .xmmkernel
1460 bytes sent
[ Entering terminal mode. Type ESC or Control-C to exit. ]
Pixels
Lines
Pixels
Lines
Pixels
Lines
Pixels
Lines
...
Ok, when I disable all DIRA lines in the QMP driver, it works in single mode.
So, there is definitely interference between the cache driver and the QMP driver.
I'll look to make sure it's not the QMP driver's fault.
Are yo sure that "HUBTEXT" works right in single mode?
Can you take a look at my "SetCommand" function.
That is where the QMP driver takes control off the bus and doesn't let go until it sets that mailbox to zero...
Ok, when I disable all DIRA lines in the QMP driver, it works in single mode.
So, there is definitely interference between the cache driver and the QMP driver.
I'll look to make sure it's not the QMP driver's fault.
Are yo sure that "HUBTEXT" works right in single mode?
Can you take a look at my "SetCommand" function.
That is where the QMP driver takes control off the bus and doesn't let go until it sets that mailbox to zero...
I did look at it and it looks fine. However, the call to printf will take it out of hub text for the duration of the call. That shouldn't be causing a problem though since you don't actually start the QMP COG until after printf returns.
Still can't find the problem... Started looking at the cache driver... Now, I don't know how this works in any mode...
Is the "release" call supposed to free the data pins?
The way it is now, it puts several ones on the data bus.
And yet, xmmc mode works somehow...
I hope it's not because the whole program is in cache so the cache driver isn't actually used in -xmmc mode...
Still can't find the problem... Started looking at the cache driver... Now, I don't know how this works in any mode...
Is the "release" call supposed to free the data pins?
The way it is now, it puts several ones on the data bus.
And yet, xmmc mode works somehow...
I hope it's not because the whole program is in cache so the cache driver isn't actually used in -xmmc mode...
When the cache driver exits it sets DIRA to zero which makes the settings in OUTA irrelevant since all pins are set as inputs. Your driver will need to do the same thing when it is idle.
Shouldn't it set DIRA to maintain the flash and sram chip selects high?
There really should be pull-ups on the CS lines. If the cache driver holds them high then no other code will be able to use the flash when the cache driver is inactive.
Quick question... xmmc mode doesn't seem to work with less than 8k specified in rampage2x.cfg..
Here's the line:
cache-size: 512+8K
Shouldn't it work with any setting, although maybe really slow?
You can use any size cache but the cache geometry settings have to match the size you specify. Check the start of cache_common.spin to find the definition of the cache geometry control word in cache-param1.
Ok, so I gather then you'd not be surprised that it works with "512+8k" but not with "512+6k"?
It won't work if you just change the size because the cache geometry uses all 8k for cache lines. The 512 is for the tags. That can be reduced as well if you configure the geometry to use fewer tags.
Here is the default cache geometry. You get this if you either leave out a setting for cache-param1 or set it to zero.
DEFAULT_WAY_WIDTH = 2 ' number of bits in the way offset (way count is 2^n)
DEFAULT_INDEX_WIDTH = 5 ' number of bits in the index offset (index size is 2^n)
DEFAULT_OFFSET_WIDTH = 6 ' number of bits in the line offset (line size is 2^n)
Since the offset width is 6 each cache line is 2^6 = 64 bytes.
Since the index width is 5 there are 2^5 = 32 tags per way.
Since the way width is 2 there are 2^2 = 4 ways.
So, 4 * 32 * 64 = 8192 which is why the cache size must be 8K.
Since there are 32 tags per way and 4 ways there are 32 * 4 = 128 tags. Each takes 4 bytes so 512 bytes are consumed by the tags.
Think I'm ready to give up on using this shared bus with xmm-single or split modes...
The cache driver just does not seem to want to share nicely...
Oops, maybe I spoke too soon.
Was double checking things and found a hardware problem...
I was using a prototype RamPage2 board instead of a production one.
This one didn't have pullup resistors on the chip select, so I added them by hand.
But, seems I messed that up and had chip selects pulled down unstead of pulled up...
Anyway, it's possible I messed myself up by not using the real board with the pullups...
Think I'm ready to give up on using this shared bus with xmm-single or split modes...
The cache driver just does not seem to want to share nicely...
Have you verified that your LCD driver sets DIRA to zero when it is not processing a command? The only other thing I can think of is that whatever the LCD driver is doing when it is running is putting the SPI chips in an odd mode. Do the SPI CS lines get reused by the LCD hardware? Also, as you pointed out before, the CS lines will need to have pull-ups if they are to work when the cache driver sets DIRA to zero.
Couldn't figure out how to get FSRW work in xmm-single mode, so switched to stdio and it seems to work well (although perhaps a bit slower).
The stdio code uses code from the old FSRW block I/O driver but it doesn't use the fastest code. We should certainly improve it at some point. Want to take a look at it? :-)
Actually, I just check the fsrw speed versus stdio and they may be very close in xmmc mode.
BTW: I've very happy with the overall program speed in xmm-split mode here with the Rampage2X driver.
This demo runs essentially the same speed as the Spin driver.
I've read complaints about slowness in this mode, but I'm not seeing it here...
Actually, I just check the fsrw speed versus stdio and they may be very close in xmmc mode.
BTW: I've very happy with the overall program speed in xmm-split mode here with the Rampage2X driver.
This demo runs essentially the same speed as the Spin driver.
I've read complaints about slowness in this mode, but I'm not seeing it here...
Congratulations on getting everything working and I'm glad to hear that you consider performance to be acceptable!
I did find one trouble thing during this... My spin code that I did spin2cpp on used a mailbox system to talk to the assembly driver.
Basically, there was a variable called "Command" that I used for this.
What I think I saw is that in Spin, Command was initialized to zero.
But, in the spin2cpp version, I don't think this variable is initialized.
However, this may have been because I changed the Spin2cpp version to make this a global variable, in the process of troubleshooting.
Anyway, I do wonder about initialization in xmm modes.
I suppose in xmmc that everything is zeroed out by the propeller itself on reboot.
But what about xmm-single or xmm-split? Is any variable data automatically initialized?
I did find one trouble thing during this... My spin code that I did spin2cpp on used a mailbox system to talk to the assembly driver.
Basically, there was a variable called "Command" that I used for this.
What I think I saw is that in Spin, Command was initialized to zero.
But, in the spin2cpp version, I don't think this variable is initialized.
However, this may have been because I changed the Spin2cpp version to make this a global variable, in the process of troubleshooting.
Anyway, I do wonder about initialization in xmm modes.
I suppose in xmmc that everything is zeroed out by the propeller itself on reboot.
But what about xmm-single or xmm-split? Is any variable data automatically initialized?
All global and static variables either have the initialization you give them in the variable declaration or they are initialized to zero. Local variables are not initialized at all by default.
Comments
One thing I did was put a printf statement in one of the calls and you can see it stop outputting when in single mode...
I've added some printf lines before and after the random pixel section:
printf("Pixels"); { int32_t _idx__0006; for(_idx__0006 = 1; _idx__0006 <= 10000; (_idx__0006 = (_idx__0006 + 1))) { Setpixel(Rgb((RandBack__(K)), (RandBack__(K)), (RandBack__(K))), ((abs((RandBack__(K)))) % Xpixels), ((abs((RandBack__(K)))) % Ypixels)); printf("."); } } printf("Lines");It seems to do all the pixels and then hang upon leaving the loop. It doesn't get to the printf "Lines" statement.
BTW: Besides just playing around, I have a notion of creating a common gui interface designer for QMP, VGA Graphics, DVI Graphics, 4.3"&5" LCDs.
I'd also like these to work for both P1 and P2.
The xmmc mode may be enough for this, so I'm happy with that.
xmmc mode looks a hair faster than Spin and allows virtually unlimited size data.
But, I have some other ideas (Like chess and Nethack) that need more memory.
I'll take another look at the driver for problems...
So, there is definitely interference between the cache driver and the QMP driver.
I'll look to make sure it's not the QMP driver's fault.
Are yo sure that "HUBTEXT" works right in single mode?
Can you take a look at my "SetCommand" function.
That is where the QMP driver takes control off the bus and doesn't let go until it sets that mailbox to zero...
Is the "release" call supposed to free the data pins?
The way it is now, it puts several ones on the data bus.
And yet, xmmc mode works somehow...
I hope it's not because the whole program is in cache so the cache driver isn't actually used in -xmmc mode...
Where does it set DIRA to zero?
Here's the line:
cache-size: 512+8K
Shouldn't it work with any setting, although maybe really slow?
Since the index width is 5 there are 2^5 = 32 tags per way.
Since the way width is 2 there are 2^2 = 4 ways.
So, 4 * 32 * 64 = 8192 which is why the cache size must be 8K.
Since there are 32 tags per way and 4 ways there are 32 * 4 = 128 tags. Each takes 4 bytes so 512 bytes are consumed by the tags.
This is where that 8K+512 number comes from.
The cache driver just does not seem to want to share nicely...
Oops, maybe I spoke too soon.
Was double checking things and found a hardware problem...
I was using a prototype RamPage2 board instead of a production one.
This one didn't have pullup resistors on the chip select, so I added them by hand.
But, seems I messed that up and had chip selects pulled down unstead of pulled up...
Anyway, it's possible I messed myself up by not using the real board with the pullups...
Everything suddenly works now, except for FSRW... Think I'll have to add some HUBTEXT, HUBDATA, volatile stuff in there...
Couldn't figure out how to get FSRW work in xmm-single mode, so switched to stdio and it seems to work well (although perhaps a bit slower).
BTW: I've very happy with the overall program speed in xmm-split mode here with the Rampage2X driver.
This demo runs essentially the same speed as the Spin driver.
I've read complaints about slowness in this mode, but I'm not seeing it here...
Basically, there was a variable called "Command" that I used for this.
What I think I saw is that in Spin, Command was initialized to zero.
But, in the spin2cpp version, I don't think this variable is initialized.
However, this may have been because I changed the Spin2cpp version to make this a global variable, in the process of troubleshooting.
Anyway, I do wonder about initialization in xmm modes.
I suppose in xmmc that everything is zeroed out by the propeller itself on reboot.
But what about xmm-single or xmm-split? Is any variable data automatically initialized?