@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 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.
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.
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.
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.
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!
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.
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.
Yes, a couple of issues with the use of the s8 library:
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.
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);
}
}
@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.
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.
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.
@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.
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.
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.
@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.
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.
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.
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.
@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.
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.
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.
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.
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.
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.
Comments
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.
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.
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.
>
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...
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:
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); } }Hello @wingineer29
Yes, a couple of issues with the use of the s8 library:
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.
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:
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...
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...
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.
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.
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.
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.
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.
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.
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.
I have had to withdraw patch release 5.9.1 as it had a problem. I will issue an updated patch shortly.
Ross.
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.
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.
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.
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:
I will continue to support the 5.9 release until the 6.0 release is ready.
Ross.
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.