The -p2 option is to the catalina compile command, not payload. For payload there are some other options you can try adding.
-z do a "double" reset -u 50 increase reset time (to 50ms) -o1 override the propeller version detection and force Propeller 1 (-o2 for Propeller 2). -l use older style lfsr check (for Propeller 1 only). -j disable lfsr check (for Propeller 1 only).
All these are described in the documentation, or just enter payload without any options for a list.
Since it seems to be the lfsr check that is failing, here is a command I just used - this one uses -l to try a different lfsr check:
payload -d -t1000 -z -l -o1 -u50 hello_world_3 -i
You could also try disabling the lfsr check altogether by using -j in place of -l. For example:
payload -d -t1000 -z -j -o1 -u50 hello_world_3 -i
What's odd is that you said payload works from the command line. But Geany uses exactly the same command.
Can you add just the -d option to your working command-line command and post what it prints?
@TommieBoy said:
I see that it is looking for a P2. From the Getting Started, on page 2 it says that P1 is the default and that I would need to add -P2 option to each Catalina command. I checked the Build->Set Build Commands but I don't see **-P2 **anywhere.
It is not "looking" for a P2 - payload is checking if the chip is a P2 if it fails to identify it as a P1 (because the lfsr check fails).
Also, it is worth noting that case is important in options - i.e. -P2 is not the same as -p2
I have ordered a P2 HyperRam add-on board, so Catalina should soon be able support XMM execution on P2 platforms other than the P2_EDGE (e.g the P2_EVAL).
I now have Catalina's source-level debugger (blackbox) working for Propeller 2 XMM programs (it already supported non-XMM programs), so Catalina can now debug XMM programs on the Propeller 2 using a gdb-like source level debugger. I may release this version separately, or I may wait till I also have the HyperRam working - not sure yet.
Also, I have decided to retire blackcat, which was Bob Anderson's C debugger with a GUI interface (blackbox is my command-line equivalent, necessary because blackcat is a windows-only GUI written in a Microsoft proprietary language, whereas blackbox is written in plain old C and runs on both Linux and Windows). Normally I like to give a release or two deprecation warning before I discontinue support for something, but the reality is that blackbox outstripped blackcat in functionality a while ago (since Bob no longer supports it). Also, a debugger like blackbox or blackcat is a hideously complicated program - in some respects more complicated than the compiler it supports - and I no longer have the time to support two such beasts (I used to wonder why gdb was so flaky ... until I had to write my own!)
Somehow the Project Path wasn't being used correctly. I don't know what was amiss, but under Project->Base Path, I had a specific path for the project. (C:\Parallax\Hello World).
Using File Explorer, I looked into the folder and found the .c file, but no object or binary file! Odd, because there were no compiler errors. I found a different folder called "C:\Parallax\Geany Test" and it had object and binary files!
Once I deleted the Geany Test folder, everything loaded as expected.
I continued to poke around and the only reference to "C:\Parallax\Geany Test" was listed in my Environment variables. I don't know why. I got rid of that variable too.
Under Set Build Commands, Working Directory, everything was set to %p, which I'm assuming %p = Project Properties, Base Path, which was c:\Parallax\Hello World.
Is there another place where a folder may be specified? Any idea how the object and binary files may have gotten into a folder other than the Project Base Path?
Here's what I speculate happened.
1) I opened a project called Hello World in C:\Parallax\Geany Test and created a file called Hello World.c in that folder.
2) I inadvertently closed Hello World.c in Catalina.
3) Oops! I didn't mean to do that. I created a new file from template, called it Hello World.c and saved it to c:\Parallax\Hello World.
4) I changed the Project Path to c:\Parallax\Hello World.
5) I think Catalina was still using the original Project Path.
Anyway, long story short, I'm back on track with the tutorials.
I don't know where "Geany Test" came from. Nothing to do with Catalina AFAIK. However, I probably don't correctly cater for case that someone changes the base directory of an existing project, so the "Download and Interact" payload command should probably be:
payload -p11 %x "%p/%e" -i -b%b
I'll investigate a bit more and update the next release.
Yes, I can confirm that Geany has issues in circumstances like yours. For instance, if you open a project, any file you then open is "remembered" by the project, even if it has the same name as another file already in the project. If you close the project, and then re-open it, Geany will re-open all the open files quite happily, which can make you think you are looking at the version that is part of the project. But it may not be. It may have nothing to do with the project at all.
I knew about this ambiguity, and indeed had documented it - but I had not realized quite how confusing it could get. It turns out that there is no way to write a set of Geany commands that uses both the "open" files and the "project" files consistently in such circumstances - e.g. you can make Geany always use the open version rather than the project version for "compile" and "build" commands, but not for commands like "compile all", "link" or "make".
The best solution I can come up with at the moment is that all Geany commands work on the project files except for the "compile" and "build" commands, which have to work on open file - not least because this assumption is hardcoded into the Geany tool bar - but make those commands put their output in the project directory rather than the source directory. At least that makes some kind of sense, and is something you might do if you wanted - for example - to try a different version of a file already in your project without modifying the one already there.
I believe the concept of "projects" was bolted on to Geany late, and it has not been fully washed through yet. But without re-writing Geany, the best I can do is just document it better.
Thanks Ross. I'm sure I'll remember this 'gotcha' for a good long while and take care not to duplicate files and to keep stray files away from a project.
I guess as a rule of thumb, if things don't compile and load as expected, check the folder and make sure that the object and binaries are there as expected. It only takes a minute.
Thanks for taking the time to guide me through this.
Nothing major - debugger support for XMM programs on the Propeller 2, and improved ymodem support in the Comms terminal emulator.
Here is the relevant extract from the README.TXT:
RELEASE 5.7
New Functionality
-----------------
1. Catalina's stand-alone vt100 emulator (comms.exe) has an improved ymodem
implementation and dialog box:
- A ymodem transfer can now be aborted in the middle of a send or
receive operation.
- The dialog box now responds to Windows messages. This stops Windows
complaining that the application is not responding during a long
ymodem transfer.
- The Abort button now attempts to abort both the local and the remote
ymodem applications if a transfer is in progress. Previously, it
could only abort the remote ymodem application and only while the
local ymodem application was not executing.
- The Start and Done buttons now check and give an error message if a
ymodem transfer is in progress. Previously, they simply performed their
respective actions, which could lead to a comms program lock up.
- Opening the dialog box no logner crashes comms if no port has been
opened.
2. Payload's interfile delay has been set to 500ms on Linux. This makes the
downloading of XMM programs more reliable on Linux (it was already 500ms
on Windows).
3. The blackbox source level debugger can now debug XMM programs on the
Propeller 2.
4. Some blackbox information messages have been changed to make them more
accurate.
5. Command line parameters (argc &argv) were not being correctly initialized
when programs were run under the blackbox debugger. However, note that it
is not possible to pass command-line parameters when using the debugger
so they should always be initialized to null values.
6. On all Propeller 2 platforms, the default pins to use for debugging are
now pins 62 & 63, which means that if you need to debug a program that
uses a serial HMI on those pins, you will need to have a Prop Plug
connected to some other pins, and then modify the pins specified in the
platform configuration file, which by default are as follows:
#define _BLACKCAT_RX_PIN 63
#define _BLACKCAT_TX_PIN 62
7. The blackcat debugger is no longer supported, and has not been updated
to debug Propeller 2 XMM programs. This debugger still works on Propeller
1 programs and non-XMM Propeller 2 programs, but it is now deprecated, and
has been removed from the release.
8. The Catalina-specific Geany commands (on the Build menu) have been updated
slightly to make them less confusing - e.g. 'Build' has been changed to
'Build File' and 'Compile' to 'Compile File' - these commands operate on
the currently selected file only, and not necessarily the files in the
project directory (even thought the currently selected file may have the
same name as a project file!). The 'Link' command has been changed to
'Link All' to match 'Compile All', to indicates that these commands act
on all files in the project directory. Other changes ensure that any
output generated when a project is selected end up in that project
directory.
9. Payload now accepts a baud rate of zero (i.e. -b0 or -B0) to indicate that
the default baudrate appropriate for the propeller should be used (which is
115200 on a P1 or 230400 on a P2). This was the default if NO baudrate was
specified, but Geany HAS to have a baud rate specified, so specifying it
as 0 is now allowed, and is equivalent to not specifying it. All the Geany
projects have been updated to use baud rate 0.
Other Changes
-------------
1. The compiler now reports the correct code size when compiling XMM LARGE
programs.
EDIT: I just noticed that the actual README.TXT file said "You must install this over an existing installation of Catalina.", which is not true - this is a full stand-alone release. I have now fixed it in the distribution, but if your README.TXT still says this (which you probably only noticed AFTER installing it) then just ignore it.
I updated the files to fix the README.TXT, but you may have caught it mid-update. I have just checked again now, and it looks ok to me. If your page still doesn't show the 5.7 files, or still says 5.6 is the latest version, try refreshing the page. Also, you may have to wait for the mirror sites to be updated - not sure how long that process takes.
I've just put up a very small patch update (5.7.1) to Catalina 5.7 here. No changes to Catalina, just minor changes to the build_utilities scripts and a small tweak to the BlackBox debugger ...
RELEASE 5.7.1
New Functionality
-----------------
1. The build_utilities script now deletes any existing load utilities in
Catalina's bin directory if you ask it to copy the utility binaries there.
This is to resolve an issue for those compiling for both the Propeller 1
and the Propeller 2 - previously, the Propeller 2 binaries were left in
place even if you compiled new binaries for a Propeller 1. If you did not
then explicitly specify the extension in the payload command (e.g. if you
just said 'xmm' instead of 'xmm.binary', then payload would use the
Propeller 2 '.bin' file if it existed, even when loading a Propeller 1.
It still leaves the old binaries in the utilities directory in case you
really did need both - it only deletes them from the bin directory.
Other Changes
-------------
2. Blackbox now assigns the code address to the correct line in more cases.
Previously, if the compiler emitted the same code address for two source
lines (typically if one of the lines was the beginning or end of a C block)
then BlackBox would assign the code to the FIRST such line and ignore
the fact that the same address for code applies to the other lines. But
in fact it is almost always correct to assign the code to the LAST such
line. This makes no functional difference, but it makes it more logical
when identifying which lines can have breakpoints placed on them.
Just before I finally drop BlackCat altogether - Bob Anderson's Windows GUI source-level C debugger for Catalina (BlackBox is my Windows/Linux command-line equivalent) - I thought I'd post here and see if either Bob Anderson or anyone who knows him is still around.
The main reason I didn't include BlackCat in the current release is that unlike BlackBox, BlackCat was never open source, so I have to maintain it and I can only release binary versions. I asked Bob before the last update whether I could release the source, but he never responded and I have not heard from him since.
BlackCat is written in C# and I am not very experienced at C# programming so it is very likely that at some point it will get beyond my ability to maintain - but I can't in good conscience either release his source or pass it on to anyone else to maintain without his permission.
If Bob sees this, or anyone knows how to contact him, please get in touch.
@RossH - I'm starting to use Catalina for more than just Hello World, and that means I need to use libraries. I'm reading A Tutorial on using the Catalina C Compiler and I see a bit about compiling libraries. I'd like to use the Simple Libraries that I've used in the passed.
I tried using -ldatetime but it was ignored.
I followed your steps to compile a library that I created myself. It has 173 functions so I tried Catalina -S *.c but I got too many errors to count. Mostly about missing header files, but they should all be found in the PATH.
I set CATALINA_LIBRARY to C:\Parallax\Simple Libraries, but the compiler didn't find them.
How do I incorporate these libraries into my programs? It seems to be a significant project to recompile them in two memory modes and then catalog them.
First, a command-line parameter like -ldatetime (that's minus "little l for library") tells Catalina to look for a directory called libdatetime - either in the current directory or in the library path. But you probably neither want nor need to change the library path - for the moment just create and use the library in your working directory. Catalina will always look there for libraries as well as in the path specified by CATALINA_LIBRARY - but If you change the library path then Catalina will not be able to find its own libraries. So get your library working in your working directory first.
Next, Catalina does not search the PATH for include files. If they are not standard include files then you have to tell it where to look for them using -I (that's minus capital "I for include") on the command line to specify an include path. You can use multiple -I options, and they can be absolute or relative paths. For example:
Your compile command looks ok, assuming the files are all in libdatetime:
cd libdatetime
catalina -S *.c
cd ..
Once the programs in the library compile, remember you need to run catbind in the library to create an index. For example:
cd libdatetime
catbind –i –e *.s –o catalina.index
cd ..
Then try using your library. If there are undefined symbols, it probably means the functions in your library depend on other functions that you will need to find and add.
I tried finding these "Simple Libraries" you referred to. I recall I tried to do this once before, without much luck. I found two different things that call themselves "Simple Libraries" but neither of them are really "simple" and both of them seem to be compiler-specific (see Note 1). Neither will be easy to port "in toto" to another C compiler - individual parts of them look easy enough to port, but then other parts are quite compiler-specific and I wouldn't even try. It would be easier to just rewrite them (see Note 2).
Let me know which particular Simple Libraries you are using, and I can have a deeper look.
Instead of trying to port the whole library, you may be better off identifying which specific functions you need, and then seeing if Catalina has an alternative or equivalent (it does for many of the functions I looked at, but I don't know if they are the ones you need). Then port only the specific functions you need.
In many cases, the Simple Libraries seem intended to just provide smaller versions of some standard C functions (e.g. the "stdio" functions, which can be quite memory hungry). But Catalina already offers several alternatives to those - e.g. I noticed some of Eric Smith's code in there, but Catalina already incorporates a version of his "tiny" stdio library functions, so you probably don't need the Simple Library ones when you are using Catalina - in many cases you can just use the normal stdio functions but link your program with the -ltiny command line option.
Ross.
EDITS:
Note 1: I originally wrote "gcc-specific" but it seems one of them compiles with flexgui and the other with PropGCC - so not "gcc-specific" but "compiler-specific".
Note 2: It looks like this is actually what happened - i.e. flexgui took a subset of the original gcc Simple Libraries and rewrote them for that compiler. So I guess if we could all agree on the subset we wanted to support, I could do the same for Catalina.
@RossH - So, just to ensure I understand fully, the Simple Libraries can't be used as is?
They must first be compiled with the command catalina -S *.c,
then I need to use catbind to create an index?
I tried one of the smaller libraries, but I've found a ton or errors. Just one function kicked up this...
I'm not sure how to proceed from here. The Simple Libraries are so important to the flexibility of the P1, yet it seems it would be a monumental task to edit them.
Am I correct in my assessment? Or is there another way?
@TommieBoy said:
@RossH - So, just to ensure I understand fully, the Simple Libraries can't be used as is?
Correct. It looks like the Simple Libraries are not written in standard C. The use of the __attribute__ keyword seems to indicate they are written in 'GCC' C. ...
__attribute__ is not part of C, but is an extension in GCC that is used to convey special information to the compiler. The syntax of __attribute__ was chosen to be something that the C preprocessor would accept and not alter (by default, anyway), so it looks a lot like a function call. It is not a function call, though.
Sometimes this is done because it enhances performance, and simply removing them would have no effect. Sometimes it is done to lock the code to a specific compiler. Most often, it is probably done just because it is an easier way to accomplish something slightly tricky than doing it the right way. Whatever the reason, it is bad practice - but not that uncommon.
It is rare that such code cannot be modified to eliminate the need for such extensions (in this case it might be as simple as defining __attribute__ to be a null function call ) - but sometimes it is more complex and you have to figure out why they needed to use such extensions and then re-implement them in standard C.
Again, the best thing to do is identify what portions of the libraries you need to use, and see how difficult it would be to rewrite them in standard C.
@RossH, thanks for the explanation. I've been investigating the functions I use on my current project. I use 28, of which 10 look like they may have direct matches in your libc, and another 5 that look like they may have similar functions in some of your other libraries. I'll investigate the header files, see how they are declared and perhaps I'll need to massage my code to match.
The other 13 will require further research. Some may be simple for me to replicate, but others will be a bigger challenge.
Thanks for your patience and help. I'm still moving forward!
One more question: Do you have plans to include Wifi OTA loading with Payloader? I'm finding that the Wifi module is very handy when paired to a Propeller.
@TommieBoy said:
@RossH, thanks for the explanation. I've been investigating the functions I use on my current project. I use 28, of which 10 look like they may have direct matches in your libc, and another 5 that look like they may have similar functions in some of your other libraries. I'll investigate the header files, see how they are declared and perhaps I'll need to massage my code to match.
The other 13 will require further research. Some may be simple for me to replicate, but others will be a bigger challenge.
Thanks for your patience and help. I'm still moving forward!
One more question: Do you have plans to include Wifi OTA loading with Payloader? I'm finding that the Wifi module is very handy when paired to a Propeller.
Tom
I''ve had a slightly closer look a the Simple Libraries. The __attribute__ keyword can mostly be ignored. The easiest way to do this is to add something like the following to one of the common header files, which equates it to nothing:
/* If we're not using GNU C, equate the __attribute__ to nothing */
#ifndef __GNUC__
#define __attribute__(x) /* NOTHING */
#endif
However, this is not true in every case. Here are the ones I found in use, and what you may have to do about them:
__attribute__((common)) -- can be safely ignored
__attribute__((weak)) -- can be safely ignored
__attribute__((unused)) -- can be safely ignored
__attribute__((fcache)) -- can be ignored provided the code runs fast enough without it
__attribute__((constructor)) -- CANNOT be ignored - initialization code must be explicitly called
It is probably only the constructor and fcache attributes that will give you problems.
The constructor attribute is a GCC-specific means of performing library module initialization, which will have to be made explicit (i.e. the initialization functions will all have to be manually called before the library is used).
The 'fcache' attribute is a bit tricky - if the code doesn't run fast enough after having the fcache attribute removed, it may need to be rewritten. Catalina supports FCACHE on the Propeller 1, but only in CMM mode, and code to use it has to be hand-crafted.
As for a WiFi OTA loader, I don't have either a WiFi adapter or any need for this capability - so this is not likely to happen any time soon.
Just noticed a very minor bug in the new Windows VTxxx emulator program (comms) which is now bundled with Catalina.
You are supposed to be able specify the comms port on the command line as either /com=N or /com=comN - but just using the bare port number only works for comms port numbers 10 or greater. For comms port numbers 0 .. 9 you have to say /com=comN because the short form /com=N doesn't work.
This also applies to the Windows vtxxx batch files as well (which just call comms). For instance, you have to say vt220 comN because vt220 N doesn't work unless N is 10 or greater.
I never noticed it because all my USB comms ports are numbered above 10 - but I just tried a PC where the USB comms ports numbering start at 3.
I had a few hours spare this afternoon, so I have ported (but not tested!) a chunk of the Simple Libraries. It might help you on your way.
I will be unable to do much coding for the next week or so, but I can answer any questions you may have.
Here is the README.TXT:
*** WARNING: MOST OF THIS THIS HAS NOT BEEN TESTED! USE IT AT YOUR OWN RISK ***
This folder contains a port of parts the I2C and Utility components of the
Simple Libraries to Catalina (basically the "simpletools" stuff). It is not
a complete port and most of it has not been tested. Anything that failed to
compile after the simple corrections required to make the code ANSI C
compliant has not been included, but it does include all the stuff that
has been ported to flexgui. It was done primarily as an example of how to
begin to port the whole of the Simple libraries.
The only part that has been tested at all are the EEPROM access functions,
which use the I2C functions. The main test program is slightly extended
version of EEPROM_DATA.c from the flexgui port of these components. This
program currently supports only the EEPROM on the Propeller 1.
To build the simple library, there is a (Windows only) batch file called
simple.bat. It takes no parameters - use the CATALINA_DEFINE mechanism to
set your platform and options before executing the script.
For example, to build and execute the EEPROM_DATA program (the only one
that has been tested at all) in COMPACT mode for a C3 using a serial
interface, and then execute it you might say ...
set CATALINA_DEFINE= C3 TTY COMPACT
simple
payload -i EEPROM_DATA.binary
I'm having a problem with payload again. The project, builds but won't load. I tried all of the options you suggested in #122 above but no joy.
However, I think I may have a clue. I just don't know how to solve it. To prevent Geany IDE from opening the files from the last session, under Preferences -> Startup, I've unselected 'Load files from last session'.
Now, I need to open projects specifically and, in theory, eliminate any unconnected files from opening.
But now when I select Project->Open->c:\catalina\testlib, I get a weird file opening. See the image.
I don't know where this is coming from, but there are several inconsistencies.
See the yellow circled text. These are not the same files. The one open for editing isn't even in the project directory.
The blue, purple and red circled text are not the same.
The green circled text, datetime.h, and libdatetime are not part of my project, though they were at one time.
If I select File->Save as, the Save As window opens in my project folder with the suggested file name of testlib.c, which would over write my main file.
And because I don't know where this file is loading from, I can't delete it. (I'm assuming that if I deleted it, Geany would rebuild it with the parameters selected.)
Nor can I edit it and save over the original, because I don't know where the original is!
Without saving, I closed the file in the editor, closed the project, and exited Geany. When I opened the next time the file wasn't there.
Is there a chance that it's still haunting my project? Or is it a red herring?
Any way, here's the output...
Any suggestions?
EDITED: Today when I started Catalina, I selected Project->Open->testLib->testLib.geany, the file is there AGAIN. Do you have any idea how to get rid of it?
EDIT#2: I found the offending testLib.c in C:\Program Files (x86)\Catalina_5.7\catalina_geany. Deleted, but I'm still getting the error with payload.
EDIT#3: From CLI, payload -p12 -d -v loads binary as expected, just not from IDE.
Not sure how this happened, but the problem seems to be that you have ended up with old Geany project data saved in a file with a '.c' extension, which is confusing Geany (not to mention you and me!). What you are looking at in 'Testlib.c' is what was once in 'testlib.geany' but is now out of date. Perhaps use a text editor (not Geany) and check out that all the files actually contain what they should contain. My suspicion is that you have at some point opened the project file ('testlib,geany') as an ordinary file in Geany (it just contains the text like what you can see) and then somehow it has ended up being saved as 'Testlib.c'.
As I said before, Geany doesn't clearly differentiate between 'session' files and 'project' files. A file can be open in the session even if it is not in the project - and vice-versa. The really silly thing is that Geany stores session data in the project file (which is the stuff you have highlighted in Green). Best thing to do in this situation is close all open files manually, then close the project, then exit Geany, re-start it, then re-open the project.
If that does not fix it, the rebuild the project from scratch in a new folder (with a new project name), copying in only the files you need.
The payload error is probably not related, but the payload commands you have given me are not complete, nor is the output, so I cannot tell you exactly what the problem is here. However, I can see that you appear have a file called 'Testlib' as well as one called 'testlib.binary', so if you try to say something like 'payload testlib' then 'Testlib' is what it is trying to load, not 'testlib.binary', which is probably not what you want. What is in file 'Testlib'?
@RossH, I deleted the errant testLib.c file, since that version of the project, its folders, and source code no longer exists so it hasn't a reason to exist either.
I'll keep an eye out if it happens again.
As for payload, I tried CLI payload (which works) versus Catalina payload (which isn't), both with the same args, except Catalina uses a couple of substitutions.
I couldn't find the meaning of the substitutions in the manuals but I figure %p is the path, and %e is the name of the binary. I don't know what %x means, so I couldn't include it in my CLI payload args list.
Here is a comparison of the outputs. (Sorry for the huge size!)
Green lines are all the same, red are where the problem is. I do have a file in my folder called testLib with no extension, but it is created by Catalina, and it is 6,063 bytes!
SOLVED: So the solution is to add .binary to the %e substitution argument. The Payload Option Summary.pdf says that .binary is optional and if not present, payload will try .bin, .eeprom, then .binary. If I reset the Set Build Command -> Download and Execute line, the file extension isn't there either, so it must be added.
Anyway, editing the Set Build Command -> Download and Execute to explicitly load the binary is the solution.
Good. In one of the recent releases, I seem to have changed the order in which payload searches for the file to load. Now it looks for the bare filename first before trying any extensions, so it was finding 'Testlib' before 'testlib.binary' (case is not important in Windows filenames). The file 'Testlib' was most likely the result of a failed compilation of 'Testlib.c' so deleting both 'Testlib.c' and 'Testlib' would also have solved the problem.
I have tried reproducing the root problem (i.e. how Geany could create, copy or rename a project file to a file with a '.c' extension) but I have not been able to find a way to make it do so. That one remains a mystery.
I will change payload in the next release to search for .bin, .binary & .eeprom extensions before matching the bare filename.
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.
EDIT: I found a bunch in the P2 Reference Manual. I'll look some more before I ask again. Sorry.
Comments
Hello @TommyBoy
The -p2 option is to the catalina compile command, not payload. For payload there are some other options you can try adding.
-z do a "double" reset
-u 50 increase reset time (to 50ms)
-o1 override the propeller version detection and force Propeller 1 (-o2 for Propeller 2).
-l use older style lfsr check (for Propeller 1 only).
-j disable lfsr check (for Propeller 1 only).
All these are described in the documentation, or just enter payload without any options for a list.
Since it seems to be the lfsr check that is failing, here is a command I just used - this one uses -l to try a different lfsr check:
payload -d -t1000 -z -l -o1 -u50 hello_world_3 -iYou could also try disabling the lfsr check altogether by using -j in place of -l. For example:
payload -d -t1000 -z -j -o1 -u50 hello_world_3 -iWhat's odd is that you said payload works from the command line. But Geany uses exactly the same command.
Can you add just the -d option to your working command-line command and post what it prints?
Ross.
It is not "looking" for a P2 - payload is checking if the chip is a P2 if it fails to identify it as a P1 (because the lfsr check fails).
Also, it is worth noting that case is important in options - i.e. -P2 is not the same as -p2
Ross.
A quick update on progress ...
I have ordered a P2 HyperRam add-on board, so Catalina should soon be able support XMM execution on P2 platforms other than the P2_EDGE (e.g the P2_EVAL).
I now have Catalina's source-level debugger (blackbox) working for Propeller 2 XMM programs (it already supported non-XMM programs), so Catalina can now debug XMM programs on the Propeller 2 using a gdb-like source level debugger. I may release this version separately, or I may wait till I also have the HyperRam working - not sure yet.
Also, I have decided to retire blackcat, which was Bob Anderson's C debugger with a GUI interface (blackbox is my command-line equivalent, necessary because blackcat is a windows-only GUI written in a Microsoft proprietary language, whereas blackbox is written in plain old C and runs on both Linux and Windows). Normally I like to give a release or two deprecation warning before I discontinue support for something, but the reality is that blackbox outstripped blackcat in functionality a while ago (since Bob no longer supports it). Also, a debugger like blackbox or blackcat is a hideously complicated program - in some respects more complicated than the compiler it supports - and I no longer have the time to support two such beasts (I used to wonder why gdb was so flaky ... until I had to write my own!)
Ross.
Hello Ross,
A new day, a new result.
Somehow the Project Path wasn't being used correctly. I don't know what was amiss, but under Project->Base Path, I had a specific path for the project. (C:\Parallax\Hello World).
Using File Explorer, I looked into the folder and found the .c file, but no object or binary file! Odd, because there were no compiler errors. I found a different folder called "C:\Parallax\Geany Test" and it had object and binary files!
Once I deleted the Geany Test folder, everything loaded as expected.
I continued to poke around and the only reference to "C:\Parallax\Geany Test" was listed in my Environment variables. I don't know why. I got rid of that variable too.
Under Set Build Commands, Working Directory, everything was set to %p, which I'm assuming %p = Project Properties, Base Path, which was c:\Parallax\Hello World.
Is there another place where a folder may be specified? Any idea how the object and binary files may have gotten into a folder other than the Project Base Path?
Here's what I speculate happened.
1) I opened a project called Hello World in C:\Parallax\Geany Test and created a file called Hello World.c in that folder.
2) I inadvertently closed Hello World.c in Catalina.
3) Oops! I didn't mean to do that. I created a new file from template, called it Hello World.c and saved it to c:\Parallax\Hello World.
4) I changed the Project Path to c:\Parallax\Hello World.
5) I think Catalina was still using the original Project Path.
Anyway, long story short, I'm back on track with the tutorials.
Cheers!
Hello @TommyBoy
I don't know where "Geany Test" came from. Nothing to do with Catalina AFAIK. However, I probably don't correctly cater for case that someone changes the base directory of an existing project, so the "Download and Interact" payload command should probably be:
payload -p11 %x "%p/%e" -i -b%bI'll investigate a bit more and update the next release.
Glad you are back on track.
Ross.
Hello @TommyBoy
Yes, I can confirm that Geany has issues in circumstances like yours. For instance, if you open a project, any file you then open is "remembered" by the project, even if it has the same name as another file already in the project. If you close the project, and then re-open it, Geany will re-open all the open files quite happily, which can make you think you are looking at the version that is part of the project. But it may not be. It may have nothing to do with the project at all.
I knew about this ambiguity, and indeed had documented it - but I had not realized quite how confusing it could get. It turns out that there is no way to write a set of Geany commands that uses both the "open" files and the "project" files consistently in such circumstances - e.g. you can make Geany always use the open version rather than the project version for "compile" and "build" commands, but not for commands like "compile all", "link" or "make".
The best solution I can come up with at the moment is that all Geany commands work on the project files except for the "compile" and "build" commands, which have to work on open file - not least because this assumption is hardcoded into the Geany tool bar - but make those commands put their output in the project directory rather than the source directory. At least that makes some kind of sense, and is something you might do if you wanted - for example - to try a different version of a file already in your project without modifying the one already there.
I believe the concept of "projects" was bolted on to Geany late, and it has not been fully washed through yet. But without re-writing Geany, the best I can do is just document it better.
Ross.
Thanks Ross. I'm sure I'll remember this 'gotcha' for a good long while and take care not to duplicate files and to keep stray files away from a project.
I guess as a rule of thumb, if things don't compile and load as expected, check the folder and make sure that the object and binaries are there as expected. It only takes a minute.
Thanks for taking the time to guide me through this.
Ross, is there a way to load code over the air to an Activity Board WX?
Not with my loaders. But Propeller 1 Catalina LMM or CMM programs (but not XMM, EMM or SMM) should be able to be loaded with any loader.
Ross.
Catalina 5.7 has been released here.
Nothing major - debugger support for XMM programs on the Propeller 2, and improved ymodem support in the Comms terminal emulator.
Here is the relevant extract from the README.TXT:
RELEASE 5.7 New Functionality ----------------- 1. Catalina's stand-alone vt100 emulator (comms.exe) has an improved ymodem implementation and dialog box: - A ymodem transfer can now be aborted in the middle of a send or receive operation. - The dialog box now responds to Windows messages. This stops Windows complaining that the application is not responding during a long ymodem transfer. - The Abort button now attempts to abort both the local and the remote ymodem applications if a transfer is in progress. Previously, it could only abort the remote ymodem application and only while the local ymodem application was not executing. - The Start and Done buttons now check and give an error message if a ymodem transfer is in progress. Previously, they simply performed their respective actions, which could lead to a comms program lock up. - Opening the dialog box no logner crashes comms if no port has been opened. 2. Payload's interfile delay has been set to 500ms on Linux. This makes the downloading of XMM programs more reliable on Linux (it was already 500ms on Windows). 3. The blackbox source level debugger can now debug XMM programs on the Propeller 2. 4. Some blackbox information messages have been changed to make them more accurate. 5. Command line parameters (argc &argv) were not being correctly initialized when programs were run under the blackbox debugger. However, note that it is not possible to pass command-line parameters when using the debugger so they should always be initialized to null values. 6. On all Propeller 2 platforms, the default pins to use for debugging are now pins 62 & 63, which means that if you need to debug a program that uses a serial HMI on those pins, you will need to have a Prop Plug connected to some other pins, and then modify the pins specified in the platform configuration file, which by default are as follows: #define _BLACKCAT_RX_PIN 63 #define _BLACKCAT_TX_PIN 62 7. The blackcat debugger is no longer supported, and has not been updated to debug Propeller 2 XMM programs. This debugger still works on Propeller 1 programs and non-XMM Propeller 2 programs, but it is now deprecated, and has been removed from the release. 8. The Catalina-specific Geany commands (on the Build menu) have been updated slightly to make them less confusing - e.g. 'Build' has been changed to 'Build File' and 'Compile' to 'Compile File' - these commands operate on the currently selected file only, and not necessarily the files in the project directory (even thought the currently selected file may have the same name as a project file!). The 'Link' command has been changed to 'Link All' to match 'Compile All', to indicates that these commands act on all files in the project directory. Other changes ensure that any output generated when a project is selected end up in that project directory. 9. Payload now accepts a baud rate of zero (i.e. -b0 or -B0) to indicate that the default baudrate appropriate for the propeller should be used (which is 115200 on a P1 or 230400 on a P2). This was the default if NO baudrate was specified, but Geany HAS to have a baud rate specified, so specifying it as 0 is now allowed, and is equivalent to not specifying it. All the Geany projects have been updated to use baud rate 0. Other Changes ------------- 1. The compiler now reports the correct code size when compiling XMM LARGE programs.EDIT: I just noticed that the actual README.TXT file said "You must install this over an existing installation of Catalina.", which is not true - this is a full stand-alone release. I have now fixed it in the distribution, but if your README.TXT still says this (which you probably only noticed AFTER installing it) then just ignore it.
I just went to download the update, but the file name says it's 5.6. See highlighted in yellow.
Hi @TommieBoy
I updated the files to fix the README.TXT, but you may have caught it mid-update. I have just checked again now, and it looks ok to me. If your page still doesn't show the 5.7 files, or still says 5.6 is the latest version, try refreshing the page. Also, you may have to wait for the mirror sites to be updated - not sure how long that process takes.
Ross.
Great! All good now.
I've just put up a very small patch update (5.7.1) to Catalina 5.7 here. No changes to Catalina, just minor changes to the build_utilities scripts and a small tweak to the BlackBox debugger ...
Just before I finally drop BlackCat altogether - Bob Anderson's Windows GUI source-level C debugger for Catalina (BlackBox is my Windows/Linux command-line equivalent) - I thought I'd post here and see if either Bob Anderson or anyone who knows him is still around.
The main reason I didn't include BlackCat in the current release is that unlike BlackBox, BlackCat was never open source, so I have to maintain it and I can only release binary versions. I asked Bob before the last update whether I could release the source, but he never responded and I have not heard from him since.
BlackCat is written in C# and I am not very experienced at C# programming so it is very likely that at some point it will get beyond my ability to maintain - but I can't in good conscience either release his source or pass it on to anyone else to maintain without his permission.
If Bob sees this, or anyone knows how to contact him, please get in touch.
Ross.
.
@RossH - I'm starting to use Catalina for more than just Hello World, and that means I need to use libraries. I'm reading A Tutorial on using the Catalina C Compiler and I see a bit about compiling libraries. I'd like to use the Simple Libraries that I've used in the passed.
I tried using -ldatetime but it was ignored.
I followed your steps to compile a library that I created myself. It has 173 functions so I tried
Catalina -S *.cbut I got too many errors to count. Mostly about missing header files, but they should all be found in the PATH.I set CATALINA_LIBRARY to C:\Parallax\Simple Libraries, but the compiler didn't find them.
How do I incorporate these libraries into my programs? It seems to be a significant project to recompile them in two memory modes and then catalog them.
Guidance please.
Hello @TommieBoy
First, a command-line parameter like -ldatetime (that's minus "little l for library") tells Catalina to look for a directory called libdatetime - either in the current directory or in the library path. But you probably neither want nor need to change the library path - for the moment just create and use the library in your working directory. Catalina will always look there for libraries as well as in the path specified by CATALINA_LIBRARY - but If you change the library path then Catalina will not be able to find its own libraries. So get your library working in your working directory first.
Next, Catalina does not search the PATH for include files. If they are not standard include files then you have to tell it where to look for them using -I (that's minus capital "I for include") on the command line to specify an include path. You can use multiple -I options, and they can be absolute or relative paths. For example:
Your compile command looks ok, assuming the files are all in libdatetime:
Once the programs in the library compile, remember you need to run catbind in the library to create an index. For example:
Then try using your library. If there are undefined symbols, it probably means the functions in your library depend on other functions that you will need to find and add.
Ross.
Hello @TommyBoy
I tried finding these "Simple Libraries" you referred to. I recall I tried to do this once before, without much luck. I found two different things that call themselves "Simple Libraries" but neither of them are really "simple" and both of them seem to be compiler-specific (see Note 1). Neither will be easy to port "in toto" to another C compiler - individual parts of them look easy enough to port, but then other parts are quite compiler-specific and I wouldn't even try. It would be easier to just rewrite them (see Note 2).
Let me know which particular Simple Libraries you are using, and I can have a deeper look.
Instead of trying to port the whole library, you may be better off identifying which specific functions you need, and then seeing if Catalina has an alternative or equivalent (it does for many of the functions I looked at, but I don't know if they are the ones you need). Then port only the specific functions you need.
In many cases, the Simple Libraries seem intended to just provide smaller versions of some standard C functions (e.g. the "stdio" functions, which can be quite memory hungry). But Catalina already offers several alternatives to those - e.g. I noticed some of Eric Smith's code in there, but Catalina already incorporates a version of his "tiny" stdio library functions, so you probably don't need the Simple Library ones when you are using Catalina - in many cases you can just use the normal stdio functions but link your program with the -ltiny command line option.
Ross.
EDITS:
Note 1: I originally wrote "gcc-specific" but it seems one of them compiles with flexgui and the other with PropGCC - so not "gcc-specific" but "compiler-specific".
Note 2: It looks like this is actually what happened - i.e. flexgui took a subset of the original gcc Simple Libraries and rewrote them for that compiler. So I guess if we could all agree on the subset we wanted to support, I could do the same for Catalina.
@RossH - So, just to ensure I understand fully, the Simple Libraries can't be used as is?
They must first be compiled with the command catalina -S *.c,
then I need to use catbind to create an index?
I tried one of the smaller libraries, but I've found a ton or errors. Just one function kicked up this...
I'm not sure how to proceed from here. The Simple Libraries are so important to the flexibility of the P1, yet it seems it would be a monumental task to edit them.
Am I correct in my assessment? Or is there another way?
Correct. It looks like the Simple Libraries are not written in standard C. The use of the
__attribute__keyword seems to indicate they are written in 'GCC' C. ...https://stackoverflow.com/questions/4223367/how-to-use-the-attribute-keyword-in-gcc-c#4228041
Sometimes this is done because it enhances performance, and simply removing them would have no effect. Sometimes it is done to lock the code to a specific compiler. Most often, it is probably done just because it is an easier way to accomplish something slightly tricky than doing it the right way. Whatever the reason, it is bad practice - but not that uncommon.
It is rare that such code cannot be modified to eliminate the need for such extensions (in this case it might be as simple as defining
__attribute__to be a null function call ) - but sometimes it is more complex and you have to figure out why they needed to use such extensions and then re-implement them in standard C.Again, the best thing to do is identify what portions of the libraries you need to use, and see how difficult it would be to rewrite them in standard C.
Ross.
@RossH, thanks for the explanation. I've been investigating the functions I use on my current project. I use 28, of which 10 look like they may have direct matches in your libc, and another 5 that look like they may have similar functions in some of your other libraries. I'll investigate the header files, see how they are declared and perhaps I'll need to massage my code to match.
The other 13 will require further research. Some may be simple for me to replicate, but others will be a bigger challenge.
Thanks for your patience and help. I'm still moving forward!
One more question: Do you have plans to include Wifi OTA loading with Payloader? I'm finding that the Wifi module is very handy when paired to a Propeller.
Tom
I''ve had a slightly closer look a the Simple Libraries. The
__attribute__keyword can mostly be ignored. The easiest way to do this is to add something like the following to one of the common header files, which equates it to nothing:However, this is not true in every case. Here are the ones I found in use, and what you may have to do about them:
It is probably only the
constructorandfcacheattributes that will give you problems.The
constructorattribute is a GCC-specific means of performing library module initialization, which will have to be made explicit (i.e. the initialization functions will all have to be manually called before the library is used).The 'fcache' attribute is a bit tricky - if the code doesn't run fast enough after having the fcache attribute removed, it may need to be rewritten. Catalina supports FCACHE on the Propeller 1, but only in CMM mode, and code to use it has to be hand-crafted.
As for a WiFi OTA loader, I don't have either a WiFi adapter or any need for this capability - so this is not likely to happen any time soon.
Ross.
Just noticed a very minor bug in the new Windows VTxxx emulator program (comms) which is now bundled with Catalina.
You are supposed to be able specify the comms port on the command line as either
/com=Nor/com=comN- but just using the bare port number only works for comms port numbers 10 or greater. For comms port numbers 0 .. 9 you have to say/com=comNbecause the short form/com=Ndoesn't work.This also applies to the Windows vtxxx batch files as well (which just call comms). For instance, you have to say
vt220 comNbecausevt220 Ndoesn't work unless N is 10 or greater.I never noticed it because all my USB comms ports are numbered above 10 - but I just tried a PC where the USB comms ports numbering start at 3.
I'll fix it in the next release.
Ross.
Hello @TommyBoy
I had a few hours spare this afternoon, so I have ported (but not tested!) a chunk of the Simple Libraries. It might help you on your way.
I will be unable to do much coding for the next week or so, but I can answer any questions you may have.
Here is the README.TXT:
Hope this helps!
Ross.
Wow @RossH, thanks! I'll do some testing and it check out.
Uggh @RossH!
I'm having a problem with payload again. The project, builds but won't load. I tried all of the options you suggested in #122 above but no joy.
However, I think I may have a clue. I just don't know how to solve it. To prevent Geany IDE from opening the files from the last session, under Preferences -> Startup, I've unselected 'Load files from last session'.
Now, I need to open projects specifically and, in theory, eliminate any unconnected files from opening.
But now when I select Project->Open->c:\catalina\testlib, I get a weird file opening. See the image.
I don't know where this is coming from, but there are several inconsistencies.
See the yellow circled text. These are not the same files. The one open for editing isn't even in the project directory.
The blue, purple and red circled text are not the same.
The green circled text, datetime.h, and libdatetime are not part of my project, though they were at one time.
If I select File->Save as, the Save As window opens in my project folder with the suggested file name of testlib.c, which would over write my main file.
And because I don't know where this file is loading from, I can't delete it. (I'm assuming that if I deleted it, Geany would rebuild it with the parameters selected.)
Nor can I edit it and save over the original, because I don't know where the original is!
Without saving, I closed the file in the editor, closed the project, and exited Geany. When I opened the next time the file wasn't there.
Is there a chance that it's still haunting my project? Or is it a red herring?
Any way, here's the output...
Any suggestions?
EDITED: Today when I started Catalina, I selected Project->Open->testLib->testLib.geany, the file is there AGAIN. Do you have any idea how to get rid of it?
EDIT#2: I found the offending testLib.c in C:\Program Files (x86)\Catalina_5.7\catalina_geany. Deleted, but I'm still getting the error with payload.
EDIT#3: From CLI, payload -p12 -d -v loads binary as expected, just not from IDE.
Hello @TommieBoy
Not sure how this happened, but the problem seems to be that you have ended up with old Geany project data saved in a file with a '.c' extension, which is confusing Geany (not to mention you and me!). What you are looking at in 'Testlib.c' is what was once in 'testlib.geany' but is now out of date. Perhaps use a text editor (not Geany) and check out that all the files actually contain what they should contain. My suspicion is that you have at some point opened the project file ('testlib,geany') as an ordinary file in Geany (it just contains the text like what you can see) and then somehow it has ended up being saved as 'Testlib.c'.
As I said before, Geany doesn't clearly differentiate between 'session' files and 'project' files. A file can be open in the session even if it is not in the project - and vice-versa. The really silly thing is that Geany stores session data in the project file (which is the stuff you have highlighted in Green). Best thing to do in this situation is close all open files manually, then close the project, then exit Geany, re-start it, then re-open the project.
If that does not fix it, the rebuild the project from scratch in a new folder (with a new project name), copying in only the files you need.
The payload error is probably not related, but the payload commands you have given me are not complete, nor is the output, so I cannot tell you exactly what the problem is here. However, I can see that you appear have a file called 'Testlib' as well as one called 'testlib.binary', so if you try to say something like 'payload testlib' then 'Testlib' is what it is trying to load, not 'testlib.binary', which is probably not what you want. What is in file 'Testlib'?
Ross.
@RossH, I deleted the errant testLib.c file, since that version of the project, its folders, and source code no longer exists so it hasn't a reason to exist either.
I'll keep an eye out if it happens again.
As for payload, I tried CLI payload (which works) versus Catalina payload (which isn't), both with the same args, except Catalina uses a couple of substitutions.
I couldn't find the meaning of the substitutions in the manuals but I figure %p is the path, and %e is the name of the binary. I don't know what %x means, so I couldn't include it in my CLI payload args list.
Here is a comparison of the outputs. (Sorry for the huge size!)
Green lines are all the same, red are where the problem is. I do have a file in my folder called testLib with no extension, but it is created by Catalina, and it is 6,063 bytes!
SOLVED: So the solution is to add .binary to the %e substitution argument. The Payload Option Summary.pdf says that .binary is optional and if not present, payload will try .bin, .eeprom, then .binary. If I reset the Set Build Command -> Download and Execute line, the file extension isn't there either, so it must be added.
Anyway, editing the Set Build Command -> Download and Execute to explicitly load the binary is the solution.
This worked.
Good. In one of the recent releases, I seem to have changed the order in which payload searches for the file to load. Now it looks for the bare filename first before trying any extensions, so it was finding 'Testlib' before 'testlib.binary' (case is not important in Windows filenames). The file 'Testlib' was most likely the result of a failed compilation of 'Testlib.c' so deleting both 'Testlib.c' and 'Testlib' would also have solved the problem.
I have tried reproducing the root problem (i.e. how Geany could create, copy or rename a project file to a file with a '.c' extension) but I have not been able to find a way to make it do so. That one remains a mystery.
I will change payload in the next release to search for .bin, .binary & .eeprom extensions before matching the bare filename.
Sorry about that!
Ross.
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.
EDIT: I found a bunch in the P2 Reference Manual. I'll look some more before I ask again. Sorry.