Shop OBEX P1 Docs P2 Docs Learn Events
Catalina and the P2 - Page 6 — Parallax Forums

Catalina and the P2

12346

Comments

  • RossHRossH Posts: 5,334
    edited 2019-06-23 23:44
    Anyone who thinks Chip would have wasted a bit by using 20 bits for addressing if he thought he could get away with 19 either doesn't know Chip very well, or hasn't studied the Propeller chips in very much detail :)

    Also, using the current methods of XMM on the P2 would be like using a Lamborghini to tow a hay cart. Yes, you could do it - but why would you?

    I will wait and see what eventuates.
  • Cluso99Cluso99 Posts: 18,066
    Chip was aiming for 1MB but it just did not fit :(
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2019-06-25 12:09
    We have FPGA P2s that have 1MB or 16 cogs but current silicon couldn't squeeze all that in as the die was already quite large so 16 cogs got reduced to 8 and 1MB RAM got reduced to 512kB.

    As for XMM, I agree it would be insane for the P2 to execute limp from serial memory although that might be suitable for Spin2 perhaps, but then again a single Spin2 bytecode gets a lot more done than an XMM opcode, so it will never need the extra memory.
  • RossHRossH Posts: 5,334
    We have FPGA P2s that have 1MB or 16 cogs but current silicon couldn't squeeze all that in as the die was already quite large so 16 cogs got reduced to 8 and 1MB RAM got reduced to 512kB.

    Remember Moore's Law? Check again in 18 months :)
  • RossH wrote: »
    We have FPGA P2s that have 1MB or 16 cogs but current silicon couldn't squeeze all that in as the die was already quite large so 16 cogs got reduced to 8 and 1MB RAM got reduced to 512kB.

    Remember Moore's Law? Check again in 18 months :)

    Parallax is already using a fairly old process node, because the price goes up rapidly as the feature geometry shrinks.

    So, less a matter of Moore's Law, and more a feature of supply and demand.
  • Cluso99Cluso99 Posts: 18,066
    Chip was surprised at how much the next geometries had come down. But the ringframe would need to be re-done for 120nm or 90nm and that costs $$$.
    IIRC Chip even mentioned 56nm??? Now that would be a P3 with 2-4MB and 32 cogs at 1+GHz ;)
  • RossHRossH Posts: 5,334
    I have just uploaded Catalina 3.15.3 to SourceForge (https://sourceforge.net/projects/catalina-c/files/releases/3.15.3).

    This is a full release that supports both the P1 and the P2. It includes both Windows and Linux releases, and is intended for those with a P2 EVAL board.

    This release does not add any significant P1 functionality, and is not recommended for those using only a P1, because the P1 support has not been extensively tested (P1 users should continue using release 3.13.2).

    Here are the latest changes (see the README.WhatsNew file for a complete list of all changes since release 3.13.2) ...
    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 3.15.3
    
    1. This is the fourth Propeller 2 release. It is partly an internal "clean
       up" and bug fix release for the previous release (3.15.2), but it also 
       extends the P2 support.
    
    2. Add P2 support for the BlackBox debugger. It now supports TINY (LMMM), 
       COMPACT, and NATIVE modes on the P2. The BlackBox debugger will detect
       the P2 automatically, so it requires no new command-line options. The
       debugger requires a serial port connection to the P2, which (by default)
       is implemented on pins 50 & 52. This allows a PropPlug to be used on the
       P2 EVAL board, plugged on to the top-right I/O pin header.
    
    3. Fixed an issue with BlackBox on both the P1 and P2 that meant in COMPACT
       mode, the contents of register r0 could not be displayed by name (i.e. 
       using a "read r0" command - it could be displayed by saying "read cog 0").
    
    4. Add P2 support for the BlackCat debugger. The BlackCat debugger was 
       originally developed by Bob Anderson, and the functionality is very 
       similar to BlackBox, except that it has a graphical user interface. 
       Note that (unlike BlackBox) BlackCat is provided in binary form only, and
       that BlackCat is a Windows-only application.
    
    5. There is a new "flash_payload" utility, which programs the P2_EVAL Flash
       with an auto-executing version of any Catalina program binary. This is 
       based on the Flash_Loader_1.2.spin2 program developed by ozpropdev. 
    
       The parameters accepted by the flash_payload utility are identical to 
       those for the "payload" utility, except that the first parameter MUST be 
       the filename to be loaded. For example: 
    
         flash_payload startrek -p4 -b230400 -z -i
    
       Note that to program the FLASH on the P2_EVAL, you must first remove any 
       SD Card, and also make sure that the FLASH microswitch is turned OFF, or
       payload will report that it cannot find the P2.
     
       Once programmed, you must turn the FLASH microswitch ON to boot your
       program automatically from FLASH (the P2 may also require a re-boot). 
       Turn it off again to boot from SD Card, or to load programs serially.
    
       Note that FLASH programming sometimes fails. If it does not seem to 
       program correctly, try repeating the procedure. 
     
    6. Fixed some issues with the Catalina Optimizer P2 support that led to 
       some erroneous results or less than optimal optimization.
    
    7. Added P2 clock definitions to catalina_cog.h, and updated the _clockinit(),
       _clockmode() and _clockfreq() functions to work correctly for the P2,
       and a new test program (test_p2_clock.c) in the "demos" folder that
       demonstrates it.
    
    8. Fixed a bug in the HMI plugin that caused some floating point operations
       to fail in programs compiled in CMM (COMPACT) mode.
    
    9. Fixed a bug that prevented the Propeller rebooting on program exit in 
       LMM & CMM modes.
    
    10. Fixed a compiler bug that could lead to incorrect results in some
        circumstances - e.g. when converting floating point values to integers
        and vice-versa. This caused problems with programs like the "paranoia" 
        IEEE floating point test. Catalina now passes this test, with the 
        exception of some lack of precision in the pow() and exp() functions, 
        and some incorrect overflow handling related to "inf" values. These 
        defects should not affect most user programs. 
    
    

    Apart from a dearth of plugins, Catalina support for the P2 is now essentially complete. Unless there are major problems found in this release, I expect it will be the last release intended for the P2 only - I would like to return to having just a single stream of releases for both the P1 and the P2.

    Ross.
  • cgraceycgracey Posts: 14,131
    RossH, that looks excellent.

    I really like the idea of a standard C library, like Eric's proposed. It would be awesome to have two C compilers, out of the gate, which cover the P2's hardware well.

    I'm always behind the curve on C things, so please correct me if my thinking is wrong.
  • RossHRossH Posts: 5,334
    cgracey wrote: »
    RossH, that looks excellent.

    I really like the idea of a standard C library, like Eric's proposed. It would be awesome to have two C compilers, out of the gate, which cover the P2's hardware well.

    I'm always behind the curve on C things, so please correct me if my thinking is wrong.

    Yes, I'll release a version of the new P2 library for Catalina when we have finalized the definitions. Most of the functions are already there - it will just be a matter of tweaking the names etc.
  • Thanks for your efforts guys. I'm not much of a C programmer, but its great that this kind of thing is being considered in advance of the silicon arriving.
  • RossHRossH Posts: 5,334
    I just found a serious problem with Catalina's COMPACT memory model in the latest release. I have temporarily withdrawn it, and will post an amended release soon.

    In the meantime, if you have already downloaded version 3.15.3, do not use the COMPACT memory model!

    Ross.
  • RossHRossH Posts: 5,334
    I've just uploaded release 3.15.4, which replaces the defective 3.15.3 release. You can get it here - https://sourceforge.net/projects/catalina-c/files/releases/3.15.4/

    I hope this is the last P2-only release, so I can get a chance to work on a combined P1 and P2 release!

    Ross.
  • RossHRossH Posts: 5,334
    This will be coming in the next release, but I have found this to be so mind-bogglingly useful already that I thought I would release it early because others may be able to use it to help them test their P2 programs.

    I have added Lua scripting to Catalina's payload program loader. Now with one command you can load a program and then automatically execute a Lua test script to validate that it executes correctly. Of course, the program currently has to use a serial interface to be verified, but I intend to add a similar capability to the Blackbox debugger so that scripts can be written to verify any program.

    The number of modes and compilation options that Catalina supports was already getting crazy on the P1, and with the addition of the P2 the number of different possible compilation options for even a trivial "Hello, World!" type C program is now in the many, many dozens - it may even be in the hundreds.

    Trivial errors had started to slip through my manual testing, so I knew I had to do something!

    Here is a very simple program called "test_lua.c":
    /*
     * A simple program to test payload's new Lua scripting facility.
     *
     * Execute this program with a payload command like the following to 
     * automatically load and start both this program and the Lua script
     * that verifies it generates the correct output:
     *
     *   payload test_lua -z -b230400 -L test_lua.lua
     *
     */
    
    #include <stdio.h>
    
    void main(void) {
       int i;
       char ch;
    
       do {
          ch = getchar();
       } while (ch !='\n');
    
       printf("program done!\n");
    
       while(1) { };
    }
    

    And here is the Lua script ("test_lua.lua") that verifies it executes correctly:
    --
    -- Catalina adds four functions to Lua:
    -- 
    -- delay(milliseconds) : Just delay by the specified number of milliseconds.
    -- 
    -- send(string) : Send a string to the loaded program.
    -- 
    -- receive(count, timeout) : Receive up to 'count' characters from the loaded
    --                           program, with a timeout of 'timeout' milliseconds.
    --                           Reads are terminated by a linefeed, and the 
    --                           characters received are returned as a string.
    --
    -- wait_for(prompt, timeout) : Wait for the 'prompt' to be sent by the loaded
    --                             program. The read is not terminated by a 
    --                             linefeed, but will be terminated after 'timeout'
    --                             milliseconds. If 'prompt' is an empty string, 
    --                             the read will be terminated by any character
    --                             (which will be returned).
    --
    -- NOTE: The script below uses the built-in Lua "error" function to report
    -- errors - this is for testing only, as this immediately terminates the
    -- script. Normally, it would be better to report the errors ourselves and 
    -- then terminate the script a bit more gracefully!
    --
    
    print("\nLua script started\n");
    
    str1 = "Hello from Lua!\n";
    str2 = "";
    
    -- delay a few milliseconds (allows for the loaded program to start)
    delay(250);
    
    -- send a string to the loaded program
    send(str1);
    
    -- receive a string up to 100 characters, with a timeout of 1000 milliseconds
    str2 = receive(100, 1000);
    
    if (str1 == str2) then 
       print("Sent string echoed correctly:", str2);
    else
       error("Sent string NOT echoed correctly");
    end
    
    str1 = "done!"
    str2 = "";
    -- wait for a specified string, with a timeout of 1000 milliseconds
    str2 = wait_for(str1, 1000);
    
    if (str1 == str2) then
       print("Received correct string:", str2, "\n");
    else
       error("Received incorrect string\n");
    end
    
    str2 = wait_for("\n", 1000);
    
    if (str2 == "\n") then
       print("Received expected linefeed character\n");
    else
       error("Received unexpected character\n");
    end
    
    print("Lua script completed - no errors detected!\n");
    

    Here is an example of what you should see:
    C:\>payload test_lua -z -b230400 -L test_lua.lua
    Using Propeller (version 2) on port COM4 for download
    
    Lua script started
    
    Sent string echoed correctly:   Hello from Lua!
    
    Received correct string:        done!
    
    Received expected linefeed character
    
    Lua script completed - no errors detected!
    

    These example files, and a windows binary, is attached.

  • The Lua scripting looks like a very useful feature. I look forward to trying it out!

  • RossHRossH Posts: 5,334
    ersmith wrote: »
    The Lua scripting looks like a very useful feature. I look forward to trying it out!

    Probably most useful for people who build tools for the Propeller, but hopefully also useful for anyone who expect to sell Propeller-based software.
  • jmgjmg Posts: 15,140
    RossH wrote: »
    This will be coming in the next release, but I have found this to be so mind-bogglingly useful already that I thought I would release it early because others may be able to use it to help them test their P2 programs.
    -- Catalina adds four functions to Lua:
    -- delay(milliseconds) : Just delay by the specified number of milliseconds.
    -- send(string) : Send a string to the loaded program.
    -- receive(count, timeout) : Receive up to 'count' characters from the loaded program
    -- wait_for(prompt, timeout) : Wait for the 'prompt' to be sent by the loaded program.
    That's very nifty, can the Lua also reset the P2 and /or download different programs, or is that done in another more-outer shell ?

  • RossHRossH Posts: 5,334
    jmg wrote: »
    RossH wrote: »
    This will be coming in the next release, but I have found this to be so mind-bogglingly useful already that I thought I would release it early because others may be able to use it to help them test their P2 programs.
    -- Catalina adds four functions to Lua:
    -- delay(milliseconds) : Just delay by the specified number of milliseconds.
    -- send(string) : Send a string to the loaded program.
    -- receive(count, timeout) : Receive up to 'count' characters from the loaded program
    -- wait_for(prompt, timeout) : Wait for the 'prompt' to be sent by the loaded program.
    That's very nifty, can the Lua also reset the P2 and /or download different programs, or is that done in another more-outer shell ?

    No, that's easier to do in a batch file.
  • ersmithersmith Posts: 5,898
    edited 2019-07-08 19:49
    @RossH: a question about timing functions. None of the standard C time related functions (time(), clock(), etc.) seem to work on my P2 eval board. Looking at the source it seems that's because I don't have an RTC, which I can understand. It'd be nice if time() had a fallback of using _cnt() to calculate seconds elapsed, but that's a "nice to have". I'm a little more bummed about clock() not working; I would have expected clock() to return processor cycles elapsed, or some fraction of those, rather than relying on an external RTC for timing -- especially if no RTC is present!

    In fact I would have expected clock() to be defined as _cnt(), and CLOCKS_PER_SEC to be defined as _clockfreq(). Is there some reason you didn't do it that way?
  • jmgjmg Posts: 15,140
    ersmith wrote: »
    ...
    In fact I would have expected clock() to be defined as _cnt(), and CLOCKS_PER_SEC to be defined as _clockfreq(). Is there some reason you didn't do it that way?
    That would roll over very often if using 32b, but IIRC P2 can deliver a 64b time, so supporting that would be a useful fallback.
    If P2 is using a TCXO, the precision/stability of that would be very good, and P2 would need some means to get an absolute time reference.
    Some RTC's give a UNIX time (seconds since some date) so that may be another form worth looking at ?
  • jmg wrote: »
    ersmith wrote: »
    ...
    In fact I would have expected clock() to be defined as _cnt(), and CLOCKS_PER_SEC to be defined as _clockfreq(). Is there some reason you didn't do it that way?
    That would roll over very often if using 32b, but IIRC P2 can deliver a 64b time, so supporting that would be a useful fallback.
    If P2 is using a TCXO, the precision/stability of that would be very good, and P2 would need some means to get an absolute time reference.
    Some RTC's give a UNIX time (seconds since some date) so that may be another form worth looking at ?

    The C clock() function doesn't return wall clock time, it returns elapsed processor time in some implementation defined units. The function to return wall time is "time()". "clock()" is often high frequency (microsecond resolution is common) and expected to roll over. It's generally used just for timing pieces of code.
  • RossHRossH Posts: 5,334
    ersmith wrote: »
    @RossH: a question about timing functions. None of the standard C time related functions (time(), clock(), etc.) seem to work on my P2 eval board. Looking at the source it seems that's because I don't have an RTC, which I can understand. It'd be nice if time() had a fallback of using _cnt() to calculate seconds elapsed, but that's a "nice to have". I'm a little more bummed about clock() not working; I would have expected clock() to return processor cycles elapsed, or some fraction of those, rather than relying on an external RTC for timing -- especially if no RTC is present!

    In fact I would have expected clock() to be defined as _cnt(), and CLOCKS_PER_SEC to be defined as _clockfreq(). Is there some reason you didn't do it that way?

    There is a real-time clock plugin that you have to enable by specifying -C CLOCK on the command-line. It is not enabled by default since it takes a cog, but if you are using the SD Card, the clock shares the same cog as the SD card driver.

    Ross.
  • RossHRossH Posts: 5,334
    Catalina 3.16 is now available. There is a separate thread for it here: http://forums.parallax.com/discussion/170388/catalina-3-16-is-now-available
  • iseries wrote: »
    I have never used Catalina or heard of it before. I have always used SimpleIDE.

    How compatible is Catalina to SimpleIDE? Is all the Andy code in it?

    Mike

    What steps should be taken to transfer a SimpleIDE project to Catalina on Code:Blocks?

    Kevin.
  • RossHRossH Posts: 5,334
    kg1 wrote: »
    iseries wrote: »
    I have never used Catalina or heard of it before. I have always used SimpleIDE.

    How compatible is Catalina to SimpleIDE? Is all the Andy code in it?

    Mike

    What steps should be taken to transfer a SimpleIDE project to Catalina on Code:Blocks?

    Kevin.

    I'm not familiar with SimpleIDE. I just did a search, and it seems that might be a Parallax thing? Code::Blocks can import some projects from other tools (e.g. MS Visual Studio projects) but it may be easier just to create a new project from scratch.

    Ross.
  • I have not used Catalina either. I like SimpleIDE as well.

    The problem here is none of the Andy libraries are available here. So none of the code that was previously developed will not work with Catalina. Catalina is its own compiler.

    So if you plan to use any parallax devices such as servos, displays, sensors your out of luck. The Simple Libraries were not imported into the Catalina compiler.

    Mike

  • RossHRossH Posts: 5,334
    iseries wrote: »
    I have not used Catalina either. I like SimpleIDE as well.

    The problem here is none of the Andy libraries are available here. So none of the code that was previously developed will not work with Catalina. Catalina is its own compiler.

    So if you plan to use any parallax devices such as servos, displays, sensors your out of luck. The Simple Libraries were not imported into the Catalina compiler.

    Mike

    Yes, Catalina is a C compiler. What are the "Andy libraries"? If they are written in C code, they should compile.
  • The Simple-libraries are all the code that is needed to talk to any of the Parallax components. All the tutorials and sample code on the Parallaxes site are in there. So to use a Servo360 one only needs to include that library #include "servo360.h" and they are good to go.

    This is also the back bone for the BlocklyProp code development.

    You can find the library here: Simple-Libraries

    There is a lot of custom code there so some of the libraries may need to be modified to work with Catalina.

    Mike
  • @iseries Thank you Mike. I will need to study Catalina and CodeBlocks then take a look at Simple-Libraries. My goal is to use BlackCat debugging. I much appreciate your advice.
    Many thanks to everyone.
    Kevin.
  • RossHRossH Posts: 5,334
    edited 2019-12-08 21:54
    iseries wrote: »
    You can find the library here: Simple-Libraries

    Thanks.

    We're bit busy fighting bushfires (I think you call them "wildfires"?) here in Australia at the moment, but I just had a quick look. It seems to be fairly straightforward C code, so it should be able to be made to work with Catalina.

    I will try compiling the libraries in the next few days. If they need to be modified, I will post a Catalina specific version.

    Ross.
  • @RossH Thank you Ross. That's much appreciated.
    I can remember a time, many years ago, when we in New Zealand received smoke from Australia! So far the wind has not brought the smoke and the red sunsets have not occurred.
    Cheers,
    Kevin.
Sign In or Register to comment.