Can't say I understand everything that is going on at the moment, but it does load and work. Whether its performance is sufficient for my purposes I won't know until I get my DAC hooked back up to my board.
XMMC with uSD works in the release_1_0 code, but will likely be deprecated in release_2_0.
Using uSD is horribly slow for various reasons, and is not recommended.
I have a precious few samples of uSD-SPI-Flash on a uSD plug-in designed for this purpose if you want one. Can't use uSD and the uSD-SPI-Flash plug-in at the same time though.
At the moment the configuration and loader options means you're using EEPROM for XMMC. To use the SD Card for XMMC, you need to use different propeller-load parameters. Enter propeller-load with no arguments for help and look for .pex and SD Card in the output.
Can't say I understand everything that is going on at the moment, but it does load and work. Whether its performance is sufficient for my purposes I won't know until I get my DAC hooked back up to my board.
But honestly, if it fits in EEPROM that is better anyways, isn't it?
Right. Not only that but there is very little advantage in a 64KB EEPROM XMMC program over a CMM program. More code will fit in EEPROM (up to 56KB or so), but in most cases XMM code is like LMM code which is about 40% bigger than CMM. Also, CMM is faster than XMMC. More importantly thoughwith the release_1_0 package, XMM code can't run parallel C cog functions (XMMC on release_2_0 will allow it when it is out of alpha state).
Would have posted this earlier, but I was scratching my head over why it was failing with the alpha_1_9 package I was using where the feature is not supported.
Yet another request.... How about a second Propeller ASC or a complete revision to support both the UNO pin outs and the MEGA pin outs. It would require more ADC support (16 pins), but it would also support some more powerful and sophisticate shields.
So yeah, compared my code from XMMC to CMM to LMM and... wow... the CMM or XMM just won't cut it. So slow. As it is I can't seem to get the SPI output to my DAC fast enough. At the highest frequency I'll need to output a sample (12 bits) every 49 clock cycles. I can't drive it that hard even in LMM. I've optimized the SPI code a bunch with assembly, but just pulling from my ring buffer and sending SPI is taking a few hundred cycles :-(
time to try going back to c code with "the other Martin's" work with simple ide. but the combination is pretty neat
It wouldn't hurt to try the Gameduino and PropellerASC with Forth on the Propeller. Actually it may be faster than C code. And Dave Hein already has a working demo of pfth Forth playing Chess on a Propeller via a serial terminal.
So yeah, compared my code from XMMC to CMM to LMM and... wow... the CMM or XMM just won't cut it. So slow. As it is I can't seem to get the SPI output to my DAC fast enough. At the highest frequency I'll need to output a sample (12 bits) every 49 clock cycles. I can't drive it that hard even in LMM. I've optimized the SPI code a bunch with assembly, but just pulling from my ring buffer and sending SPI is taking a few hundred cycles :-(
Are you using PASM or GAS with cognew? If not, as I suspect from your description above, you are definitely missing speed opportunities.
The fastest possible propeller code is PASM running in a COG. It's about 20MIPs with an 80MHz system clock. Typically, the fastest inline ASM will be about 5MIPS unless you use the fcache trick (it also can speed up normal C code - there is no SPIN equivalent). Using fcache will speed things up to 20MIPS if the function is small enough. The problem is only about 60 instructions can be used with that method. Here's an example of using fcache.
PASM running in a COG is limited to 496 longs for code and data (some tricks can increase that if necessary).
I recommend reading the Propeller Manual and data-sheet to learn more about PASM. There are plenty of PASM lovers around here that can help if you're stuck.
Capitualation... Jazzed mentioned to me that Parallax is stocking the PropellerASC+, so I don't have to order directly from Martin (with the added shipping to Taiwan fee).
Since we now have several shields on sale over-the-counter in Taiwan, I guess I will just have to buy one... but I suspect more will be done in Forth than in GCC..
Thanks for the tips; I'm not really wanting to give up C++ to make a wholesale move to PASM, was hoping to use PASM inline only where necessary. I guess I don't really understand how it's possible to set it up to have one cog running a PASM program using COG/HUB memory only, while have other COGs running C++. Also cog memory is not appropriate here and I will need to use HUB to store the ring buffer of the data being sent out via SPI, so not clear on how that would work exactly. I guess I'm going to have to dig in and see what's possible. It'd definitely have to be GAS for me though, I have no desire to use Parallax's windows-only IDEs and the like.
Thanks for the tips; I'm not really wanting to give up C++ to make a wholesale move to PASM, was hoping to use PASM inline only where necessary. I guess I don't really understand how it's possible to set it up to have one cog running a PASM program using COG/HUB memory only, while have other COGs running C++. Also cog memory is not appropriate here and I will need to use HUB to store the ring buffer of the data being sent out via SPI, so not clear on how that would work exactly. I guess I'm going to have to dig in and see what's possible. It'd definitely have to be GAS for me though, I have no desire to use Parallax's windows-only IDEs and the like.
SimpleIDE provides editing capability for Spin files and cleanly integrates the PASM into the project when the code is included in the project as a .spin file. Of course GAS can be used too. You could write a COGC driver that would run at speed as well, but it won't be so finely tuned and may be more difficult to write than necessary. COGC is easily added to the SimpleIDE project as a .cogc file. Just because a driver is written to run in COG memory doesn't mean the data has to be stored in COG memory. A speedy driver can be written that uses access to data in HUB RAM. The propeller manual and datasheet go a long way in helping to learn how to do things efficiently even if the code is written with GAS.
Yeah I won't be using SimpleIDE, I prefer to use a Makefile + Emacs, or Eclipse. But yeah, if GAS can do it, then that should be fine. It does feel like I'm circling around to the point where I'll probably end up rewriting a lot of stuff in pure PASM.
It does kind of feel in a way that there's a big conceptual gap between the "C" way of doing things (which I don't necessarily love) and PASM. Lots of operations in PASM don't seem to have a natural C equivalent; I found for example that for sending SPI, a loop with andn/ror/muxc/or was far far more efficient than what GCC was outputting.
I have toyed with the idea of writing a compiler for a language of my own that maps more closely 1:1 with PASM but adds block structured syntax, etc. But I have enough hobbies.
porcupine, have you tried the COG memory model in PropGCC? This will produce code that will execute from COG memory, and will run much faster than the other modes.
porcupine, have you tried the COG memory model in PropGCC? This will produce code that will execute from COG memory, and will run much faster than the other modes.
Wouldn't fit my code, pretty sure. Isn't that a 2k limit? Pretty hard to fit what I'm doing into that. Maybe if I was hand writing PASM.
Comments
clkfreq: 80000000clkmode: XTAL1+PLL16X
baudrate: 115200
rxpin: 31
txpin: 30
sd-driver: sd_driver.dat
sdspi-do: 12
sdspi-clk: 13
sdspi-di: 11
sdspi-cs: 8
# cache geometry - 128 * 64 = 8192 byte cache
index-width: 7 # 2^7 = 128 cache lines
offset-width: 6 # 2^6 = 64 byte cache lines
cache-geometry: ({index-width} << 8) | {offset-width}
xmem-driver: eeprom_xmem.dat
eeprom-first: TRUE
Then using the following in my Makefile for the load portion:
load: $(EXEC)
$(LOAD) -Dreset=dtr -I $(PARALLAX_DIR)/propeller-load/ $(EXEC) -e -r -t -b asc
all: $(EXEC)
Can't say I understand everything that is going on at the moment, but it does load and work. Whether its performance is sufficient for my purposes I won't know until I get my DAC hooked back up to my board.
At the moment the configuration and loader options means you're using EEPROM for XMMC. To use the SD Card for XMMC, you need to use different propeller-load parameters. Enter propeller-load with no arguments for help and look for .pex and SD Card in the output.
Loading program image to flash42356 bytes sent
Was an indication it was using the SD card. But honestly, if it fits in EEPROM that is better anyways, isn't it?
propeller-load.exe -Dreset=dtr -I C:/propgcc/propeller-load/ -b ACTIVITYBOARD -r -z xmmc/tonokip.elf -p COM52
Would have posted this earlier, but I was scratching my head over why it was failing with the alpha_1_9 package I was using where the feature is not supported.
http://arduino.cc/en/Main/ArduinoBoardMega
It wouldn't hurt to try the Gameduino and PropellerASC with Forth on the Propeller. Actually it may be faster than C code. And Dave Hein already has a working demo of pfth Forth playing Chess on a Propeller via a serial terminal.
The fastest possible propeller code is PASM running in a COG. It's about 20MIPs with an 80MHz system clock. Typically, the fastest inline ASM will be about 5MIPS unless you use the fcache trick (it also can speed up normal C code - there is no SPIN equivalent). Using fcache will speed things up to 20MIPS if the function is small enough. The problem is only about 60 instructions can be used with that method. Here's an example of using fcache.
PASM running in a COG is limited to 496 longs for code and data (some tricks can increase that if necessary).
I recommend reading the Propeller Manual and data-sheet to learn more about PASM. There are plenty of PASM lovers around here that can help if you're stuck.
Since we now have several shields on sale over-the-counter in Taiwan, I guess I will just have to buy one... but I suspect more will be done in Forth than in GCC..
It does kind of feel in a way that there's a big conceptual gap between the "C" way of doing things (which I don't necessarily love) and PASM. Lots of operations in PASM don't seem to have a natural C equivalent; I found for example that for sending SPI, a loop with andn/ror/muxc/or was far far more efficient than what GCC was outputting.
I have toyed with the idea of writing a compiler for a language of my own that maps more closely 1:1 with PASM but adds block structured syntax, etc. But I have enough hobbies.
Wouldn't fit my code, pretty sure. Isn't that a 2k limit? Pretty hard to fit what I'm doing into that. Maybe if I was hand writing PASM.