Catalina 4.0 is now available

I just posted this in the Propeller 2 forums:

http://forums.parallax.com/discussion/170697/catalina-4-0-is-now-available

However, Catalina 4.0 supports both the Propeller 1 and the Propeller 2, so I am posting this here as well!
Catalina - a FREE ANSI C compiler for the Propeller.
Download it from http://catalina-c.sourceforge.net/

Comments

  • Just a quick note for FLiP module users ...

    I was originally intending to add a specific platform symbol to Catalina for the FLiP module, but when I came to do so I realized that there is actually nothing on the FLiP that requires special configuration - the default platform (aka CUSTOM) is suitable already.

    However, it now occurs to me (too late for this release!) that it might have been better to add the FLiP symbol anyway, just in case anyone has both the FLiP module and some other platform that requires a different CUSTOM configuration.

    I will add this symbol to the next release. In the meantime, if you have a FLiP module, just use the default platform.

    Ross.

    Catalina - a FREE ANSI C compiler for the Propeller.
    Download it from http://catalina-c.sourceforge.net/
  • Hi @RossH,

    No doubt you've already anticipated this question already, so I'm going to go ahead and ask it:

    Do you plan on adding a 2-Port serial library to the Propeller1 as well as a 4-Port serial library to the Propeller2?

    I'm just curious about this.

    Please note that I do not need a 2-Port serial library for the Propeller1 code I'm working on, but if I decide to migrate to the Propeller2 (P2D2), I will need a 4-Port serial library for it.

    At this point I don't anticipate migrating to the Propeller2 as the tweaks you've done to the 4-Port serial library and 8K XMM cache are working great. All of the Menus are working fine, and I'm able to communicate with the GPS receiver via both the 4-Port serial library as well as my own I2C functions. I'm really happy with the results I'm getting.

    The only reason I would contemplate moving to the Propeller2 as this point would be if I need to perform message unpacking/formatting and serial port traffic management using another cog in the background. Without having to use XMM on the Propeller2 I would be able to run multiple C functions on the other cogs.

    Anyway, just wondering what your plans were to have common serial port library functions available for the two Propeller platforms...
  • Hi @RossH,

    No doubt you've already anticipated this question already, so I'm going to go ahead and ask it:

    Do you plan on adding a 2-Port serial library to the Propeller1 as well as a 4-Port serial library to the Propeller2?

    No, there seems very little point. Apart from the fact that the P1 supports 4 ports, and the P2 supports higher baud rates (neither of which I can do much about), the existing 4 port serial library on the P1 is almost identical to the 2 port library on the P2. I did that deliberately. All the functions have very similar names and profiles.

    A few #define statements would be all that is necessary to port a program that required only 2 ports and lower baud rates from the P1 to the P2 or vice-versa. I suppose I could provide a common "catalina_serial.h" file for the P1 and P2 which did that for you - i.e.:
    #ifdef __CATALINA_P2
    #include <catalina_serial2.h>
    #define s_tx s2_tx
    ... etc ...
    #else
    #include <catalina_serial4.h>
    #define s_tx s4_tx
    ... etc ...
    #endif 
    

    Ross.
    Catalina - a FREE ANSI C compiler for the Propeller.
    Download it from http://catalina-c.sourceforge.net/
  • RossHRossH Posts: 4,494
    edited 2019-11-05 - 02:57:24
    Hi @Wingineer

    Just realized I didn't answer this bit ...
    ... if I decide to migrate to the Propeller2 (P2D2), I will need a 4-Port serial library for it.

    I am not sure there will ever be a 4-port serial driver for the P2, but it would be fairly easy to load two copies of the current 2-port serial drivers. It would cost an additional cog **.

    Ross.

    ** EDIT: To facilitate this, I have just reserved another plugin name and number for a second 2-port serial plugin. This will make it trivial for me to add 4-port support in future if no-one has developed a 4-port serial plugin for the P2 by the time you need it!
    Catalina - a FREE ANSI C compiler for the Propeller.
    Download it from http://catalina-c.sourceforge.net/
  • I'd be surprised if this is an issue for p2...
    The smartpins should allow a single cog to do many serial ports...
    Prop Info and Apps: http://www.rayslogic.com/
  • Ross is using FullDuplexSerial2.spin converted to C.

    And yes more ports should be possible but my Goal was to have the LUT as buffer, so it is two ports with buffer in the LUT. It might be extensible, but with less available buffer for rx/tx of the ports.

    Mike
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • Hi @RossH,

    I'm having some issues with structures and unions in Catalina and wanted to make sure I've got a proper grasp on variable sizes to ensure they aren't causing some alignment issues.

    First, I want to verify that under Catalina, a short int is a 16-bit value?

    Second, under Catalina, an int is a 32-bit value?

    If so, is a long int a 32-bit or 64-bit value?

    OK, with that being said, I want to read in a serial stream of data from a GPS receiver (ublox ZOE-M8Q). I'm doing this using one of the Ports on the 4-Port serial driver.

    The data is stored in a character string while being read in. This string is "unioned" to a structure so I can grab, unpack, and print the values.

    This test structure is a truncated version of the actual UBX-NAV-SOL message for the GPS receiver, but it will be enough to illustrate the problem I'm having.

    Here's the test structure and union:
    struct UBX_NAV_TEST
    {
     unsigned   char          Header1;              // 0xb5
     unsigned   char          Header2;              // 0x62
     unsigned   char          MsgClass;             // 0x01
     unsigned   char          MsgId;                // 0x06
     unsigned   short         MsgLen;               // 0x34
     
     unsigned   int           GpsTime;            
       signed   int           GpsFrac;
    
     unsigned   short         GpsWeek;
    
     unsigned   char          GpsFixType;
     unsigned   char          GpsFlags;
    };
    
    union Tsetvanxbu 
    {
     unsigned   char          Chr[40];
       struct   UBX_NAV_TEST  Info;
    };
    
    union Tsetvanxbu  UbxNavTest;
    

    Placing all of this inside my program, along with the code that retrieves the various Structure values and prints them out, yields no compiling problems at all.

    Upon execution, the code appears to work fine.

    The string is properly populated.

    When I unpack and display the Structure variables as Hex values, the data up to and including the MsgLen variable is correct:
    B5 62 01 06 34 00 F0 D6 87 1A F0 98 05 00 1E 08 03 DD CC 93 <-Input String
    
    B5 62 01 06 0034  <-Correct Values of Header1,Header2,MsgClass,MsgId,MsgLen
    
    98F01A87 081E0005 DD03 CC 93 <-Incorrect Values of GpsTime,GpsFrac,GpsWeek,etc
    
    1A87D6F0 000598F0 081E 03 DD <-Should Be This For GpsTime,GpsFrac,GpsWeek,etc
    

    However, for some reason, retrieving the Structure variables after MsgLen there appears to be some strange offset that causes the GpsTime to be retrieved starting 2-bytes to the right of where it should be.

    And because of this offset, all the other Structure variables after GpsTime are also skewed and incorrect as well.

    Any idea what is going on here? I'm completely puzzled by this.

    Is there a Packed issue with the Structure that I'm not accounting for?




  • @Wingineer19

    I think all C compilers for the P1 default to the ILP32 programming model, where "int", "long", and pointers are all 32 bits. The P1 hardware only allows accesses on properly aligned boundaries: that is, a 16 bit quantity must start on a 16 bit boundary, and a 32 bit quantity must start on a 32 bit boundary in memory. So the struct:
    struct foo {
       unsigned short s;
       unsigned long i;
    } f;
    
    will actually be arranged in memory as if it were:
       unsigned short s;
       unsigned char _pad[2];
       unsigned long i;
    
    Some compilers support a #pragma or __attribute__ to force structures to be packed (ignoring the hardware alignment restrictions). In this case 32 bit loads have to be emulated by loading bytes, shifting, and or'ing. I don't think Catalina supports packed structs, although @RossH will know for sure. I tried the following test program with Catalina and it printed offsets of 0 and 4:
    #include <stdio.h>
    #include <stddef.h>
    
    #pragma pack(1)
    
    struct foo {
        unsigned short S;
        unsigned long L;
    } x;
    
    int main()
    {
        printf("offsets: S=%d L=%d\n", offsetof(struct  foo, S), offsetof(struct foo, L));
        for(;;) ;
    }
    

    The P2 hardware allows unaligned accesses, so theoretically it should be straightforward to support packed structs on P2. This doesn't seem to be implemented yet in Catalina (or in fastspin, it's something I should look into).
  • ersmith wrote: »
    The P2 hardware allows unaligned accesses, so theoretically it should be straightforward to support packed structs on P2. This doesn't seem to be implemented yet in Catalina (or in fastspin, it's something I should look into).

    I believe Eric is quite correct. Catalina will pad structures according to the alignment of their types (e.g. 1 byte for char, 2 bytes for short, 4 for int). I could allow unaligned access on the P2, but on the P1 it would be horrendously inefficient.


    Catalina - a FREE ANSI C compiler for the Propeller.
    Download it from http://catalina-c.sourceforge.net/
  • Wingineer19Wingineer19 Posts: 147
    edited 2019-11-08 - 17:07:48
    ersmith wrote: »
    @Wingineer19

    I think all C compilers for the P1 default to the ILP32 programming model, where "int", "long", and pointers are all 32 bits. The P1 hardware only allows accesses on properly aligned boundaries: that is, a 16 bit quantity must start on a 16 bit boundary, and a 32 bit quantity must start on a 32 bit boundary in memory...

    Some compilers support a #pragma or __attribute__ to force structures to be packed (ignoring the hardware alignment restrictions). In this case 32 bit loads have to be emulated by loading bytes, shifting, and or'ing. I don't think Catalina supports packed structs, although @RossH will know for sure...

    The P2 hardware allows unaligned accesses, so theoretically it should be straightforward to support packed structs on P2. This doesn't seem to be implemented yet in Catalina (or in fastspin, it's something I should look into).

    Thanks for confirming it was an alignment issue within the structure that required padding to the next boundary.

    I suspected that was the case and was hoping for a compiler directive like Packed to get around it, but unfortunately it's not available.

    However, I was able to work around this problem by breaking up the int values into short ones then reassembling them back into int after reading them.

    With this workaround in place, the union of the struct with the char string worked great!

    I'm now able to read the GPS Time, GPS Week, ECEF position and velocity, and various Status information from the receiver as desired.

    Thanks again for your feedback!

    And I do have a P2 Eval Board on order :smile:


  • Hi @RossH,

    With the structure issue resolved, I do have a couple more questions to ask:

    It seems that Catalina only allows Bitfield variables to be constructed using int but not short?

    It also appears that the string functions like strcpy() and strcat(), for example, only work with char strings and not unsigned char strings?

    So this will work:
    char TempStr[40];
    strcpy(TempStr,"This Is A Test");
    
    But this one will throw a compiler error:
    unsigned char TempStr[40];
    strcpy(TempStr,"This Is A Test");
    

    Which isn't a big deal, just something to keep in mind.

    I guess I still haven't completely recovered from my OpenWatcom C/C++ days when I wrote code for the AMD Geode processor boards at work and took advantage of the Packed directive for Structures, created Bitfield variables using short instead of int, and carelessly tossed unsigned char variables at the string functions without pushback :wink:

    When keeping these very, very minor limitations in mind, one can see that Catalina is quite an impressive compiler!

    I've had a lot of fun working with it while making the Propeller do the same types of GPS data collection and display functions that the Geode board did :smile:




  • By the way Ross, I've updated the spin2cpp program to work pretty well with Catalina, at least recent versions. For example, spin2cpp is able to automatically convert the Spin version of my P2 VGA text output code (https://github.com/totalspectrum/p2_vga_text) to a portable C form that can compile with Catalina, GCC, or fastspin. The Makefile in the ccode directory shows how that works.

    Your work on propeller2.h was instrumental in this -- on P1 the header file situation is a mess, and producing output that's compatible with all of the P1 C compilers is quite a headache. I think P2 should be much cleaner. Thanks for your help!
  • It seems that Catalina only allows Bitfield variables to be constructed using int but not short?

    Yes, according to the C standard a bit field can only be an integer (signed or unsigned). Some compilers may allow other types.
    It also appears that the string functions like strcpy() and strcat(), for example, only work with char strings and not unsigned char strings?

    Yes, again, that's according to the C standard. Just use a cast - i.e. pass "(char *)str" instead of just "str".

    Catalina - a FREE ANSI C compiler for the Propeller.
    Download it from http://catalina-c.sourceforge.net/
  • ersmith wrote: »
    By the way Ross, I've updated the spin2cpp program to work pretty well with Catalina, at least recent versions. For example, spin2cpp is able to automatically convert the Spin version of my P2 VGA text output code (https://github.com/totalspectrum/p2_vga_text) to a portable C form that can compile with Catalina, GCC, or fastspin. The Makefile in the ccode directory shows how that works.

    I'll have a look at it. I have been waiting to update Catalina's Spin support until there is an "official" Spin compiler/interpreter available. Or is fastspin "official"? I have not been keeping up with Spin developments on the P2 - no time! :(
    Your work on propeller2.h was instrumental in this -- on P1 the header file situation is a mess, and producing output that's compatible with all of the P1 C compilers is quite a headache. I think P2 should be much cleaner. Thanks for your help!

    No worries!
    Catalina - a FREE ANSI C compiler for the Propeller.
    Download it from http://catalina-c.sourceforge.net/
  • RossH wrote: »
    ersmith wrote: »
    By the way Ross, I've updated the spin2cpp program to work pretty well with Catalina, at least recent versions. For example, spin2cpp is able to automatically convert the Spin version of my P2 VGA text output code (https://github.com/totalspectrum/p2_vga_text) to a portable C form that can compile with Catalina, GCC, or fastspin. The Makefile in the ccode directory shows how that works.

    I'll have a look at it. I have been waiting to update Catalina's Spin support until there is an "official" Spin compiler/interpreter available. Or is fastspin "official"? I have not been keeping up with Spin developments on the P2 - no time! :(
    fastspin is not official (it's my own project, not affiliated with Parallax at this time). But at the moment it's the only Spin solution for P2. I'm sure Chip's interpreter will be along soon though.

    As I recall Catalina's Spin support involves invoking the Spin interpreter and interpreting bytecodes. spin2cpp is an alternate path, since it converts the Spin source into C source. The two can co-exist quite nicely, I think :).
Sign In or Register to comment.