Catalina 4.1 is now available

RossH

Catalina 4.1 is now available on Sourceforge - https://sourceforge.net/projects/catalina-c/

Catalina 4.1 is the latest release of Catalina, supporting both the Propeller 1 and the Propeller 2. It replaces all previous releases and is validated on many Propeller 1 platforms for all memory model, library, optimization level and floating point combinations. It is also validated on the Propeller 2 P2_EVAL board.

This release adds Multi-Memory Model support, allowing C programs that use different memory models to be run simultaneously. It also allows program overlays to be loaded and run from XMM RAM (Propeller 1) or SD Card (Propeller 1 and 2).

This release is intended to provide a baseline release for further incremental updates, which will mainly now concentrate on adding new plugins to Catalina's Propeller 2 support, until Catalina on the Propeller 2 has as rich a range of plugins as Catalina already has on the Propeller 1.

Catalina 4.1 includes both Windows and Linux releases.

This release will be supported for both the Propeller 1 and the Propeller 2.

Attached is the README file. Refer to it for more details.

Ross.

RossH

After struggling yet again with Code::Blocks in an attempt to reduce some of its complexity for new users, I have decided to introduce a new, simpler Integrated Development Environment (IDE) for Catalina.

This is the Catalina Geany IDE, based (as the name implies) on the Geany IDE (see https://www.geany.org/).

I decided to do this after realizing how flexible and simple Geany was to use. It is the first full-function IDE I have ever seen that tempts me to use it over a simple command-line interface. It didn't require any customization to use with Catalina, but I added some anyway - mainly because the number of configurable commands in the off-the-shelf version was not sufficient for use in an embedded environment where you typically need to do many more things than just "build" and "execute".

I have added a new set of releases to SourceForge called "4.1_with_IDE" for both Windows and Linux (see https://sourceforge.net/projects/catalina-c/files/releases/4.1_with_IDE/). As the name implies, this is exactly the same release as Catalina 4.1, but the Windows installer gives you the option of also installing the new IDE, and the Linux package also has a precompiled version included.

Some initial documentation for the new IDE is attached.

Ross.

P.S. I have no plans to drop Code::Blocks support, but it may no longer progress from the current version.

RossH

I've just uploaded a couple of small bug fixes for Catalina 4.1. If you don't use the BlackBox debugger, or use Catalina on Linux, you probably don't need to worry about it. Just copy the files included in the errata over any existing Catalina 4.1 release.

The fixes will be included in the next release.

It is available here - https://sourceforge.net/projects/catalina-c/files/errata/Catalina_4.1_Errata.zip/download

Wingineer19

Hi @RossH,

I just wanted to give you a quick update on my experience with the Multi-Memory Model for the Prop1.

In summary, it's working quite well.

I'm using the 4-Port Serial driver, and with 3 of the ports currently active, I've not noticed any anomalies or other odd behavior that you initially expressed some concern about in the Catalina 4.1 Release Candidate.

Serial Configuration:
Port 0: Console (i.e. VT100 interface to the Prop1 via pins P30 and P31 @115.2Kbps)
Port 1: GPS Receiver (interfaces to the Sparkfun ZOE-M8Q @ 57.6Kbps)
Port 2: CduPort (Control/Display Unit -- provides same screens as Console Port)
Port 3: Radio (currently not active)

The Primary program is using the XMM Large Memory Model.

The Secondary program is running in CMM.

The Shared Memory between the XMM Primary and CMM Secondary contains all of the needed GPS structures, some flag variables, and the TX output buffer for both the Console and CduPorts.

The XMM Primary has all of the various user interface Menus needed to display the GPS receiver and other device status. Eventually I'll add other functions to retrieve Battery status, temperature status, etc., along with some external motor control. But I'm not there yet.

Right now the XMM Primary can fill either the Console or CduPort buffers (or both) with the desired Menu output information and the CMM Secondary will perform the task of outputting it to either or both Ports.

Also, the CMM Secondary program is able to start a couple more CMM cogs using the coginit_C() function.

One of these new cogs handles all of the GPS I/O traffic, message parsing, formatting etc, and places this information within Shared Memory for review by the XMM Primary. It's awesome!

The other new cog handles the Wifi traffic (which at present is not much).

So far, it's all working well, with this much HubRam used:

code = 7548 bytes
cnst = 650 bytes
init = 2012 bytes
data = 720 bytes
file = 26408 bytes

I've also reserved 1024 bytes for stack space using spinc.

Once I've completed all of the Wifi stuff there will probably be another 2K to 3K of code, and considering that I'm using 8K of HubRam for XMM cache, I'm thinking everything will fit OK.

I guess my only question at this time circles back to the 4-Port Serial Driver.

Looking at the original configuration of the Extras.spin file, we have this:

S4.AddPort(0,31,30,-1,-1,0,0,115200)
'S4.AddPort(1,rx,tx,cts,rts,threshold,mode,baud)
'S4.AddPort(2,rx,tx,cts,rts,threshold,mode,baud)
'S4.AddPort(3,rx,tx,cts,rts,threshold,mode,baud)

There are pin definitions for cts and rts, but currently I'm not using them.

If I did, is there a function to toggle RTS as well as check CTS status? I looked through the various header files under Catalina but couldn't seem to find any. If not, I guess these are automatically handled by the driver itself?

Also, could you briefly explain the threshold and mode settings?

Thanks!

RossH

Hello @Wingineer19

Good news. Thanks for the feedback!

On the 4 port serial driver, the best answer is to look at the source code, which is in the file target/Catalina_FullDuplexSerial4FC.spin. This is essentially unchanged from version written by TIm Moore, and based on Chip's original serial driver. Looking at that code, the rts and cts are enabled and handled automatically if you specify pin values other than -1. There doesn't seem to be a way to control them manually. The "threshold" is the number of bytes that must be in the buffer before rts/cts flow control is triggered - i.e. to slow down the transmitter and prevent buffer overflow. Some bits in the "mode" also affect rts/cts. Here are the comments from the code:

'' rx/tx/cts/rtspin pin number                          XXX#PINNOTUSED if not used
'' rtsthreshold - buffer threshold before rts is used   XXX#DEFAULTTHRSHOLD means use default
'' mode bit 0 = invert rx                               XXX#INVERTRX
'' mode bit 1 = invert tx                               XXX#INVERTTX
'' mode bit 2 = open-drain/source tx                    XXX#OCTX
'' mode bit 3 = ignore tx echo on rx                    XXX#NOECHO
'' mode bit 4 = invert cts                              XXX#INVERTCTS
'' mode bit 5 = invert rts                              XXX#INVERTRTS

Ross.

JonnyMac

I'm a big fan of Geany; I use it when coding in Python, desktop C (not a lot of that), and used PNut as a CL tool for Geany before the alpha version of Propeller Tool for the P2 was ready. I installed 4.1, ran the tutorial, and everything worked great. Thanks, Ross!