Revisiting XMM Mode Using Modern Memory Chips

Wingineer19Wingineer19 Posts: 55
edited 2019-06-22 - 16:11:49 in Propeller 1
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:
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:


«134

Comments

  • I guess my ramblings above were really directed to RossH for the Catalina Compiler, and Jazzed, David Betz, and any other developers who worked on the PropGCC Compiler.

    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.




  • IIRC I wrote the drivers for Ross to use the 512KB SRAM on my RAMBlade pcbs.
    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.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • As far as I know, the version of PropGCC that is distributed with SimpleIDE can still do XMM. However, SimpleIDE itself has had all XMM support removed. You'll have to use the command line tools if you want to do XMM. PropGCC comes with drivers for SPI flash chips that will probably work with these newer chips as well. I think I wrote a quad SPI driver at one point but I'm not sure it was all that much faster than regular SPI. Here is the configuration file for the DNA board that supports both SPI and quad SPI.
    # 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} << 24
    
  • One problem with PropGCC XMM mode is that the interface to the "cache drivers" changed between the version of GCC that is distributed with SimpleIDE and the one that is in the main branch of the current PropGCC repository. Parallax asked that we make it possible to run XMM code in more than one COG at the same time and that required some refactoring. However, they never released that new version of PropGCC and then later dropped XMM entirely.
  • I guess my ramblings above were really directed to RossH for the Catalina Compiler, and Jazzed, David Betz, and any other developers who worked on the PropGCC Compiler.

    Hello Wingineer. I just saw this thread. I'll take a closer look in the next day or two.

    Ross.
    Catalina - a FREE ANSI C compiler for the Propeller.
    Download it from http://catalina-c.sourceforge.net/
  • There's this fast 512K 32-bit wide multi-port RAM that's available. I think the part number is P2X8C4M64P and it should be available in the next few months. The beauty about this "memory chip" is that it comes with eight 32-bit CPUs embedded with their own local RAM and 64 smart I/O to play with :)

    Sure, it's the P2 but it is a one-chip and cheaper solution than a P1 and slow external memory.

    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    --->CLICK THE LOGO for more links<---
    P2 +++++ TAQOZ INTRO & LINKS +++++ P2 SHORTFORM DATASHEET
    P1 +++++ Latest binary V5.4 includes EASYFILE +++++ Tachyon Forth News Blog
    Brisbane, Australia
  • Sure, it's the P2 but it is a one-chip and cheaper solution than a P1 and slow external memory.
    But we love our "oldtimers"!
    :-P
    ◁ propeller-wiki ▷ ◁ FastSpin ▷ ◁ DK-E ▷ ◁ :-D ▷ ◁ Stay OmmmmmmPtimistic! ▷ ◁ No Source – No Go! ▷ ◁ Help Spin at RosettaCode.org ▷ ◁ Why Asimov's Laws of Robotics Don't Work ▷ ◁ DNA is a four letter word. ▷
  • yeti wrote: »
    Sure, it's the P2 but it is a one-chip and cheaper solution than a P1 and slow external memory.
    But we love our "oldtimers"!
    :-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.


    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    --->CLICK THE LOGO for more links<---
    P2 +++++ TAQOZ INTRO & LINKS +++++ P2 SHORTFORM DATASHEET
    P1 +++++ Latest binary V5.4 includes EASYFILE +++++ Tachyon Forth News Blog
    Brisbane, Australia
  • it just doesn't make any sense.
    Sense is not a criterium when it is hobby!
    Be tolerant!
    ◁ propeller-wiki ▷ ◁ FastSpin ▷ ◁ DK-E ▷ ◁ :-D ▷ ◁ Stay OmmmmmmPtimistic! ▷ ◁ No Source – No Go! ▷ ◁ Help Spin at RosettaCode.org ▷ ◁ Why Asimov's Laws of Robotics Don't Work ▷ ◁ DNA is a four letter word. ▷
  • yeti wrote: »
    it just doesn't make any sense.
    Sense is not a criterium when it is hobby!
    Be tolerant!

    "Non"sense it is then :)

    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    --->CLICK THE LOGO for more links<---
    P2 +++++ TAQOZ INTRO & LINKS +++++ P2 SHORTFORM DATASHEET
    P1 +++++ Latest binary V5.4 includes EASYFILE +++++ Tachyon Forth News Blog
    Brisbane, Australia
  • yeti wrote: »
    it just doesn't make any sense.
    Sense is not a criterium when it is hobby!
    Be tolerant!

    "Non"sense it is then :)
    Equally wrong.

    ◁ propeller-wiki ▷ ◁ FastSpin ▷ ◁ DK-E ▷ ◁ :-D ▷ ◁ Stay OmmmmmmPtimistic! ▷ ◁ No Source – No Go! ▷ ◁ Help Spin at RosettaCode.org ▷ ◁ Why Asimov's Laws of Robotics Don't Work ▷ ◁ DNA is a four letter word. ▷
  • yeti wrote: »
    yeti wrote: »
    it just doesn't make any sense.
    Sense is not a criterium when it is hobby!
    Be tolerant!

    "Non"sense it is then :)
    Equally wrong.

    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.


    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    --->CLICK THE LOGO for more links<---
    P2 +++++ TAQOZ INTRO & LINKS +++++ P2 SHORTFORM DATASHEET
    P1 +++++ Latest binary V5.4 includes EASYFILE +++++ Tachyon Forth News Blog
    Brisbane, Australia
  • David BetzDavid Betz Posts: 13,341
    edited 2019-06-15 - 14:25:42
    Ross: Do you expect to have an XMM mode for P2 in Catalina? I'm sure there will be people who run out of code space even with 512K of RAM especially if they are using big graphics buffers.
  • Thanks for the replies.

    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.


  • Hi
    When you say-
    there will be lots of Menus available, which will eat through lots of RAM. Hence the exploration of XMM Memory.

    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
    I just want to dump the code to the 512KB SRAM and run it from there in XMM mode

    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
  • Tritonium,

    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...
  • Hello Wingineer

    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.
    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
    

    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.
    Catalina - a FREE ANSI C compiler for the Propeller.
    Download it from http://catalina-c.sourceforge.net/
  • yeti wrote: »
    yeti wrote: »
    it just doesn't make any sense.
    Sense is not a criterium when it is hobby!
    Be tolerant!

    "Non"sense it is then :)
    Equally wrong.

    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.

    Had a chuckle at this. P2 will be a bit more expensive than a 512KB SRAM tho' ;)
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • David Betz wrote: »
    Ross: Do you expect to have an XMM mode for P2 in Catalina? I'm sure there will be people who run out of code space even with 512K of RAM especially if they are using big graphics buffers.

    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.
    Catalina - a FREE ANSI C compiler for the Propeller.
    Download it from http://catalina-c.sourceforge.net/
  • jmgjmg Posts: 13,609
    There's this fast 512K 32-bit wide multi-port RAM that's available. I think the part number is P2X8C4M64P ...

    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 :)


  • RossH,

    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.
  • Ross,

    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.
  • Hi Wingineer19

    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:
    '-------------------------------------------------------------------------------
    '
    '  Catalina_XMM_RamTest - A Memory Test program for XMM RAM.
    '  
    '  Load the program. It will print "To begin, Press any key" and wait for a key
    '  to be pressed. It will then print an "XMM RAM:" banner and display the 
    '  contenst of XMM RAM, 16 longs at a time. To proceed to the first test, say 
    '  "N" at the "Again?" prompt, and the first test will commence. The first
    '  test reads/writes the first few locations of XMM RAM as a trivial test that 
    '  it can read/write XMM RAM at all.
    '
    '  This test should print a "TRIVIAL:" banner, followed by a few lines like:
    '
    '     A 000000xx 000000xx DEADBEEF
    '
    '  Everything is ok if the first two values are the same, and the second value
    '  is DEADBEEF, otherwise the program cannot read/write XMM RAM even when no 
    '  paging is required. The test will continue in any case, but is doomed to 
    '  fail.
    '
    '  The trivial test will print "Again?" when complete. Press Y to repeat the 
    '  trivial test, or N to proceed to a more complex test. The program will
    '  print the banner "COMPLEX:" and then proceed with the test. If it works,
    '  the program will simply print "Complete" and then "Again?" to ask if you
    '  want to repeat the test. Press Y to repeat the complex test, or N to 
    '  proceed to the FLASH test (or to end the program, if the platform being
    '  tested has no FLASH). 
    '
    '  In the complex test, the program initializes the RAM and repeatedly reads 
    '  it back in each of multiple test passes. After each pass it will print 
    '  "Complete". If any memory cells fail it will print "FAIL" and details of
    '  each XMM memory failure. Note the XMM base address is not included in 
    '  the address printed, so XMM address 00000000 is always the first XMM 
    '  location. The base address of the XMM RAM must be set in Catalina_Common.
    '
    '  If you press a key in the middle of a pass, the program will print "Abort"
    '  and abandon the current pass, and return to the "Again?" prompt.
    '
    '  Normally, the complex test prints nothing for successful passes, although
    '  this can be modified by defining the PRINT_DETAIL or PRINT_PROGRESS 
    '  options. But on detecting a memory failure the program prints:
    '  
    '      "FAIL XXXXXXXX=YYYYYYYY(ZZZZZZZZ)"
    '
    '  which means XMM address XXXXXXXX contained the value YYYYYYYY, and not 
    '  the expected value of ZZZZZZZZ.
    '
    '  Note that once a memory location fails, it will fail every pass from then
    '  on if the memory location has actually been corrupted. If you continue to 
    '  test, more memory locations may fail. Note that even if the memory is 
    '  faulty, it may take many passes to fail - it often depends on the size of 
    '  the test. A test of a few hundred longs may take many dozens of passes to 
    '  make a location fail, while a large test (more than a few thousand longs) 
    '  may show a failure on the first pass. Set the number of bytes to include 
    '  in the test using the RAM_SIZE constant.
    '
    '  A memory test of only a small number of longs may never fail - especially 
    '  on page-based XMM systems where the problem is with the paging code and 
    '  the number of longs is small enough that the program never needs to 
    '  change the XMM page.
    '
    '  Note that the complex test also includes long writes, long reads and byte 
    '  writes, and also page reads and writes - but a failure in a page read or 
    '  write will only be detected during the next test pass - so you should 
    '  always do at least 2 passes of the complex test.
    '
    '  On platforms that support SPI FLASH, a Flash test is conducted after the
    '  complex test. This test simply displays the contents of the Flash RAM in
    '  blocks of 64 bytes (press Y to display another block at the "More?" prompt
    '  or N to proceed to the next step) and then erases the whole flash (Again
    '  displaying the contents). Then it writes to the first 512 bytes and then
    '  displays the contents again. The whole test can be repeated at the final 
    '  "Again?" prompt.
    '
    '  On platforms with multiple SRAM chips, a page write may fail if the page
    '  overlaps the boundary between chips. This will show up as a failure in the
    '  second iteration of the complex test. If this occurs, you can define the
    '  symbol NO_OVERLAP to adjust the page size used. 
    '
    

    Enabling the PRINT_DETAIL option in that file may give you more clues.

    Ross.
    Catalina - a FREE ANSI C compiler for the Propeller.
    Download it from http://catalina-c.sourceforge.net/
  • hinvhinv Posts: 850
    edited 2019-06-18 - 21:44:49
    Wingineer19, I would love to see what you come up with, especially if it develops into a usable self hosting environment, or you can get the kind of bandwidth out of it needed for a VGA frame buffer.
    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
  • hinv wrote: »
    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.

  • @hinv said:
    Wingineer19, I would love to see what you come up with, especially if it develops into a usable self hosting environment, or you can get the kind of bandwidth out of it needed for a VGA frame buffer.
    

    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...
  • Let me know if you decide to try this with PropGCC. It should only require creating your own config file with the correct pin definitions if you're using either a SPI or a QuadSPI memory chip.
  • @David Betz,

    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.
  • yetiyeti Posts: 529
    edited 2019-06-19 - 22:13:26
    David Betz wrote: »
    Let me know if you decide to try this with PropGCC. It should only require creating your own config file with the correct pin definitions if you're using either a SPI or a QuadSPI memory chip.
    Even with the 512k*8 chips?
    ◁ propeller-wiki ▷ ◁ FastSpin ▷ ◁ DK-E ▷ ◁ :-D ▷ ◁ Stay OmmmmmmPtimistic! ▷ ◁ No Source – No Go! ▷ ◁ Help Spin at RosettaCode.org ▷ ◁ Why Asimov's Laws of Robotics Don't Work ▷ ◁ DNA is a four letter word. ▷
  • yeti wrote: »
    David Betz wrote: »
    Let me know if you decide to try this with PropGCC. It should only require creating your own config file with the correct pin definitions if you're using either a SPI or a QuadSPI memory chip.
    Even with the 512k*8 chips?
    They will need a new cache driver but that shouldn't be too hard to create. Does someone have a board with these chips on it?

Sign In or Register to comment.