Revisiting XMM Mode Using Modern Memory Chips
Wingineer19
Posts: 291
Greetings Everyone:
I'm a retiree and a newbie here, so I now have the time to ponder some of the great mysteries of the Universe. Like XMM mode on the Prop1 for example.
Of course as Engineers we never really retire, so here goes this project...
I'm using the Parallax Project USB Board: https://www.parallax.com/product/32810
I've been looking over various memory schemes developed for the Prop1, and have settled on duplicating the PMC since it involves the smallest amount of Board space using the fewest number of Pins and chips.
Check out these little jewels I now have in my hot little hands:
512KB SRAM: http://www.issi.com/WW/pdf/IS62-65WVS5128GALL-BLL.pdf
4MB FLASH: http://www.issi.com/WW/pdf/25LP-WP032D.pdf
I've already installed these two chips onto the Project Board.
Instead of following the PMC convention of using Pins P0 to P7 to communicate with these chips, I've done the following:
Right now I don't have the SD Card holder installed, and don't plan on using it for this exercise anyway, so I'm assuming all references to the SD Card can be ignored.
I wrote a program using SimpleIDE that reads and writes to the SRAM (see below attachments).
The code starts out in SPI mode then commands a switchover to SQI mode. Afterwards, starting at memory location 0x00000 it writes a byte to that location, reads it back, then compares. It then increments to the next memory location and repeats until the loop is completed. This works perfectly. I haven't yet modified the code to attempt the same with the FLASH chip.
The SimpleIDE no longer offers an XMM compile option. I assume PropGCC still does using command line switches, but I haven't tried it yet.
As a further test, I decided to use the Catalina compiler with its Code::Blocks integration to compile the Sumeria.c program in the demo folder.
But first, I modified the PMC_XMM_DEF.INC file to reflect the following changes in conformance with the Pinouts listed above:
That being done, I then had Catalina compile the Sumeria.c which equated to this command line:
Catalina responded with:
OK, great. I then ran the build_utilities program, told it that it was using a QUICKSTART board along with the PMC board, set the cache settings for 1K for both FLASH and SRAM, and told it to build the bootloader for SRAM.
Then, I ran the Payload utility: payload SRAM sumeria -I
Catalina responded:
Excellent, then it presented the Interface screen and then -- Nothing. No response.
I went back and reconfigured the build_utilities to create the bootloader for FLASH instead.
Then ran Payload again: payload FLASH sumeria -I
Catalina Response:
Bummer. But for this test I was wanting to load the SRAM only and execute, which is what the first payload attempt above was about, but to no avail.
I would like to look at the XMM config files for PropGCC and attempt to compile and run this program using it.
But before I head too far down this rabbit hole, I want to make sure my hardware setup is correct.
Is there a Byte boundary issue that comes into play? Because my current scheme has the D3 to D0 lines in the Nibble right below the one for the Rx,Tx,SDA,SCL, with my Control signals in the Nibble right below the one for D3 to D0.
Like I said, this scheme works fine with my code, but it may not be "legal" with the XMM drivers available for both Catalina and PropGCC?
If the Byte boundary is an issue, would this work:
If the Byte boundary isn't an issue, would this be acceptable:
But if the Byte boundary is an issue, would this be acceptable:
I'd appreciate your thoughts and tips on this issue before I plunge over a cliff on this, only to find out there's some Byte boundary issue at play I hadn't considered.
Thanks,
Jeff
PS: Let's see if I can attach my code to this:
I'm a retiree and a newbie here, so I now have the time to ponder some of the great mysteries of the Universe. Like XMM mode on the Prop1 for example.
Of course as Engineers we never really retire, so here goes this project...
I'm using the Parallax Project USB Board: https://www.parallax.com/product/32810
I've been looking over various memory schemes developed for the Prop1, and have settled on duplicating the PMC since it involves the smallest amount of Board space using the fewest number of Pins and chips.
Check out these little jewels I now have in my hot little hands:
512KB SRAM: http://www.issi.com/WW/pdf/IS62-65WVS5128GALL-BLL.pdf
4MB FLASH: http://www.issi.com/WW/pdf/25LP-WP032D.pdf
I've already installed these two chips onto the Project Board.
Instead of following the PMC convention of using Pins P0 to P7 to communicate with these chips, I've done the following:
P27 - "D3" = SIO3 = (HOLD On SRAM) ( HOLD#/RESET# On Flash) P26 - "D2" = SIO2 = (DNU On SRAM) (WP# On Flash) P25 - "D1" = SIO1 = SO On Both SRAM And Flash P24 - "D0" = SIO0 = SI On Both SRAM And Flash P23 - SCLK (Common To SRAM and FLASH) P22 - RAMCS (Selects SRAM) P21 - FLCS (Selects FLASH) P20 - SDCS (Selects SD Card)
Right now I don't have the SD Card holder installed, and don't plan on using it for this exercise anyway, so I'm assuming all references to the SD Card can be ignored.
I wrote a program using SimpleIDE that reads and writes to the SRAM (see below attachments).
The code starts out in SPI mode then commands a switchover to SQI mode. Afterwards, starting at memory location 0x00000 it writes a byte to that location, reads it back, then compares. It then increments to the next memory location and repeats until the loop is completed. This works perfectly. I haven't yet modified the code to attempt the same with the FLASH chip.
The SimpleIDE no longer offers an XMM compile option. I assume PropGCC still does using command line switches, but I haven't tried it yet.
As a further test, I decided to use the Catalina compiler with its Code::Blocks integration to compile the Sumeria.c program in the demo folder.
But first, I modified the PMC_XMM_DEF.INC file to reflect the following changes in conformance with the Pinouts listed above:
'============================= XMM DEFINITIONS ================================= ' ' XMM Base Address. Catalina currently requires one contiguous block ' of XMM RAM - Note that this is the internal hardware address, not ' the address the Catalina XMM Kernel uses: ' XMM_BASE_ADDRESS = $0000_0000 ' XMM adddressing from 0 ' ' XMM RW & RO Base Addresses - Note that these are the addresses used ' by the Catalina XMM Kernel - they typically start AFTER the last ' Hub address: ' XMM_RW_BASE_ADDRESS = $0000_8000 ' Read-Write Base address XMM_RO_BASE_ADDRESS = $0008_8000 ' Read-Only Base address ' ' XMM RW & RO Sizes (in bytes): ' XMM_RW_SIZE = $0008_0000 ' Read-Write Size XMM_RO_SIZE = $0040_0000 ' Read-Only Size ' ' The following constant determines the number of longs used in the ' cache cog index - it can be reduced (e.g. to 6 or 5) if the XMM API ' is so large it needs more space even in the cache cog (e.g. for ' QUAD FLASH boards): ' CACHE_INDEX_LOG2 = 6 ' log2 of entries in cache index ' ' PMC QUAD SPI RAM Definitions (NOTE you also need to set the symbols ' defined below these pin definitions to appropriate values): ' QSPI_VDD = -1 ' PIN (PMC) - see below to enable QSPI_VSS = -1 ' PIN (PMC) - see below to enable ' QSPI_CLK = 23 ' PIN (PMC) Common Clock QSPI_SCEN = 22 ' PIN (PMC) SRAM Chip Enable QSPI_FCEN = 21 ' PIN (PMC) FLASH Chip Enable QSPI_SDCEN = 20 ' PIN (PMC) SD Card Chip Enable ' QSPI_SIO3 = 27 ' PIN (PMC) \ QSPI_SIO2 = 26 ' PIN (PMC) | MUST BE CONTIGUOUS QSPI_SIO1 = 25 ' PIN (PMC) | AND IN THIS ORDER QSPI_SIO0 = 24 ' PIN (PMC) / ' SSPI_SI = QSPI_SIO0 ' PIN (PMC) SSPI_SO = QSPI_SIO1 ' PIN (PMC) ' XMM_DEBUG_PIN = 11 ' PIN (PMC) Used only for debugging ' ' Define this to enable applying power to the QSPI_VDD & QSPI_VSS Pins ' (i.e. if they are connected to Propeller pins, and not directly to the ' appropriate power rails): ' '#ifndef QUAD_POWER_PINS '#define QUAD_POWER_PINS '#endif ' ' Since Homespun/Openspin have no general "#if" capability, we cannot tell ' whether or not we have to shift bits left or right to make the nibbles align ' with the pins QSPI_SIO0 .. QSPI_SIO3 when outputting data - so we have ' to explicitly define whether or not we need to shift each nibble left ' or right (but since the lower nibble would never have to be shifted ' right, we only have three possibilities to worry about): ' ' Define this symbol if the lower nibble has to be ' shifted LEFT for output (i.e. QSPI_SIO0 is > 0): ' '#ifndef QUAD_LOWER_NIBBLE_LEFT '#define QUAD_LOWER_NIBBLE_LEFT '#endif ' ' Define this symbol the upper nibble has to be ' shifted LEFT for output (i.e. QSPI_SIO0 is > 4): ' '#ifndef QUAD_UPPER_NIBBLE_LEFT '#define QUAD_UPPER_NIBBLE_LEFT '#endif ' ' Define this symbol if the upper nibble has to be ' shifted RIGHT for output (i.e. QSPI_SIO0 is < 4): ' #ifndef QUAD_UPPER_NIBBLE_RIGHT #define QUAD_UPPER_NIBBLE_RIGHT #endif '========================== END OF XMM DEFINITIONS ============================= '
That being done, I then had Catalina compile the Sumeria.c which equated to this command line:
catalina sumeria.c -lc -lm -C SMALL -C QUICKSTART -C PMC -C TTY -C CACHED_1K
Catalina responded with:
Catalina compiler 3.13 code = 25564 bytes cnst = 3220 bytes init = 252 bytes data = 1292 bytes file = 63176 bytes
OK, great. I then ran the build_utilities program, told it that it was using a QUICKSTART board along with the PMC board, set the cache settings for 1K for both FLASH and SRAM, and told it to build the bootloader for SRAM.
Then, I ran the Payload utility: payload SRAM sumeria -I
Catalina responded:
Using Propeller (version 1) on port COM3 for first download Using Secondary Loader on port COM3 for subsequent download
Excellent, then it presented the Interface screen and then -- Nothing. No response.
I went back and reconfigured the build_utilities to create the bootloader for FLASH instead.
Then ran Payload again: payload FLASH sumeria -I
Catalina Response:
Using Propeller (version 1) on port COM3 for first download No secondary loader found on any port
Bummer. But for this test I was wanting to load the SRAM only and execute, which is what the first payload attempt above was about, but to no avail.
I would like to look at the XMM config files for PropGCC and attempt to compile and run this program using it.
But before I head too far down this rabbit hole, I want to make sure my hardware setup is correct.
Is there a Byte boundary issue that comes into play? Because my current scheme has the D3 to D0 lines in the Nibble right below the one for the Rx,Tx,SDA,SCL, with my Control signals in the Nibble right below the one for D3 to D0.
Like I said, this scheme works fine with my code, but it may not be "legal" with the XMM drivers available for both Catalina and PropGCC?
If the Byte boundary is an issue, would this work:
P23 - "D3" = SIO3 = (HOLD On SRAM) ( HOLD#/RESET# On Flash) P22 - "D2" = SIO2 = (DNU On SRAM) (WP# On Flash) P21 - "D1" = SIO1 = SO On Both SRAM And Flash P20 - "D0" = SIO0 = SI On Both SRAM And Flash P19 - SCLK (Common To SRAM and FLASH) P18 - RAMCS (Selects SRAM) P17 - FLCS (Selects FLASH) P16 - SDCS (Selects SD Card)
If the Byte boundary isn't an issue, would this be acceptable:
P27 - SCLK (Common To SRAM and FLASH) P26 - RAMCS (Selects SRAM) P25 - FLCS (Selects FLASH) P24 - SDCS (Selects SD Card) P23 - "D3" = SIO3 = (HOLD On SRAM) ( HOLD#/RESET# On Flash) P22 - "D2" = SIO2 = (DNU On SRAM) (WP# On Flash) P21 - "D1" = SIO1 = SO On Both SRAM And Flash P20 - "D0" = SIO0 = SI On Both SRAM And Flash
But if the Byte boundary is an issue, would this be acceptable:
P23 - SCLK (Common To SRAM and FLASH) P22 - RAMCS (Selects SRAM) P21 - FLCS (Selects FLASH) P20 - SDCS (Selects SD Card) P19 - "D3" = SIO3 = (HOLD On SRAM) ( HOLD#/RESET# On Flash) P18 - "D2" = SIO2 = (DNU On SRAM) (WP# On Flash) P17 - "D1" = SIO1 = SO On Both SRAM And Flash P16 - "D0" = SIO0 = SI On Both SRAM And Flash
I'd appreciate your thoughts and tips on this issue before I plunge over a cliff on this, only to find out there's some Byte boundary issue at play I hadn't considered.
Thanks,
Jeff
PS: Let's see if I can attach my code to this:
Comments
If I use the Propeller Memory Card arrangement as a template, but modify it to use a 512KB SPI/SQI SRAM chip and a 4MB SPI/SQI Flash chip with the following Pin arrangement, will it be compatible with your respective PMC XMM memory drivers (assuming, of course, I modify the CFG files to match the new pin settings):
P27 - "D3" = SIO3 = (HOLD On SRAM) ( HOLD#/RESET# On Flash)
P26 - "D2" = SIO2 = (DNU On SRAM) (WP# On Flash)
P25 - "D1" = SIO1 = SO On Both SRAM And Flash
P24 - "D0" = SIO0 = SI On Both SRAM And Flash
P23 - SCLK (Common To SRAM and FLASH)
P22 - RAMCS (Selects SRAM)
P21 - FLCS (Selects FLASH)
P20 - SDCS (Selects SD Card)
Or will this arrangement NOT work regardless of whatever settings are done to the respective PMC CFG files?
Based on my experiments so far, I'm beginning to suspect that this arrangement will NOT work...
This brings up the question as to should the Chip Select and Clock signals be listed first, followed by the Data Bus:
P27 - SCLK (Common To SRAM and FLASH)
P26 - RAMCS (Selects SRAM)
P25 - FLCS (Selects FLASH)
P24 - SDCS (Selects SD Card)
P23 - "D3" = SIO3 = (HOLD On SRAM) ( HOLD#/RESET# On Flash)
P22 - "D2" = SIO2 = (DNU On SRAM) (WP# On Flash)
P21 - "D1" = SIO1 = SO On Both SRAM And Flash
P20 - "D0" = SIO0 = SI On Both SRAM And Flash
Or is there also a Byte boundary issue where each of these Pins must slide down by 4 to the next whole byte (i.e. starting at P23 instead of P27)?
Thanks.
Alas, they are parallel bytewide SRAMs, not SPI/QSPI.
BTW I used Catalina in a commercial product, so I know it can work with XMM.
# dna.cfg # for the DNA board clkfreq: 80000000 clkmode: XTAL1+PLL16X baudrate: 115200 rxpin: 31 txpin: 30 sd-driver: sd_driver.dat sdspi-do: 0 sdspi-clk: 1 sdspi-di: 2 sdspi-cs: 3 # 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} [sqi-sram] load-target: ram sio0-pin: 22 clk-pin: 26 sram-cs-pin: 27 xmem-driver: sqi_sram_xmem.dat xmem-param1: ({sio0-pin} << 24) | ({clk-pin} << 8) | 0x01 xmem-param2: {sram-cs-pin} << 24 [spi-sram] mosi-pin: 22 miso-pin: 23 clk-pin: 26 sram-cs-pin: 27 xmem-driver: spi_sram24_xmem.dat xmem-param1: ({mosi-pin} << 24) | ({miso-pin} << 16) | ({clk-pin} << 8) | 0x21 xmem-param2: {sram-cs-pin} << 24 [spi-flash] miso-pin: {sdspi-do} clk-pin: {sdspi-clk} mosi-pin: {sdspi-di} flash-cs-pin: 4 xmem-driver: winbond_spi_flash_xmem.dat xmem-param1: ({mosi-pin} << 24) | ({miso-pin} << 16) | ({clk-pin} << 8) | 0x01 xmem-param2: {flash-cs-pin} << 24Hello Wingineer. I just saw this thread. I'll take a closer look in the next day or two.
Ross.
Sure, it's the P2 but it is a one-chip and cheaper solution than a P1 and slow external memory.
:-P
True, and the P1 is simpler hardware-wise too but that's where I would draw the line because once it is no longer "simpler" then it like trying to option up an old mini or Altair with modern parts. Whatever you do, it's still a clunker and loses any appeal or nostalgia value it may have had. So the option exists where you could interface the P2 as a fast and cheap 512K customisable SRAM to the P1, either in some parallel or serial fashion. You could and it would make more sense than some of these other awkward memory chips out there, but then that is kind of like how the Prop gets used as a peripheral to some 8-bit micro, it just doesn't make any sense.
Be tolerant!
"Non"sense it is then
If I wanted to have fun on an old system and needed 512K SRAM with a custom interface then I would seriously consider using a P2 just for that very purpose.
Please bear in mind the tone in my replies, it is not critical but I take into consideration that the OP is a newbie here and might not be totally aware of the many options that are available.
Should we do him a disservice because we feel we need to be politically "tolerant"? I think not since we are far more open and friendly than that.
We are simply musing about ways and means because the OP has posted onto an active and public forum which by its very definition is "a meeting or medium where ideas and views on a particular issue can be exchanged."
I exchange my ideas and views because I am trying to be helpful in this regard.
I guess, so far, nobody has any heartburn with this physical pin mapping:
P27 - "D3" = SIO3 = (HOLD On SRAM) ( HOLD#/RESET# On Flash)
P26 - "D2" = SIO2 = (DNU On SRAM) (WP# On Flash)
P25 - "D1" = SIO1 = SO On Both SRAM And Flash
P24 - "D0" = SIO0 = SI On Both SRAM And Flash
P23 - SCLK (Common To SRAM and FLASH)
P22 - RAMCS (Selects SRAM)
P21 - FLCS (Selects FLASH)
P20 - SDCS (Selects SD Card)
It's wire-wrapped so I can change it if necessary. No biggie.
Additional Comments:
-Yes, I'm aware of the forthcoming P2 chip. I'm aware that Chip has been working on designing one since nearly the time the P1 was released. I've seen some threads on the P2Hot effort as well as the various FPGA platforms several of you have been using to test the P2 design.
-Sure, the P2 is the solution to the memory problem. Throw in the smart pins, CORDIC solver, interrupts, and 64 pin I/O interface and you have a very impressive microcontroller. I look forward to getting one once there's a choice of project boards available.
-I think it's unfortunate that Parallax removed the XMM option from SimpleIDE. Granted, the vast majority of users will likely operate under CMM because of memory restrictions. But keeping XMM as an option within the GUI for us crazy folks would have been nice. Glad to see that the underlying PropGCC compiler still supports it via the command line.
-Speaking of SimpleIDE, one feature I would really like on the next release (if there is one) is the ability to choose the installation folder. Right now it installed in the C:\Program Files(x86) folder and I would really prefer to have it in a C:\Compiler folder where I installed the Catalina and CCS compilers.
-I suspect David Betz is correct: Someone, sometime will want an XMM capability for the P2. (Slowly raising my hand)...
-Yeah, the P1 experimentation is a hobby right now. Since I don't have a P2 system, I'm wanting to push the P1 to its limits. A man can't just sit around waiting for a new toy
-I want to know if the P1 can handle communication with a uBlox GPS receiver, a WiFi radio, and provide a user interface to the operator, using the full-duplex serial drivers. Pretty sure it can since there won't be a lot of math involved, just mainly repackaging the data. But there will be lots of Menus available, which will eat through lots of RAM. Hence the exploration of XMM Memory.
-I'll continue to experiment with the current setup. I resorted to a simple program that repeatedly prints "Hello, World!" to the screen (at least it does under CMM). Right now I just want to dump the code to the 512KB SRAM and run it from there in XMM mode. The Flash experiment can come later. So far, I've gotten through the Catalina XMM compile process, and two-stage payload process, but I get nothing on the screen when complete. I haven't tried PropGCC yet but will shortly.
Thanks again for your comments. Please keep them coming. More is better.
When you say-
I get the impression from 'menus' that you want to read in blocks of text (or even an image) and ask the user to select an option. If this is the case then any external memory - (flash or sd) can be rapidly accessed and displayed on screen or terminal without exotic code. Menus in that sense are just static text. Trying to run 'code' from external memory is where the complication comes in.
But
shows the intention to run code from external memory- not necessary if all you want to do is pull text from external memory and display it on your output device. So I am a bit confused.
I expect I have completely misunderstood- but just saying...
Dave
Regarding your first point:
You are absolutely correct that blocks of Menu text can be stored in external memory, read out, then sent to the terminal for display without going the XMM route.
Furthermore, the Menu text could be stored in either the SPI Flash memory or on the SD card and grabbed and displayed when needed.
However, I would be more inclined to have them stored in the Flash memory rather than SD card. Initial loading of the Flash memory could be done by having my code read it from the SD card then storing it in Flash. That way the program could run afterwards without the need for an SD card installed.
But note that most of these Menus will display live raw and formatted data, so they aren't just static Menus requesting a user input.
I would have to write functions to display the static portions and intermix them with live data as well.
Not all that hard to do, but not as easy as just using some printf() statements, either.
Regarding your second point:
My existing code is already at 25KB using the CMM model, and that's without
Menus. I have yet to add the remaining GPS data structures, the GPS uplink and downlink commands and parsing, command structures, the radio uplink and downlink structures, decoding, repackaging, uplink and downlink functions, display outputting and formatting, etc, etc. I'm confident that I will quickly run out of Hub RAM when I start adding these.
For comparison, many years ago, when I did something like this in my former life as a Project Leader developing a GPS tracking system for a military customer, I used a PC/104 stack running FreeDOS on an x86 CPU with separate boards for the GPS receiver and radio. The code to make it all happen was nearly 300KB. And that was after I removed a bunch of features from it. With those additional features the code was somewhere around 450KB.
Now, I'm exploring how much of this capability could be done using a dedicated microcontroller board instead of a PC/104 stack.
Out of curiosity I want to see if I can do something with similar Menus and features using the Prop1 and low cost COTS GPS receiver and radio just as a test. A starting template for future possibilities if you know what I mean. If the Prop1 can't handle it I'm pretty sure the Prop2 could.
So, combining the aforementioned, upcoming, big expansion in the code, along with the Menus, I want to try to do everything using XMM memory.
If XMM works, great. If it doesn't, then I'll have to explore workarounds. Or wait for the Prop2 boards to hit the market and see if it would work.
In the meantime, I'm pressing forward. If nothing else, it will be an educational experience as I learn more of the intricacies of the Prop1.
Hopefully this clarified things...
I won't have time today to look any deeper today, but on a first glance it seems you know about the PMC XMM support files and have started modifying them. The modifications you have made to PMC_XMM_DEF.INC are a start. However, I would suggest you go with your second proposal, as it is closer to the original PMC pin arrangement - i.e.
There are no byte boundary issues that I am aware of - I am recommending this mainly in case there are any undocumented assumptions in the PMC XMM code concerning the order of the pins. I am not aware of any, but there could be some in there.
The main advice I can give you at this point is to get your modified PMC_XMM files working in isolation from the rest of Catalina. To do this, in the "utilities" folder there is a stand-alone XMM RAM Test program that you can use to test your modified PMC files. See The files README.RAM_Test and RAM_Test.Spin. Also, note there is a section in the Catalina Reference Manual called "A Description of the Standard Catalina XMM API" which you should read.
Once you have your XMM RAM working in the RAM Test program, Catalina should work.
Ross.
Had a chuckle at this. P2 will be a bit more expensive than a 512KB SRAM tho'
I think that eventually there might be. This is one reason that I am keeping the LMM execution mode alive on the P2 - this will make it trivial to "bolt on" XMM support at some stage ... and if you are using XMM RAM you probably don't care too much about the performance hit that comes with LMM execution vs Native execution.
However, I am not going to jump into this one. I made a rod for my own back on the P1 by supporting all the available XMM boards available at the time, in all their bewildering variety.
This time I will probably wait until there is some kind of Parallax-endorsed (or at least reasonably widely agreed) standard hardware interface.
As specialty memories go, it's not a bad price either.
Digikey show 4.5MBit dual port memory for ~ $200 3k+
A hot new are is processing-in-memory (PIM) architecture, so this multi-port RAM could fine uses there too
Many thanks for your tips and suggestions.
I'll rearrange the pinouts as you recommended.
It makes sense that the PMC XMM driver was written with the assumption that the clock and control signals are contained within the upper Nibble and the data bus signals in the lower one.
Why I didn't follow that convention at the outset is beyond me.
I'll make the changes over the next week or so and try your XMM test utility to see if it works.
I'm not going to mess with the XMM API settings just yet as I'm hoping the pinout changes and the CFG file update will get the job done.
Once it works under Catalina, I'll venture over to PropGCC and see if I can get it to work there as well.
Thanks again for your help on this.
Just a quick update here.
I essentially copied all of the PMC XMM API info into the CUSTOM config.
I'm still using the original clock, control, and data bus pinouts. I've not implemented the pinout changes you recommended yet. Hopefully I can get to that later this week once I get the new wire wrap tool.
I was able to run the RAM Test utility on my original pinout and in addition to an interesting DEADBEEF message, it showed FAILED for every block of memory it tested.
So either it doesn't like my original pinout, or I screwed up the API settings, or both, or something else is happening.
Anyway, I'll reconfigure the pinouts as you recommended and take it for a spin (no pun intended) later this week (hopefully).
Thanks again for your help.
The "DEADBEEF" message usually means a trivial "one off" read/write to your RAM is working. The subsequent failures mean that more intensive paged read/writes are not, which may often indicate a timing issue.
Here is the header from the Catalina_XMM_RamTest.spin file:
Enabling the PRINT_DETAIL option in that file may give you more clues.
Ross.
I can respect Peter's position also. When the P2 is actually shipping in volume, it will be really nice to see what people will come up with it, including external ram solutions, and emulation solutions(6502, Z90, 68000, ARM, etc).
Actually, the biggest progress we can hope to achieve is a self hosting development environment, especially if that self hosted development environment is the best and most used.
Hinv
There are already a few self-hosting environments for the P2:
(1) First and foremost Tachyon is self-hosted and very mature
(2) micropython is now able to run self-hosted (with a USB keyboard, VGA monitor, and SD card). It's still under development; I don't know how many people have been using it self-hosted.
(3) Chip has mentioned that he plans to make Spin2 self hosted.
Well, I'm not doing anything dramatic like that. I'm just attempting to port my design for a GPS data collection unit from an x86 platform to the Prop1.
The unit doesn't need VGA or KVM capability as all user interaction can take place via the serial Console port (like P31 and P30 on the Prop1).
There were very few math operations performed on the X86 unit, and those were primarily for the Operator display.
Nearly all of the work involved casting data from one type to another and repackaging it from the Novatel GPS format into that used by the control system.
That's in addition to the data downlink via radio, recording via SD card, and multitudes of Menus for the Operator. The maximum data downlink and record rates were 10Hz so nothing really crazy there.
My hunch is that the Prop1 could be used for all of that but I can't really proceed until I have more memory as almost all of the 32KB HubRAM has been consumed even with the CMM compile option.
Hence the need to explore XMM. I'm working with the Catalina compiler so @RossH has been graciously tutoring me on making this happen using the old Propeller Memory Card as the template for my memory addition. I haven't explored this with the PropGCC compiler yet. One step at a time...
I'm really pleased with what this Prop1 can do so far. But if it ultimately can't cut it, I have little doubt that the Prop2 can.
My hardware mods are on hold until I receive some additional parts, but regardless of the final platform (Prop1 or Prop2), the coding effort continues...
Will do. I definitely will try it with PropGCC.
I just decided to give it a try with Catalina first. @RossH has been very helpful with that.
Once I confirm that the hardware and drivers are working with Catalina, I'll swing over to PropGCC and give it a try there.