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

Catalina 3.17 is now available

RossHRossH Posts: 5,336
edited 2019-09-16 05:59 in Propeller 2
I have just uploaded Catalina 3.17 to SourceForge - https://sourceforge.net/projects/catalina-c/

Here is an extract from the README.WhatsNew file:
RELEASE 3.17

1. Added a new floating point maths library (libmc) which uses the P2 built-in
CORDIC solver to allow all the floating point functions to be fitted into a
single cog. It is also much faster than the other floating point options.
The CORDIC library is is selected by specifying -lmc on the command line
(i.e. instead of -lm, -lma or -lmb). This option is only available on the
Propeller 2.

2. Added a new "propeller2.h" header file, and all the functions specified
therein to the standard libraries (libc, libci, libcx, libcix). See the
file propeller2.h in the include directory for more details. This header
file (and associated library funtions) will only compile correctly and run
on the Propeller 2. A new demo subdirectory ("demos\p2") has been created
with programs that test these functions. The P2 clock demo program
"test_p2_clock.c" has also been moved to this subdirectory.

3. On the Propeller 2, Catalina now uses the same locations as Spin to store
the clock mode and frequency (i.e. $14 for clock frequency & $18 for clock
mode). However, note that these are set up AFTER the Propeller program has
been loaded, so the option that some loaders (like 'loadp2') have to change
these values during the load process should NOT be used with Catalina
programs.

4. Added function s4_txcheck() to libserial4, which returns the number of
bytes available in the tx buffer for the port specified. This can be
used to tell whether a call to s4_tx() would block (i.e. if s4_txcheck()
returns 0). The test program in "demos\serial4" has been updated to test
this function, but it requires both a TTY and a TV output. Note that the
4 port serial driver is only available on the Propeller 1.

5. Fixed a bug in the 4 port serial driver - unused ports were not being
initialized, and so could interfere with the used ports or cause memory
corruptions. Also, updated the driver to incorporate some CTS/RTS handling
bug fixes by the original author. Note that the 4 port serial driver is
only available on the Propeller 1.

6. Added support for executing XMM code from EEPROM on the Propeller 1, which
is enabled via the XEPROM command-line symbol. The resulting programs can
then be loaded using the EEPROM option to payload, once the utilities have
been built for your platform. The XEPROM option is IN ADDITION to any other
XMM option you have on your platform, and works on any Propeller with an
EEPROM larger than 32Kb.

XEPROM is only supported for the SMALL memory model (i.e. code in EEPROM,
data in Hub RAM) and also requires the use of the cache.

For example, if you have a QuickStart board, after you have used the
"build_utilities" batch file to build the EEPROM loader, you can compile,
load and execute the "othello.c" program as XMM executed from EEPROM by
using the following commands:

catalina othello.c -lc -C TTY -C QUICKSTART -C SMALL -C XEPROM -C CACHED
payload EEPROM othello.binary -i

For more information, see the XEPROM_README.TXT file in the "target"
subdirectory.

7. On the Propeller 2, once initialization is complete and the C code is
executing, only the upper half of the LUT is now used (to hold common
library code). This means that the lower half of the LUT (i.e. Cog address
$200 - $2FF) is available for C applications to use for any purpose if
required.

Unless someone finds some serious bugs, I am hoping this will be the last release I need to do for a while. I would like to get some time to go back and update the documentation, which has (as yet) only had a very cursory update for the Propeller 2!

Comments

  • cgraceycgracey Posts: 14,133
    Very nice, RossH!

    Have you and Eric Smith done any comparisons between runtime speeds and memory footprints for some benchmarks? It would be interesting to see how they differ.

    Long term, it would be good if there was some agreement among C compilers on conventions. I know there have been a few threads about this. Ultimately, it would be great to have enough standardization among the C compilers that a set of source files could be used with any of them. That may not be realistic, entirely, but some solid common ground would suffice.

    Sorry if my comments seem out-to-lunch. I'm behind the curve on some things.
  • Cluso99Cluso99 Posts: 18,066
    That was way quicker than I though Ross. Congratulations :smiley:
  • Shameless plug.

    You don't have a 4 port serial driver for the P2, I can at least offer you a 2 port driver.

    There is a lot of spin code around it, but basically the PASM part is self contained (buffer are in the LUT) and works alike the cogserial PASM driver you already looked at. Needs some Mailbox area in the HUB.

    Mike

  • RossHRossH Posts: 5,336
    msrobots wrote: »
    Shameless plug.

    You don't have a 4 port serial driver for the P2, I can at least offer you a 2 port driver.

    There is a lot of spin code around it, but basically the PASM part is self contained (buffer are in the LUT) and works alike the cogserial PASM driver you already looked at. Needs some Mailbox area in the HUB.

    Mike

    Hi Mike.

    I already use your cogserial 2 port driver! But the acknowledgement seems to have been lost - I will add it back when I update the documentation.

    But I have to admit I have been lazy in not providing a C library to access the second port. I will do so in a forthcoming release.

    Ross.
  • RossHRossH Posts: 5,336
    cgracey wrote: »
    Very nice, RossH!

    Have you and Eric Smith done any comparisons between runtime speeds and memory footprints for some benchmarks? It would be interesting to see how they differ.

    Long term, it would be good if there was some agreement among C compilers on conventions. I know there have been a few threads about this. Ultimately, it would be great to have enough standardization among the C compilers that a set of source files could be used with any of them. That may not be realistic, entirely, but some solid common ground would suffice.

    Sorry if my comments seem out-to-lunch. I'm behind the curve on some things.

    Hi Chip

    I have not done any benchmarking. Still too busy adding functionality. There's some internal work I'd like to do on Catalina's code generator before benchmarking would be very meaningful. So far, this exercise has been pretty much a straight port of the P1 version of Catalina to the P2, and I haven't really taken advantage (yet!) of much of the the new P2 functionality.

    However, Eric and I have at least agreed on the "propeller2.h" file and associated library functions. Porting straight C code from one compiler to the other should be reasonably routine.

    Ross.
  • RossHRossH Posts: 5,336
    I guess I should point out that Catalina 3.17 was not intended to be a major release. I really only released this version because @Wingineer19 wanted the s4_txcheck() function and the XEPROM support, so I figured that (along with the CORDIC support and the propeller2.h support) there was enough new functionality to warrant a release.

    I intend Catalina 4.0 to be the first new major release, once I have updated all the documentation.
  • msrobotsmsrobots Posts: 3,701
    edited 2019-09-17 01:09
    cgracey wrote: »
    Very nice, RossH!

    Have you and Eric Smith done any comparisons between runtime speeds and memory footprints for some benchmarks? It would be interesting to see how they differ.

    Long term, it would be good if there was some agreement among C compilers on conventions. I know there have been a few threads about this. Ultimately, it would be great to have enough standardization among the C compilers that a set of source files could be used with any of them. That may not be realistic, entirely, but some solid common ground would suffice.

    Sorry if my comments seem out-to-lunch. I'm behind the curve on some things.

    The same goes for SPIN compilers. Since FastSpin is already there and has some nice added features it would be nice if your SPIN would agree with @ersmith version.

    Eric is doing a fantastic job there and will obviously follow your implementation, but maybe your two should talk to agree on sensible ways to name and handle things.

    Because Eric is doing the dance between SPIN and C so in Princip YOU need to agree to them C conventions too so that porting from SPIN to C or C to SPIN will be made more easy.

    That may not be realistic, entirely, but some solid common ground would suffice.

    Enjoy!

    Mike
  • msrobotsmsrobots Posts: 3,701
    edited 2019-09-17 04:37
    RossH wrote: »
    msrobots wrote: »
    Shameless plug.

    You don't have a 4 port serial driver for the P2, I can at least offer you a 2 port driver.

    There is a lot of spin code around it, but basically the PASM part is self contained (buffer are in the LUT) and works alike the cogserial PASM driver you already looked at. Needs some Mailbox area in the HUB.

    Mike

    Hi Mike.

    I already use your cogserial 2 port driver! But the acknowledgement seems to have been lost - I will add it back when I update the documentation.

    But I have to admit I have been lazy in not providing a C library to access the second port. I will do so in a forthcoming release.

    Ross.

    OK.

    I charge you the same as you charge for Catalina. This is my current version, I added optional echo on input for inputting strings.

    Use it as you wish, consider it MIT but I really do not care. It is out there and working nicely. The PASM part was heavily inspired by jdserial a full in one COG buffered driver for the P1, offering a SPIN and a PASM interface.

    What a relive as I found that one. simple debug out of my PASM code!

    So FullDuplexSerial2.spin2 is the SPIN shell around it to run nicely with FastSpin, the driver itself can just be called from PASM also.

    What I am personally proud of is that I got the async functions working, so you can tell the driver 1 to send HUB from1-size1 and while this is happening the command interface and the second port are not blocked.

    Mike
  • msrobots wrote: »
    cgracey wrote: »
    Long term, it would be good if there was some agreement among C compilers on conventions. I know there have been a few threads about this. Ultimately, it would be great to have enough standardization among the C compilers that a set of source files could be used with any of them. That may not be realistic, entirely, but some solid common ground would suffice.

    Sorry if my comments seem out-to-lunch. I'm behind the curve on some things.

    The same goes for SPIN compilers. Since FastSpin is already there and has some nice added features it would be nice if your SPIN would agree with @ersmith version.

    Spin is Chip's baby completely and I'll follow his lead when it comes to language features. Obviously fastspin does have some extensions to Spin and if Chip likes some of those he's welcome to use them, but there are some that probably would be difficult and perhaps not make sense in an interpreter.

    The main thing to me, compatibility wise, is that it would be nice if Spin2 were compatible with Spin1 as much as possible -- that would both make it easier to support Spin2 in fastspin, and also make it easier for all the people who want to port their code from P1 to P2. But again, that's ultimately up to Chip. If the two languages diverge so much that it's hard to support both in the same tool then I could just stick to Spin1 compatibility in fastspin, but I really doubt that's going to happen.

  • cgracey wrote: »
    Have you and Eric Smith done any comparisons between runtime speeds and memory footprints for some benchmarks? It would be interesting to see how they differ.
    I've compared all 4 of the C compilers currently available for P2. They're all still under heavy development so it probably doesn't make sense to post exact numbers, but here are my overall impressions. I'm not an impartial observer, so others may have different impressions :). I should also point out that all of the compilers should have decent performance when generating native code.

    Catalina has the potential to output the smallest code (with its CMM mode) and should have pretty good floating point performance. It's based on the LCC compiler, which is somewhat weak in terms of general optimization, so on integer benchmarks it'll probably not do quite as well. Catalina's pretty mature and has a good set of libraries and documentation.

    fastspin has good knowledge of the P2 and will probably turn in the best numbers on bitbanging benchmarks. It's optimizer will fall behind GCC's on larger more sophisticated benchmarks, but will still be a little better than Catalina on those. It doesn't currently have a CMM mode, so it will do mediocre on code size benchmarks. fastspin's C support is still pretty experimental and not really ready for production.

    p2gcc has pretty good performance on most benchmarks; a little weaker than fastspin on some bit-banging, but much better on general integer. It's based on an older GCC so it won't do quite as well as riscvp2 on general optimization. It has no CMM and generates has the largest code of all 4 compilers. p2gcc has fairly good library coverage but is still missing a few things.

    riscvp2 always generates compressed instructions, so it has pretty small code (it'll be interesting to compare with Catalina's CMM, I haven't really looked at that yet). It's got a JIT compiler internally that produces pretty good code, and it's won more benchmarks than any of the other compilers, so overall performance is very good thanks to the modern GCC optimizer. But the JIT does introduce latency, and code that overflows the cache can perform poorly. riscvp2 has solid library and tools, but interfacing PASM to it is awkward.
    Long term, it would be good if there was some agreement among C compilers on conventions. I know there have been a few threads about this. Ultimately, it would be great to have enough standardization among the C compilers that a set of source files could be used with any of them. That may not be realistic, entirely, but some solid common ground would suffice.
    Definitely, and I think we've made a good start with the propeller2.h header file. Ross has probably got the most mature implementation of this, so I'll try to catch up with what he's done.

  • cgraceycgracey Posts: 14,133
    Great update, Ersmith! That's amazing that there are four C compilers in the works. Who'd have thought?
  • actually 5 @ntosme2 is working on getting the newest version of GCC running, so 5 C compiler, 2 BASIC, 2 SPIN, FORTH, PHYTON so currently we have about a language for every 10 boards out.


  • RossHRossH Posts: 5,336
    I guess I should have anticipated this! :)

    Parallax kindly just sent me a RevB P2 EVAL board which arrived yesterday, and of course the first thing I realized was that my payload loader was looking specifically for "Prop_Ver A" whereas the new P2 chip sends "Prop_Ver G" - very simple to fix, and I will post a patch shortly.

    However, of more concern is that everything else seems to work except for the SD Card. Before I start diving in to find out why, are there any known differences between the SD Card circuitry of the RevA and the RevB boards?

  • Cluso99Cluso99 Posts: 18,066
    edited 2019-09-19 05:29
    RossH wrote: »
    I guess I should have anticipated this! :)

    Parallax kindly just sent me a RevB P2 EVAL board which arrived yesterday, and of course the first thing I realized was that my payload loader was looking specifically for "Prop_Ver A" whereas the new P2 chip sends "Prop_Ver G" - very simple to fix, and I will post a patch shortly.

    However, of more concern is that everything else seems to work except for the SD Card. Before I start diving in to find out why, are there any known differences between the SD Card circuitry of the RevA and the RevB boards?
    Ross,
    The RevB should do better at releasing the DO pin (the SD card drives this pin). There are some changes to hopefully make this more robust with timeouts etc.
    Of course you'll need to have the pullup on P61 disabled (the Flash CS pin) or otherwise it will boot from the Flash and not the SD.

    I am presuming you are using the same microSD that works on the RevA board?

    And what brand/size/class? Presume it's formatted as FAT32?
  • RossHRossH Posts: 5,336
    Cluso99 wrote: »
    Ross,
    The RevB should do better at releasing the DO pin (the SD card drives this pin). There are some changes to hopefully make this more robust with timeouts etc.

    Software changes, or hardware changes?
    Of course you'll need to have the pullup on P61 disabled (the Flash CS pin) or otherwise it will boot from the Flash and not the SD.

    Makes no difference. I am not booting from the SD Card, just trying to read it after boot, using code that worked on RevA.
    I am presuming you are using the same microSD that works on the RevA board?

    And what brand/size/class? Presume it's formatted as FAT32?

    Yes, same card which works reliably on RevA (and still works - I just tried it!). A SanDisk 8Gb, formatted as FAT32.

  • RossHRossH Posts: 5,336
    RossH wrote: »
    Makes no difference. I am not booting from the SD Card, just trying to read it after boot, using code that worked on RevA.

    An update: I can boot from this SD card! I just can't read from the card when I load the same program serially.

    Now that I come to think about it, I had the same problem on the RevA board at one stage... but I can't remember how I solved it :(
  • RossHRossH Posts: 5,336

    Aha! ok - my bad! I had not noticed that the boot mode configuration switches are mounted upside down compared to the Rev A board!

    All working correctly now! I think I may need new glasses :)
  • Cluso99Cluso99 Posts: 18,066
    edited 2019-09-19 06:58
    <sigh of relief> It's not the boot code.

    So what SD code are you using?

    BTW While slower, you can use the ROM code as hubexec routines, but alas, there is no write routine as there was no room in the ROM so it had to go.
    Meanwhile, I'm adding the ticks we learnt over the past year to the code ;)
  • RossHRossH Posts: 5,336
    Cluso99 wrote: »
    So what SD code are you using?

    Yours! :)

    I stole it out of your boot rom code, but I only use the Sd_Init, ReadSector and WriteSector routines. DOSFS does the rest.

  • RossHRossH Posts: 5,336
    Here is the patch release to update to Catalina 3.17.1 - it contains both Windows and Linux files, and should be unzipped over an existing 3.17 release. It is only relevant to Propeller 2 users.

    Here is the relevant portion of README.WhatsNew:
    RELEASE 3.17.1
    
    1. Updated payload.c, payload.exe (Windows binary) & payload (Linux binary) 
       to accept any version of the Propeller 2. The previous version only 
       accepted "Prop_Ver A"
    
    2. Update cogserial.pasm to the latest version. This caused a name conflict
       with BlackCat_DebugCog.Spin2, so that file has been updated as well.
    
    3. Recompiled the Catalyst binaries in P2_EVAL.ZIP to use the latest version
       of cogserial.pasm.
    
    
  • Cluso99Cluso99 Posts: 18,066
    RossH wrote: »
    Cluso99 wrote: »
    So what SD code are you using?

    Yours! :)

    I stole it out of your boot rom code, but I only use the Sd_Init, ReadSector and WriteSector routines. DOSFS does the rest.
    Do you mean from the P1?
    There is no WriteSector routine in either P2 ROM :(
    But I have it if you need it :)
  • RossHRossH Posts: 5,336
    Cluso99 wrote: »
    Do you mean from the P1?
    There is no WriteSector routine in either P2 ROM :(
    But I have it if you need it :)

    No, it's definitely P2 code. Maybe it wasn't from the ROM, but I think it was code you wrote with that in mind.

    See the attached plugin, which contains the code (lines 497 onwards). I may have modified it slightly - I don't recall.



  • Cluso99Cluso99 Posts: 18,066
    Yes, it's my code, but quite old and before I had to strip it down.
  • RossHRossH Posts: 5,336
    Cluso99 wrote: »
    Yes, it's my code, but quite old and before I had to strip it down.

    Hi Cluso

    I just found a problem in this SD code - but you may have already fixed it in a later release, in which case ignore this post!

    According to the SD Card spec, it is required that you send 8 clocks before shutting down the clock after each data read or write transaction. Failing to do so can lock up the SD Card, requiring a power cycle. To fix it in this case, all you need to do is add a call #_recvbyte statement before disabling CS in each of the _readBlock and _writeBlock functions.

    I have no idea why the existing code works reliably on RevA (with Prop_Ver A) but not on RevB (with Prop_Ver G), but I have verified this is the case. After adding 8 clocks before disabling CS, I now have my SD Card plugin working reliably again on RevB.

    This is a minor irritation, because everything works correctly again after a reset, but I will post a new patch release once I complete some more testing.
  • Which card or cards are you testing with, Ross?
  • Ah sorry you mention a sandisk 8gb. Is it red and grey ("silver") or red and gold, or some other ?

    When I was testing the gold card it seemed to like an extra clock, however the grey variant was ok without that extra clock. I think Cluso tested with the red and grey variant mainly, but that particular one doesn't really show up the fault
  • RossHRossH Posts: 5,336
    Tubular wrote: »
    Ah sorry you mention a sandisk 8gb. Is it red and grey ("silver") or red and gold, or some other ?

    When I was testing the gold card it seemed to like an extra clock, however the grey variant was ok without that extra clock. I think Cluso tested with the red and grey variant mainly, but that particular one doesn't really show up the fault

    My card is just grey. It just says "Sandisk 8GB MicroSD HC"
  • Cluso99Cluso99 Posts: 18,066
    Yes I was aware of that Ross. The ROM code does it a different way tho.
  • RossHRossH Posts: 5,336
    Another patch to release 3.17, which affects the Propeller 2 only.

    Patch release 3.17.2 fixes a potential problem with Catalina's clock support. This patch also incorporates all the changes previously released in patch 3.17.1, and is suitable for both Linux and Windows installations ...
    RELEASE 3.17.2
    
    1. Updated Catalina_SD_Plugin.Spin2, to fix a potential problem when both
       the clock and the SD card are used intensively - in such cases, the clock 
       may not have had a chance to be updated, leading to the time being out
       of date. This only affected the Propeller 2.
    
    2. Updated the "test_p2.c" program in the demos\p2 directory, to fix a 
       potential lockup when testing the locks.
    
    

Sign In or Register to comment.