parallaxinc / propgcc

A Port of GCC to the Parallax Propeller

This is a project for the port of GCC (the GNU Compiler Collection) to the Parallax Propeller.

Please use the Makefile to build Propeller GCC.

To build from scratch use: $ make

All the files will be placed in a ../build directory. You can also build individual components, e.g "make gdb" to build gdb.

Cross compilation from Linux to Windows or Raspberry Pi is also supported by the Makefile, e.g. "make CROSS=win32" or "make CROSS=rpi". See README.cross for more details.

Output is placed in /opt/parallax by default (/opt/parallax-win32 or /opt/parallax-rpi for cross compiles). You can change this by saying "make PREFIX=".

---

Directory organization is as follows:

binutils - binutils 2.23.1 (complete) plus propeller changes demos - some demos for the compiler (see below) doc - some propeller specific library documentation gcc - gcc 4.6.1 (complete) plus propeller changes gdb - gdb 7.3.1 plus propeller changes gdbstub - interface between gdb and the propeller lib - propeller libraries loader - propeller-load serial loader and communications program ncurses - terminal library; needed to build gdb on Raspberry Pi newlib - a different C library (not currently used) spin2cpp - a tool to convert Spin programs to C or C++ spinsim - Dave Hein's Propeller simulator

--------------------------- demos ---------------------------------

A number of demos are provided. In each directory there should be a Makefile. To build the demo do "make"; to run it do "make run".

Of particular interest is the demo/toggle directory, containing a number of different ways of toggling an LED, using one or multiple COGs.

--------------------------- test suites ---------------------------------

Copy the contents of propgcc/dejagnu to /opt/parallax/share/dejagnu.

Set the environment variable DEJAGNU to /opt/parallax/share/dejagnu/site.exp.

If you are not using a C3 board, edit /opt/parallax/share/dejagnu/board/propeller-sim.exp to reflect the actual board you are using. The propeller-load options are given in the line that reads: set_board_info sim,options "-bc3 -r -t -q" Modify the command line to whatever you need to run XMM programs with propeller-load on your system.

Make sure that your Propeller board is connected and turned on, then in build/gcc, do: make check-gcc RUNTESTFLAGS="--target_board=propeller-sim"

--------------------------- .pdf documentation --------------------------

in build/gcc do: make pdf make install-pdf

This will copy various .pdf files to the /opt/parallax/share/doc directory. The ones in the root of that directory (gmp.pdf, libiberty.pdf, libquadmath.pdf, mpc.pdf, and mpfr.pdf) are not really interesting, since they are for libraries used in building the compiler.

The ones in the gcc/ subdirectory, in particular gcc/cpp.pdf and gcc/gcc.pdf, are the "real" compiler documents. They do have some propeller specific information in them, although more is needed.

propgcc's Issues

l modifier (for long) does not work with scanf functions

No modifier with l in it (e.g. %lx or %lc) works correctly in scanf. The 'l' 
character is picked up in the code as the type rather than subtype. This 
appears to be a code generator problem -- it happens only when the optimization 
is -Os. If vfscanf.c is compiled with -O or -O2 it works correctly.

Original issue reported on code.google.com by [email protected] on 24 Nov 2011 at 8:48

Build fails on F16 (GCC-4.6.2)

Another "set but not used" error in tc-propeller.c

gcc -DHAVE_CONFIG_H -I. -I../../../propgcc/binutils/gas  -I. 
-I../../../propgcc/binutils/gas -I../bfd -I../../../propgcc/binutils/gas/config 
-I../../../propgcc/binutils/gas/../include -I../../../propgcc/binutils/gas/.. 
-I../../../propgcc/binutils/gas/../bfd 
-DLOCALEDIR="\"/usr/local/propeller/share/locale\""  -W -Wall 
-Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -g -O2 -MT 
tc-propeller.o -MD -MP -MF .deps/tc-propeller.Tpo -c -o tc-propeller.o `test -f 
'config/tc-propeller.c' || echo 
'../../../propgcc/binutils/gas/'`config/tc-propeller.c
../../../propgcc/binutils/gas/config/tc-propeller.c: In function 
‘md_assemble’:
../../../propgcc/binutils/gas/config/tc-propeller.c:999:11: error: variable 
‘xd’ set but not used [-Werror=unused-but-set-variable]
cc1: all warnings being treated as errors

Original issue reported on code.google.com by [email protected] on 7 Dec 2011 at 3:40

Wrong bstc binary called while making demos

demos/common/common.mk seems to default to bstc.osx. Created symlink as 
workaround.

[root@Dell demos]# make
...
make[1]: Entering directory `/root/demos/TV/TvText_demo'
propeller-elf-gcc -Os -mlmm -o TvDemo.o -c TvDemo.c
propeller-elf-gcc -Os -mlmm -o TvText.o -c TvText.c
bstc.osx -ls -Ox -c -o TV TV.spin
make[1]: bstc.osx: Command not found
make[1]: *** [TV.dat] Error 127
make[1]: Leaving directory `/root/demos/TV/TvText_demo'
make: *** [all] Error 2

Original issue reported on code.google.com by [email protected] on 17 Nov 2011 at 9:30

eeprom-first should be loader-first

The configuration variable "eeprom-first" should be renamed to "loader-first" 
to avoid confusion. That option is only really useful when using the eeprom 
cache driver so both the loader and the user's program are written to eeprom. 
This makes "eeprom-first" ambiguous. Does it mean to write the loader first or 
the user's program first. It would be better if it was called "loader-first" to 
make this clear.

Original issue reported on code.google.com by [email protected] on 2 Apr 2012 at 11:38

QuickStart board spits random characters at program end.

What steps will reproduce the problem?
1. Compile/load hello program such as included below.
2. Watch terminal after program finishes.
3. Notice extra garbage characters at program end.

#include <stdio.h>

int main(int argc, char* argv[])
{
    printf("Hello world\n");
    return 0;
}

Original issue reported on code.google.com by [email protected] on 11 Nov 2011 at 11:58

XMM Cache and Library SD Access - both hog the SPI/I2C bus

Most of the XMM cache drivers and the library SD card access routines use 
either the SPI or I2C bus.  These agents just grab the bus whenever they need 
it, with no regard for any asynchronous agents that may need access to the bus.

In general, if all access to these buses is via a C thread in XMM mode and in 
hub memory, then there are no issues.  However there are two troublesome 
scenarios:

A) If two competing LMM C threads try to access the SPI bus (directly, or 
indirectly through the SD card routines).

B) If an asynchronous agent (such as a PASM cog) tries to access a SPI or I2C 
device (e.g. such as the SPI ADC on the C3 or the I2C RTC on the PDB), then 
that access will interfere with the XMM cache or the SD routines and very bad 
failures ensue.

Original issue reported on code.google.com by [email protected] on 2 Apr 2012 at 4:09

Propeller-GCC build fails on Fedora Core 15 x64

Please see Alpha Test post.
http://forums.parallax.com/showthread.php?135710-Loader-Bug-Fixed&p=1050152&view
full=1#post1050152

Original issue reported on code.google.com by [email protected] on 9 Nov 2011 at 4:52

propeller-load windows terminal misbehaves if port disconnected while running

What steps will reproduce the problem?
1. load and run program $ propeller-load -r -t program.elf
2. pull plug on serial port without stopping program

What is the expected output? What do you see instead?

Terminal should shut down on error. Instead we get an infinite loop of this 
output:

Error reading port
    Access is denied.


Error reading port
    Access is denied.


Please use labels and text to provide additional information.

Program should exit with non-zero return on error.
Need to check if a similar problem happens with other platforms.

Original issue reported on code.google.com by [email protected] on 2 Nov 2011 at 4:52

Demos should use bstc.osx on Mac

What steps will reproduce the problem?
1. cd propgcc/demos
2. make

What is the expected output? What do you see instead?
Successful build. Failed build.

Please use labels and text to provide additional information.

Original issue reported on code.google.com by [email protected] on 24 Mar 2012 at 12:37

Definition of waitcnt(a) broken in propeller.h

What steps will reproduce the problem?

1. Create test.c with the following contents:

#include <stdio.h>
#include <propeller.h>

void main()
{
    register unsigned long t1, t2, t3, t4;

    // Wait a couple of secs for the terminal mode to fully kick in
    waitcnt(CNT + (CLKFREQ << 1));
    printf("Hello\n");

    t1 = CNT;
    t2 = t1 + 10000;
    t3 = waitcnt(t2);
    t4 = CNT;

    printf("t1, t2, t3, t4 = %10u %10u %10u %10u\n", t1, t2, t3, t4);
}

2.  Compile and run it with the following commands:

propeller-elf-gcc -O2 -mfcache  -mlmm -o test.o -c test.c
propeller-elf-gcc -mlmm -fno-exceptions -fno-rtti -o test.elf test.o -s
propeller-load -b <yourboard> test.elf -r -t


What is the expected output? What do you see instead?

Expected something like this:

[ Entering terminal mode. Type ESC or Control-C to exit. ]
Hello
t1, t2, t3, t4 = 3586977037 3586987037 3586987037 3586987149

But got something like this:

[ Entering terminal mode. Type ESC or Control-C to exit. ]
Hello
t1, t2, t3, t4 =  139379025  139389025  278768114  139389137

Notice that t3 is should be the same as t2 (it should be the clock at the time 
the waitcnt woke up) but instead is effectively t1 + t2 plus a 64 cycles or so. 
 This value is *completely useless*.


What version of the product are you using? On what operating system?

propgcc-0.2.2


Please provide any additional information below.

This problem is caused by an incorrect definition in lib\include\propeller.h.

Change:

#define waitcnt(a) __builtin_propeller_waitcnt((a),_CNT)

To:

#define waitcnt(a) __builtin_propeller_waitcnt((a),0)

Original issue reported on code.google.com by [email protected] on 28 Jan 2012 at 11:35

propeller-load dumps help with -P option

What steps will reproduce the problem?
1. propeller-load -P

What is the expected output? What do you see instead?
Expect only a port list. Also see help.

Please use labels and text to provide additional information.

Original issue reported on code.google.com by [email protected] on 17 Mar 2012 at 4:15

Duplicate symbol, undefined reference in library

What steps will reproduce the problem?

1. Enter the following "standard" C++ program:

#include <iostream>

int main()
{
    std::cout << "Hello World\n";
}

2. Compile with the following commands:

propeller-elf-g++ -g -Os -mfcache -save-temps -mxmmc -fno-exceptions -fno-rtti 
-o main.o -c main.cpp
propeller-elf-g++ -Xlinker -Map=main.rawmap -mxmmc -o main.elf main.o


What is the expected output? What do you see instead?

Expected: No Error
Instead Received:

c:/users/ted/documents/propgcc/propgcc-0.2.2/bin/../lib/gcc/propeller-elf/4.6.1/
../../../../propeller-elf/lib/xmmc\libc.a(rdwr.o): In function `_write':
(.text+0x98): multiple definition of `_write'
c:/users/ted/documents/propgcc/propgcc-0.2.2/bin/../lib/gcc/propeller-elf/4.6.1/
../../../../propeller-elf/lib/xmmc\libc.a(write.o):(.text+0x0): first defined 
here
c:/users/ted/documents/propgcc/propgcc-0.2.2/bin/../lib/gcc/propeller-elf/4.6.1/
../../../../propeller-elf/lib/xmmc\libstdc++.a(basic_file.o): In function 
`.LVL35':
c:\src\build\gcc\propeller-elf\xmmc\libstdc++-v3\src/basic_file.cc:228: 
undefined reference to `_fdopen'


What version of the product are you using? On what operating system?

propgcc-0.2.2 and propgcc-0.2.3 (Windows)


Please provide any additional information below.

The first error is caused by duplicate "write()" definitions in 
lib/stdio/write.c and lib/misc/rdwr.c.  This could easily cause problems in 
other programs (i.e. "saner" programs that don't use C++ <iostream>).

The second error is caused by "fdopen()" being used by 
gcc/libstdc++-v3/config/io/basic_file_stdio.cc (I think that's the right file) 
and not being present in libc.a.  This error is probably limited to programs 
that try to use C++ <iostream> (which is not necessarily wise on the Propeller).

Original issue reported on code.google.com by [email protected] on 9 Feb 2012 at 7:24

rebuild.sh fails on Fedora 16

What steps will reproduce the problem?
1.run ./rebuild.sh

What is the expected output? What do you see instead?

checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... no
checking how to hardcode library paths into programs... immediate
checking for shl_load... configure: error: Link tests are not allowed after 
GCC_NO_EXECUTABLES.
make[1]: *** [configure-target-libstdc++-v3] Error 1
make[1]: Leaving directory `/usr/local/src/build/gcc'
make: *** [all] Error 2
gcc make all failed

What version of the product are you using? On what operating system?
Fedora 16
  kernel-.1.1-1.fc16.x86_64
  gcc-4.6.2-1.fc16.x86_64
  make-3.82-8.fc16.x86_64
  glibc-2.14.90-14.x86_64

Original issue reported on code.google.com by [email protected] on 17 Nov 2011 at 3:56

Documentation correction/clarification for the Propeller GCC Library documentation

Two corrections/clarifications for the Propeller GCC Library documentation at 
http://propgcc.googlecode.com/hg/doc/Library.html:

The page references _simple_printf, but the routine is actually named 
__simple_printf (two leading underscores) in both the header file and library 
code.  This should be fixed in either the code or (more likely) in the 
documentation.

The following note (IMHO) would be a useful addition at the end of the "Simple 
Serial Driver (Prefix SSER:)" section:

Note that because the Simple Serial Driver runs completely in the local cog, it 
shares the cog's DIRA and OUTA register with the calling code.  Therefore, 
avoid overwriting the DIRA/OUTA bits corresponding to the Simple Serial 
Driver's TX and RX pins.  You can do this when setting or clearing bits for 
other I/O devices by using bit-setting and bit-masking instead of direct 
assignment (e.g. DIRA |= 3 or DIRA &= ~3 instead of DIRA = 3 or DIRA = 0).  
This is always a good idea, but failing to do this in any code that uses the 
Simple Serial Driver will result in unpredictable I/O.

Original issue reported on code.google.com by [email protected] on 29 Jan 2012 at 4:40

Program load size is bigger than necessary

What steps will reproduce the problem?
1. compile demos/pong
2. load program
3. note load size

What is the expected output? What do you see instead?
load size should be about 2K. instead it's 21K

Please use labels and text to provide additional information.

Original issue reported on code.google.com by [email protected] on 30 Mar 2012 at 4:38

User would like S2 board type.

There is no S2.cfg board type in the distribution. S2 is HUB type with extra 
peripherals.

Original issue reported on code.google.com by [email protected] on 3 Jul 2012 at 12:33

LoadSDDriver should be folded into dfs_mount

Dave Hein posted this message in the GCC Developer's Forum:

If we do this, we should also merge the calls to LoadSDDriver and dfs_mount 
into one routine. One of the things on my TODO list was to replace dfs_mount 
with the standard mount routine.


Additional information:

This is 100% the right thing to do.  It is useless to call LoadSDDriver() 
unless you intend to call dfs_mount().

On the other hand, the generic mount(2) routine is so Unix-specific that it 
does not make sense to try to "emulate" that call.  Particularly if you try to 
emulate it by allowing users to pass string parameter lists and then decode 
them; this is bad because we are completely out of memory in the 
demo/c3files/lmm case.

Original issue reported on code.google.com by [email protected] on 1 Apr 2012 at 5:59

input does not recognize carriage return

What steps will reproduce the problem?
1. launch a program that reads input from stdin
2. using a terminal other than propeller-load, try to enter text
3. notice that carriage return does not terminate the line, but ctrl-J does

Seems to be a bug in drivers/terminal.c.

Original issue reported on code.google.com by [email protected] on 24 Nov 2011 at 5:54

COG mode printf end of line problem.

What steps will reproduce the problem?
1. make hello.c file

#include <stdio.h>
#include <propeller.h>
int main(void)
{
    int n = 0;
    /* loop forever */
    while(1) 
    {   /* use waitcnt so program will fit in a COG */
        waitcnt(CLKFREQ+CNT);
        printf("Hello World %d\n", n);
        n++;
    }
    return 0;
}

2. propeller-elf-gcc -mcog -Os hello.c; propeller-load -r -t a.out
3. load and run

What is the expected output? What do you see instead?

Expected:
propeller-elf-gcc -mlmm -Os hello.c; propeller-load -r -t a.out
[ Entering terminal mode. Type ESC or Control-C to exit. ]
Hello World 0
Hello World 1
Hello World 2

See:
propeller-elf-gcc -mcog -Os hello.c; propeller-load -r -t a.out
[ Entering terminal mode. Type ESC or Control-C to exit. ]
�Hello World 0
              Hello World 1
                           Hello World 2

Please use labels and text to provide additional information.

Original issue reported on code.google.com by [email protected] on 14 Feb 2012 at 10:07

immediate constants not loaded properly in -mcog mode

The code

long long foo() { return 0x123456789abcdef0; }

produces the following assembly under options -mcog -Os:

    .text
    .balign 4
    .global _foo
_foo
    mov r0, .LC0
    rdlong  r1, .LC1
    jmp lr
    .balign 4
.LC0
    long    -1698898192
    long    305419896
    .balign 4
.LC1
    long    .LC0+4

The rdlong is incorrect; it should be "mov r1, .LC0+4".

Original issue reported on code.google.com by [email protected] on 13 Jun 2012 at 12:39

Propeller Loader fails to autodetect port

What steps will reproduce the problem?

1. Bluetooth serial ports enumerated, no bluetooth serial device attached 
2. In Windows, execute the loader without specifying a "download-to" COM port.


What is the expected output? What do you see instead?

The loader hangs, displaying no output.  Ctrl+c to terminate the program and 
return back to the shell terminal.  


What version of the product are you using? On what operating system?

Latest version of PropGCC.  Unknown loader version (whichever comes with the 
latest downloadable package).  Running on Windows 7 Pro x64.

executing the command "propeller-load -P" to list available ports returns this:

COM1
COM23
COM25
COM40
COM22
COM24
COM39
Standard Modem over Bluetooth link
COM142


COM142 has the Propeller on it.

Original issue reported on code.google.com by [email protected] on 22 Feb 2012 at 11:27

Off-by-one Error in FDSerial Driver Prevents Useful Initialization Via freopen()

1. Create a simple program (test.c):

#include <stdio.h>
#include <driver.h>

extern _Driver _SimpleSerialDriver;
extern _Driver _FullDuplexSerialDriver;
_Driver *_driverlist[] = {
  &_SimpleSerialDriver,
  &_FullDuplexSerialDriver,
  NULL
};
void main()
{
    freopen("FDS:115200,31,30", "w", stdout);
    while (1) printf("Hello World\n");
}

2. Compile and load to a propeller thus:

propeller-elf-gcc -O2 -mfcache  -mlmm -o test.o -c test.c
propeller-elf-gcc -mlmm -fno-exceptions -fno-rtti -o test.elf test.o -s
propeller-load -b <yourboard> test.elf -r -t


What is the expected output? What do you see instead?

I expect to see lots and lots of "Hello Worlds".  Instead, I see nothing.  An 
astute observer with an oscilloscope or an LED on P0 will see that P0 is being 
used as the TX pin instead of P30.


What version of the product are you using? On what operating system?

propgcc-0.2.2


Please provide any additional information below.

The problem is at line 153 of lib/drivers/FdSerial.c; we need to increment name 
before doing the atoi.   lib/drivers/SimpleSerial.c (at around line 123) does 
the exact same parsing of the driver parameters, and it gets it right.

The exact fix is:

Change lines 152 and 153 of FdSerial.c from:

      if (*name)
        txpin = atoi(name);

To:

      if (*name)
        {
          name++;
          txpin = atoi(name);
        }

Original issue reported on code.google.com by [email protected] on 28 Jan 2012 at 9:34

SpinStamp not supported in propeller-load.cfg

In propgcc-0.2.2, the propeller-load.cfg does not contain definitions for the 
Spin Stamp module from Parallax.

Because this module contains a 10MHz crystal, it is important to use the 
correct target board -- otherwise the PLL16X mode overdrives the CPU.  
Furthermore, the Spin Stamp only has 32KB of ROM, making caching not relevant.  
Thus, the Spin Stamp requires definitions similar to the demo board, but with 
the clkmode changed to PLL8X:

[spinstamp]
    clkfreq: 80000000
    clkmode: XTAL1+PLL8X
    baudrate: 115200
    rxpin: 31
    txpin: 30
    tvpin: 12   # only used if TV_DEBUG is defined

Also note there are no definitions for the PropStick.  I don't have one, but 
the PropStick is documented to have a 5MHz crystal, and again it has 32KB of 
ROM.  Thus, it should use the exact same definitions as the demo board, but it 
would be nice to explicitly show that by having a separate entry in the 
propeller-load.cfg file:

[propstick]
    clkfreq: 80000000
    clkmode: XTAL1+PLL16X
    baudrate: 115200
    rxpin: 31
    txpin: 30
    tvpin: 12   # only used if TV_DEBUG is defined

Is GCC currently in a state where "average joes" can check in additions like 
this?  If not, then I'd like to request that the above additions be added to 
propeller-load.cfg in future releases.

Original issue reported on code.google.com by [email protected] on 28 Jan 2012 at 3:27

Function expanded in-line inappropriately

What steps will reproduce the problem?

volatile uint32_t __attribute__((section(".hub"))) *xmm_mbox;

static uint32_t __attribute__((section(".hubtext"))) do_cmd(uint32_t cmd)
{
    xmm_mbox[0] = cmd;
    while (xmm_mbox[0])
        ;
    return xmm_mbox[1];
}

Work-around is to use:
static uint32_t __attribute__((section(".hubtext"))) __attribute__((noinline)) 
do_cmd(uint32_t cmd)
{
    xmm_mbox[0] = cmd;
    while (xmm_mbox[0])
        ;
    return xmm_mbox[1];
}

What is the expected output? What do you see instead?
 A. Unexpectedly got inline versions of the function.

Please use labels and text to provide additional information.
 See: http://forums.parallax.com/showthread.php?135378-Function-expanded-in-line-inappropriately

Original issue reported on code.google.com by [email protected] on 25 Oct 2011 at 10:54

Loader freezes

What steps will reproduce the problem?
1.  On a Mac.
2.  Invoke loader like normal.
3.  Specified serial port may have been in use by another application.

What is the expected output? What do you see instead?
Expected output: normal output from loading an elf binary to the Propeller
Observed output: none.  Loader seemed to hang.  Ctrl+C dumped back to terminal, 
no caught exception output.

What version of the product are you using? On what operating system?
Mac OSX 10.7.2. Loader version - current, just built from updated source.

Please provide any additional information below.
May be a problem on other OSes too.

Original issue reported on code.google.com by [email protected] on 2 Nov 2011 at 5:07

XTAL and PLL Constants in loader/src/config.c are not correct

What steps will reproduce the problem?

1. In propeller-load.cfg, change clkmode to XTAL1 (with no PLL), or run 
propeller-load by providing an explicit "-D clkmode=XTAL1" argument.
2. Run propeller-load with the -S flag so you can look at the resulting .binary


What is the expected output? What do you see instead?

Check the fifth byte of the .binary file.  Notice the byte is 0x28, not the 
required 0x2A.


What version of the product are you using? On what operating system?

propgcc-0.2.2


Please provide any additional information below.

The values for XTAL* and PLL* in the configSymbols[] table are incorrect.  In 
fact, they do not match the constants in the config.h file (the constants in 
config.h are correct).

The fix is to change the configSymbols[] definition to:

static ConfigSymbol configSymbols[] = {
{   "RCFAST",       0x00        },
{   "RCSLOW",       0x01        },
{   "XINPUT",       0x22        },
{   "XTAL1",        0x2A        },
{   "XTAL2",        0x32        },
{   "XTAL3",        0x3A        },
{   "PLL1X",        0x41        },
{   "PLL2X",        0x42        },
{   "PLL4X",        0x43        },
{   "PLL8X",        0x44        },
{   "PLL16X",       0x45        },
{   "K",            1024        },
{   "M",            1024*1024   },
{   "MHZ",          1000*1000   },
{   "TRUE",         TRUE        },
{   "FALSE",        FALSE       },
{   NULL,           0           }
};

Original issue reported on code.google.com by [email protected] on 28 Jan 2012 at 8:11

demos/fft broken with xmm mode - lmm & xmmc OK

What steps will reproduce the problem?
1. cd demos/fft
2. make clean; make MODEL=XMM
3. propeller-load -r -t fft_bench.elf -b c3

What is the expected output? What do you see instead?
Expect full FFT output, only see fft_bench v1.0

The demo/fibo/xmm works. Others not tested.

Please use labels and text to provide additional information.

Original issue reported on code.google.com by [email protected] on 16 Nov 2011 at 3:41

gmtime() in library is busted by logic error

What steps will reproduce the problem?

1. Compile the attached test.c program using the following script:

propeller-elf-gcc -O2 -mfcache -save-temps -mlmm -o test.o -c test.c
propeller-elf-gcc -Xlinker -Map=DS1302_test.map -mlmm -fno-exceptions -fno-rtti 
-o DS1302_test.elf test.o  -s

2. Run the program by loading it to a propeller.

What is the expected output? What do you see instead?

I expect to see the program spew out a bunch of date conversions without the 
programming printing out any errors.  Instead all dates have conversion errors!

Example:

Date to test:    01/01/1970 00:00:00
Converted time_t:           0   (now set the clock)
Sytem time:                 0
Convert back:    01/00/1970 00:00:00
Error: gmtime mismatch!
Day of year:     0
Day of week:     4
Using strftime:  01/00/1970 00:00:00
Error: strftime mismatch!

What version of the product are you using? On what operating system?

propgcc-0.2.2


Please provide any additional information below.

The problem is in the _gmtime_r routine.  The code says it is from the MiNT 
library, but looking at the MiNT source at 
http://cd.textfiles.com/geminiatari/FILES/MINT/MNTLIB18/LOCALTIM.C, it is 
obvious that the _gmtime routine was changed from the MiNT source.

The first problem is the missing  " + 1" in the "stm->tm_mday = mday + 1;" line.

A second and more troubling problem is that the new "align on post-1972 
boundary" code is just wrong.  You can't align starting at 1972, because the 
leap day hasn't happened yet.  You can only align starting at the beginning of 
1973, and knock off quad-years, but afterwards (with the "up to 4 years" 
remainder) you still have to knock off a year at a time to account for a 
possible year with a leap day.

Attached please find code that works if you compile with the following commands:

propeller-elf-gcc -O2 -mfcache -save-temps -mlmm -o test.o -c test.c
propeller-elf-gcc -O2 -mfcache -save-temps -mlmm -o localtim.o -c localtim.c
propeller-elf-gcc -Xlinker -Map=DS1302_test.map -mlmm -fno-exceptions -fno-rtti 
-o DS1302_test.elf test.o localtim.o  -s

Note that this code loses in the "space vs time" tradeoff - it's quicker to 
run, but takes up more room.  In my opinion, I'd prefer to have the new "align 
on post-1972 boundary" code removed leaving just the original MiNT code.  Sure 
it's a little slower, but personally I think gmtime is just not run that often 
and I'd rather have it be slower but smaller.

On last thing to point out: I've attached the diffs of this code to the code 
checked in at 
http://code.google.com/p/propgcc/source/browse/lib/time/localtim.c.  If you 
notice in the diff, there's an addition of a "struct tm *gmtime()" routine at 
"@@ -179,6 +190,11 @@".

The interesting thing is that I did not add this code.  This extra line appears 
in the library found at 
http://code.google.com/p/propgcc/downloads/detail?name=propgcc-libsrc_2011-12-21
.zip, but this particular change is not checked in to the repository at 
http://code.google.com/p/propgcc/source/browse/lib/time/localtim.c.

It's a little disconcerting to see these out of sync.

Original issue reported on code.google.com by [email protected] on 2 Feb 2012 at 7:25

Attachments:

• test.c
• localtim.c
• localtim.diffs

Propeller-Loader: Baud Rate Is Not What It's Cracked Up To Be - Documentation Request

What steps will reproduce the problem?

1. Create a simple program (test.c):

#include <stdio.h>
void main()
{
    while (1) printf("Hello World\n");
}

2. Compile and load to a propeller thus:

propeller-elf-gcc -O2 -mfcache -mlmm -o test.o -c test.c
propeller-elf-gcc -mlmm -fno-exceptions -fno-rtti -o test.elf test.o -s
propeller-load -b <yourboard> test.elf -r -t

This should work fine; you will see loads of "Hello World" lines.

3. Now, change propeller-load.cfg's "baudrate" for your board to 57600.  Or, 
use the following loader command:

propeller-load -b <yourboard> -Dbaudrate=57600 test.elf -r -t


What is the expected output? What do you see instead?

I would expect that I would see lots of "Hello World" lines again.  Instead I 
see a lot of garbage.


What version of the product are you using? On what operating system?

propgcc-0.2.2


Please provide any additional information below.

Apologies, but the full Discussion is a bit wordy...

*** Summary:

My goal is to be able to use serial communications with a reduced baud rate.  I 
cannot do this in what appears as the most straight-forward way, but I can do 
this by a series of work-arounds.  IMHO, either propgcc should either fix the 
situation to work in the most straight-forward way, or we should document and 
thus formalize the work-arounds.

*** What I thought should work:

It is clear that the propeller-load program dynamically patches the clkfreq and 
clkmode from propeller-load.cfg into executable. The fact that 
propeller-load.cfg contains the baud rate, rx/tx pins, and tv pin(s) implies 
that the loader will dynamically patch these values into the executable.  
Further evidence is this snippet taken from lib/cog/cogserial.c:

/* globals that the loader may change; these represent the default
 * pins to use
 */
unsigned int _rxpin = 31;
unsigned int _txpin = 30;
unsigned int _baud = 115200;

So I thought the easiest thing to do would be to change the baudrate in 
propeller-load.cfg.  This obviously does not do the correct thing.  I 
double-checked the propeller-loader source code, and found that 
loader/src/loader.c does patch the serial_helper loader with the tx/rx/baud/tv, 
but that's about it - nothing (particularly not BuildInternalImage()) patches 
the final executable with rx/tx/baud.

Thus, it appears that the loader functionality to patch baud/pins is either 
unplanned or still TBD.

*** What I did to make it work:

I included the following line at the start of my main() routine:

    freopen("SSER:57600,31,30", "w", stdout);

I loaded the propeller with this command:

    propeller-load -b <yourboard> test.elf -r -t57600

Notice that I did not include the -Dbaudrate=57600, because that just slows 
down the load.

*** Explicit Requests For Fixes

Your response is most likely to be "Yep, that's the way it works, your 
work-around is the right thing and we're not planning on fixing any code to 
patch the baud/rx/tx in the final executable".  Therefore, please add the 
following information to http://code.google.com/p/propgcc/wiki/PropGccLoader:

** Start Quote **
Note: The loader uploads a small helper program into your Propeller to help it 
perform the final loading.  The loader patches the clkfreq and clkmode into 
both this helper program and also your final program.  However, the baudrate, 
rxpin, txpin, and tvpin specify the paramaters that the loader and helper 
programs use when transferring your program to the propeller, and also in 
terminal mode after your program starts running.  These values *are not* 
patched into your executable for use during normal program execution.  You 
should keep the loader's baudrate at a high value (but one that is still 
reasonable for your board configuration) so that your program loads as quickly 
as possible.

However, you will need to take special measures if the loader's baudrate does 
not match the program's baudrate (e.g. you set the loader's baudrate to a value 
other than 115200, or if your program sets its baudrate to a value other than 
115200).  Please see the Propeller GCC Library (link to 
http://propgcc.googlecode.com/hg/doc/Library.html) for information on how to 
set the baud rate in your program.  See the -t<baud> option below for 
information on how to specify that terminal mode's baud rate matches your 
program's baud rate.
** End Quote **

One reasonable place to add this is after "The -D variables are listed in the 
help output" and the ensuing 10-item list.

If on the other hand, if your response is "Yep, we know that those variables 
are not being patched into the executable, we just haven't gotten around to it 
yet", then please still add a message explaining the serial helper and how/when 
the baudrate/rxpin/txpin get patched into the binary.  And it would be nice to 
be able to specify two sets of parameters, one for loading and one for running.

*** Why am I messing around with baud anyway?

I need to work around two requirements:

- My application runs on an Spin Stamp in low power mode (battery operated).  
Therefore, I run the Propeller in XTAL1 mode (no PLL), yielding a 10MHz clock.

- I want to use printf() for debugging, but I don't want to give up the extra 
cog for the FDSerial driver.

With a 10MHz clock, SimpleSerial will not work above around 19200 baud.  
Therefore I must change the baud rate.

*** Other Foolery

I've noticed that the propeller-loader will not work with baud rates below 
38400 (at least in my Spin Stamp connected to my desktop).  Furthermore, the 
FDSerial and Simple Serial drivers will not work with baud rates below 9600.  
My best guess is that this is a problem with the FTDI drivers not the 
loader/library code.  However, because it seems to fail with all revs of the 
driver I could test, I'm not sure of this.  I just thought that I'd mention 
this in case someone else sees it and cares, but I'm unlikely to want to use 
baud rates that low.

Original issue reported on code.google.com by [email protected] on 28 Jan 2012 at 10:55

propeller-elf-objdump -d a.out crashes

What steps will reproduce the problem?
1. $ propeller-elf-gcc helloworld.c
2. $ propeller-elf-objdump -d a.out
3. See crash.

What is the expected output?
full dump.

What do you see instead?
c:\gccdev\side\side-demos\hello>propeller-elf-objdump -d

a.out:     file format elf32-propeller


Disassembly of section .boot:

00000000 <__clkfreq>:
   0:   04c4b400        if_a            rdword  168 <__LMM_MVI_lr+0x8>, #0

00000004 <__clkmode>:
   4:   0010006f        if_c_and_nz     wrbyte  0 <__clkfreq>, 1bc <__LMM_POPM+0xc>

00000005 <chksum>:
   5:   e8001000                        nop
   9:   ^C

Please use labels and text to provide additional information.

Original issue reported on code.google.com by [email protected] on 6 Dec 2011 at 5:57

lib/time/localtim.c leapyear calculation seems wrong.

A Gregorian leap year is not simply a year evenly divisible by 4.

Years evenly divisible by 100 are not leap years unless
the year is evenly divisible by 400.

For example: 2000 and 2400 are leap years, but 1900 and 2100 are not.

Original issue reported on code.google.com by [email protected] on 5 Mar 2012 at 7:30

Use a smaller 32 bit floating point library for Propeller-GCC

This is not a defect, it is a feature request.

Today's 64 bit library used in 32 bit mode makes floating point programs too 
big to be useful with Propeller GCC LMM programs. We must decide whether or not 
to use a smaller 32 bit library.

Original issue reported on code.google.com by [email protected] on 11 Nov 2011 at 10:50

Need a way to make .cfg file variables available to the user's C code

The .cfg files that propeller-load uses have useful information in them that 
may be of use to the user's program once it is loaded. For instance, the 
baudrate that is used for the serial port will probably want to be the same as 
the one the loader uses. Also, any SD card pin numbers or other parameters 
would be useful if the user's program wants to use the SD card itself.

This can be done by having the loader automatically initialize global variables 
with names that match the .cfg file variables. For instance, the config file 
variable "baudrate" can be used to initialize the user variable "_baudrate". 
This can be done for the SD card parameters as well. For example, the config 
file variable "sdspi-clk" can be used to initialize the user variable 
"_sdspi_clk".

Original issue reported on code.google.com by [email protected] on 2 May 2012 at 2:53

error: unrecognizable insn:

What steps will reproduce the problem?
1. cd propgcc/demos/TV/TvText_demos
2. make clean
3. make

What is the expected output?
No crash.

What do you see instead?
steve@debian-vm:~/gcc/propgcc/demos/TV/TvText_demo$ make
propeller-elf-gcc -Os -mlmm -o TvDemo.o -c TvDemo.c
propeller-elf-gcc -Os -mlmm -o TvText.o -c TvText.c
TvText.c: In function 'newline':
TvText.c:235:1: error: unrecognizable insn:
(jump_insn 119 81 83 (set (reg:HI 6 r6)
        (unspec:SI [
                (label_ref:SI 117)
                (label_ref 112)
            ] 121)) TvText.c:80 -1
     (nil))
TvText.c:235:1: internal compiler error: in insn_default_length, at 
insn-attrtab.c:237
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make: *** [TvText.o] Error 1
steve@debian-vm:~/gcc/propgcc/demos/TV/TvText_demo$ 



Please use labels and text to provide additional information.

Original issue reported on code.google.com by [email protected] on 7 Dec 2011 at 4:38

Can't read Windows INSTALL.txt with notepad

What steps will reproduce the problem?
1. download .zip and/or extract
2. open propgcc folder
3. open INSTALL.txt with notepad


What is the expected output? What do you see instead?

Notepad shows one continuous line.
Should text should have line breaks.


Please use labels and text to provide additional information.

Presumably this problem is because linux end of line was used.
Workaround is to use wordpad.

Fix would be to use unix2dos in release.sh.

Original issue reported on code.google.com by [email protected] on 30 Oct 2011 at 12:17

compile with gcc, test with ppropellersim

I'd like to know what combination of 
gcc toolchain (compile and objcopy, whatever
is needed)

produces a binary code that I can load with
ppropellersim and test

Can someone point me to a short howto do this

Original issue reported on code.google.com by [email protected] on 6 Jul 2012 at 6:42

The configuration files should be updated to make use of board subtypes

The loader supports board subtypes as a way to avoid having to create numerous 
configuration files that are all the same except for a few parameters. The 
common parameters can be gathered together at the top of the file and named 
tags can refer to board subtypes that have a few unique parameters in addition 
to the common ones. This support has been in the loader for a while but the 
configuration files have not been updated to use it.

Original issue reported on code.google.com by [email protected] on 2 Apr 2012 at 11:40

Propeller-load: -z and -l eat a lock

What steps will reproduce the problem?

1. Compile the attached file as usual (propeller-elf-gcc -m<model> tst.c -o 
tst.elf
2. Run tst.elf on any board that supports XMMC and SD (e.g. a C3), using 
propeller-load -b <board> -r -t tst.elf
3. Do this for models lmm and xmmc.  In xmmc mode, run these additional tests:

propeller-load -b <board> -r -t -z tst.elf
propeller-load -b <board> -r -t -l tst.elf


What is the expected output? What do you see instead?

In LMM mode, there should be 7 cogs and 7 locks free.  In XMMC mode, there 
should be 6 cogs and 7 locks free.  However, in both the -z and the -l cases, 
there are only 6 locks free.


Additional information:

I believe the misplaced lock is the in the LMM kernel's lock for the C runtime 
of the sd_loader.c or sd_cache_loader.c trampoline programs - nothing frees the 
lock before handing over control to vm_start.s.

Original issue reported on code.google.com by [email protected] on 2 Apr 2012 at 2:03

Attachments:

• tst.c

Issues System Test

This is a test of the issues system.

Original issue reported on code.google.com by [email protected] on 29 Aug 2011 at 11:01

Attachments:

• P8X32A-Q44.jpg

Probable typo in lib/drivers/dosfs.c wastes a small amount of space

The DFS_GetPtnStart() routine at the top of dosfs.c is conditionally included 
via "#ifndef PROPGCC_MODE" conditional.  However, the rest of dosfs.c and 
dosfs.h use "#ifndef PROPGCC_MODS" to trim off code that PropGCC does not need.

(Note that the comment at the start of dosfs.c also mentions PROPGCC_MODE, 
while the comment at the start of dosfs.h mentions PROPGCC_MODS.)

I checked the rest of the code and nothing seems to call DFS_GetPtnStart.

This problem really quite trivial, but fixing it will free up 344 bytes to 
hapless hackers like myself trying to use a SD card in LMM mode. 


What version of the product are you using? On what operating system?

propgcc-0.2.2

Original issue reported on code.google.com by [email protected] on 5 Feb 2012 at 8:28

Real Time Clock - Fixes and Improvements

Rather than the standard "steps to repro, expected output, etc.", this bug 
report will just "dive in" to details...

Problems occur when using the feature documented in the Propeller GCC Library 
page at http://propgcc.googlecode.com/hg/doc/Library.html#RTC:

*** Begin Quote ***
There is also a mechanism to use another cog to update the cycle counter, which 
will remove the requirement for frequent calling of the clock functions. If the 
global variable _default_ticks_updated is set to a non-zero value, then the 
default RTC assumes that another cog is keeping the 64 bit counter 
_default_ticks up to date, and it does not set it from the cycle counter.
*** End Quote ***

This RTC feature (as coded) has two basic problems:

1) It is not thread safe, and will generate spurious results at times
2) It is not easy to use:
  A) The cog tending function is not in the library, it is a "main()" function
  B) A roll-your-own solution requires people to cut/paste declarations from the code


What version of the product are you using? On what operating system?

propgcc-0.2.2


Please provide any additional information below.

Attached please find several files:

rtc.c - a fixed lib/sys/propeller/rtc.c
rtc_cog.c - a fixed lib/sys/propeller/rtc_cog.c
rtc.h - a fixed lib/include/sys/rtc.h
c_sample.c - a sample program showing how to use the fixed rtc_cog.c

Also included are .diff files that show the differences from the 0.2.2 versions.

Discussion:

The rtc.c file suffered from thread-unsafe practices.  If two threads are going 
to access _default_ticks, then it needs to be locked as each thread updates it. 
 All the fixes in rtc.c are to add the necessary locking, except...  The 
update_ticks function is now global (named _default_update_ticks), not static 
local.  This is due to the streamlining of rtc_cog.c.

About rtc_cog.c: The issue here is that IMHO, a sizable majority of its users 
will want to just say "OK, I want a stable time, but I don't want to think 
about it.  Use the cog if you need to, but just make the time works reliably 
and properly".  Therefore, the library should have a simple routine that a 
typical user can call to simply direct the RTC to do exactly that.  The new 
"void _rtc_start_tender_cog()" routine does exactly that.  Please add rtc_cog.o 
to the library.

Regarding sys/rtc.h:  It now has declarations for the _default_ticks_updated 
variable, and the "void _default_update_ticks()" routine (as well as the 
aforementioned _rtc_start_tender_cog().  If a programmer doesn't want to give 
up a cog, but just wants to call a "hey - wake up and make sure the time being 
tracked is OK" function from some other cog that has the time and frequency to 
do so, why should the user have to know the gory details of the _default_ticks 
structure?  All the user needs to do is set _default_ticks_updated to 1, then 
call _default_update_ticks() on a regular basis.  (Note that this is exactly 
what _rtc_start_tender_cog() function does, albeit in a standalone cog.)

Adding to this argument is my belief that folks are not going to want to write 
some other way to keep track of the ticks within the _default_ticks structure.  
Indeed, if a particular application needs a different/better way to keep the 
clock (perhaps by using a DS1318 or some other time-keeping chip), these 
programmers are not going to be fussing with the _default_ticks counter; 
instead they are going to "install" their own diver by overwriting the 
_rtc_gettime and _rtc_settime pointers.  That's why I didn't bother suggesting 
adding the _default_ticks structure declaration to sys/rtc.h.

For a project I'm working on, I ported the DS1302.spin file to C, and fixed and 
added a bunch of stuff.  One thing that would be desirable for me (and I'm 
guessing others) is to add a battery-backed up DS1302 chip (it's a three-wire 
interface) to their system and have their C code have full access to standard 
"C" date/time routines.  The attached c_sample.c file contains an example of 
how to set this up.  The call to _rtc_start_tender_cog() causes the timekeeping 
to "just work", then the rtc_init() and rtc_c_library_init() calls from my 
DS1302 driver look up the time stored in the DS1302 and initializes the C 
runtime via a "settimeofday" call.

I plan on submitting the DS1302 C code to the Propeller Object Exchange as soon 
as PropGCC has the fixed gmtime() function (issue 27) and also has these fixes.

In summary, I hope you accept and integrate these changes.  As far as I can 
tell, the changes to rtc.c are mandatory, even if you don't want to change 
rtc_cog.c.  In this case, you have to add the locking to rtc_cog.c as well 
(yuck).  Please accept both of my fixes, and please accept the changes to 
sys/rtc.h as well.  Then, please make the following changes to the library 
documentation:

*** Start Quote ***
The interface to real time clocks is via two function pointers:

    #include <sys/time.h>
    int (*_rtc_gettime)(struct timeval *tv);
    int (*_rtc_settime)(const struct timeval *tv);
*** End Quote ***

This is wrong, no matter if you accept my proposed changes or not.  This should 
say sys/rtc.h, not sys/time.h.

*** Start Quote ***
There is a default clock that simply uses the built-in cycle counter. At a 
typical clock rate of 80MHz this counter overflows in 54 seconds. The default 
RTC driver uses a 64 bit tick counter to compensate for this, but it must be 
called more often than the counter overflows in order for it to keep the high 
word of the tick counter accurate.

There is also a mechanism to use another cog to update the cycle counter, which 
will remove the requirement for frequent calling of the clock functions. If the 
global variable _default_ticks_updated is set to a non-zero value, then the 
default RTC assumes that another cog is keeping the 64 bit counter 
_default_ticks up to date, and it does not set it from the cycle counter.
*** End Quote ***

Change this to:

*** Start Quote ***
There is a default clock that simply uses the built-in cycle counter. At a 
typical clock rate of 80MHz this counter overflows in 54 seconds. The default 
RTC driver uses a 64 bit tick counter to compensate for this, but a time 
retrieval function (such as time()) must be called more often than the counter 
overflows in order for it to keep the high word of the tick counter accurate.

There is also a mechanism to use another cog to update the cycle counter, which 
will remove the requirement for frequent calling of a clock functions (e.g. 
time()). To do this, call the _rtc_start_tender_cog() routine - it starts a cog 
whose entire purpose is to keep the clock up-to-date.

Alternatively, if you have spare time on one of your cogs, you can kick the 
built-in cycle counter yourself (without the expensive call to the time() 
routine which performs several 64-bit math operations).  To do this, set the 
global variable _default_ticks_updated to a non-zero value, and call the 
_update_default_ticks() routine on a regular basis.

If you have an alternate way to keep time (such as a hardware chip like the 
DS1318), replace the built-in drivers by assigning the global _rtc_gettime and 
_rtc_settime pointers to your own gettime() and settime() routines.
*** End Quote ***

Original issue reported on code.google.com by [email protected] on 3 Feb 2012 at 5:28

Attachments:

• rtc.c
• rtc_cog.c
• rtc.h
• rtc.c.diffs
• rtc_cog.c.diffs
• rtc.h.diffs
• c_sample.c

Can't change Propeller clock mode with CLKMODE macro.

Need CLK

What is the expected output? What do you see instead?


Please use labels and text to provide additional information.

Original issue reported on code.google.com by [email protected] on 17 Nov 2011 at 1:17

An incorrect "symbolic" numeric value does not produce an error

What steps will reproduce the problem?

1. Change propeller-load.cfg so that clkmode has an invalid value (e.g. 
"clkmode: foo"
2. Run propeller-load.


What is the expected output? What do you see instead?

I expect to see an error message telling me the symbol is not correct.  
Instead, I see no error message.


What version of the product are you using? On what operating system?

propgcc-0.2.2


Please provide any additional information below.

The error is at line 451 of loader/src/config.c...

Change:

            if (!sym) {
                Error("undefined symbol: %s", id);
                return FALSE;
            }

To:


            if (!sym->name) {
                Error("undefined symbol: %s", id);
                return FALSE;
            }

Original issue reported on code.google.com by [email protected] on 28 Jan 2012 at 8:16

Trouble building demos/toggle/toggle_cog

Forum User Reinhard reports:

I set the environment with the addpath.bat and went into the 
toggle\cog_c_toggle directory.
I start the Makefile and get the errors: libcog.a and crt0_cog.o not found.
The reason was the Makefile in libpropeller is not executed and the objects 
don't exist.
After do this, the compile and link was successfull.


A similar failure has been seen in the repository, but a change was pushed to 
fix the problem. Was the change not effective?


Bug will be verified before accepted.
Repeat by will be added in a few days.

What steps will reproduce the problem?
1.
2.
3.

What is the expected output? What do you see instead?
 A. demos/toggle/toggle_cog should automatically include demos/libpropeller


What version of the product are you using? On what operating system?
 A. windows-x86-32-propgcc_v0_1_2.zip ??

Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 25 Oct 2011 at 10:49

MacOSX propeller-elf-gcc -mcog mode appears to be broken

What steps will reproduce the problem?
1. build propeller-gcc toolchain
2. cd propgcc/demos/pong
3. make

What is the expected output? What do you see instead?
Successful build. Failed build.

Please use labels and text to provide additional information.

Original issue reported on code.google.com by [email protected] on 24 Mar 2012 at 12:35

SD cache driver doesn't work on older cards

What steps will reproduce the problem?

1. Compile any test program with propeller-elf-gcc -xmmc
2. Use a propeller board that has an attached SD adapter.  Use a suitably old 
and small SD card, typically 512MB or less
2. Load the program into a propeller via propeller-load -r -t -z -b 
<proper-board-name> <yourprogram>.elf


What is the expected output? What do you see instead?

The program should run.  Instead, the program does nothing.


Additional Details:

This problem is a regression.  When I converted sd_cache.spin to use the same 
code base as sd_driver.spin, I omitted the call to sd_release at the end of 
every cache access.  This appears to affect only older cards, but needs to be 
fixed nonetheless, because it ties up the SPI bus between cache accesses.

This problem is independent of the "locks needed for SPI bus access" problem 
(although the latter problem depends on this fix), and should be strongly 
considered for the beta regardless of the disposition of any other 
bugs/features.

Original issue reported on code.google.com by [email protected] on 1 Apr 2012 at 3:38

Symbols in wchar.h and time.h causing "multiple definition" errors in C++

What steps will reproduce the problem?

1. Save the following two programs:

sample1.cpp:

#include <wchar.h>
#include <time.h>

int foo()
{
    return 0;
}



sample:cpp

#include <wchar.h>
#include <time.h>

int main()
{
    return 0;
}



2. Compile using the following commands:

propeller-elf-g++ -g -Os -mfcache -mlmm -save-temps -o sample.o -c sample.cpp
propeller-elf-g++ -g -Os -mfcache -mlmm -o sample1.o -c sample1.cpp
propeller-elf-g++ -mlmm -o sample.elf sample.o sample1.o



What is the expected output? What do you see instead?

Expected: no errors

Saw Instead:

sample1.o: In function `foo()':
c:\Users\Ted\Documents\propgcc\DS1302/sample1.cpp:5: multiple definition of 
`__timezone'
sample.o:c:\\Users\\Ted\\Documents\\propgcc\\DS1302/sample.cpp:5: first defined 
here
sample1.o: In function `foo()':
c:\Users\Ted\Documents\propgcc\DS1302/sample1.cpp:5: multiple definition of 
`__tzname'
sample.o:c:\\Users\\Ted\\Documents\\propgcc\\DS1302/sample.cpp:5: first defined 
here
sample1.o: In function `__wcrtomb_ptr':
(.bss+0xc): multiple definition of `__wcrtomb_ptr'
sample.o:(.bss+0xc): first defined here
sample1.o: In function `__mbrtowc_ptr':
(.bss+0x10): multiple definition of `__mbrtowc_ptr'
sample.o:(.bss+0x10): first defined here
collect2: ld returned 1 exit status


What version of the product are you using? On what operating system?

propgcc-0.2.3


Please provide any additional information below.

The symbols mentioned above (_timezone, _tzname, _mbrtowc_ptr, and 
_wcrtomb_ptr) were recently added to the headers without the "extern" keyword.  
Because of this, they cause duplicate symbols when compiled with elf-g++ (but 
not with elf-gcc due to a difference in linkage rules).

The fix is to add the "extern" keyword to the appropriate lines in 
lib/include/time.h and lib/include/wchar.h.

Unfortunately, any C++ compile unit in the stdlibc++.a or libsupc++.a that 
included these headers now has a definition that will cause "multiple 
definition" errors.  There are many compile units that are part of the 
<iostream> library that are so affected, making linking with these functions in 
the 0.2.3 release of the stdlibc++.a library impossible.

Original issue reported on code.google.com by [email protected] on 9 Feb 2012 at 8:45

Propeller-load sometimes looses contact

Propeller-load reset timing may need adjusting. Occasionally I have to try 
several times to get a binary loaded. This seems to happen when there is 
already a program in eeprom that immediately hits P30-P31 with serial data.

[root@Dell cog]# propeller-load -r -t fibo.elf 
Lost HW contact. 1 f9
error: load failed
error: load failed
[root@Dell cog]# propeller-load -r -t fibo.elf 
Lost HW contact. 1 f9
error: load failed
error: load failed
[root@Dell cog]# propeller-load -r -t fibo.elf 
Lost HW contact. 1 f9
error: load failed
error: load failed
[root@Dell cog]# propeller-load -r -t fibo.elf 
Lost HW contact. 1 f9
error: load failed
error: load failed
[root@Dell cog]# propeller-load -r -t fibo.elf 
Lost HW contact. 1 f9
error: load failed
error: load failed
[root@Dell cog]# propeller-load -r -t fibo.elf 
Propeller Version 1 on /dev/ttyUSB0
Writing 2024 bytes to Propeller RAM.
Verifying ... Upload OK!
[ Entering terminal mode. Type ESC or Control-C to exit. ]
fibo(00) = 000000 (00000ms) (212 ticks)
...

Original issue reported on code.google.com by [email protected] on 17 Nov 2011 at 9:47

fgetc should yield for pthreads

Function fgetc always blocks until a character is available without
yielding. This is inconvenient at best and broken at worst.

Is there any way we can make it yield for pthread programs without
using too much code space ?

Original issue reported on code.google.com by [email protected] on 5 Mar 2012 at 8:20

Using propeller-load -l or -z to upload to a non-C3 shared SPI system does not work

What steps will reproduce the problem?
1. Use a non-C3 board with shared SPI (i.e. a board that uses the sdspi-clr, 
sdspi-inc, sdspi-sel, sdspi-msk, and/or sdspi-addr configuration parameters_
2. Try to upload an XMM or XMMC program using propeller-load with the -l or -z 
parameter.


What is the expected output? What do you see instead?

The file should transfer up OK.  Instead, you see:

Propeller Version 1 on COM6
Loading the serial helper to hub memory
9528 bytes sent
Verifying RAM ... OK
Loading 'main.pex' to SD card
<10 second delay>
Timeout waiting for ACK/NAK
error: SendPacket DATA failed

error: load failed


Additional information:

This bug was caused by an incomplete implementation of the FSRW-based file 
driver used by serial helper.  Specifically, the version of FSRW was hacked to 
understand the C3 based solely on the 4 "main pins": DO/CLK/DI/CS; it does not 
understand the extended parameters used by the rest of PropGCC (in the library, 
drivers, and cache system).

The fix is to add the missing code to handle the full set of parameters.

Original issue reported on code.google.com by [email protected] on 1 Apr 2012 at 4:02