Shop OBEX P1 Docs P2 Docs Learn Events
Catalina - ANSI C and Lua for the Propeller 1 & 2 - Page 6 — Parallax Forums

Catalina - ANSI C and Lua for the Propeller 1 & 2

13468916

Comments

  • RossHRossH Posts: 5,463
    edited 2023-02-16 01:12

    @TommieBoy said:
    Thanks @RossH! Now I can turn my attention to the libraries.

    Rather than start with the Simple Libraries, I thought maybe I shouldn't reinvent the wheel.

    You have several libraries included with Catalina and they include 586 unique functions. Some of which are straight forward, like abs(int) , but some are more esoteric, like add_CT1.() .

    Some are also probably equivalents or very similar, like pause() and waitms() . I wouldn't have to recompile these with Catalina to use them.

    I could go through all of the include files and find the declarations, but perhaps you already have some documentation stored away someplace? If so, that would allow me to shorten my research.

    I haven't documented functions that are just standard ANSI C or POSIX library functions - such as abs(). Your best source of information for those is an ANSI C reference guide, such as https://eecs.wsu.edu/~aofallon/cpts122/CLibraryReferenceGuide.pdf and https://raw.githubusercontent.com/freebendy/ben-books/master/POSIX_Thread/Programming with Posix Threads.pdf

    I also haven't documented functions that are essentially just a C wrapper around a single PASM instruction - such as add_CT1() which is just a wrapper around the "addct1" instruction. I expected people to recognize those, although I guess they are not so obvious to those unfamiliar with the Propeller and its instruction set. The header files are indeed your best source of documentation for those, since all you generally need to know is the parameter names and types.

    Any other documentation I have is already in the released documents, such as the Catalina Reference Manual - it documents functions whose operation may not be immediately obvious, such as the HMI or other plugin functions, or the cog or thread functions.

    Ross.

  • Thanks @RossH. I'll check out those references.

  • RossHRossH Posts: 5,463

    Haven't had much time for Catalina recently, but I just updated the P2 XMM support to add support for the P2 HyperFlash/Hyper RAM add-on board - worked first try! However, I can't take much credit - most of it has to go to Rogloh's drivers.

    The HyperFlash/HyperRAM add-on board is supported on both the P2 EVAL and the P2 EDGE. On the P2 EDGE you now have the choice of using the internal PSRAM (if your board has it) or the Hyper add-on board.

    More testing to do, but a new release - which will also include an improved version of payload - won't be far off.

    Ross.

  • RossHRossH Posts: 5,463
    edited 2023-02-27 05:31

    Catalina 5.8 has been released here.

    The main purpose of this release is to add support for the Parallax Propeller 2 HyperFlash & HyperRAM add-on board, thanks mainly to Roger Loh's memory drivers. This add-on board is now supported on the P2_EVAL and the P2_EDGE. On the P2_EDGE you can use either the internal PSRAM (if your board has it) or you can use the HyperRAM add-on board as XMM RAM and also use the HyperRAM and HyperFlash as additional storage.

    This release also fixes a few issues with the payload loader and the comms vt100 emulator.

    The only Propeller 1-specific change is the addition of configuration files for the Parallax Activity board, and the addition of a Catalina symbol (i.e. ACTIVITY) to use them.

    Here is the relevant extract from the README.TXT:

    RELEASE 5.8
    
    New Functionality
    -----------------
    
    1. The Parallax P2 HyperRAM/HyperFlash add on board can now be used as
       either additional RAM & Flash storage or as XMM RAM. It is supported on 
       the P2_EDGE and P2_EVAL boards. There is a new library (libhyper) that
       supports this board, so to use it simply inlcude the '-lhyper' option on
       the Catalina command line. The hyper library is functionally similar to 
       the existing psram library, but it has additional functions to support 
       the Hyper Flash memory on this board.
    
       It is not normally necessary to specify the type of XMM RAM when 
       building programs for the P2_EDGE or P2_EVAL. Just specify -C SMALL 
       or -C LARGE on the command line. On the P2_EVAL Catalina will assume
       you have a Hyper RAM add-on board, and on the P2_EDGE Catalina will
       assume you want to use the on-board PSRAM.
    
       For example - to use Hyper RAM on the P2_EVAL:
    
          catalina -p2 -lci -C P2_EVAL -C LARGE hello_world.c
    
       Or, to use PSRAM on the P2_EDGE:
    
          catalina -p2 -lci -C P2_EDGE -C LARGE hello_world.c
    
       However, you can override this by specifying -C HYPER or -C PSRAM on
       the command line. For instance, to use the Hyper RAM add-on board on
       a P2_EDGE, you might say:
    
          catalina -p2 -lci -C P2_EDGE -C SMALL -C HYPER hello_world.c
    
       Note that you have to use the build_utilities script to build the
       XMM utilities appropriately. The build_utilities script has been 
       updated to know how to build the XMM utilities required to use the 
       Hyper RAM as XMM RAM. Just specify HYPER as the XMM add-on board 
       when building utilities for either the P2_EDGE or the P2_EVAL.
    
       A simple demo program called 'ex_hyper.c' has been added to the Catalina
       demos\examples folder to illustrate the use of the HyperRAM library.
    
       A more extensive HyperRAM & HyperFlash test program has been added in
       a new folder called demos\p2_ram, which also contains utilities that 
       can be used to demonstrate PSRAM as well as Hyper RAM.
    
       Some versions of the P2_EDGE have PSRAM and can use either PSRAM or the
       Parallax HyperRAM/HyperFlash add-on board, but it is not currently 
       possible to use both the on-board PSRAM and Hyper RAM in the same 
       programs because of name conflicts between the two drivers. 
    
       On the P2_EVAL, the Hyper RAM module uses base pin 32. On the P2_EDGE, 
       it uses base pin 16. You can change this in the files P2_EVAL.inc and
       P2_EDGE.inc in the target_p2 directory.
    
    2. Payload has revised file extension processing:
    
       Use the bare filename if an extension is specified, but if not, then for 
       the first download try ".binary", ".eeprom", ".bin", ".bix", ".biy" in 
       that order, and then the bare filename if none of these are found. 
    
       For the second and subsequent downloads, use the bare filename if an 
       extension is specified, but if not then for a Propeller 1 try ".binary" 
       and ".eeprom" then the bare filename. For a Propeller 2 try ".bin", 
       ".bix" and ".biy" then the bare filename. 
    
       Also, unless it has been overridden, set the default baud rate depending
       on whether the first file has a Propeller 1 or Propeller 2 file extension.
    
       If a version override is specified (i.e. via command line option -o) then 
       only try the extensions appropriate for the version (".binary" or ".eeprom"
       for a Propeller 1, or ".bin", ".bix", ".biy" for a Propeller 2) for the
       first file as well as the second or subsequent files. 
    
       The local directory is always searched for all extensions first, then 
       %LCCDIR%\bin (Windows) or $LCCDIR/bin (Linux) if no matching file is found
       in the local directory. This is mainly intended to allow payload to load 
       the various loader utilities, such as XMM, SRAM, EEPROM, FLASH etc.
    
    3. Payload has revised override version processing. If an override version
       is specified (using the -o option on the command line), payload will only 
       detect Propeller chips with the specified version, and will not detect
       other versions even if they are connected. This allows Propeller 2 ".bin" 
       file to co-exist in the same directory as a Propeller 1 ".binary" files
       provided the correct override version is specified in the payload command. 
       It also means you no longer have to unplug Propellers if you routinely 
       develop for both Propeller 1 and Propeller 2 chips.
    
    4. Comms now correctly decodes the comm port when it is specified on the
       command line as "/com=N". Previously, this only worked when N >= 10.
       It was (and still is) possible to specify it as "/com=comN".
    
    5. Blackbox has been modified so that when duplicate source lines have the 
       same address, it associates the address with the LAST such line, rather
       than the FIRST such line, because this is the line more likely to actually
       have any code associated with that address.
    
    6. Support has been added in the Propeller 1 target packages for the Parallax
       Activity board. The Catalina symbol is ACTIVITY. This means you can now
       specify -C ACTIVITY on the Catalina command line (or just add ACTIVITY
       to the CATALINA_DEFINE environment variable) and Catalina will use the pin
       definitions etc in the Activity configuration files (i.e. Activity_DEF.inc,
       Activity_CFG.inc, Activity_HMI.inc). For example:
    
          catalina -lc -C ACTIVITY hello_world.c 
    
    Other Changes
    -------------
    
    1. The default VGA and USB pins on the P2_EVAL have changed from 32 & 40
       to 0 & 8 - this was done to match the P2_EDGE, and also to allow the 
       default base pin used for the P2 HyperFlash/HyperRAM module on the 
       P2_EVAL to be the same as in RogLoh's original Spin drivers - to 
       encourage users of those drivers to try Catalina! :) 
       You can change this in the file P2_EVAL.inc in the target_p2 directory.
    
    2. The 'ex_psram.c' demo program in the demos\examples folder has been 
       revised to demonstrate that a program that uses PSRAM for storage can 
       itself be compiled as an XMM program.
    
    3. The build_utilities scripts have been extensively re-written to make them
       more maintainable (e.g. the Linux and Windows versions are now much more
       similar). The new scripts have been tested for all supported Propeller 2 
       boards and all the working Propeller 1 boards I still have, but just in 
       case I made a mistake and they do not work correctly, the previous scripts
       have been left in the utilities folder and called build_utilities_5.7.
    

    I will support this release - do doubt there will be some issues. Everything I have tested to do with PSRAM, HyperRAM or HyperFlash works, but Roger's drivers have so much functionality that I have not even figured out what some of it is for, let alone how to test it adequately!

    However, I need to take a long hard think about Catalina's future. Just as it did on the Propeller 1, the addition of XMM RAM support on the Propeller 2 has increased the complexity exponentially and made it a beast to support and modify. Catalina now has so much functionality that even with partly automated testing, there are so many options and combinations of options that it now takes so long just to do a basic sanity test on a release that I am not getting any time to do any of my own stuff.

    Ross.

  • RE: Prop2 SPI Boot Flash File System?

    Hello @RossH,

    For my newest Project, I need to save about 1KB of WiFi configuration information to external memory, then retrieve it upon application startup. For the Prop1, I simply stored this information as a string in the upper regions of the boot EEPROM memory, and wrote my own functions to support access to it.

    Since this Project code is becoming more complex, I've made the fateful decision to migrate it over to the Prop2. I have a P2_EVAL board and in addition to its 16MB SPI boot flash memory it has a socket for a micro-SD card. But we all knew that.

    Now, to save the WiFi parameters for the Prop2, I could use your SD_Card plugin to access the SD_Card which would allow me to use the standard fopen(), fclose(), fwrite(), fread(), etc functions. This would certainly get the job done.

    However, I would prefer to not use an external micro-SD card but rather store (and retrieve) the WiFi information within the SPI flash boot memory. Although the currently marketed P2_EVAL and P2_EDGE boards do support an SD_Card, future Prop2 boards (perhaps something similar to a Prop2 FLiP) might not, but all of them will need to have an SPI boot flash.

    I think the P2_EVAL has a 16MB SPI flash boot memory, and I assume only 512KB of that will be required for Prop2 bootup, so it appears that over 15MB of storage is there for the taking.

    I only need 1KB or so for variable storage. Write operations will be few and far between, so we're primarily looking at read operations here, and typically only at application startup.

    I think you can see where this is going: Is there any way the SD_Card plugin can support the SPI flash boot memory?

    Obviously I don't need access to the entire 16MB, but maybe the plugin could allow the user access to 8MB or so? That would be more than sufficient.

    If not, it's no big deal. I can write my own functions to write/read to/from the SPI flash on the Prop2 just like I did for the EEPROM of the Prop1, but it wouldn't be as clean and elegant as using the standard library file functions.

  • RossHRossH Posts: 5,463

    @Wingineer19 said:
    RE: Prop2 SPI Boot Flash File System?

    I think you can see where this is going: Is there any way the SD_Card plugin can support the SPI flash boot memory?

    >

    Hello @Wingineer19

    This is on my TO DO list. However, it is not near the top and the list is now so long I am beginning to suspect I will never reach the end of it in my lifetime! :)

  • @RossH,

    LOL, I understand. Too much to do and too little time to get it all done.

    I'll continue my software development using a micro-SD card and your SD_Card plugin to save and retrieve the WiFi information.

    When (if?) you modify the SD_Card driver to also support the SPI boot flash memory then I'll modify my code to work with it.

  • Hi @RossH,

    I'm working on my own set of functions to write/read to/from a block of memory in the SPI flash chip on my P2_EVAL (RevB) board.

    To do that I need to be able to toggle the SPI_CS (pin 60), SPI_CLK (pin 61), and SPI_DO (pin 59) pins, along with reading the SPI_DI (pin 58) pin.

    I've tried using the setpin() as well as the _pinl() and _pinh() functions to get the pins to change state but to no avail.

    I've also tried using the getpin() and _pinr() functions to read the input pin state but it always reads as a 1.

    Am I missing a DIR configuration setup of some sort before I attempt to use the above functions? That would explain the results I'm seeing...

  • RossHRossH Posts: 5,463

    Hello @Wingineer19

    It should not be necessary to explicitly use DIR with setpin(), _pinl() or _pinh().

    They all seem ok to me. Here is a trivial test program:

    /*
     * simple pin test program
     *
     * compile for P2_EVAL using:
     *
     *    catalina -p2 -lci -C P2_EVAL pintest.c
     *
     * compile for P2_EDGE using:
     *
     *    catalina -p2 -lci -C P2_EDGE pintest.c
     *
     * For other platforms, edit the definitions of PIN1 and PIN2 below.
     *
     * Execute with a command like:
     *
     *    payload pintest -i
     */
    
    #include <propeller.h>
    #include <propeller2.h>
    
    #ifdef __CATALINA_P2_EVAL
    #define PIN1 56
    #define PIN2 57
    #elif __CATALINA_P2_EDGE
    #define PIN1 38
    #define PIN2 39
    #else
    #define PIN1 1
    #define PIN2 2
    #endif
    
    void main() {
       printf("PIN1 = %d\n", PIN1);
       printf("PIN2 = %d\n", PIN2);
       printf("\n");
    
       while (1) {
          printf("Press a key to setpin(PIN1, 0)\n");
          k_wait();
          setpin(PIN1, 0);
          printf("_pinr(PIN1) = %d\n\n", _pinr(PIN1));
    
          printf("Press a key to setpin(PIN1, 1)\n");
          k_wait();
          setpin(PIN1, 1);
          printf("_pinr(PIN1) = %d\n\n", _pinr(PIN1));
    
          printf("Press a key to _pinl(PIN2)\n");
          k_wait();
          _pinl(PIN2);
          printf("_pinr(PIN2) = %d\n\n", _pinr(PIN2));
    
          printf("Press a key to _pinh(PIN2)\n");
          k_wait();
          _pinh(PIN2);
          printf("_pinr(PIN2) = %d\n\n", _pinr(PIN2));
    
       }
    }
    
    

    One problem might be using getpin() - this is problematic because getpin() turns the pin into an input - you cannot use it to read the value of an output. But _pinr() seems to work ok for this purpose since it test the value without turning the pin into an input.

    Here is a quick summary:

    • setpin => set pin to output and set its value
    • getpin => set pin to input and read its value
    • _pinl => set pin to output and drive pin low
    • _pinh => set pin to output and drive pin high
    • _pinr => test pin
  • Just as a side note re: SPI flash file systems, I've ported the ARM LittleFS flash file system to FlexC. It does require some C99 features; @RossH I don't think Catalina supports C99 yet, but perhaps there's a newer version of LCC that has C99 support? Other than the C99 requirement it's very generic C. At this point very few compilers are restricted to C89 (the original ANSI).

    As an alternative it may be possible to compile SPIFFS with a plain C89 compiler; I found the documentation for SPIFFS a bit lacking, though.

  • Hi @RossH,

    Try this code and see if you can get it to work.

    Initially the printout is correct.

    After the first toggle the printout goes haywire, but the pin toggling appears to still work.

    Maybe I'm doing something wrong with the s8 functions?

    //Program Is PinTest.c
    //Last Revision On 14Mar23
    //Works With The SPI Pins
    
    // Compile with: catalina pintest.c -p2 -lc -lma -lserial8 -C NO_HMI -C P2_EVAL -C NATIVE -y
    
    // Upload with:  payload pintest.bin -o2 -b115200 -Ivt100
    
    #include <stdio.h>
    #include <stdlib.h>
    #include <stdarg.h>
    #include <math.h>
    #include <string.h>
    #include <time.h>
    #include <propeller.h>
    #include <propeller2.h>
    #include <catalina_serial8.h>
    #include <catalina_plugin.h>
    
    #define     ConSerPort                 0
    #define     ConRxDPortNum              0
    #define     ConRxDPinNum               63
    #define     ConTxDPortNum              1
    #define     ConTxDPinNum               62
    #define     ConBaud                    115200
    #define     ConBuffSize                128
    
    #define     SPI_CS                     60
    #define     SPI_CLK                    61
    #define     SPI_OUT                    59
    #define     SPI_IN                     58  
    
    
    char        ConTxDBuffer[ConBuffSize];
    char        ConRxDBuffer[ConBuffSize];
    
    void ConPrint(char *format,...)
    {
     va_list ptr;
     va_start(ptr,format);
     vsprintf(ConTxDBuffer,format,ptr);
     va_end(ptr);
     s8_str(ConSerPort,ConTxDBuffer);
    }
    
    int getkey(char Port)
    {
     return(s8_rxcheck(Port));
    }
    
    void main(void)
    {
     s8_openport(ConSerPort,ConBaud,0,
                 ConRxDPinNum,ConRxDBuffer,ConRxDBuffer + ConBuffSize,
                 ConTxDPinNum,ConTxDBuffer,ConTxDBuffer + ConBuffSize);
     while(getkey(ConSerPort) < 0);
     ConPrint("Testing SPI_CS and SPI_CLK Pins\r\n\r\n");
     while(getkey(ConSerPort) < 0);
     ConPrint("Hit Any Key To Begin Testing\r\n\r\n");
     while(getkey(ConSerPort) < 0);
     for(;;)
      {
       ConPrint("Now Setting SPI_CS LO -- The LED Should Be ON\r\n");
       _pinl(SPI_CS);
       ConPrint("Reading SPI_CS Pin As %d\r\n",_pinr(SPI_CS));
       while(getkey(ConSerPort) < 0);
    
       ConPrint("Now Setting SPI_CS HI -- The LED Should Be OFF\r\n");
       _pinh(SPI_CS);
       ConPrint("Reading SPI_CS Pin As %d\r\n",_pinr(SPI_CS));
       while(getkey(ConSerPort) < 0); 
    
       ConPrint("Now Setting SPI_CLK HI -- The LED Should Be OFF\r\n");
       _pinh(SPI_CLK);
       ConPrint("Reading SPI_CLK Pin As %d\r\n",_pinr(SPI_CLK));
       while(getkey(ConSerPort) < 0);
    
       ConPrint("Now Setting SPI_CLK LO -- The LED Should Be ON\r\n");
       _pinl(SPI_CLK);
       ConPrint("Reading SPI_CS Pin As %d\r\n",_pinr(SPI_CLK));
       while(getkey(ConSerPort) < 0);
      }
    }
    
  • RossHRossH Posts: 5,463

    Hello @wingineer29

    Yes, a couple of issues with the use of the s8 library:

    1. You cannot use the the buffers you provide to s8_openport() yourself - they are for internal use by the s8 library. So in ConPrint() just define a local buffer and use that instead. This was the main problem.
    2. You should point to the last byte in the buffer in s8_openport(), whereas your code points to the following byte - add -1 to the appropriate parameters.

    Here is a working version:

    //Program Is PinTest.c
    //Last Revision On 14Mar23
    //Works With The SPI Pins
    
    // Compile with: catalina pintest.c -p2 -lc -lma -lserial8 -C NO_HMI -C P2_EVAL -C NATIVE -y
    
    // Upload with:  payload pintest.bin -o2 -b115200 -Ivt100
    
    #include <stdio.h>
    #include <stdlib.h>
    #include <stdarg.h>
    #include <math.h>
    #include <string.h>
    #include <time.h>
    #include <propeller.h>
    #include <propeller2.h>
    #include <catalina_serial8.h>
    #include <catalina_plugin.h>
    
    #define     ConSerPort                 0
    #define     ConRxDPortNum              0
    #define     ConRxDPinNum               63
    #define     ConTxDPortNum              1
    #define     ConTxDPinNum               62
    #define     ConBaud                    115200
    #define     ConBuffSize                128
    
    #define     SPI_CS                     60
    #define     SPI_CLK                    61
    #define     SPI_OUT                    59
    #define     SPI_IN                     58  
    
    
    char        ConTxDBuffer[ConBuffSize];
    char        ConRxDBuffer[ConBuffSize];
    
    void ConPrint(char *format,...)
    {
     char        tmpBuff[ConBuffSize];
     va_list ptr;
     va_start(ptr,format);
     vsprintf(tmpBuff,format,ptr);
     va_end(ptr);
     s8_str(ConSerPort,tmpBuff);
    }
    
    int getkey(char Port)
    {
     return s8_rxcheck(Port);
    }
    
    void main(void)
    {
     s8_openport(ConSerPort,ConBaud,0,
                 ConRxDPinNum,ConRxDBuffer,ConRxDBuffer + ConBuffSize-1,
                 ConTxDPinNum,ConTxDBuffer,ConTxDBuffer + ConBuffSize-1);
     while(getkey(ConSerPort) < 0);
     ConPrint("Testing SPI_CS and SPI_CLK Pins\r\n\r\n");
     while(getkey(ConSerPort) < 0);
     ConPrint("Hit Any Key To Begin Testing\r\n\r\n");
     while(getkey(ConSerPort) < 0)
     for(;;)
      {
       ConPrint("Now Setting SPI_CS LO -- The LED Should Be ON\r\n");
       _pinl(SPI_CS);
       ConPrint("Reading SPI_CS Pin As %d\r\n",_pinr(SPI_CS));
       while(getkey(ConSerPort) < 0);
    
       ConPrint("Now Setting SPI_CS HI -- The LED Should Be OFF\r\n");
       _pinh(SPI_CS);
       ConPrint("Reading SPI_CS Pin As %d\r\n",_pinr(SPI_CS));
       while(getkey(ConSerPort) < 0); 
    
       ConPrint("Now Setting SPI_CLK HI -- The LED Should Be OFF\r\n");
       _pinh(SPI_CLK);
       ConPrint("Reading SPI_CLK Pin As %d\r\n",_pinr(SPI_CLK));
       while(getkey(ConSerPort) < 0);
    
       ConPrint("Now Setting SPI_CLK LO -- The LED Should Be ON\r\n");
       _pinl(SPI_CLK);
       ConPrint("Reading SPI_CS Pin As %d\r\n",_pinr(SPI_CLK));
       while(getkey(ConSerPort) < 0);
      }
    }
    

    Ross.

  • RossHRossH Posts: 5,463

    @ersmith said:
    Just as a side note re: SPI flash file systems, I've ported the ARM LittleFS flash file system to FlexC. It does require some C99 features; @RossH I don't think Catalina supports C99 yet, but perhaps there's a newer version of LCC that has C99 support? Other than the C99 requirement it's very generic C. At this point very few compilers are restricted to C89 (the original ANSI).

    As an alternative it may be possible to compile SPIFFS with a plain C89 compiler; I found the documentation for SPIFFS a bit lacking, though.

    I'll take a look. Thanks.

    Catalina supports some C99 features (the sensible ones). In any case, C89 and C99 are so close it should be possible to get it working fairly easily. Interestingly, one of the most problematic changes - variable length arrays - introduced in C99 was removed again from C in C11. The C standards bodies lost the plot a bit after C89.

    Ross.

  • Hi @RossH,

    OK, what you said makes sense about the two character buffers referenced within the s8_openport() function as being for internal use only.

    To avoid confusing myself further, I created a new function called s8_portopen() wherein I only need to provide the two character buffers and their size, not their endpoints.

    Here's the test code:

    //Program Is Trouble.c
    //Last Revision On 15Mar23
    
    //compile using: catalina trouble.c -p2 -lc -lma -lserial8 -O5 -C NO_HMI -C P2_EVAL -C NATIVE -y
    
    //upload using:  payload trouble.bin -o2 -b115200 -Ivt100
    
    #include <stdio.h>
    #include <stdlib.h>
    #include <stdarg.h>
    #include <math.h>
    #include <string.h>
    #include <time.h>
    #include <propeller.h>
    #include <propeller2.h>
    #include <catalina_serial8.h>
    #include <catalina_plugin.h>
    
    #define  ConPort                0
    #define  ConRxDPin              63
    #define  ConTxDPin              62
    #define  ConBaudRate            115200
    #define  ConBuffSize            128
    
    char ConFifoTxD[ConBuffSize];
    char ConFifoRxD[ConBuffSize];
    
    int s8_portopen(unsigned port,unsigned baud,unsigned mode,
                    unsigned rx_pin,char *rx_buff,unsigned rx_size,
                    unsigned tx_pin,char *tx_buff,unsigned tx_size)
    {
     return(s8_openport(port,baud,mode,rx_pin,rx_buff,rx_buff + rx_size - 1,tx_pin,tx_buff,tx_buff + tx_size - 1));
    }
    
    void main(void)
    {
     s8_portopen(ConPort,ConBaudRate,0,ConRxDPin,ConFifoRxD,ConBuffSize,ConTxDPin,ConFifoTxD,ConBuffSize);
    }
    

    However, when I attempted to compile I got this error:

    C:\WorkDesk\Compiler\Catalina\Prop2\Trouble>catalina trouble.c -p2 -lc -lma -lserial8 -O5 -C NO_HMI -C P2_EVAL -C NATIVE -y
    Catalina Compiler 5.8
    trouble.c:32: illegal return type; found `void' expected `int'
    
    C:\WorkDesk\Compiler\Catalina\Prop2\Trouble>
    

    But if I change the s8_portopen() function to a void type like this it will compile fine:

    void  s8_portopen(unsigned port,unsigned baud,unsigned mode,
                    unsigned rx_pin,char *rx_buff,unsigned rx_size,
                    unsigned tx_pin,char *tx_buff,unsigned tx_size)
    {
     s8_openport(port,baud,mode,rx_pin,rx_buff,rx_buff + rx_size - 1,tx_pin,tx_buff,tx_buff + tx_size - 1);
    }
    

    By no means did this create any type of problem for me.

    I just found it curious because I thought the s8_openport() function returned an int value as referenced in the manual but I guess not...

  • RossHRossH Posts: 5,463

    @Wingineer19 said:

    I just found it curious because I thought the s8_openport() function returned an int value as referenced in the manual but I guess not...

    The mistake is in the manual - s8_openport() is defined in the header file and library source as returning a void - i.e. it does not return anything at all.

    The same is true of s8_closeport().

    Apologies. I will update the manual in the next release.

    Ross.

  • Hi @RossH,

    No problem, I just wanted to make sure I wasn't missing something or doing something wrong again.

    Now, I will turn my focus to the SPI chip itself and try to determine why it isn't storing the block of data I'm sending to it...

  • @ersmith said:
    Just as a side note re: SPI flash file systems, I've ported the ARM LittleFS flash file system to FlexC..

    Catalina supports a flash file system that allows the use of ANSI standard file I/O functions, but right now it's confined to an SD Card.

    Since both the SD Card and the P2_EVAL boot flash both use SPI, it seems that the SPI functions needed to communicate with the boot flash instead of the SD Card would be very similar, if not identical.

    One of the issues involved with modifying the SD Card file system functions would be the necessity of introducing a fixed offset address from the beginning of the flash chip to avoid overwriting of the bootup code. If, for example, the first 2MB or so was blockaded, then the remaining 14MB could be used by the file system for storage.

    Ultimately, when (or if?) the time and opportunity arises for @RossH to include this capability within Catalina he would have to make the call on whether or not to modify the existing SD Card code to support the SPI flash, or go with a ported version of the LittleFS as is used for Flexprop.

    In the meantime I will continue work on my own functions to get the SPI flash to store/retrieve a block of configuration data that my application needs. Admittedly, though, the ability to use standard file I/O functions would be a lot less messy.

  • RossHRossH Posts: 5,463

    Catalina 5.9 has been released here.

    The main purpose of this release is to add a few small features that had been requested, polish up the documentation, and fix a few minor issues, including one with the Windows Installer - at some point (not exactly sure when) it seems to have stopped correctly adding the Catalina Command Line entry to the Windows Start Menu. The desktop shortcuts worked correctly and I never use the Windows Start Menu, so I hadn't noticed.

    Here is the relevant section of the README.TXT:

    RELEASE 5.9
    
    New Functionality
    -----------------
    
    1. The multiport serial libraries (serial2, serial4, serial8) have each had
       two new functions added:
    
          int sX_txcount(unsigned port)
          int sX_rxcount(unsigned port)
    
       where X = 2, 4 or 8. The functions return the current count of characters 
       waiting in the transmit or receive buffers.
    
    2. New variants of the maths functions to truncate and round floats have been
       added, called ltrunc() and lround(), which return longs. The original 
       versions of trunc() and round() were incorrectly defined in the include
       file catalina_float.h as returning floats - in fact, they both returned 
       long values. These functions have been retained, but have been renamed as 
       _round() and _trunc(). These functions were only available when a maths 
       co-processor library option was specified - e.g. if -lma, -lmb (P1 or P2) 
       or -lmc (P2 only), and were not available in the software-only library
       option -lm. 
    
       The new variants are called lround() and ltrunc() and return longs. 
       They are available when any maths library option is used - i.e. including
       the -lm option. Also, new functions have been added called fround() and 
       ftrunc() which return floats. 
    
       So now a program that needs round() or trunc() can choose which to use
       either by calling them directly, or by adding suitable #defines, such as
    
       EITHER:
    
          #define round(x) lround(x)
          #define trunc(x) ltrunc(x)
    
       OR:
    
          #define round(x) fround(x)
          #define trunc(x) ftrunc(x)
    
       OR:
    
          #define round(x) _round(x)
          #define trunc(x) _trunc(x)
    
       depending on whether it needs versions that return longs, versions that
       return floats (or doubles - in Catalina doubles are the same as floats, 
       so if the program expects these functions to return doubles, it will work 
       perfectly well with the new versions) or it wants to use the original
       versions.
    
    3. On the Propeller 1, the functions _waitsec(), _waitus() and _waitms()
       use the WAITCNT instruction, and are "thread-safe", but on the Propeller 
       2 they use timer 2 and the WAITCT2 instruction. This means they are not 
       "thread-safe" since waiting on a timer also stalls interrupts. However, 
       there are now "interrupt-safe" versions provided for the Propeller 2, 
       called _iwaitsec(), _iwaitms() and _iwaitus(). These use the POLLCT2 
       instruction and so do not stall interrupts, but they busy-wait. This 
       means they consume more power, and they will also be very slightly less 
       accurate, but accuracy cannot be guaranteed in a multi-threaded program, 
       or one that uses interrupts.
    
    Other Changes
    -------------
    
    1. The Catalina Propeller 2 Reference Manual said the 8 port serial functions 
       s8_openport() and s8_closeport() returned an int. In fact, they both return 
       void - i.e. they don't return anything. The manual has been updated.
    
    2. The Catalina maths functions round() and trunc() were incorrectly defined 
       in catalina_float.h as returning floats - in fact, they both returned long
       values. See the New Functionality section for more details.
    
    3. Catalina's original implementation of trunc(), which was also used when 
       a float was "cast" to an integer, was based on Cam Thompson's original 
       Float32_A co-processor, which unnecessarily limited the range in which 
       it would return a value. That range has been extended to include the 
       maximum range that can be encoded accurately in a float. Note that 
       this does not mean all longs in this range can be encoded - the way 
       IEEE457 floats are implemented means there are "gaps" in the integers
       that can be encoded as floats once you exceed the number of bits in the 
       mantissa. However, within the newly extended range (which corresponds to
       the integer range of -2,147,483,583 to 2,147,483,583) the implementation 
       of both ltrunc() and lround() will now return the correct integer value. 
       Outside that range they will return zero.
    
    4. The documentation regarding the 8 Port Serial plugin was a little 
       contradictory regarding the meaning and use of S8_MAX_PORTS. Setting this 
       determines the maximum number of ports that CAN BE OPENED, not the number 
       of ports that will be opened automatically. A port will only be opened 
       automatically if the port number is less than S8_MAX_PORTS, AND it has 
       pins specified in the range 0 .. 63 in the platform configuration file. 
       If the port has pins specified outside this range (e.g. as -1) then the 
       port will not be opened automatically but can be opened manually using
       the s8_openport() function. A port number greater or equal to S8_MAX_PORTS 
       will never be opened. If you want different baud rates or large buffer 
       sizes, it is recommended to open the ports manually.
    
    5. The accuracy of the various _wait functions (i.e. _waitsec(), _waitms(), 
       _waitus()) has been improved significantly. Also, the calculations of how
       long each unit of time is in clock ticks are now only done on the first
       call, not on every call as in previous releases. They are also recalculated
       on any call where a change in clock frequency is detected, This speeds up 
       the calls, but it means that the very first call in such cases will be very
       slightly longer than subsequent calls - if this is a problem, add a call 
       like:
          _waitus(0);
       to force a re-calculation - subsequent waits will then be more consistent.
       Note that any call calculates the times for all the _wait functions, not 
       just the one actually called. Also note that for _waitus() there is a 
       minimum number of microseconds that can be waited for accurately - the 
       actual value depends on the memory model used, but for Propeller 2 in 
       NATIVE mode (the default mode) it is about 5 10us, and on the Propeller 1
       in TINY mode (the default mode) it is about 30us. If shorter accurate wait
       times are required, consider using an inline PASM assembly language 
       function instead of the C _wait functions.
    
    6. In previous versions, the 8 port serial plugin would discard the entire
       receive buffer if a character was received and the buffer was full. 
       It now discards the character received instead if there is no space
       left in the receive buffer.
    
    7. All the Catalina documents have been revised to correct various typos, 
       and also make the formats more consistent between documents. Also, some 
       have been renamed to make the file names more consistent with the titles 
       and the file contents.
    
    8. The main window of the Windows Installer has been enlarged slightly to
       ensure all options are displayed (previously, some installation options
       were only visible if the window was scrolled). 
    
    9. The Catalina Command Line menu entry was not being shown in the Windows 
       Start Menu in some versions of Windows - a new batch script called 
       catalina_cmd.bat has been created for this purpose - all it does is open 
       a command window and then execute the use_catalina batch script, which is 
       what the Catalina Command Line start menu entry does.
    
    10. The various Windows startup options (i.e. the setup scripts, Start Menu 
       entries, and desktop icons) have been modified so that if the LCCDIR
       environment variable is not set, then they set it appropriately. This is
       intended to allow multiple versions of Catalina to be installed and started
       without needing to modify the LCCDIR environment variable (which is 
       required for versions prior to 5.9). The Windows setup program still 
       defaults to setting the LCCDIR environment variable, since most users will
       only want the latest version, but this option can now be unchecked in the
       setup program, or the environment variable can subsequently be deleted and 
       versions of Catalina from 5.9 onwards should work correctly.
    

    Ross.

  • I found some remnants of an old Geany installation in my AppData folder. Once removed, I was able to re-install Catalina and it works (with a P1, anyway). Cool.

  • RossHRossH Posts: 5,463

    @JonnyMac said:
    I found some remnants of an old Geany installation in my AppData folder. Once removed, I was able to re-install Catalina and it works (with a P1, anyway). Cool.

    Good. And thanks for the heads up. I just had a quick look and I can't see any reason why Catalina's version of Geany shouldn't co-exist happily with other versions. Catalina didn't make any changes to any Geany configuration files, but it seems a previous version of Geany may have done so.

    I'll add a warning to the next release.

    Ross.

  • JonnyMacJonnyMac Posts: 9,110
    edited 2023-05-07 00:52

    Is there a mechanism for changing the default project path? ATM it's on my OS drive, and I'd like to move it to a data drive.
    Found under Edit/Preferences/General. Sorry -- I didn't get any sleep last night.

  • RossHRossH Posts: 5,463
    edited 2023-05-13 03:21

    The next release of Catalina will be able to cross-compile itself so that it can run natively on the Propeller 2. While working on this I found an obscure bug in Catalina release 5.9 which affects programs written for the Propeller 2 that use the PSRAM or HyperRAM as XMM RAM.

    I won't put updates on SourceForge until I am sure there are no other lurking issues - but I'll post updates here for anyone currently compiling C programs that use PSRAM on the Propeller 2.

    The attached patch includes one updated source file and one updated Windows binary. If you use Windows, just copy these files over the existing ones in your Catalina directory. If you use Linux, you will need to install the updated source and then recompile Catalina.

    Ross.

    EDIT: Withdrawing this patch, as it causes other problems. Will post a more correct fix soon.

  • JonnyMacJonnyMac Posts: 9,110
    edited 2023-05-10 03:47

    Good. And thanks for the heads up. I just had a quick look and I can't see any reason why Catalina's version of Geany shouldn't co-exist happily with other versions.

    Well, I thought about reinstalling a normal version of Geany so that I could work through the K&R properly. Before doing that I decided to check on User/AppData and found that the Catalina version of Geany puts information there which may be why I had the conflict in the past. The date in the capture are from when I re-installed Catalina. The geany.conf file has elements connected to the Catalina demos I ran.

  • RossHRossH Posts: 5,463

    @JonnyMac said:
    I decided to check on User/AppData and found that the Catalina version of Geany puts information there which may be why I had the conflict in the past.

    Yes, that's where it is supposed to go. I have not messed with the Geany code that does that, so I don't know why that would cause problems. But I'll have another look at it.

    Ross.

  • RossHRossH Posts: 5,463

    I have had to withdraw patch release 5.9.1 as it had a problem. I will issue an updated patch shortly.

    Ross.

  • RossHRossH Posts: 5,463
    edited 2023-05-17 09:47

    Catalina 5.9.1 has been released here.

    Although it only contains a few bug-fixes, this is a full release since one of its purpose is to completely replace the previous (now withdrawn) 5.9.1 patch release. It is therefore highly recommended to install this release to a new directory, since some of the files added in previous releases need to be removed.

    Here is the relevant section of the README.TXT:
    
    RELEASE 5.9.1
    
    New Functionality
    -----------------
    
    None.
    
    Other Changes
    -------------
    
    1. Fixed a bug in the copying of components of structures in the XMM LARGE 
       mode on the Propeller 2. Components were being copied as longs, which 
       could fail if the start and end were not both aligned on long boundaries. 
       Affected the Propeller 2 only - on the Propeller 1 all components of
       structures are copied as bytes.
    
    2. The _cogstart_XMM functions added in release 5.6 have been removed from
       the C library and added as stand-alone functions where needed (e.g. see
       the folder demos/p2_ram).
    
       The functions affected are:
    
         _cogstart_XMM_SMALL();
         _cogstart_XMM_SMALL_cog(g);
         _cogstart_XMM_LARGE();
         _cogstart_XMM_LARGE_cog();
    
         _cogstart_XMM_SMALL_2();
         _cogstart_XMM_SMALL_cog_2();
         _cogstart_XMM_LARGE_2();
         _cogstart_XMM_LARGE_cog_2();
    
       When these functions were introduced Catalina supported only one type of 
       XMM RAM on the Propeller 2, but now that multiple types of XMM RAM are
       supported (currently Catalina supports the internal PSRAM on the P2 Edge, 
       and the HyperRAM add-on board on the P2 Edge or P2 Eval boards) these 
       functions now need to be compiled specifically for the platform on which 
       they are to be used, and so can no longer be included in the C library.
    
    3. The Propeller 1 CUSTOM configuration did not have ACTIVATE_EACH_USE_SD 
       defined in Custom_CFG.inc, which made the SD plugin too large to load.
    
    4. Payload's simple-minded internal VT100 emulator now ignores color escape
       codes, so if vi is compiled with USE_COLOR defined (e.g. to work better
       with the external VT100 emulator) then using payload's internal terminal 
       emulator will still work correctly (but note no color will be displayed). 
       Previously, color escape codes were not recognized and were treated as
       output to be displayed on the terminal, which garbled the output, whereas 
       now they are recognized and ignored.
    

    Note that this release does not yet support self-hosted C development on the Propeller 2 - this feature will be coming in release 6, but there are so many changes associated with that release that I will continue to support Catalina release 5 until release 6 proves to be sufficiently stable.

    Ross.

  • RossHRossH Posts: 5,463
    edited 2023-06-03 09:06

    Microsoft recently released an update for Windows 10 which has broken a few things - not just Catalina, but also some MinGW utilities (e.g make). The symptoms are that one of the constituent process (such as cpp or make) reports that they cannot find the files it needs and aborts the compilation - but when you look the files are there. Which means that sometimes just repeating the same command twice but adding the Catalina -u option (which tells Catalina not to delete intermediate files) can fix the problem because the second time it tries the compilation the files it is looking for are still there from the first attempt.

    I do not have a reliable fix for this yet, but as soon as I do I will release an update.

    Ross.

  • RossHRossH Posts: 5,463

    A quick update - Catalina 5.9.1 seems unaffected by this problem. Something introduced in Catalina 6.0 (not yet released) has exposed a problem that can occur when a sub-process tries to return its status to the parent process. The parent process thinks the sub-process has failed when it has actually succeeded. I have a workaround but it is ugly, so I will keep investigating.

  • RossHRossH Posts: 5,463

    I have just released Catalina 5.9.2. It is available here.

    No functional changes - one minor bug fix, one major bug fix, and some speed improvement to the PASM assembler (thanks to Wuerfel_21).

    Here is the relevant extract from the README.TXT:

    RELEASE 5.9.2
    
    New Functionality
    -----------------
    
    None.
    
    Other Changes
    -------------
    
    1. The changes in the round() and trunc() functions in Release 5.9 stopped
       the Catalyst pascal compiler from compiling correctly. Affected the
       Propeller 1 and Propeller 2.
    
    2. The p2asm assembler has been modified to improve its speed. Thanks to 
       Wuerfel_21. The p2asm assembler is used on the Propeller 2 only.
    
    3. The SD card plugin had an error that could cause a failure to write 
       a sector to go undetected. Also, some delays have been reduced to 
       speed up the writing of sectors. Affected the Propeller 2 only.
    

    I will continue to support the 5.9 release until the 6.0 release is ready.

    Ross.

  • RossHRossH Posts: 5,463
    edited 2023-06-16 07:32

    I have put up two new releases of Catalina.

    Release 5.9.3 is primarily a bug fix release. It is available here. Windows and Linux versions available.

    Release 6.0 adds support for the new self-hosting feature on the Propeller 2. It is available here. Only a Windows version is available at the moment. Self-hosting is only supported on Propeller 2 EDGE or EVAL boards equipped with either PSRAM or HyperRAM, so unless you have those boards and want to try the self-hosting capability, it is recommended that you continue to use the 5.9.x releases, which will remain the default version on SourceForge.

    The technical changes in the 6.x releases are not that large - the main one was making everything work on a system with only DOS 8.3 file names - but they have reached deeper and been more impactful that I expected, and I am still in the process of doing all the necessary testing and updating all the documentation. So the 6.x releases should be considered BETA releases until further notice. Oh, and there's still this ...

    When using Catalina on a Propeller 2. the larger C demo programs can take a long time to compile. Even the standard C "hello world" program (hello.c) can take almost 10 minutes. Compiling the "chimaera" game (chimaera.c, approx 5,500 lines of C code) takes about 170 minutes.

    Here are the relevant extracts from the README files:

    Release 5.9.3:

    New Functionality
    -----------------
    
    1. Catalyst auto-execution is now slightly more sophisticated. First, the
       AUTOEXEC.TXT file can also now contain a script consisting of multiple 
       commands - however, unlike the EXECONCE.TXT file, when the last command 
       in the AUTOEXEC.TXT file has been executed, the entire file will then be 
       re-executed.
    
       Also, just before it executes each command, Catalyst now checks for a key 
       press and offers to abort the command auto-execution if one is detected. 
       Previously, there was no way to abort the execution of a sequence of 
       commands once initiated other than removing the SD card. Note that since 
       the key buffer is reset on each reboot and so the key will only be
       detected between the reboot and the execution of the next command, it 
       will usually be necessary to hold a key down until the current command 
       completes. To abort the current command, hold a key down and reset the 
       Propeller.
    
       Also, Catalyst now echoes commands in the AUTOEXEC.TXT or EXECONCE.TXT 
       files before execution unless the first character of the command is '@' 
       (which is ignored). Also, if the first character in the command line is 
       '#' then the line is treated as a comment. Note that this functionality 
       does not interfere with the use of the '!', '@' and '#' characters to 
       specify the CPU if multi-cpu support is enabled, since that only applies 
       to commands entered interactively.
    
       Note that since it takes too much space on some Propeller 1 platforms
       (depending on the XMM and HMI options selected) the default is to disable 
       command scripting. To enable scripting it may be necessary to disable 
       something else to make enough space. For example, Lua commands could be 
       disabled instead.
    
       Note that disabling Lua commands does not disable Lua itself, it just 
       disables the auto-detection and execution of Lua programs directly from
       the command line. Lua programs can always be executed by explicitly passing 
       them to Lua. For example, if Lua commands are enabled, the lua program 
       list.lua can be executed using a command like:
    
          list *.bas
    
       If Lua commands are disabled, the command required would be:
    
          lua list.lua *.bas
    
    2. The Catalyst rm command now has a -k option to kill (suppress) information
       messages.
    
    Other Changes
    -------------
    
    1. Payload was incorrectly interpreting the VT100 escape sequence 'ESC [ 2 J'
       as 'erase to end of screen', instead of 'erase entire screen'. Affected 
       both the Propeller 1 and 2.
    
    2. Payload was incorrectly interpreting the VT100 cursor position escape 
       sequence 'ESC [ r ; c H' when 0 was specified as the row or column position. 
       It now accepts either 0 or 1 to mean the first position. Payload also now 
       accepts 'ESC [ r ; c f' to mean the same thing. Affected both the Propeller
       1 and 2.
    
    3. The vi text editor was using the VT100 escape sequence 'ESC c' to reset the
       terminal to the initial state when it started - but it is not clear what 
       the initial state for some of the DEC private options should be, so it 
       now simply clears the screen instead - this avoids resetting some VT100
       options (such as Auto Wrap) with some VT100 terminal emulators. Affected 
       both the Propeller 1 and 2.
    
    4. The demos\p2_ram examples would not compile correctly for the P2_EVAL board
       with the HyperRAM add-on board. Affected the Propeller 2 P2_EVAL only.
    
    5. The demos\interrupts\ example programs now use the correct LEDs on the 
       P2_EDGE boards (pins 38 & 39) and P2_EVAL boards (pins 56, 57 & 58).
    
    6. The Lua executuion engine (luax) was not being built correctly when the
       ENABLE_PSRAM option was specified.
    
    

    Release 6.0:

    New Functionality
    -----------------
    
    1. There is a new Catalyst demo - Catalina itself! The demos\catalyst folder
       has a new subdirectory called 'catalina', in which a self-hosting version
       of Catalina can be built. Since it is supported only on a limited number
       of Propeller 2 platforms, this new demo is not built by default when you
       build Catalyst. If you have a P2 EDGE board with PSRAM or a P2 EVAL board
       with HyperRAM then you can build it manually - go to the 'catalina' 
       subdirectory, and use the build_all script with the same options you
       used to build Catalyst. For example
    
          cd catalina
          build_all P2_EDGE SIMPLE VT100 CR_ON_LF USE_COLOR OPTIMIZE MHZ_200
       or
          cd catalina
          build_all P2_EVAL VGA COLOR_4 OPTIMIZE MHZ_200
    
       Note that the build_all script will automatically use the copy_all script
       to copy the results to the Catalyst image folder.
    
       The self-hosted version of Catalina currently has the following limitations:
    
          - it supports the Propeller 2 only.
          - it supports the TINY, COMPACT and NATIVE modes only.
          - it does not support the Catalina debugger, optimizer or parallelizer.
    
       Since the self-hosting version of catalina introduces a 'bin' directory to 
       hold the catalina executables, the build_all and copy_all scripts now put 
       their output in a directory called 'image' instead of 'bin'. See the
       Catalyst Reference Manual for more details on the self-hosted version of 
       Catalina.
    
    2. Local user libraries must now be created in a local subdirectory called
       'lib'. For example, if you specify -liberty on the command line, previous 
       versions of Catalina would first look for a local library in a subdirectory
       in the current directory called libiberty, but now Catalina will look for a
       it in a local subdirectory called lib\iberty.
    
    3. A new Catalina symbol P2_REV_A can now be defined (e.g. using -C P2_REV_A
       to the catalina command) to indicate that p2asm should not generate
       instructions not supported by the Rev A version of the Propeller 2.
       Previously, the p2_asm batch script had to be edited to do this. Note
       that this applies only to the Catalina compiler itself, which no longer 
       uses the p2_asm script. The p2_asm script must still be manually edited 
       (to remove the -v33 option to p2asm) if the Catalina Optimizer is used.
    

    Note that in release 6.0, the usual pre-built demo versions of Catalyst in the P2_EDGE and P2_EVAL zip files now also contain the self-hosted version of Catalina, but the version in the P2_DEMO zip file does not, since it is intended to run on any EDGE or EVAL board, including those without either PSRAM or HyperRAM.

    Ross.

Sign In or Register to comment.