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