This is a real beginners question but how do I determine at compile time whether I'm using the Catalina C compiler? I'd like to add some #ifdefs to my program allow it to compile with Catalina but didn't find in a quick search through the docs if there is any preprocessor symbol defined automatically by the Catalina compiler. Is there something like _CATALINA_ or something like that that I can check for to conditionally include Catalina-specific code?
Edit: I figured this out myself. The symbol is called __CATALINA__.
Hi David,
Correct. See the Catalina Reference Manual ("A note about Catalina symbols vs C symbols", p 121).
Correct. See the Catalina Reference Manual ("A note about Catalina symbols vs C symbols", p 121).
Ross.
Thanks. I guess I missed that reference. All I did was do a quick search for #ifdef thinking I might find text suggesting what symbol to use to detect compiling with Catalina. Not a very good approach. I should have done a more thorough reading of the manual. Anyway, spinwrap now generates code that is compatible with Catalina. I was able to compile and run my simple test program.
Attached to the second post in this thread is a slightly improved version of payload (source code and windows binary) that allows you to override the default terminal size (80x24) to be used in interactive mode. See here for more details.
Thank you for developing this software to this community. I'm struggling with the native mode memory limitation of P1 from the beginning. Since I need to use relatively high resolution TV graphics (320x240 mininum), there is so little space is left for my application. I'm not displaying dynamic graphics, animations etc. So, I used Potatohead's really nice 1/4th, 1/8th buffer spin graphics drivers. It saved my life and allowed me to complete my proof-of-concept design. But after some point, my application filled the remaining space again. Nowadays, I'm trying to move my application to C.
I have already replaced my EEPROM with an 24LC1024 and using SimpleIDE, I could run applications larger than 50K with it with a speed penalty. I wasn't heard about much Catalina and I have just downloaded it to evaluate.
Do you think I can still use iXMM memory mode while I'm generating 320x240 or 384x240 TV graphics? Is there any demo code related to this?
Do you think I can still use iXMM memory mode while I'm generating 320x240 or 384x240 TV graphics? Is there any demo code related to this?
Hi Sobakava,
Of course!
Catalina has full TV text and graphics support using the standard Parallax TV and Graphics drivers, and these can be used from any memory model (provided there is enough Hub RAM). My standard resolution for TV graphics is 256x192, but I just did some quick experiments, and it can easily be wound up to 352x256 resolution.
You don't specify what Propeller board you have, but here is what I did to get this working on a Hydra. The process would be similar for other boards, but would be a little more complicated if you only have serial XMM RAM (and therefore have to enable the cache).
First, you need to edit the file Catalina_Common.spin (it is in the target directory). Change the following lines:
' GRAPHICS Support:
'
X_TILES = 16 ' Tiles are 16 by 16, so X resolution is 256
Y_TILES = 12 ' Tiles are 16 by 16, so Y resolution is 192
to:
' GRAPHICS Support:
'
X_TILES = 22 ' Tiles are 16 by 16, so X resolution is 352
Y_TILES = 16 ' Tiles are 16 by 16, so Y resolution is 256
Then build the XMM loader utilities for your platform and the graphics_demo program. I used the HYDRA and the SMALL XMM memory model, so I just opened a Catalina command line window and typed:
cd utilities
build_all HYDRA
cd ..\demos\graphics
build_all HYDRA SMALL
payload XMM graphics_demo
You don't specify what Propeller board you have, but here is what I did to get this working on a Hydra. The process would be similar for other boards, but would be a little more complicated if you only have serial XMM RAM (and therefore have to enable the cache).
Ross.
This is the sweetest thing I've heard today!
I'm using my own board. It is equipped with an I2C 1Mbit 24LC1025 EEPROM as main EEPROM and 64kbit SPI EEPROM. I also have an empty slot for a SPI SRAM but I rather not to use SRAM since I have many of these boards.
Can I use XMM with 24LC1024 only? I'm using SPI EEPROM for data logging only.
This is the sweetest thing I've heard today!
I'm using my own board. It is equipped with an I2C 1Mbit 24LC1024 EEPROM as main EEPROM and 64kbit SPI EEPROM. I also have an empty slot for a SPI SRAM but I rather not to use SRAM since I have many of these boards.
Can I use XMM with 24LC1024 only? I'm using SPI EEPROM for data logging only.
Hi Sobakava,
I'll have to look up the 24LC1024 specifically, but I'm sure I have an I2C XMM driver that could easily be adapted. I'll let you know.
But your problem is not going to be your program code size - it is likely to be your program data size. Since you don't want to use XMM SRAM, the Hub RAM has to be used for all your data requirements - and just to run at 352x256 resolution requires a screen buffer of 11k!
Also, since you only have serial XMM (i.e. EEPROM), you will also need to use the cache - and (from experience) I'd recommend an 8k cache if you want to get this program to execute at speeds comparable with Spin. You might get away with a smaller cache, but only if execution speed is not critical.
So already you have consumed nearly 20k of your 32K HUB RAM! Which means that all your other data, including other driver buffers, C global variables and stack and heap space needs have to fit into the remaining 12k.
If you are sure this is the case, then it is worth pursuing the idea of executing the code from EEPROM. If not, then this will not help (and by the way, this is true regardless of what program language or compiler you use).
Can you do an estimate of your total data requirement? I'd hate to have you waste your time if at the end of the day it is still not going to fit!
I have variables (longs, bytes, byte arrays) total of 1200bytes. I have several menus, submenus at the video display. But I am always fetching menu item strings, titles etc from SPI eeprom to a temporary 20 byte long array. Then I put it into screen. Then I fetch next string to the same array and so on. And I don't have any other displays, data log memories, sound buffers etc.
My program basically displays a set of boxes at the screen. (I want to fit boxes as many as I can, this is why I want to keep resolution high) And program receives 8byte data packets from another MCU using an SPI like interface. Using this data, it refreshes the colors of the boxes at the screen. And there are several all text based setting menus.
I implemented both SPI EEPROM Read/Write and SPI-Like-External MCU Read/Write routines with PASM. I would like to keep using them if I use C in the future.
I'll have to look up the 24LC1025 specifically, but I'm sure I have an I2C XMM driver that could easily be adapted. I'll let you know.
But your problem is not going to be your program code size - it is likely to be your program data size. Since you don't want to use XMM SRAM, the Hub RAM has to be used for all your data requirements - and just to run at 352x256 resolution requires a screen buffer of 11k!
Also, since you only have serial XMM (i.e. EEPROM), you will also need to use the cache - and (from experience) I'd recommend an 8k cache if you want to get this program to execute at speeds comparable with Spin. You might get away with a smaller cache, but only if execution speed is not critical.
So already you have consumed nearly 20k of your 32K HUB RAM! Which means that all your other data, including other driver buffers, C global variables and stack and heap space needs have to fit into the remaining 12k.
If you are sure this is the case, then it is worth pursuing the idea of executing the code from EEPROM. If not, then this will not help (and by the way, this is true regardless of what program language or compiler you use).
Can you do an estimate of your total data requirement? I'd hate to have you waste your time if at the end of the day it is still not going to fit!
I have variables (longs, bytes, byte arrays) total of 1200bytes. I have several menus, submenus at the video display. But I am always fetching menu item strings, titles etc from SPI eeprom to a temporary 20 byte long array. Then I put it into screen. Then I fetch next string to the same array and so on. And I don't have any other displays, data log memories, sound buffers etc.
My program basically displays a set of boxes at the screen. (I want to fit boxes as many as I can, this is why I want to keep resolution high) And program receives 8byte data packets from another MCU using an SPI like interface. Using this data, it refreshes the colors of the boxes at the screen. And there are several all text based setting menus.
I implemented both SPI EEPROM Read/Write and SPI-Like-External MCU Read/Write routines with PASM. I would like to keep using them if I use C in the future.
It sounds like your application should be fine, both for code speed and data size. You can re-use your PASM code in Catalina in several ways - turn them into a Catalina plugin or use the spinc utlity (see the Catalina documentation for both of these), or check out David Betz's new SpinWrap utility.
I'll have a look at getting you an XMM driver over the weekend. I have one somewhere that handles EEPROMs, but it may need some tweaks for your particular EEPROM chip. In the interim, just start coding and use LMM or CMM mode (just be aware that when your program gets too large for these memory models, XMM will be slower!).
As requested by Sobakava (above) I have released a new version of the Catalina target support package for Catalina 3.13.2 that enables executing XMM code from EEPROM.
I decided to release a whole new target support package (rather than just add a new set of CUSTOM files specifically for Sobakava) becasue this should work on any Propeller with an EEPROM larger than 32kb. It also gave me the chance to add a more efficient two-phase loader specifically for such programs, and also add a few checks in various other target files to make sure the new command line symbol (XEPROM) is being used correctly.
See the second post in this thread for the new target package.
While testing Catalina's version of the Parallax graphics library with the new "execute XXM from EEPROM" (XEPROM) option, I found this particular library non longer works with Catalina's LARGE memory model.
The problematic changes were introduced way back in Catalina 3.8, so obviously no-one is using this combination (or else has not updated Catalina recently!). I use the library quite a lot - but never in LARGE mode.
However, I now have a version of the Parallax Graphics library that works with every memory model again, so if anyone needs it please let me know - otherwise I will just include it in the next release.
While testing Catalina's version of the Parallax graphics library with the new "execute XXM from EEPROM" (XEPROM) option, I found this particular library non longer works with Catalina's LARGE memory model.
The problematic changes were introduced way back in Catalina 3.8, so obviously no-one is using this combination (or else has not updated Catalina recently!). I use the library quite a lot - but never in LARGE mode.
However, I now have a version of the Parallax Graphics library that works with every memory model again, so if anyone needs it please let me know - otherwise I will just include it in the next release.
I have just downloaded and installed new Catalina. Can you send me the graphics library and target support packages?
Can't wait to test my app with it.
The current graphics library will work in LMM, CMM and XMM SMALL mode, but not in XMM LARGE mode.
If you are executing code from EEPROM, you will be using XMM SMALL mode, so the current library should be fine.
Just be sure to install the new target package (see the second post in this thread) over the standard target directory - this adds the ability to execute XMM SMALL code from from EEPROM.
I do have an updated graphics library that also works in XMM LARGE mode (which I broke a few releases ago) - I'll put something together on the weekend and post it.
Sobakava has asked again (in a private message) whether I could make Catalina support 384x256 resolution on a TV display with graphics, and whether I had a demo program for it. He intends to use the SMALL memory model, and wants to execute his program from EEPROM.
The answer to everything is yes. Here's what I did (I did this is on a HYDRA, but only step 4 would need to change for any platform with a TV output):
1. Download the new target package with XEPROM support (see post 2 of this thread) and install it.
2. Find the lines in the file target\Catalina_Common.spin that set X_TILES and Y_TILES and amend them as follows:
X_TILES = 24 ' Tiles are 16 by 16, so X resolution is 384
Y_TILES = 16 ' Tiles are 16 by 16, so Y resolution is 256
3. Find the line in the file target\Catalina_CGI_Plugin_TV.spin that sets the hx value, and amend it as follows:
long 9 'hx (was 10)
4. Go to the demos\graphics folder, and build the graphics demo program (this is for the HYDRA):
cd demos\graphics
build_all HYDRA SMALL XEPROM CACHED_1K
5. Build the payload utilites for your platform (this is an interactive program - follow the prompts):
I just wanted to give Catalina a try. I made a quick project. In main.c there is only the standard main routine with the while(1) loop.
I can compile. But if I then hit the run button I get a error message:
-------------- Clean: Debug in SMCatalina (compiler: Catalina C Compiler)---------------
Cleaned "SMCatalina - Debug"
-------------- Build: Debug in SMCatalina (compiler: Catalina C Compiler)---------------
catalina.exe -b -CTTY -CTINY -Clibc -CDEMO -b -g3 -CPC -CTINY -Clibc -CDEMO -IC:\Users\dnalor\Elektronik\Programme\Catalina\include -IC:\Users\dnalor\Elektronik\Propeller\Projekte\SMCatalina -c main.c -o .objs\main.obj
Catalina Compiler 3.13
catalina.exe -o SoundmodulCatalina.binary .objs\main.obj -b -CTTY -CTINY -lc -CDEMO -b -g3 -CPC -CTINY -lc -CDEMO
Catalina Compiler 3.13
code = 356 bytes
cnst = 0 bytes
init = 8 bytes
data = 4 bytes
file = 6500 bytes
Output file is SoundmodulCatalina.binary with size 6.35 KB
Process terminated with status 0 (0 minute(s), 1 second(s))
0 error(s), 0 warning(s) (0 minute(s), 1 second(s))
Build log saved as:
file://C:/Users/dnalor/Elektronik/Propeller/Projekte/SMCatalina/SMCatalina_build_log.html
-------------- Run: Debug in SMCatalina (compiler: Catalina C Compiler)---------------
Checking for existence: C:\Users\dnalor\Elektronik\Propeller\Projekte\SMCatalina\SoundmodulCatalina.binary
Executing: "C:\Users\dnalor\Elektronik\Programme\Catalina\bin\codeblocks/cb_console_runner.exe" "C:\Users\dnalor\Elektronik\Propeller\Projekte\SMCatalina\SoundmodulCatalina.binary" (in C:\Users\dnalor\Elektronik\Propeller\Projekte\SMCatalina\.)
Process terminated with status 1992619145 (0 minute(s), 2 second(s))
I have a protoboard on Com 12. I run Catalina on Win 7 Professional. Do anyone else have this problem or did I miss something ?
I just wanted to give Catalina a try. I made a quick project. In main.c there is only the standard main routine with the while(1) loop.
I can compile. But if I then hit the run button I get a error message:
...
I have a protoboard on Com 12. I run Catalina on Win 7 Professional. Do anyone else have this problem or did I miss something ?
That may not be an error. I can't quite tell from what you posted, but I can get the same kind of error when I download using the "Download to Hub RAM and interact" tool, and then abort payload by closing the command window that appears without first exiting payload (via Ctrl-D).
In that case, the error code returned to Code::Blocks is unpredictable - but the program has been downloaded and executed. You can't see that if the program doesn't produce any output.
Try making your test program produce some output (e.g. add a printf() statement) or compile the "hello_world.c" demo program).
EDIT: Actually, looking at your output again, the problem may be even easier to solve. I think you may be using the "Build and Run" or "Run" commands from the Code::Blocks menu. These commands are for running native applications. Catalina doesn't use these commands to run Propeller applications because they don't give you a chance to specify any of the necessary download options. To run Catalina applications, use the entries on the Tools menu such as "Download to Hub RAM".
Ok, I understand. That was one problem. Thank you.
With 'Tools-Download to RAM' payload starts, but nothing happens after that. I see payload in the taskmanager, but the binary is not loaded. Payload stays, until I kill it with the taskmanager.
Then I tried to load the binary with the PropTool. There I could load it, but it did not run. Then I realized that all options in the build command are twice and I think I understand now the system of the build options in Code-Blocks. Now I can compile with catalina, load the binary with the PropTool and my LED flashes.
But payload seems to do nothing.
I will look further tomorrow.
-------------- Clean: Debug in SMCatalina (compiler: Catalina C Compiler)---------------
Cleaned "SMCatalina - Debug"
-------------- Build: Debug in SMCatalina (compiler: Catalina C Compiler)---------------
catalina.exe -b -g3 -CTINY -Clibc -CCUSTOM -IC:\Users\dnalor\Elektronik\Programme\Catalina\include -IC:\Users\dnalor\Elektronik\Propeller\Projekte\SMCatalina -c main.c -o .objs\main.obj
Catalina Compiler 3.13
catalina.exe -o SMCatalina.binary .objs\main.obj -b -g3 -CTINY -lc -CCUSTOM
Catalina Compiler 3.13
code = 508 bytes
cnst = 0 bytes
init = 8 bytes
data = 4 bytes
file = 6652 bytes
Output file is SMCatalina.binary with size 6.50 KB
Process terminated with status 0 (0 minute(s), 1 second(s))
0 error(s), 0 warning(s) (0 minute(s), 1 second(s))
Build log saved as:
file://C:/Users/dnalor/Elektronik/Propeller/Projekte/SMCatalina/SMCatalina_build_log.html
Launching tool 'Download to Hub RAM': payload.exe SMCatalina (in C:\Users\dnalor\Elektronik\Propeller\Projekte\SMCatalina)
/*
* main.c - main program
*/
//#include <stdio.h>
#include <propeller.h>
#define LED 7
#define LED_MASK (1 << LED)
#define LED_ON() OUTA &= LED_MASK
#define LED_OFF() OUTA |= LED_MASK
#define LED_TOGGLE() OUTA ^= LED_MASK;
int main(int argc, char *argv[])
{
// insert your code here
DIRA |= LED_MASK;
LED_ON();
while(1) // the propeller reboots on exit - this line prevents that
{
msleep(500);
LED_TOGGLE();
}
return 0;
}
With 'Tools-Download to RAM' payload starts, but nothing happens after that. I see payload in the taskmanager, but the binary is not loaded. Payload stays, until I kill it with the taskmanager.
Then I tried to load the binary with the PropTool. There I could load it, but it did not run. Then I realized that all options in the build command are twice and I think I understand now the system of the build options in Code-Blocks. Now I can compile with catalina, load the binary with the PropTool and my LED flashes.
But payload seems to do nothing.
I will look further tomorrow.
Yes, Setting options in Code::Blocks is a bit confusing at first. There are actually three different places you can set options, and Catalina can only check for conflicting options if you set them all in one place only.
Try using payload from the command line, if necessary with the -v or -d options (or both), and tell me what it says. In a Catalina Command line window (i.e. started from that entry in the Start Menu under Windows), you would enter a command like:
cd C:\Users\dnalor\Elektronik\Propeller\Projekte\SMCatalina
payload -v -d SMCatalina
Also, it seems from the symptoms that payload may be getting stuck trying to find the correct serial port. if you know what port you are using (e.g. on my computer it is COM7, which I specify on the command line as \\.\COM7) then specify it manually - e.g:
cd C:\Users\dnalor\Elektronik\Propeller\Projekte\SMCatalina
payload -v -d -p\\.\COM7 SMCatalina
Can I set somewhere a fixed comport in Code::Blocks?
Odd. All payload does is try and "open" the port. If it cannot open it, or it can but it does not get a response, it closes the port again and moves to the next one. Do you not have a COM1 port at all, or is it there but with some device connected to it?
Anyway, there are several ways to solve this problem. You can simply edit the entries on your Code::Blocks Tools menu to add the necessary parameter. To do this, go Tools->Configure tools ... and select the entry you want to edit (e.g. Download to Hub RAM). Press Edit and add -p12 or -p\\.\COM12 (they do the same thing) to the end of the Parameters string (include a space before it). You will have to do this for each tool.
The only problem with this solution is that if you ever change ports, you will have to re-edit all the tools entries, so if you want to retain the abilty to auto-detect the Propeller port, I'd suggest instead testing (on the command line) if just skipping COM1 fixes the problem, You can do this by the -a option. In your case, try
payload -a2 <filename>
This tells payload to skip the first port (COM1) and start autodetecting from the second port (COM2). You can only have one -a option, but you could try -a2, -a3 etc until you get to the end of any "problem" ports. Then use that parameter in the Tools entries instead of specifying a specific port. This way, you won't have to re-edit the tools if your port changes.
In the device manager in section COM&LPT it shows only COM12.
parameter -a2 helps, so it is COM1 that makes somehow problems, although there is none.
I added this parameter in payload_blackcat.bat, too, and changed my comport to COM2 (was free) because I wanted to test the debug function.
Did not work at first. -> Running program message.
After reading the 'BlackCat-Getting started',
You cannot specify your own target to use BlackCat you must use the
default target, which allows Catalina to select a BlackCat-enabled target
file.
I changed the target to demo.
Now debugging works.
Why I can not use the custom target? Or is it save to use the demoboard target ? At the moment my pins > 8 are free, but will not be later. So this collides with the definitions for Keyb,mouse,....
Should I edit the demo target files?
I changed the target to demo.
Now debugging works.
Why I can not use the custom target? Or is it save to use the demoboard target ? At the moment my pins > 8 are free, but will not be later. So this collides with the definitions for Keyb,mouse,....
Should I edit the demo target files?
Partly a terminology problem I think. **
You can certainly use a CUSTOM platform with the debugger - the word "target" in the blackcat document should really be "target package" - there are three such packages provided with Catalina - target (the default), basic (a smaller one intended for embedded use which has no HMI drivers) and minimal (an absolutely minimal one) - or you can create your own.
Only the default and basic target packages have debug capabilities - I removed them from the minimal target to reduce its complexity. So if you were to create your own target package, it may or may not have debug capabilities.
But there is no reason your CUSTOM platform should not work with the debugger (I just tried it here, and it does). It must be that something in there is not correctly configured for your board (most likely in the Custom_DEF.inc file). If you post a copy of it I will try and see what it might be, but if the DEMO platform works, another alternative is to do what you suggest and simply copy all the DEMO files to overwrite the CUSTOM files, and then edit those to suit your platform instead.
** At some point I realized I was going to need to support multiple target packages, so I switched from using the term "target" to using the terms "target package" and "platforms" - I may not have updated all the document references correctly. I'll revise this for the next release.
I heard a rumor that Catalina now has a COG mode. Where can I find a description of it?
Yes it does - and there is no documentation so far, since I only started it yesterday!
So far, all I have done is tweak the standard code generator so that it emits only pure PASM. Current characteristics are:
It is enabled just by adding -C COG to the catalina command. Thinking about it, I think I will rename the current default mode (which I originally called TINY) as HUB mode. I think this nomenclature suits the new P16X32 better.
All code, local and global variables, as well as the stack, must fit entirely within in a single cog. The stack will occupy any cog space not used by anything else, so to make best use of the limited cog space, using global or register variables, and a single main() function consisting mainly of linear code (i.e. as few function calls as possible) is strongly recommended.
All C syntax is supported, although I may end up disallowing variadic functions, since the overhead is ridiculously high, and disallowing them would simplify the code generator significantly.
All data types are essentially implemented using a 32 bit long. You can define 8 and 16 bit integer types, but each one is implemented using 32 bits. You can also define strings, but there will probably not be enough space in a cog to include the library functions necessary to manipulate them.
The only way currently to refer to Hub RAM (other than by inserting RDxxxx and WRxxxx instructions inline) is to call special readbyte(), readword(), readlong(), writebyte(), writeword() or writelong() functions. I'll probably also provide functions for copying larger objects (structures, arrays etc) to and from Hub RAM.
The only way to use the compiled code at the moment is to compile it, extract the compiled data segment manually as a binary blob, and then use that blob in another program via a coginit() function (much like the spinc utility currently does). I will make this easier before release - not sure how yet. I am currently thinking that I add facilities so that the compiled C program can be turned into a loadable "plugin" in a single command.
There is no optimizer support yet, and I think this will absolutely be needed in COG mode, to squeeze as much into the limited cog space as possible.
I had not anticipated doing this, I just decided to try it yesterday since after it came up again in another discussion. I thought about it for a bit and realized it is actually quite easy to do.
Whether or not it is any use is still an open question.
I may include it in the next release of Catalina, but since this will be a completely new code generator there will be a lot of testing to do first, and the next release is almost ready to go. However, I'm not aware of any crying need for this new release (no major bugs or anything) so I may just hold off the next release long enough in include this.
Yes it does - and there is no documentation so far, since I only started it yesterday!
So far, all I have done is tweak the standard code generator so that it emits only pure PASM. Current characteristics are:
It is enabled just by adding -C COG to the catalina command. Thinking about it, I think I will rename the current default mode (which I originally called TINY) as HUB mode. I think this nomenclature suits the new P16X32 better.
All code, local and global variables, as well as the stack, must fit entirely within in a single cog. The stack will occupy any cog space not used by anything else, so to make best use of the limited cog space, using global or register variables, and a single main() function consisting mainly of linear code (i.e. as few function calls as possible) is strongly recommended.
All C syntax is supported, although I may end up disallowing variadic functions, since the overhead is ridiculously high, and disallowing them would simplify the code generator significantly.
All data types are essentially implemented using a 32 bit long. You can define 8 and 16 bit integer types, but each one is implemented using 32 bits. You can also define strings, but there will probably not be enough space in a cog to include the library functions necessary to manipulate them.
The only way currently to refer to Hub RAM (other than by inserting RDxxxx and WRxxxx instructions inline) is to call special readbyte(), readword(), readlong(), writebyte(), writeword() or writelong() functions. I'll probably also provide functions for copying larger objects (structures, arrays etc) to and from Hub RAM.
The only way to use the compiled code at the moment is to compile it, extract the compiled data segment manually as a binary blob, and then use that blob in another program via a coginit() function (much like the spinc utility currently does). I will make this easier before release - not sure how yet. I am currently thinking that I add facilities so that the compiled C program can be turned into a loadable "plugin" in a single command.
There is no optimizer support yet, and I think this will absolutely be needed in COG mode, to squeeze as much into the limited cog space as possible.
I had not anticipated doing this, I just decided to try it yesterday since after it came up again in another discussion. I thought about it for a bit and realized it is actually quite easy to do.
Whether or not it is any use is still an open question.
I may include it in the next release of Catalina, but since this will be a completely new code generator there will be a lot of testing to do first, and the next release is almost ready to go. However, I'm not aware of any crying need for this new release (no major bugs or anything) so I may just hold off the next release long enough in include this.
I'll see how it goes over the next week or two.
Ross.
Sounds interesting. It is a different approach than taken with PropGCC so it will be interesting to see how well it works out. It certainly seems like it will have fewer quirks than our COG mode. Actually, ours isn't too bad if you give it a hub stack to work with but most of the time when I write COG code I want it to run entirely in the COG and not require any working space in hub memory. Keep us posted on this.
...
The stack will occupy any cog space not used by anything else, so to make best use of the limited cog space, using global or register variables, and a single main() function consisting mainly of linear code (i.e. as few function calls as possible) is strongly recommended.
One simple idea for tiny C resource, is to support in-line-of-functions. Code can be written a little clearer with single function calls, but the final code generated manages those like Assembler Macros, and expands them in-line.
(it does need some simple rules like single exit point at end of function )
Sounds interesting. It is a different approach than taken with PropGCC so it will be interesting to see how well it works out. It certainly seems like it will have fewer quirks than our COG mode. Actually, ours isn't too bad if you give it a hub stack to work with but most of the time when I write COG code I want it to run entirely in the COG and not require any working space in hub memory. Keep us posted on this.
Seriously? What's the point of COG mode if the stack is in HUB? Presumably all local variables would also be in HUB, so you would have all the slowness of HUB code and none of the advantages, since your code is still limited to 496 instructions.
I presumed COG mode meant everything in the COG. Otherwise, I really see very little point to it!
Seriously? What's the point of COG mode if the stack is in HUB? Presumably all local variables would also be in HUB, so you would have all the slowness of HUB code and none of the advantages, since your code is still limited to 496 instructions.
I presumed COG mode meant everything in the COG. Otherwise, I really see very little point to it!
Ross.
I think Eric felt that trying to put the stack in COG memory required awkward stack access code that wasted a lot of the very limited COG memory. Since GCC passes function parameters in registers you can have a main function and any number of leaf functions without needing a stack at all. The fact that data references require hub accesses isn't really much of a problem since mostly COG mode gets used for drivers and most data references are to buffers that have to be in hub memory. You can, of course, declare variables as COG resident so you can avoid the use of the stack entirely if you're careful. That's what I have done when I've written COG mode code. The problem is that you have to be conscious of these details to avoid using a hub stack and that isn't easy for novices. Your approach may be more easily understood but may also more severely limit the amount of code that will fit in COG memory. As I said, it will be interesting to see which approach is the more useful.
I think Eric felt that trying to put the stack in COG memory required awkward stack access code that wasted a lot of the very limited COG memory. Since GCC passes function parameters in registers you can have a main function and any number of leaf functions without needing a stack at all. The fact that data references require hub accesses isn't really much of a problem since mostly COG mode gets used for drivers and most data references are to buffers that have to be in hub memory. You can, of course, declare variables as COG resident so you can avoid the use of the stack entirely if you're careful. That's what I have done when I've written COG mode code. The problem is that you have to be conscious of these details to avoid using a hub stack and that isn't easy for novices. Your approach may be more easily understood but may also more severely limit the amount of code that will fit in COG memory. As I said, it will be interesting to see which approach is the more useful.
Personally, I don't think either of them will be very useful - but it's kind of fun to see if it can be made to work - and anyway, I was running out of things to add to Catalina while waiting for the P16X32B, so why not?
Comments
Hi David,
Correct. See the Catalina Reference Manual ("A note about Catalina symbols vs C symbols", p 121).
Ross.
Attached to the second post in this thread is a slightly improved version of payload (source code and windows binary) that allows you to override the default terminal size (80x24) to be used in interactive mode. See here for more details.
Ross.
32bit and 64 bit Linux versions of Catalina 3.13.2 have now been uploaded to SourceForge.
Ross.
Thank you for developing this software to this community. I'm struggling with the native mode memory limitation of P1 from the beginning. Since I need to use relatively high resolution TV graphics (320x240 mininum), there is so little space is left for my application. I'm not displaying dynamic graphics, animations etc. So, I used Potatohead's really nice 1/4th, 1/8th buffer spin graphics drivers. It saved my life and allowed me to complete my proof-of-concept design. But after some point, my application filled the remaining space again. Nowadays, I'm trying to move my application to C.
I have already replaced my EEPROM with an 24LC1024 and using SimpleIDE, I could run applications larger than 50K with it with a speed penalty. I wasn't heard about much Catalina and I have just downloaded it to evaluate.
Do you think I can still use iXMM memory mode while I'm generating 320x240 or 384x240 TV graphics? Is there any demo code related to this?
Best Regards
Sobakava
Hi Sobakava,
Of course!
Catalina has full TV text and graphics support using the standard Parallax TV and Graphics drivers, and these can be used from any memory model (provided there is enough Hub RAM). My standard resolution for TV graphics is 256x192, but I just did some quick experiments, and it can easily be wound up to 352x256 resolution.
You don't specify what Propeller board you have, but here is what I did to get this working on a Hydra. The process would be similar for other boards, but would be a little more complicated if you only have serial XMM RAM (and therefore have to enable the cache).
First, you need to edit the file Catalina_Common.spin (it is in the target directory). Change the following lines: to:
Then build the XMM loader utilities for your platform and the graphics_demo program. I used the HYDRA and the SMALL XMM memory model, so I just opened a Catalina command line window and typed:
Voil
This is the sweetest thing I've heard today!
I'm using my own board. It is equipped with an I2C 1Mbit 24LC1025 EEPROM as main EEPROM and 64kbit SPI EEPROM. I also have an empty slot for a SPI SRAM but I rather not to use SRAM since I have many of these boards.
Can I use XMM with 24LC1024 only? I'm using SPI EEPROM for data logging only.
Hi Sobakava,
I'll have to look up the 24LC1024 specifically, but I'm sure I have an I2C XMM driver that could easily be adapted. I'll let you know.
But your problem is not going to be your program code size - it is likely to be your program data size. Since you don't want to use XMM SRAM, the Hub RAM has to be used for all your data requirements - and just to run at 352x256 resolution requires a screen buffer of 11k!
Also, since you only have serial XMM (i.e. EEPROM), you will also need to use the cache - and (from experience) I'd recommend an 8k cache if you want to get this program to execute at speeds comparable with Spin. You might get away with a smaller cache, but only if execution speed is not critical.
So already you have consumed nearly 20k of your 32K HUB RAM! Which means that all your other data, including other driver buffers, C global variables and stack and heap space needs have to fit into the remaining 12k.
If you are sure this is the case, then it is worth pursuing the idea of executing the code from EEPROM. If not, then this will not help (and by the way, this is true regardless of what program language or compiler you use).
Can you do an estimate of your total data requirement? I'd hate to have you waste your time if at the end of the day it is still not going to fit!
Ross.
I have variables (longs, bytes, byte arrays) total of 1200bytes. I have several menus, submenus at the video display. But I am always fetching menu item strings, titles etc from SPI eeprom to a temporary 20 byte long array. Then I put it into screen. Then I fetch next string to the same array and so on. And I don't have any other displays, data log memories, sound buffers etc.
My program basically displays a set of boxes at the screen. (I want to fit boxes as many as I can, this is why I want to keep resolution high) And program receives 8byte data packets from another MCU using an SPI like interface. Using this data, it refreshes the colors of the boxes at the screen. And there are several all text based setting menus.
I implemented both SPI EEPROM Read/Write and SPI-Like-External MCU Read/Write routines with PASM. I would like to keep using them if I use C in the future.
It sounds like your application should be fine, both for code speed and data size. You can re-use your PASM code in Catalina in several ways - turn them into a Catalina plugin or use the spinc utlity (see the Catalina documentation for both of these), or check out David Betz's new SpinWrap utility.
I'll have a look at getting you an XMM driver over the weekend. I have one somewhere that handles EEPROMs, but it may need some tweaks for your particular EEPROM chip. In the interim, just start coding and use LMM or CMM mode (just be aware that when your program gets too large for these memory models, XMM will be slower!).
Ross.
As requested by Sobakava (above) I have released a new version of the Catalina target support package for Catalina 3.13.2 that enables executing XMM code from EEPROM.
I decided to release a whole new target support package (rather than just add a new set of CUSTOM files specifically for Sobakava) becasue this should work on any Propeller with an EEPROM larger than 32kb. It also gave me the chance to add a more efficient two-phase loader specifically for such programs, and also add a few checks in various other target files to make sure the new command line symbol (XEPROM) is being used correctly.
See the second post in this thread for the new target package.
Ross.
While testing Catalina's version of the Parallax graphics library with the new "execute XXM from EEPROM" (XEPROM) option, I found this particular library non longer works with Catalina's LARGE memory model.
The problematic changes were introduced way back in Catalina 3.8, so obviously no-one is using this combination (or else has not updated Catalina recently!). I use the library quite a lot - but never in LARGE mode.
However, I now have a version of the Parallax Graphics library that works with every memory model again, so if anyone needs it please let me know - otherwise I will just include it in the next release.
Ross.
Can't wait to test my app with it.
The current graphics library will work in LMM, CMM and XMM SMALL mode, but not in XMM LARGE mode.
If you are executing code from EEPROM, you will be using XMM SMALL mode, so the current library should be fine.
Just be sure to install the new target package (see the second post in this thread) over the standard target directory - this adds the ability to execute XMM SMALL code from from EEPROM.
I do have an updated graphics library that also works in XMM LARGE mode (which I broke a few releases ago) - I'll put something together on the weekend and post it.
Ross.
Sobakava has asked again (in a private message) whether I could make Catalina support 384x256 resolution on a TV display with graphics, and whether I had a demo program for it. He intends to use the SMALL memory model, and wants to execute his program from EEPROM.
The answer to everything is yes. Here's what I did (I did this is on a HYDRA, but only step 4 would need to change for any platform with a TV output):
1. Download the new target package with XEPROM support (see post 2 of this thread) and install it.
2. Find the lines in the file target\Catalina_Common.spin that set X_TILES and Y_TILES and amend them as follows:
3. Find the line in the file target\Catalina_CGI_Plugin_TV.spin that sets the hx value, and amend it as follows:
4. Go to the demos\graphics folder, and build the graphics demo program (this is for the HYDRA):
5. Build the payload utilites for your platform (this is an interactive program - follow the prompts):
6. Load the program into EEPROM:
Voil
I can compile. But if I then hit the run button I get a error message:
I have a protoboard on Com 12. I run Catalina on Win 7 Professional. Do anyone else have this problem or did I miss something ?
That may not be an error. I can't quite tell from what you posted, but I can get the same kind of error when I download using the "Download to Hub RAM and interact" tool, and then abort payload by closing the command window that appears without first exiting payload (via Ctrl-D).
In that case, the error code returned to Code::Blocks is unpredictable - but the program has been downloaded and executed. You can't see that if the program doesn't produce any output.
Try making your test program produce some output (e.g. add a printf() statement) or compile the "hello_world.c" demo program).
EDIT: Actually, looking at your output again, the problem may be even easier to solve. I think you may be using the "Build and Run" or "Run" commands from the Code::Blocks menu. These commands are for running native applications. Catalina doesn't use these commands to run Propeller applications because they don't give you a chance to specify any of the necessary download options. To run Catalina applications, use the entries on the Tools menu such as "Download to Hub RAM".
Let me know how you go.
Ross.
With 'Tools-Download to RAM' payload starts, but nothing happens after that. I see payload in the taskmanager, but the binary is not loaded. Payload stays, until I kill it with the taskmanager.
Then I tried to load the binary with the PropTool. There I could load it, but it did not run. Then I realized that all options in the build command are twice and I think I understand now the system of the build options in Code-Blocks. Now I can compile with catalina, load the binary with the PropTool and my LED flashes.
But payload seems to do nothing.
I will look further tomorrow.
/* * main.c - main program */ //#include <stdio.h> #include <propeller.h> #define LED 7 #define LED_MASK (1 << LED) #define LED_ON() OUTA &= LED_MASK #define LED_OFF() OUTA |= LED_MASK #define LED_TOGGLE() OUTA ^= LED_MASK; int main(int argc, char *argv[]) { // insert your code here DIRA |= LED_MASK; LED_ON(); while(1) // the propeller reboots on exit - this line prevents that { msleep(500); LED_TOGGLE(); } return 0; }Yes, Setting options in Code::Blocks is a bit confusing at first. There are actually three different places you can set options, and Catalina can only check for conflicting options if you set them all in one place only.
Try using payload from the command line, if necessary with the -v or -d options (or both), and tell me what it says. In a Catalina Command line window (i.e. started from that entry in the Start Menu under Windows), you would enter a command like:
Also, it seems from the symptoms that payload may be getting stuck trying to find the correct serial port. if you know what port you are using (e.g. on my computer it is COM7, which I specify on the command line as \\.\COM7) then specify it manually - e.g:
Ross.
I have only Com12.
This works:
Can I set somewhere a fixed comport in Code::Blocks?
Odd. All payload does is try and "open" the port. If it cannot open it, or it can but it does not get a response, it closes the port again and moves to the next one. Do you not have a COM1 port at all, or is it there but with some device connected to it?
Anyway, there are several ways to solve this problem. You can simply edit the entries on your Code::Blocks Tools menu to add the necessary parameter. To do this, go Tools->Configure tools ... and select the entry you want to edit (e.g. Download to Hub RAM). Press Edit and add -p12 or -p\\.\COM12 (they do the same thing) to the end of the Parameters string (include a space before it). You will have to do this for each tool.
The only problem with this solution is that if you ever change ports, you will have to re-edit all the tools entries, so if you want to retain the abilty to auto-detect the Propeller port, I'd suggest instead testing (on the command line) if just skipping COM1 fixes the problem, You can do this by the -a option. In your case, try
This tells payload to skip the first port (COM1) and start autodetecting from the second port (COM2). You can only have one -a option, but you could try -a2, -a3 etc until you get to the end of any "problem" ports. Then use that parameter in the Tools entries instead of specifying a specific port. This way, you won't have to re-edit the tools if your port changes.
Ross.
In the device manager in section COM&LPT it shows only COM12.
parameter -a2 helps, so it is COM1 that makes somehow problems, although there is none.
I added this parameter in payload_blackcat.bat, too, and changed my comport to COM2 (was free) because I wanted to test the debug function.
Did not work at first. -> Running program message.
After reading the 'BlackCat-Getting started', I changed the target to demo.
Now debugging works.
Why I can not use the custom target? Or is it save to use the demoboard target ? At the moment my pins > 8 are free, but will not be later. So this collides with the definitions for Keyb,mouse,....
Should I edit the demo target files?
Partly a terminology problem I think. **
You can certainly use a CUSTOM platform with the debugger - the word "target" in the blackcat document should really be "target package" - there are three such packages provided with Catalina - target (the default), basic (a smaller one intended for embedded use which has no HMI drivers) and minimal (an absolutely minimal one) - or you can create your own.
Only the default and basic target packages have debug capabilities - I removed them from the minimal target to reduce its complexity. So if you were to create your own target package, it may or may not have debug capabilities.
But there is no reason your CUSTOM platform should not work with the debugger (I just tried it here, and it does). It must be that something in there is not correctly configured for your board (most likely in the Custom_DEF.inc file). If you post a copy of it I will try and see what it might be, but if the DEMO platform works, another alternative is to do what you suggest and simply copy all the DEMO files to overwrite the CUSTOM files, and then edit those to suit your platform instead.
There are three files you should copy:
cd target copy Demo_DEF.inc Custom_DEF.inc copy Demo_CFG.inc Custom_CFG.inc copy Demo_HMI.inc Custom_HMI.incRoss.
** At some point I realized I was going to need to support multiple target packages, so I switched from using the term "target" to using the terms "target package" and "platforms" - I may not have updated all the document references correctly. I'll revise this for the next release.
Yes it does - and there is no documentation so far, since I only started it yesterday!
So far, all I have done is tweak the standard code generator so that it emits only pure PASM. Current characteristics are:
- It is enabled just by adding -C COG to the catalina command. Thinking about it, I think I will rename the current default mode (which I originally called TINY) as HUB mode. I think this nomenclature suits the new P16X32 better.
- All code, local and global variables, as well as the stack, must fit entirely within in a single cog. The stack will occupy any cog space not used by anything else, so to make best use of the limited cog space, using global or register variables, and a single main() function consisting mainly of linear code (i.e. as few function calls as possible) is strongly recommended.
- All C syntax is supported, although I may end up disallowing variadic functions, since the overhead is ridiculously high, and disallowing them would simplify the code generator significantly.
- All data types are essentially implemented using a 32 bit long. You can define 8 and 16 bit integer types, but each one is implemented using 32 bits. You can also define strings, but there will probably not be enough space in a cog to include the library functions necessary to manipulate them.
- The only way currently to refer to Hub RAM (other than by inserting RDxxxx and WRxxxx instructions inline) is to call special readbyte(), readword(), readlong(), writebyte(), writeword() or writelong() functions. I'll probably also provide functions for copying larger objects (structures, arrays etc) to and from Hub RAM.
- The only way to use the compiled code at the moment is to compile it, extract the compiled data segment manually as a binary blob, and then use that blob in another program via a coginit() function (much like the spinc utility currently does). I will make this easier before release - not sure how yet. I am currently thinking that I add facilities so that the compiled C program can be turned into a loadable "plugin" in a single command.
- There is no optimizer support yet, and I think this will absolutely be needed in COG mode, to squeeze as much into the limited cog space as possible.
I had not anticipated doing this, I just decided to try it yesterday since after it came up again in another discussion. I thought about it for a bit and realized it is actually quite easy to do.Whether or not it is any use is still an open question.
I may include it in the next release of Catalina, but since this will be a completely new code generator there will be a lot of testing to do first, and the next release is almost ready to go. However, I'm not aware of any crying need for this new release (no major bugs or anything) so I may just hold off the next release long enough in include this.
I'll see how it goes over the next week or two.
Ross.
If the PASM has C Source as comments, it is already useful as a means to learn PASM
One simple idea for tiny C resource, is to support in-line-of-functions. Code can be written a little clearer with single function calls, but the final code generated manages those like Assembler Macros, and expands them in-line.
(it does need some simple rules like single exit point at end of function )
Seriously? What's the point of COG mode if the stack is in HUB? Presumably all local variables would also be in HUB, so you would have all the slowness of HUB code and none of the advantages, since your code is still limited to 496 instructions.
I presumed COG mode meant everything in the COG. Otherwise, I really see very little point to it!
Ross.
Personally, I don't think either of them will be very useful - but it's kind of fun to see if it can be made to work - and anyway, I was running out of things to add to Catalina while waiting for the P16X32B, so why not?
Ross.