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

124

Comments

  • David BetzDavid Betz Posts: 13,663
    edited 2013-03-19 - 07:34:15
    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 HenningBill Henning Posts: 6,445
    edited 2013-03-19 - 07:41:21
    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.
    www.mikronauts.com / E-mail: mikronauts _at_ gmail _dot_ com / @Mikronauts on Twitter
    RoboPi: The most advanced Robot controller for the Raspberry Pi (Propeller based)
  • ctwardellctwardell Posts: 1,700
    edited 2013-03-19 - 07:43:20
    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 BetzDavid Betz Posts: 13,663
    edited 2013-03-19 - 07:58:31
    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.
  • ctwardellctwardell Posts: 1,700
    edited 2013-03-19 - 08:11:00
    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.
  • RaymanRayman Posts: 10,054
    edited 2013-03-19 - 08:12: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?
    Prop Info and Apps: http://www.rayslogic.com/
  • RaymanRayman Posts: 10,054
    edited 2013-03-19 - 08:29:12
    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...
    Prop Info and Apps: http://www.rayslogic.com/
  • David BetzDavid Betz Posts: 13,663
    edited 2013-03-19 - 08:30:54
    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 BetzDavid Betz Posts: 13,663
    edited 2013-03-19 - 08:34:03
    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=
  • RaymanRayman Posts: 10,054
    edited 2013-03-19 - 08:55:06
    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...
    Prop Info and Apps: http://www.rayslogic.com/
  • Bill HenningBill Henning Posts: 6,445
    edited 2013-03-19 - 08:59:15
    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=
    www.mikronauts.com / E-mail: mikronauts _at_ gmail _dot_ com / @Mikronauts on Twitter
    RoboPi: The most advanced Robot controller for the Raspberry Pi (Propeller based)
  • RaymanRayman Posts: 10,054
    edited 2013-03-19 - 10:50:44
    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?
    Prop Info and Apps: http://www.rayslogic.com/
  • SRLMSRLM Posts: 5,045
    edited 2013-03-19 - 12:11:50
    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.
  • RaymanRayman Posts: 10,054
    edited 2013-03-19 - 12:41:31
    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...
    Prop Info and Apps: http://www.rayslogic.com/
  • David BetzDavid Betz Posts: 13,663
    edited 2013-03-19 - 12:55:53
    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.
  • jazzedjazzed Posts: 11,803
    edited 2013-03-19 - 13:05:31
    Rayman,

    Try getpin(...), setpin(...), and friends. Look at propeller1.h and propeller2.h these files are in the p2test distribution also.
  • RaymanRayman Posts: 10,054
    edited 2013-03-19 - 13:09:11
    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...
    Prop Info and Apps: http://www.rayslogic.com/
  • David BetzDavid Betz Posts: 13,663
    edited 2013-03-19 - 13:13:28
    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 BetzDavid Betz Posts: 13,663
    edited 2013-03-19 - 13:16:26
    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.
  • jazzedjazzed Posts: 11,803
    edited 2013-03-19 - 13:29:39
    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 BetzDavid Betz Posts: 13,663
    edited 2013-03-19 - 13:39:36
    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 ElthamRoy Eltham Posts: 2,699
    edited 2013-03-19 - 13:42:48
    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 BetzDavid Betz Posts: 13,663
    edited 2013-03-19 - 13:44:57
    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?
  • RaymanRayman Posts: 10,054
    edited 2013-03-20 - 06:35:28
    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?
    Prop Info and Apps: http://www.rayslogic.com/
  • Bill HenningBill Henning Posts: 6,445
    edited 2013-03-20 - 06:54:55
    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?
    www.mikronauts.com / E-mail: mikronauts _at_ gmail _dot_ com / @Mikronauts on Twitter
    RoboPi: The most advanced Robot controller for the Raspberry Pi (Propeller based)
  • David BetzDavid Betz Posts: 13,663
    edited 2013-03-20 - 06:55:21
    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.
  • RaymanRayman Posts: 10,054
    edited 2013-03-20 - 08:09:34
    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...
    Prop Info and Apps: http://www.rayslogic.com/
  • doggiedocdoggiedoc Posts: 2,064
    edited 2013-03-20 - 16:30:04
    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.
    Some times my mind seems to wander..... these days I just tag along.
  • David BetzDavid Betz Posts: 13,663
    edited 2013-03-20 - 18:22:39
    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!
  • doggiedocdoggiedoc Posts: 2,064
    edited 2013-03-25 - 18:04:13
    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
    Some times my mind seems to wander..... these days I just tag along.
Sign In or Register to comment.