PropGCC Propeller 2 Bug Fixes - and your chance for first-release Propeller hardware!

David Betz · 2013-03-19 07:34

I've just finished a new Windows build of the P2-capable version of PropGCC. Is anyone interested in it? It fixes some bugs in the P2 opcode table and also adds -e support to propeller-load which allows you to program the SPI flash chip so your board will boot directly into your program from reset. This is like the -e option for the P1 that writes a program to EEPROM but in the case of P2 it writes to SPI flash instead. I guess we can claim that -e stands for "external memory" now.

Anyway, it's a big upload so I won't bother doing it unless some of you think you'll upgrade to the newer version.

Bill Henning · 2013-03-19 07:41

Hi David,

I am interested, assuming I can integrate PASM drivers without having to re-write them for GAS... (and without spending the time to re-build gcc for Windows or Ubuntu 12.04)

It would let me play with the display drivers and other cog code I am working on without having to write everything in PASM.

How do I specify to the linker to only use the first 32KB of the hub? (I use the rest for a frame buffer)

Thanks,

Bill

David Betz wrote: »

I've just finished a new Windows build of the P2-capable version of PropGCC. Is anyone interested in it? It fixes some bugs in the P2 opcode table and also adds -e support to propeller-load which allows you to program the SPI flash chip so your board will boot directly into your program from reset. This is like the -e option for the P1 that writes a program to EEPROM but in the case of P2 it writes to SPI flash instead. I guess we can claim that -e stands for "external memory" now.

Anyway, it's a big upload so I won't bother doing it unless some of you think you'll upgrade to the newer version.

ctwardell · 2013-03-19 07:43

David Betz wrote: »

I've just finished a new Windows build of the P2-capable version of PropGCC. Is anyone interested in it? It fixes some bugs in the P2 opcode table and also adds -e support to propeller-load which allows you to program the SPI flash chip so your board will boot directly into your program from reset. This is like the -e option for the P1 that writes a program to EEPROM but in the case of P2 it writes to SPI flash instead. I guess we can claim that -e stands for "external memory" now.

Anyway, it's a big upload so I won't bother doing it unless some of you think you'll upgrade to the newer version.

David,

I'd like to try it, but I won't have time until the weekend, so if you think you may have any other changes by then I can wait until Friday evening to download it.

Thanks,

C.W.

David Betz · 2013-03-19 07:58

ctwardell wrote: »

David,

I'd like to try it, but I won't have time until the weekend, so if you think you may have any other changes by then I can wait until Friday evening to download it.

Thanks,

C.W.

It takes all day to build the Windows version on my Windows laptop so I doubt I'll build it again before the weekend unless some significant bug gets fixed or feature added.

ctwardell · 2013-03-19 08:11

David Betz wrote: »

It takes all day to build the Windows version on my Windows laptop so I doubt I'll build it again before the weekend unless some significant bug gets fixed or feature added.

Sounds like it might be a good idea to go ahead and upload what you have then since Bill wants to give it a go as well.

Thanks,

C.W.

Rayman · 2013-03-19 08:12

David, can you remind me exactly how loading from spi flash would work?
Does it just load cog0? Or, does it load up all of HUB and then launch cog0 from HUB?

Rayman · 2013-03-19 08:29

Bug or not enough cogs? ----> Tried the "calc" example (C:\propgcc\demos\forumists\jazzed\calc) again.
It works fine on Quickstart, but has bad math on DE0:

inf
Very Simple Propeller Calculator Demo
Commands +, -, *, or / then number1 number2.
Command? *
Enter first  number: 5
Enter second number: 3
inf * inf = infCommand?

If I select "32bit Double" it does slightly better, but is still wrong...

Is this because I only have 1 cog? Or, something else?

BTW: The calc demo should also be in ..\demos\calc, but is missing...

David Betz · 2013-03-19 08:30

Rayman wrote: »

David, can you remind me exactly how loading from spi flash would work?
Does it just load cog0? Or, does it load up all of HUB and then launch cog0 from HUB?

Chip's ROM loader just loads a single COG image and starts it. What propeller-load -e does is to write a second-stage loader into the start of SPI flash and then the rest of a hub image following it. The second-stage loader loads hub memory from the image in flash and starts the COG image that then resides at $1000. This leaves the memory from $0e80-$0fff to be used for globals and mailboxes. Currently, only the long at 0x0e80 is used and it holds CLKFREQ.

David Betz · 2013-03-19 08:34

The updated Windows version of PropGCC for P1 and P2 is now available on Google Code in the "Downloads" section.

http://code.google.com/p/propgcc/downloads/detail?name=prop2gcc-2013-03-19.zip&can=2&q=

Rayman · 2013-03-19 08:55

I just tried to run Spin2Cpp on one of Chip's P2 graphics demos, "simple_VGA_1280x1024"...
That didn't go so well, even with the --P2 option.
I'm guessing that Spin2Cpp can't yet convert P2 spin code.
Maybe that shouldn't be a surprise... Anyway, I hope that would work one day...

Bill Henning · 2013-03-19 08:59

Thanks David, will grab it.

David Betz wrote: »

The updated Windows version of PropGCC for P1 and P2 is now available on Google Code in the "Downloads" section.

http://code.google.com/p/propgcc/downloads/detail?name=prop2gcc-2013-03-19.zip&can=2&q=

Rayman · 2013-03-19 10:50

Question about compile error in Spin2Cpp converted code:

I know I only have one cog, but I tried to compile something with a couple cognews anyway...
It gives an error on this line in P2 mode, but works in P1 mode:

Okay = (Cog = (cognew((int32_t)(&(*(int32_t *)&dat[0])), (int32_t)(&Rx_head)) + 1));

This is the error message:
fullduplexserial.cpp:61:18: error: invalid conversion from 'int32_t {aka int}' to 'void*' [-fpermissive]

Now, I did have to add "volitile" to Rx_head to make it compile for P1 (SRLM's idea). Is that related?

SRLM · 2013-03-19 12:11

Rayman wrote: »

This is the error message:
fullduplexserial.cpp:61:18: error: invalid conversion from 'int32_t {aka int}' to 'void*' [-fpermissive]

That's because Spin is untyped, and so you can use longs as pointers. spin2cpp has no idea what you do with the data, so it just makes the best guess possible and goes from there. For the most part, that works ok, but not always. There is a flag to downgrade the error to warnings. I think it is -fpermissive.

Rayman · 2013-03-19 12:41

I can believe that, but why would it work for P1 and not P2? Maybe the P2 syntax is different..

On another note, I was able to convert a Spin2Cpp port of my Spin test program for the RamPage2 into something that compiles and seems to run
on both Quickstart and DE0-nano. Here are a couple things I added to make that work:

#ifdef _PROPELLER2_H_
#define INA  PINA
#define OUTA PINA
#endif

#ifdef _PROPELLER2_H_
#define CNT getcnt()
#endif

It seems to work this way, but is this a good approach?
I'm still trying to grasp PINA being both INA and OUTA...

David Betz · 2013-03-19 12:55

Rayman wrote: »
I can believe that, but why would it work for P1 and not P2? Maybe the P2 syntax is different..

On another note, I was able to convert a Spin2Cpp port of my Spin test program for the RamPage2 into something that compiles and seems to run
on both Quickstart and DE0-nano. Here are a couple things I added to make that work:
#ifdef _PROPELLER2_H_
#define INA  PINA
#define OUTA PINA
#endif

#ifdef _PROPELLER2_H_
#define CNT getcnt()
#endif
It seems to work this way, but is this a good approach?
I'm still trying to grasp PINA being both INA and OUTA...

I guess defining CNT that way would be okay. I don't think the INA and OUTA definitions will be that useful though since you're likely to need to use more than just PINA. What about PINB, PINC, and PIND? They have no analogs in P1 so code that uses those will be different anyway. Also, the fixed pins on P1 like serial TX/RX and the I2C pins are on different pin numbers on P2. Finally, on P2 you're more likely to use the new PIN instructions than the registers anyway.

jazzed · 2013-03-19 13:05

Rayman,

Try getpin(...), setpin(...), and friends. Look at propeller1.h and propeller2.h these files are in the p2test distribution also.

Rayman · 2013-03-19 13:09

That might work for me if there were things like: getpins(basePin,nPins) and setPins(basePin,nPins)...
I'm trying to operate on several pins at the same time...

David Betz · 2013-03-19 13:13

Rayman wrote: »

That might work for me if there were things like: getpins(basePin,nPins) and setPins(basePin,nPins)...
I'm trying to operate on several pins at the same time...

I'm afraid those aren't there and obviously those will require accessing the PINx registers not the setp/getp instructions. I started writing these but they are tricky since you have to worry about a number of things:

1) Which PINx register is the bitfield in?
2) Does the bitfield span two PINx registers?

I'd hate to have the function or macro take pin numbers and figure out the appropriate PINx register at runtime but I'm not sure how else to do it.

If you can come up with a good approach, we'll certainly consider adding it to propeller2.h!

David Betz · 2013-03-19 13:16

David Betz wrote: »

I'm afraid those aren't there and obviously those will require accessing the PINx registers not the setp/getp instructions. I started writing these but they are tricky since you have to worry about a number of things:

1) Which PINx register is the bitfield in?
2) Does the bitfield span two PINx registers?

I'd hate to have the function or macro take pin numbers and figure out the appropriate PINx register at runtime but I'm not sure how else to do it.

If you can come up with a good approach, we'll certainly consider adding it to propeller2.h!

Maybe I spoke too soon. If we made these inline functions and you passed in constant pin numbers then GCC would do dead code elimination on any if statement clauses that were always false. That would result in code for only the appropriate PINx register to be generated assuming the pin group doesn't span two PINx registers which we probably don't want to support anyway.

jazzed · 2013-03-19 13:29

Rayman wrote: »

That might work for me if there were things like: getpins(basePin,nPins) and setPins(basePin,nPins)...
I'm trying to operate on several pins at the same time...

Well at least the conversation bubbly or at least frothy now. A common API set would be beneficial even as a library.

David Betz · 2013-03-19 13:39

jazzed wrote: »

Well at least the conversation bubbly or at least frothy now. A common API set would be beneficial even as a library.

One problem though is that the getpins and setpins functions will never be as fast as using explicit masks because they will build a mask on the fly. I defined some pin classes a while back that created the mask in the constructor so they didn't have to do it on every access. That requires you to use C++ though.

Roy Eltham · 2013-03-19 13:42

I think a common API that just took which bank (A/B/C/D) and a 32bit in or out param would work, and a mask. For P1 you can only specify bank A/B, for P2 you get all 4.

David Betz · 2013-03-19 13:44

Roy Eltham wrote: »

I think a common API that just took which bank (A/B/C/D) and a 32bit in or out param would work, and a mask. For P1 you can only specify bank A/B, for P2 you get all 4.

You mean something like getpinsA, getpinsB, etc?

Rayman · 2013-03-20 06:35

David Betz wrote: »

Sorry for commenting on my own message but what is really likely to hinder porting Linux to either P1 or P2 using the existing PropGCC is that we currently put the stack in hub memory no matter which memory model is selected. A 32k stack may be insufficient on the P1 and even a 126k stack may be too small on the P2. Moving the stack to external memory is likely to be really bad for performance at least on the P1.

I have a question about GCC XMM mode with P2 and SDRAM.... Can we not use a 32-bit wide data bus SDRAM chip and some large number of seperate address pins to get very fast access to vast memory? Would that not be just as fast as HUB memory access?

Bill Henning · 2013-03-20 06:54

The schematic I've been playing with chews up 32+25 pins... the serial pins and Flash chew up another 6, for 63 pins used out of 92, leaving 29 I/O's for other uses.

Rayman wrote: »

I have a question about GCC XMM mode with P2 and SDRAM.... Can we not use a 32-bit wide data bus SDRAM chip and some large number of seperate address pins to get very fast access to vast memory? Would that not be just as fast as HUB memory access?

David Betz · 2013-03-20 06:55

Rayman wrote: »

I have a question about GCC XMM mode with P2 and SDRAM.... Can we not use a 32-bit wide data bus SDRAM chip and some large number of seperate address pins to get very fast access to vast memory? Would that not be just as fast as HUB memory access?

Fast SDRAM-based XMM is something we're looking forward to. I'm not sure Chip has documented the SDRAM interface yet though so I'm starting with XMM using the SPI flash chip.

Rayman · 2013-03-20 08:09

Great. I'll look forward to that too then...

BTW: I wonder if the PropGCC Beta thread could be made to show up over here too...
In my mind it's more relevant to P2 than P1 really...

doggiedoc · 2013-03-20 16:30

Rayman wrote: »

BTW: I wonder if the PropGCC Beta thread could be made to show up over here too...
In my mind it's more relevant to P2 than P1 really...

I've been playing around with the p2test build but I only have access to P1 hardware. Admittedly I'm not stressing the code's limits like you guys are but Ken did mention testing with P1 was important too.

David Betz · 2013-03-20 18:22

doggiedoc wrote: »

I've been playing around with the p2test build but I only have access to P1 hardware. Admittedly I'm not stressing the code's limits like you guys are but Ken did mention testing with P1 was important too.

Actually, P1 testing was what we were most interested in at this point. This is mainly to verify that we haven't broken anything while adding P2 support. Of course, we also want to hear about P2 problems but we're sure there are probably plenty of those. It's P1 regressions that we're trying to avoid at this point. So, both types of testing are needed. Thanks!

doggiedoc · 2013-03-25 18:04

I can't seem to find the thread in the P1 forum where Ken Gracey mentions testing the 'p2test' build on the P1. Did it disappear?

I've rewritten my traffic light controller in C and it works great. Haven't found any bugs but I don't think I'm pushing the limits too hard. :P I redirected SimpleIDE to use the p2test build and am finding it to work nicely too.

Just for giggles, here's my code for the traffic light controller:

/* filename:  signal_std.c
 random pin function
 homebrew traffic light contoller
 4 different modes:
 *emulates normal operation
 *pseudo-random single light
 *pseudo-random multibles
 *fast scrolling
 Paul A. Willoughby, DVM
 3/24/2013
*/

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


/*
*Constant Definitions
*/
#define OUT_MASK 0x070000  
#define DELAY 5000  


/*
*Function Declarations
*/
void pause(int ms);
void standard(int count);
void scroll(int count);
void random_single(int count);
void random_multi(int count);
int aRandomInt(int r);


int main(void)
{  
    DIRA = OUT_MASK;
    srand(CNT);
    while(1){
        standard(2);
        random_single(20);
        random_multi(20);
        scroll(20);
    }
    return 0;
}



void pause(int ms){
    waitcnt((CLKFREQ/1000)*ms + CNT);
}

int aRandomInt(int r){
    return  (rand() % r);
}

void standard(int count){
    for(int c = 0; c < count; c++){
        for (int i = 0; i < 1; i++){
            int pin = 1 << 18; //green
            OUTA |= pin; 
            pause((DELAY*2));       
            OUTA &= ~pin; 
            pin = 1 << 17;    //yellow
            OUTA |= pin; 
            pause(DELAY);       
            OUTA &= ~pin; 
            pin = 1 << 16;    //red
            OUTA |= pin; 
            pause((DELAY*2));       
            OUTA &= ~pin;         
        }
    }
}

void scroll(int count){
    for(int c = 0; c < count; c++){
        for(int i = 0; i < 3; i++ ){
            int pin = 1 << 16+i; //green
            OUTA |= pin; 
            pause(35);       
            OUTA &= ~pin; 
            pin = 1 << 16+i;    //yellow
            OUTA |= pin; 
            pause(35);       
            OUTA &= ~pin; 
            pin = 1 << 16+i;    //red
            OUTA |= pin; 
            pause(35);       
            OUTA &= ~pin;         
       }       
    }
}

void random_single(int count){  
    for(int c = 0; c < count; c++){
        int pin = 16 + aRandomInt(3);
        pin = 1 << pin;
        OUTA |= pin; //set pin output HIGH
        pause(125);
        OUTA &= ~pin;
        pause(125);
    }
}

void random_multi(int count){
    for(int c = 0; c < count; c++){
        int pin = 16 + aRandomInt(3);
        pin = 1 << pin;
        OUTA |= pin; //set pin output HIGH
        pause(250);
        pin = 16 + aRandomInt(3);
        pin = 1 << pin;
        OUTA &= ~pin;
    }
}

/*
 +--------------------------------------------------------------------
 | TERMS OF USE: MIT License
 +--------------------------------------------------------------------
 Permission is hereby granted, free of charge, to any person obtaining
 a copy of this software and associated documentation files
 (the "Software"), to deal in the Software without restriction,
 including without limitation the rights to use, copy, modify, merge,
 publish, distribute, sublicense, and/or sell copies of the Software,
 and to permit persons to whom the Software is furnished to do so,
 subject to the following conditions:
 
 The above copyright notice and this permission notice shall be
 included in all copies or substantial portions of the Software.
 
 THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
 MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
 IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
 CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
 TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
 SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
 +--------------------------------------------------------------------
 */

Thanks to the propgcc team for all the hard work. It's nice kicking it in the C playground again!

Paul

PropGCC Propeller 2 Bug Fixes - and your chance for first-release Propeller hardware!

Comments