Shop OBEX P1 Docs P2 Docs Learn Events
Catalina 4.0 is now available — Parallax Forums

Catalina 4.0 is now available

RossHRossH Posts: 5,336
edited 2019-10-31 10:19 in Propeller 2
Catalina 4.0 is now available on Sourceforge - https://sourceforge.net/projects/catalina-c/

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

This release adds a new library for the 2 Port Serial plugin on the Propeller 2, XEPROM support (i.e. execute XMM code from EEPROM) for the Propeller 1, and several significant bug fixes for the Propeller 1 and Propeller 2. It also improves the Code::Blocks support for the Propeller 2, which had been lagging behind the command line support. However, the main purpose of this release is that it is the first release for the Propeller 2 that also updates the documentation. All documents have been updated to reflect the Propeller 2 support, and there is a new Catalina Reference Manual specific to the Propeller 2.

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

Catalina 4.0 includes both Windows and Linux releases.

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

Here is the README.WhatsNew
Catalina release 4.0 is a full release. You can install this over an 
existing version of Catalina, but it is recommended that you instead uninstall 
any previous Catalina release before installing, or install this release to a 
different location. 

If you are installing under Linux, you should execute the following command 
to set your permissions correctly after installing (this command is a script 
in the Catalina bin directory):

   Set_Linux_Permissions

The following changes have been made since the previous release of Catalina. 
If you have not used a previous release of Catalina, you can ignore the
following list:

RELEASE 4.0

1. Updated Code::Blocks to include the XEPROM option. Now you can select
   XEPROM in the Catalina Project Wizard (by selecting the menu entry for
   File->New->Project and then selecting "Catalina Project") and you can
   also use 2 new tools for loading XEPROM projects (by selecting the 
   Tools menu entry)

2. Added a new named platform to Catalina_platforms.inc. This is the P2_CUSTOM
   platform, which by default is identical to the P2_EVAL platform, but which
   is intended to be customized for new Propeller 2 boards.

3. Because the support for the Propeller 2 is (at least at present!) much 
   simpler than that for the Propeller 1 (e.g. it does not require XMM support
   to run large C programs, and complex loaders to load them), the Catalina 
   Reference Manual now has two versions - one specifically for the original
   Propeller 1 (which removes most of the details that are relevant only to 
   the Propeller 2), and another for the Propeller 2 (that removes most of the
   details that are only relevant to the Propeller 1). All other documents
   have also been updated to reflect the functionality now available in 
   Catalina 4.0.

4. Moved the inline PASM demos to the spinc folder, and updated the README.TXT
   in that folder. Also added the program "test_inline_pasm.c" as a project in 
   the Code::Blocks "Spinc Demos" workspace.

5. Added tty_txcheck() functions to the tty and tty256 libraries, to match the
   s4_txcheck() function recently added to the s4 library. These functions all
   return the number of spaces left in the transmit buffer. The important
   point is that if they ever return 0, it means a call to the corresponding
   tx function may block.

6. Fixed a bug that affected Propeller 1 XMM programs that used the cache. 
   Typically, it meant that a program would work with a smaller cache size 
   (e.g 1K, 2K or 4K) but not with a larger cache size (e.g. 2K, 4K or 8K)
   even though there was enough Hub RAM to accommodate the larger cache.

7. The batch files p2_asm.bat and p2_asm have been modified to include the
   -v33 flag to the p2asm assembler. This enables the differences in the 
   instructions set in the latest (and hopefully last) version of the 
   Propeller 2 chip used in the rev B version of the P2_EVAL board. Note 
   that Catalina itself does not use the different instruction sets, but 
   some plugins or user programs may do so. If it is ever necessary to 
   revert to the previous instruction set (e.g. to run a program on a revA 
   version of the P2_EVAL board), these files must be edited to remove this 
   flag. 

8. Fixed a bug where the plugin type of the kernel cog was being overwritten 
   during registry initialization, so the cog would appear to be unused.

9. Added the 2 port serial driver as a plugin, and a library (libserial2) 
   to use it. The 2 port serial driver is only supported on the Propeller 2.
   The functions in the 2 port serial library are similar to the existing 
   libtty, libtty256 and libserial4 functions. Catalina will load the 2 port
   serial plugin automatically if you compile your program with the -lserial2
   option. Note that you should not use the 2 port serial driver with the 
   TTY HMI option - they will conflict. This means that when compiling with 
   -lserial2 you should also either specify -C NO_HMI, or use another 
   supported HMI option. For instance:
   
      catalina -p2 test_serial2.c -lci -lserial2 -C NO_HMI

10. Fixed a problem with the Code::Blocks "Download to Hub Ram and Interact at
    230400 baud" tool, which was not setting the directory correctly, and so
    would sometimes not find the file to download. After installing, you may
    need to run the "Reset_CodeBlocks" script (found in the Catalina bin 
    directory).

11. Made some small changes to the test_dosfs.c program in the "validation"
    subdirectory, to allow more variants of the program to run on P1 platforms
    with very limited XMM SRAM (such as the C3). On such platforms, this test
    program may still fail to run when compiled in LARGE mode unless the FLASH
    option is also used, because 64kb of XMM SRAM is simply insufficient in 
    some cases (e.g. if the program is compiled with the libx library variant).
    However, this is not a Catalina failiure, and the test program now runs 
    correctly in most cases.

Comments

  • JonnyMacJonnyMac Posts: 8,912
    edited 2019-10-31 15:49
    The version of Code::Blocks that gets installed with Catalina is 13.12, while the latest version of Code:Blocks is 17.12. Since the former gets installed in the Catalina path, it seems unknown to the rest of the system except through Catalina CodeBlocks in the Catalina group. I did a normal install of 17.12 and there seems to be no conflict. That said, 17.12 shows user tools that correspond to the Propeller, though the New Projects pane does not include Catalina.
  • RossHRossH Posts: 5,336
    JonnyMac wrote: »
    The version of Code::Blocks that gets installed with Catalina is 13.12, while the latest version of Code:Blocks is 17.12.

    Odd! I must have packaged the wrong version :( It should be 17.12.

    I'll investigate.
  • RossHRossH Posts: 5,336
    edited 2019-10-31 22:44
    JonnyMac wrote: »
    The version of Code::Blocks that gets installed with Catalina is 13.12, while the latest version of Code:Blocks is 17.12. Since the former gets installed in the Catalina path, it seems unknown to the rest of the system except through Catalina CodeBlocks in the Catalina group. I did a normal install of 17.12 and there seems to be no conflict. That said, 17.12 shows user tools that correspond to the Propeller, though the New Projects pane does not include Catalina.

    Hello Jon

    I've investigated, and the version of codeblocks installed by the Catalina 4.0 installer is definitely 17.12.

    And yes, Catalina installs its own version of Code::Blocks - this should not interfere with any other version you already already have installed, except possibly for any settings saved in your local "default.conf" file (such as the Tools menu entries). However, those other versions of codeblocks will not include the Catalina-specific extensions, and it probably means that if you just start codeblocks from the command line, you may be getting the wrong version (this will depend on your path settings). You must start Catalina's version using the Start Menu, which knows where it is installed.

    If doing so is starting version 13.12 of Code::Blocks, it could be that you installed Catalina 4.0 over an older version, and for some reason it did not update the codeblocks files. If this is the case, please try completely uninstalling the previous version of Catalina before installing version 4.0.

    Let me know how you go.

    Ross.
  • May have found the problem: The big green download button at this link

    -- https://sourceforge.net/projects/catalina-c/

    ... is connected to version 3.13.2. I missed this when I downloaded. I had to manually navigate to Files/Releases/4.0 to get the correct installer.

    Just a note: Windows defender was not happy. I installed anyway and my very-high horsepower machine went full blast for a while. Everything seems now. I ran from Start menu and everything is in place.
  • RossHRossH Posts: 5,336
    JonnyMac wrote: »
    May have found the problem: The big green download button at this link

    -- https://sourceforge.net/projects/catalina-c/

    ... is connected to version 3.13.2. I missed this when I downloaded. I had to manually navigate to Files/Releases/4.0 to get the correct installer.

    Ah! I have no control over that. There must be a delay before it switches to the latest release. I will delete some of the older releases - this may help, and they are very out of date anyway.
    Just a note: Windows defender was not happy. I installed anyway and my very-high horsepower machine went full blast for a while. Everything seems now. I ran from Start menu and everything is in place.

    Odd. I run Windows and it installs without comment. I did see this once before (months ago!) but it seemed to go away again. There is a process you can use to tell Microsoft this is a false detection, but I can't remember what it is. I will try and look it up.

    What does Windows Defender say on your machine? That may help me identify which file is causing the problem.

    Ross.
  • RossHRossH Posts: 5,336
    I just reloaded the page (https://sourceforge.net/projects/catalina-c/) and the big Green download button now correctly points to the latest release.

    Next time, I will try and remember to wait for this before announcing it :(

    Ross.
  • RossHRossH Posts: 5,336
    First errata ... :(

    The Catalina 4.0 Linux release contains an old version of the Catalina "New Project" wizard script. Easy to fix - just overwrite the existing version with the one attached. NOTE: the Windows installer installs the correct version.

    If you installed codeblocks to the recommended location under Linux, the original file will be found in:
    /opt/codeblocks-17.12/share/codeblocks/templates/wizard/catalina/wizard.script
    

    The new version adds XEPROM support (to the wizard only - XEPROM support can still be specified on the command-line, or manually selected within Code::Blocks).

    Ross.
  • RossHRossH Posts: 5,336
    Another (fairly trivial) errata ...

    I accidentally left the pin definitions for the second serial port on the P2_EVAL board set to 50 & 52 (which I test with a PropPlug) instead of 56 and 57 (which are the pins intended to be used by the 2nd USB port, if you have it enabled). This might cause some head scratching because the second serial port would not work as expected "out of the box" with the 2 port serial plugin.

    This is fixed in the attached file, which applies to both Windows and Linux (I have left the pins set to 50 & 52 in the P2_CUSTOM platform).

    Also, I have now added CUSTOM and P2_CUSTOM as synonyms for the configuration intended to be modified to support other boards. This is because the many of the batch files now set the -p2 flag automatically if the platform name starts with P2 (e.g. P2_EVAL, P2D2), whereas in other cases (e.g. in Code::Blocks) it is still assumed this platform will just be called CUSTOM. So now you can use either one.

    Just copy the attached file over the existing version in your catalina/target_p2 directory.

    Ross.
  • OK @RossH,

    I have to say upfront that I am born and raised to be a COBOL programmer and I have never liked C. I was threatened to use the net framework and C# when migrating things from big iron to PC hardware, but - hmm- was able to avoid C, mostly in my life.

    But besides Mainframes I like those micro controllers. Just for fun. Since you stated at some time that you used my 2-port driver serial, I sort of HAD to install Catalina. Not that I need it but, gosh a SERIOUS product for the Propellers and my 2-port-driver used? I still am to shy to ask @ersmith to put that into flexgui and you are using it. COOL.

    So I HAD to install it.

    I am seriously impressed by Catalina and the Code Blocks integration. Really nice done. Just WOW.

    I never used Catalina on the P1, I was just fine with PASM and SPIN, but I think I missed out somehow there. You even support my Ramblade from @Cluso99, incredible!

    so a big THANK YOU for doing that, even if I do not need C but, hell YES you did a good job and someone has to say that.

    Enjoy!

    Mike
  • RossHRossH Posts: 5,336
    Thanks, Mike.

    I may make a C programmer out of you yet! :)
  • msrobotsmsrobots Posts: 3,701
    edited 2019-11-03 07:44
    no, the OBOL is missing from that C.

    But if you would be able to add some POSIX stuff I might be able to run GnuCOBOL, it does transpile COBOL to C but does even have a hard time to run on Windows without mingw or a virtual whatever.

    Anyways, VERY cool what you did.

    And, YES I did wrote a small C program just to test Catalina. I sort of had to.

    guess what, it even worked on P1 and P2 eval A.

    Mike
  • RossHRossH Posts: 5,336
    msrobots wrote: »
    But if you would be able to add some POSIX stuff I might be able to run GnuCOBOL, it does transpile COBOL to C ...
    No way!

    I really, really, REALLY don't want to ever see the C code that results from that process! :)

    Ross.

  • me neither, even if it does not look too bad on a first glance. The basic idea behind this is to look at the beautiful COBOL code and let the compiler look at the C code.

    I do really like the GnuCobol project, but it is quite Linux centric, and I am not.

    Enjoy!

    Mike
  • RossHRossH Posts: 5,336
    I'v only just noticed (while messing about with something else) that the blink.c program (included in the Catalina demos folder) makes a very pretty test program for the 64006-ES (c) accessory board (i.e. the LED MATRIX) - so I've updated it slightly to make the base pin more easily configurable.

    A compiled version using base pin 56 is attached (this is the default because it also flashes the LEDs on the P2_EVAL board).

    Ross.
  • RossHRossH Posts: 5,336
    edited 2020-05-18 05:52
    Hello all!

    I don't know if Propeller 2 users have been following recent developments of Catalina on the Propeller 1, so I thought I'd post an update here.

    Catalina 4.1 will be released soon, and will incorporate a new "multi-memory model" feature which allows the concurrent execution of programs that use different memory models (e.g. COMPACT and XMM on the P1, or COMPACT and NATIVE on the P2). For instance, on the Propeller 1, it can be used to launch COMPACT programs as needed from XMM RAM, saving valuable Hub RAM.

    On the Propeller 2, Catalina doesn't support XMM RAM yet, but it allows you to do the same thing using the SD Card - i.e. to launch COMPACT, LMM or NATIVE programs from the SD Card, all from within a program itself compiled as any supported type. This works on both the Propeller 1 and the Propeller 2, but is especially useful on the Propeller 2.

    One consequence of this is that a Propeller program can now be of essentially any size even without XMM RAM, provided it is structured as a primary program that loads multiple secondary programs as overlays.

    And it is all as easy as ABC! Well, perhaps as easy as ABCDEFGHIJKL ... etc ... :)

    All the concurrent programs share the registry and any plugins. They can each be multi-threaded or single-threaded. They can all communicate. See the attached README_MMM.TXT file for more details.

    Attached is a fully working example for the P2, with program source code and binaries. You can run the binaries, but won't be able to compile the source until Catalina 4.1 is released. The demo can be executed on the P2 simply by copying all the files to an SD Card and rebooting the P2. It uses a serial terminal at 230400 baud. It is compiled for a VT100 emulator (I use 'putty') but if you use the Parallax Serial Terminal, just disable Line Feed processing, and if you use the Catalina payload terminal, just include the command line option '-q1'

    The example includes the Catalyst program loader. At the Catalyst command line, enter one of the following commands:
    run_cmm - run a COMPACT version of the demo
    run_lmm - run an LMM version of the demo
    run_nmm - run a NATIVE version of the demo
    

    In each case, the program you run will simply execute the "dining philosophers" program 3 times, loaded each time from a different overlay file - one compiled as COMPACT, one as LMM, and one as NATIVE. None of them will run to completion - the primary program only allows each secondary to run for 10 seconds and then kills it (this is only a demo!). Note that you have to press ENTER each time the primary starts a secondary program - this is really only to demonstrate that all the programs (primary or secondary) are sharing the same serial comms plugin.

    The important point is that it demonstrates that the primary program and secondary program can be any combination of memory model, and any combination of threaded and unthreaded. This allows different portions of the program to be compiled for SPEED (i.e. compile them as NATIVE) or to save SPACE (i.e. compile them as COMPACT). You can now mix and match to suit!

    For those interested in the gory details, here are all the commands I actually used to build the demos (this will only mean anything to you after you have read the README file):

    catalina -p2 dining_philosophers.c -lci -lthreads -R 0x40000 -C NO_ARGS -C P2_EVAL -C TTY -C VT100 -C CR_ON_LF
    spinc -p2 -B2 -n LMM -s 8000 -c -l -f _threaded_cogstart_LMM_cog dining_philosophers.bin -o diners.lmm  >dining_philosophers_lmm.inc
    
    catalina -p2 dining_philosophers.c -lci -lthreads -R 0x40000 -C NO_ARGS -C COMPACT -C P2_EVAL -C TTY -C VT100 -C CR_ON_LF
    spinc -p2 -B2 -n CMM -s 8000 -c -l dining_philosophers.bin -o diners.cmm  >dining_philosophers_cmm.inc
    
    catalina -p2 dining_philosophers.c -lci -lthreads -R 0x40000 -C NO_ARGS -C NATIVE -C P2_EVAL -C TTY -C VT100 -C CR_ON_LF
    spinc -p2 -B2 -n NMM -s 8000 -c -l dining_philosophers.bin -o diners.nmm >dining_philosophers_nmm.inc
    
    catalina -p2 run_dining_philosophers.c -lcix -o run_lmm -C P2_EVAL -C TTY -C VT100 -C CR_ON_LF
    catalina -p2 run_dining_philosophers.c -lcix -C COMPACT -o run_cmm -C P2_EVAL -C TTY -C VT100 -C CR_ON_LF
    catalina -p2 run_dining_philosophers.c -lcix -C NATIVE -o run_nmm -C P2_EVAL -C TTY -C VT100 -C CR_ON_LF
    

    Note that the "dining_philosophers.c" program is nothing special - it is actually the one already included in Catalina as a multi-threaded demo program. And the "run_dining_philosophers.c" program is quite trivial - apart from all the messages it prints out as it executes, it is really only a few lines long.

    You can thank Covid-19 for this new capability. I am finding I have a lot of spare time on my hands at the moment :(

    Ross.
  • RossHRossH Posts: 5,336
    edited 2020-05-18 05:02
    One more thing ...

    While working on the multithreading aspects of the new Multi-Memory Model support, I noticed that some of the programs in the demos\multithread folder don't work on the P2 RevB silicon (they worked on the P1 and the P2 RevA).

    The problem is that the following code (or something similar) should be included at the start of any multi-threading program, before any other thread functions are called:
       // assign a lock to avoid context switch contention 
       _thread_set_lock(_locknew());
    

    Some of the demo programs had it, some didn't. I will fix this in release 4.1, or you can simply edit the demo programs now.

    Ross.
  • Im a cobol guy too.
    But had to migrate to c and later to .net c#
    I would love to have a c# like thing on p2

  • RossHRossH Posts: 5,336
    Surac wrote: »
    Im a cobol guy too.
    But had to migrate to c and later to .net c#
    I would love to have a c# like thing on p2

    I am not a Cobol programmer. I believe there may be some who visit these forums, but I can't remember who they were.

    As for C# ... well, I doubt we will ever see C# on the Propeller, but if you want to try porting it and there is anything you can use in Catalina, be my guest!

    Ross.
  • Hi Ross,

    I have to admit that I've never used Catalina for the P1. I've just read the feature list... "Full debugger support (source code and/or assembly level debugging)" This really already works for the P2? That would be awesome! I already use Code::Blocks for PC software development, BTW.
  • RossHRossH Posts: 5,336
    edited 2020-05-18 12:13
    ManAtWork wrote: »
    Hi Ross,

    I have to admit that I've never used Catalina for the P1. I've just read the feature list... "Full debugger support (source code and/or assembly level debugging)" This really already works for the P2? That would be awesome! I already use Code::Blocks for PC software development, BTW.

    The source level debugger certainly works for both the P1 and the P2. There is a command line version for Windows and Linux (BlackBox) and a Windows-only GUI version (BlackCat). I use those myself occasionally, and have updated them for the P2.

    I have to admit I haven't used the assembly level debugger for quite a while! The P1 version was based on the POD debugger, and there is no P2 equivalent that I am aware of. I will update the documentation for the P2 to say there is only source level debugging, unless someone can point me to an assembly level debugger for the P2?

    Ross.
  • Ok, I'll try it out. I've just downloaded and installed it. I've created a project and tried to compile the hello world example. I got the following error:
    ||=== Build: Debug in HelloWorld (compiler: Catalina C Compiler) ===|
    output file bin\Debug\HelloWorld.bin.bin||cannot open|
    ||=== Build finished: 1 error(s), 0 warning(s) (0 minute(s), 0 second(s)) ===|
    
    When I try to download the binary I get this message:
    Launching tool 'Download to Hub RAM': payload.exe HelloWorld (in D:\Projekte\Catalina\HelloWorld\bin\Debug)
    stderr> Error: Unable to open file HelloWorld.binary
    Tool execution terminated with status 1
    
    It seems that some of the configurations went wrong. In the "create project" wizard I've choosen (almost) everything as it was recommended in the readme:
    Hardware: P2
    Platform: P2EVAL
    XMM Board: none
    Standard C Library (with float)
    HMI: TTY (serial)
    memory: NATIVE
    filename extension: .bin

  • RossHRossH Posts: 5,336
    ManAtWork wrote: »
    Ok, I'll try it out. I've just downloaded and installed it. I've created a project and tried to compile the hello world example. I got the following error:
    ||=== Build: Debug in HelloWorld (compiler: Catalina C Compiler) ===|
    output file bin\Debug\HelloWorld.bin.bin||cannot open|
    ||=== Build finished: 1 error(s), 0 warning(s) (0 minute(s), 0 second(s)) ===|
    

    Something is wrong with the file name - "HelloWorld.bin.bin". Did you by chance call your project "HelloWorld.bin"?

    I am not at my normal computer at the moment, but I think doing that may cause problems on Windows. I will investigate further when I get a chance, but you may want to try it calling the project just "HelloWorld".

    Also, since a "hello world" program probably uses the normal serial I/O port, note that when you do get it compiled that the source-level debugger will require a separate serial port to that used by the stdio functions - it cannot share the same port.

    The pins used for the debugger's serial port are configured in the "Catalina_platforms.inc" file in the "target_p2" directory, and (depending on your hardware) you may need a PropPlug or equivalent.
  • No, I just called it "HelloWorld"
    Opening D:\Projekte\Catalina\HelloWorld\HelloWorld.cbp
    Done.
    NativeParser::CreateParser(): Finish creating a new parser for project 'HelloWorld'
    NativeParser::OnParserEnd(): Project 'HelloWorld' parsing stage done!
    
    736 x 533 - 30K
  • RossH wrote: »
    Also, since a "hello world" program probably uses the normal serial I/O port, note that when you do get it compiled that the source-level debugger will require a separate serial port to that used by the stdio functions - it cannot share the same port.

    The pins used for the debugger's serial port are configured in the "Catalina_platforms.inc" file in the "target_p2" directory, and (depending on your hardware) you may need a PropPlug or equivalent.
    Is it possible to use the standard pins 62/63 for programming AND debugging? (of course that implies that I don't use printf/standard IO). I already have two serial ports but the second one is a half duplex RS485 port.
    #define pinDTX  62
    #define pinDRX  63
    #define pinMTX  11
    #define pinMTE  12
    #define pinMRX  13
    #define baudRate1 230_400	// serial debug port
    #define baudRate2 1_000_000	// RS485 port
    static struct __using("FullDuplexSerial2.spin") com;
    
    void main()
    {
      clkset (...
      com.start2 (pinDRX, pinDTX, 0, baudRate1, pinMRX, pinMTX, 0, baudRate2);
    
    My board is a custom one but it's compatible to the P2EVAL. At least it has a 20MHz crystal, an SPI flash ROM and the first serial port on the same pins.
  • RossHRossH Posts: 5,336
    ManAtWork wrote: »
    No, I just called it "HelloWorld"
    Opening D:\Projekte\Catalina\HelloWorld\HelloWorld.cbp
    Done.
    NativeParser::CreateParser(): Finish creating a new parser for project 'HelloWorld'
    NativeParser::OnParserEnd(): Project 'HelloWorld' parsing stage done!
    

    Then I must have a bug in the "new project" script. I will investigate.

    In the meantime you can fix it manually by right clicking on the project, and selecting "Properties" (or selecting the Project->Properties menu item). In the Properties dialog box select the "Build targets" tab, and then remove the ".bin" from the "Output filename".

  • RossHRossH Posts: 5,336
    ManAtWork wrote: »
    Is it possible to use the standard pins 62/63 for programming AND debugging? (of course that implies that I don't use printf/standard IO). I already have two serial ports but the second one is a half duplex RS485 port.

    Yes, it is possible to use the same port for programming and debugging, provided you don't also use the same pins for serial I/O. To make sure that the TTY HMI plugin is not being loaded, select "No HMI" in the build options, or specify -C NO_HMI manually.

    In the target_p2\Catalina_platforms.inc file, find the platform you are using (I am guessing it would be either P2_EVAL or CUSTOM) and modify the BlackCat pins (also used for BlackBox) to be as follows:
    #define _BLACKCAT_RX_PIN  63
    #define _BLACKCAT_TX_PIN  62
    
  • RossH wrote: »
    In the meantime you can fix it manually by right clicking on the project, and selecting "Properties" (or selecting the Project->Properties menu item). In the Properties dialog box select the "Build targets" tab, and then remove the ".bin" from the "Output filename".

    Ok, that worked and now I'm able to compile. But when I choose Tools->Download to HUB RAM and interact at 230400bd I get this message:
    Payload.exe HelloWorld -i -z -b230400 -q1
    No Propeller found on any port
    
    Process returned 1 (0x1)   execution time : 0.750 s
    Press any key to continue.
    
    I have my board connected with a standard (P1) ProgPlug which has proven to work with loadp2. The LEDs on the ProgPlug are blinking shortly for half a second. I can see from the LEDs of the P2 board that it does a reset and loads the program that was previously stored in the flash ROM (not the hello world program).

    My board has the standard boot pin connections:
    TX/RX to P62/P63
    SO, SI, CK, /CS to P58 to P61
    10k pullup on /CS
    no SD card or anything else connected, schematic available here
  • RossHRossH Posts: 5,336
    edited 2020-05-20 07:58
    ManAtWork wrote: »
    Ok, that worked and now I'm able to compile. But when I choose Tools->Download to HUB RAM and interact at 230400bd I get this message:
    Payload.exe HelloWorld -i -z -b230400 -q1
    No Propeller found on any port
    
    Process returned 1 (0x1)   execution time : 0.750 s
    Press any key to continue.
    

    Try executing that payload command manually (i.e. in a Catalina Command Line). You can add -d and it should print diagnostic information which might tell you something. You can also try removing the -z, or adding one or more of the following, which extend various timeouts:
    -t 1000 
    -u 100
    -r 100
    -n 1000
    

    I know some of these are necessary on Linux (notably -t 1000), but they are not usually necessary on Windows.

    However, at the end of the day, you don't need to use payload at all, even when debugging. If loadp2 works for you, you can continue to use that and any suitable serial terminal emulator (or the Catalina debuggers).
Sign In or Register to comment.