Shop OBEX P1 Docs P2 Docs Learn Events
Programming Prop 1 with a C.H.I.P. — Parallax Forums

Programming Prop 1 with a C.H.I.P.

I received my C.H.I.P. (1 GHz single-core ARM board with 512 MB RAM, 4 GB eMMC, integrated wifi & BT for $9) a while back, and finally got around to trying to integrate it into my propeller projects; it's a better fit for my projects than any of the Pis.

The good news is that I was able to copy the /opt/parallax directory from my RPi to the CHIP, and it just works (cc, as, ld, size, objdump, etc). The not quite as good news is propeller-load. While I can specify a serial port, I can't find any way to specify the reset pin (I only use propgcc on the command line, never spin or Simple/PropellerIDE), which I believe is hard-coded to GPIO17 in the RPi version, but that won't work for the CHIP.

I would be willing to modify propeller-load to add this functionality, but I'm not sure of the location of the official version. I found one at https://github.com/dbetz/propeller-load, but that doesn't seem to be the one that I'm using (included with propellergcc_alpha_v1_9_0), since I found a RASPBERRY_PI #ifdef in ./blob/master/src/propeller-load.c that should have printed "This version supports -Dreset=gpio to use gpio 17 to reset the Propeller board.", but it doesn't print that in my binary version.

So, this is not very important (it probably affects *very* few potential users, and it's certainly no blockpoint for me), but I think it's probably a pretty easy fix that I could do if pointed in the right direction. Oh, and I have an informal competition with Heater that he may have forgotten about :-).
«1

Comments

  • The version of propeller-load that is in my github repository is the latest version. The version that is included in SimpleIDE is fairly old as is the version of PropGCC. How do you plan to reset the Propeller from the CHIP? Just a different GPIO or something different?
  • altosackaltosack Posts: 132
    edited 2016-08-29 02:22
    Yes, it's just a different GPIO (logical number 17 is not available; I think they start at #1018 or something foolish like that). After I posted this, I realized that I could cobble up a python script to do the prop reset and it would probably work to include this command in my make file just before propeller-load, but it would be cool to be able to specify the GPIO port in propeller-load.

    My propeller-load won't tell me a version #, but it's either the one included with Propgcc_alpha_v1_9_0, or I got it from Heater's pi thread, I don't remember.
  • David BetzDavid Betz Posts: 14,511
    edited 2016-08-29 02:34
    altosack wrote: »
    Yes, it's just a different GPIO (logical number 17 is not available; I think they start at #1018 or something foolish like that). After I posted this, I realized that I could cobble up a python script to do the prop reset and it would probably work to include this command in my make file just before propeller-load, but it would be cool to be able to specify the GPIO port in propeller-load.

    My propeller-load won't tell me a version #, but it's either the one included with Propgcc_alpha_v1_9_0, or I got it from Heater's pi thread, I don't remember.
    I don't know about Heater's version but the version in my github account can deal with GPIO on the RaspberryPi. It should be easy enough to modify it to allow a different GPIO number than 17 as long as that new GPIO works with the same sysfs interface that the RaspberryPi uses (/sys/class/gpio). If not, you'll have to tell me how to access the pin you're using. BTW, I have a CHIP module so I could test this if necessary.

  • It does use the same sysfs interface; however, the GPIO numbers differ depending on the version of the CHIP OS you have (410-417 for pre-production, which is probably what you have unless you reflashed it, or 1018-1025 for post-kickstart sales). What I'm proposing is to keep GPIO17 as the default, but allow us to specify a different port number, which should be extensible to other ARM boards in the future.

    I realize that my python script idea probably won't work, because trying to export GPIO17 when it's not available will probably cause a problem with the existing propeller-load.

    As I said, I'm willing to make the change myself, but it should be rather trivial and probably more practical for you to do it. In order to test it (probably not necessary for you; I could do that), you'd have to do some wiring, because a prop HAT for the pi will not fit.
  • jmgjmg Posts: 15,148
    altosack wrote: »
    It does use the same sysfs interface; however, the GPIO numbers differ depending on the version of the CHIP OS you have (410-417 for pre-production, which is probably what you have unless you reflashed it, or 1018-1025 for post-kickstart sales). What I'm proposing is to keep GPIO17 as the default, but allow us to specify a different port number, which should be extensible to other ARM boards in the future.

    Do you mean specify the GPIO pin, on the command line ?
    That would make sense, and could default to the Pi ?

  • jmg wrote: »
    Do you mean specify the GPIO pin, on the command line ?
    That would make sense, and could default to the Pi ?

    Yes, I mean to specify it on the command line if you don't want to use the default that works with the Pi, just like you can specify a different serial port now.

    I assume SimpleIDE uses the propeller-load command and could also benefit from this, but I've never used it, and really don't know.
  • altosack wrote: »
    jmg wrote: »
    Do you mean specify the GPIO pin, on the command line ?
    That would make sense, and could default to the Pi ?

    Yes, I mean to specify it on the command line if you don't want to use the default that works with the Pi, just like you can specify a different serial port now.

    I assume SimpleIDE uses the propeller-load command and could also benefit from this, but I've never used it, and really don't know.
    I'll add that option to propeller-load in the morning. Someone will have to add an interface to SimpleIDE to set the PIN number though.

  • altosackaltosack Posts: 132
    edited 2016-08-29 03:24
    David Betz wrote: »
    I'll add that option to propeller-load in the morning. Someone will have to add an interface to SimpleIDE to set the PIN number though.

    Thanks, David ! I'm not sure when I'll get around to testing it, but it shouldn't be too long.

    It does seem a bit unlikely that anyone will use SimpleIDE on the CHIP. In fact, I won't really use the CHIP for development, but I would like to be able to update a controller in the field that's deployed with the CHIP. The CHIP is cheaper, smaller, more robust (due to the eMMC rather than uSD) and uses less power than any existing Pi with wifi, so it's quite attractive to me.
  • jmgjmg Posts: 15,148
    altosack wrote: »
    It does seem a bit unlikely that anyone will use SimpleIDE on the CHIP. In fact, I won't really use the CHIP for development, but I would like to be able to update a controller in the field that's deployed with the CHIP. The CHIP is cheaper, smaller, more robust (due to the eMMC rather than uSD) and uses less power than any existing Pi with wifi, so it's quite attractive to me.
    Even if CHIP may not be the first choice for Small Linux Module Development, it sounds like supporting development is not much effort, and then it will give a valuable second opinion test platform, plus more choice to users.
    As you mention, there are use-advantages for CHIP in the field.


  • David Betz wrote: »
    altosack wrote: »
    jmg wrote: »
    Do you mean specify the GPIO pin, on the command line ?
    That would make sense, and could default to the Pi ?

    Yes, I mean to specify it on the command line if you don't want to use the default that works with the Pi, just like you can specify a different serial port now.

    I assume SimpleIDE uses the propeller-load command and could also benefit from this, but I've never used it, and really don't know.
    I'll add that option to propeller-load in the morning. Someone will have to add an interface to SimpleIDE to set the PIN number though.

    Can you have the pin number search list go in the following order:

    1) cli argument
    2) environment variable
    3) hadrcoded default

    The environment variable could make life much easier since this is very hardware specific, not project specific.
  • David BetzDavid Betz Posts: 14,511
    edited 2016-08-29 11:22
    I updated the sources for propeller-load in my github account to include an option for specifying the gpio pin for resetting the RaspberryPi or other similar boards like the C.H.I.P. board. If you specify -Dreset=gpio, propeller-load will use the pin number specified in the environment variable PROPELLER_LOAD_GPIO if it is set or 17 otherwise. You can also specify -Dreset=gpio<n> to use a specified pin number. For example, -Dreset=gpio12 will use gpio 12.
  • Thanks, David; that was quick.

    In README.txt, it says to run "source setenv.linux" and then make. What should be in the file setenv.linux ? Mine is now:
    export OS=linux
    export CFLAGS=-DRASPBERRY_PI
    export ARM_SBC=1
    
    and then I had to modify the Makefile to conditionally include "OBJS += gpio_sysfs.o" ifeq(ARM_SBC,1) to get it to compile. We may want to change the other references to RASPBERRY_PI to ARM_SBC or somesuch eventually.

    I haven't tested it on a CHIP yet, and it may be a few days, but I'll let you know as soon as I do.
  • There are no references to ARM_SBC in propeller-load. It shouldn't be necessary to define it.
  • Hmmm... There were some problems with the Makefile and README.txt. I think I've fixed them. You should now be able to build the RaspberryPi version like this:
    OS=raspberrypi make
    
  • I'm getting an error when I attempt to compile:
    dzweb@davidzemonname:~/software$ git clone https://github.com/dbetz/propeller-load.git
    Cloning into 'propeller-load'...
    remote: Counting objects: 480, done.
    remote: Compressing objects: 100% (15/15), done.
    remote: Total 480 (delta 5), reused 0 (delta 0), pack-reused 465
    Receiving objects: 100% (480/480), 837.40 KiB | 1.19 MiB/s, done.
    Resolving deltas: 100% (243/243), done.
    Checking connectivity... done.
    dzweb@davidzemonname:~/software$ cd propeller-load/
    dzweb@davidzemonname:~/software/propeller-load$ make
    TOOLCC: gcc
    CFLAGS: -Wall -Isrc/common -Isrc/runtime -Isrc/loader
    LDFLAGS: -Wall -Isrc/common -Isrc/runtime -Isrc/loader
    SPIN:
    bin//bin2c
    src/propeller-load.c: In function ‘main’:
    src/propeller-load.c:292:23: error: ‘PORT_PREFIX’ undeclared (first use in this function)
                 ShowPorts(PORT_PREFIX);
                           ^
    src/propeller-load.c:292:23: note: each undeclared identifier is reported only once for each function it appears in
    make: *** [obj//propeller-load.o] Error 1
    dzweb@davidzemonname:~/software/propeller-load$
    
  • DavidZemon wrote: »
    I'm getting an error when I attempt to compile:
    I got that error earlier, which I fixed as my message above and by restricting it to "make propeller-load". If you clone it again with David Betz' changes, you'll have more joy.
  • altosack wrote: »
    DavidZemon wrote: »
    I'm getting an error when I attempt to compile:
    I got that error earlier, which I fixed as my message above and by restricting it to "make propeller-load". If you clone it again with David Betz' changes, you'll have more joy.

    Fresh checkout. Still no luck
    dzweb@davidzemonname:~/software$ git clone https://github.com/dbetz/propeller-load.git
    Cloning into 'propeller-load'...
    remote: Counting objects: 480, done.
    remote: Compressing objects: 100% (15/15), done.
    remote: Total 480 (delta 5), reused 0 (delta 0), pack-reused 465
    Receiving objects: 100% (480/480), 837.40 KiB | 1.17 MiB/s, done.
    Resolving deltas: 100% (243/243), done.
    Checking connectivity... done.
    dzweb@davidzemonname:~/software$ cd propeller-load/
    dzweb@davidzemonname:~/software/propeller-load$ make propeller-load
    bin//bin2c
    src/propeller-load.c: In function ‘main’:
    src/propeller-load.c:292:23: error: ‘PORT_PREFIX’ undeclared (first use in this function)
                 ShowPorts(PORT_PREFIX);
                           ^
    src/propeller-load.c:292:23: note: each undeclared identifier is reported only once for each function it appears in
    make: *** [obj//propeller-load.o] Error 1
    dzweb@davidzemonname:~/software/propeller-load$
    
  • DavidZemon wrote: »
    altosack wrote: »
    DavidZemon wrote: »
    I'm getting an error when I attempt to compile:
    I got that error earlier, which I fixed as my message above and by restricting it to "make propeller-load". If you clone it again with David Betz' changes, you'll have more joy.

    Fresh checkout. Still no luck
    dzweb@davidzemonname:~/software$ git clone https://github.com/dbetz/propeller-load.git
    Cloning into 'propeller-load'...
    remote: Counting objects: 480, done.
    remote: Compressing objects: 100% (15/15), done.
    remote: Total 480 (delta 5), reused 0 (delta 0), pack-reused 465
    Receiving objects: 100% (480/480), 837.40 KiB | 1.17 MiB/s, done.
    Resolving deltas: 100% (243/243), done.
    Checking connectivity... done.
    dzweb@davidzemonname:~/software$ cd propeller-load/
    dzweb@davidzemonname:~/software/propeller-load$ make propeller-load
    bin//bin2c
    src/propeller-load.c: In function ‘main’:
    src/propeller-load.c:292:23: error: ‘PORT_PREFIX’ undeclared (first use in this function)
                 ShowPorts(PORT_PREFIX);
                           ^
    src/propeller-load.c:292:23: note: each undeclared identifier is reported only once for each function it appears in
    make: *** [obj//propeller-load.o] Error 1
    dzweb@davidzemonname:~/software/propeller-load$
    

    Okay, I had to define the OS variable prior to invoking make. that worked. No auto-detection.
  • altosackaltosack Posts: 132
    edited 2016-08-29 18:49
    You need to specify OS=something. It doesn't default to anything, so there are some undefined things. (edit): I see you figured this out.
  • Try:
    OS=linux make
    
  • DavidZemonDavidZemon Posts: 2,973
    edited 2016-08-29 19:07
    I have propeller-load building 64-bit Linux binaries in TeamCity now. I'd like to provide compressed archives Linux, Windows, and Raspberry Pi (presumably that is binary-compatible with C.H.I.P.). I see there are a few different targets produced in the bin/linux directory, should I include any of them other than propeller-load?

    http://david.zemon.name:8111/project.html?projectId=PropellerLoad&guest=1
  • Okay... nvm about cross compiling. Looks like the Makefile isn't quite setup for that.
  • DavidZemon wrote: »
    Okay... nvm about cross compiling. Looks like the Makefile isn't quite setup for that.
    No, it's not yet. I'm afraid it may inherit that support from the propeller-gcc Makefile. I need to make propeller-load build by itself though.

  • David Betz wrote: »
    DavidZemon wrote: »
    Okay... nvm about cross compiling. Looks like the Makefile isn't quite setup for that.
    No, it's not yet. I'm afraid it may inherit that support from the propeller-gcc Makefile. I need to make propeller-load build by itself though.

    If you're interested in jumping on the cmake bandwagon, I'd happily convert the build for you.
  • DavidZemon wrote: »
    David Betz wrote: »
    DavidZemon wrote: »
    Okay... nvm about cross compiling. Looks like the Makefile isn't quite setup for that.
    No, it's not yet. I'm afraid it may inherit that support from the propeller-gcc Makefile. I need to make propeller-load build by itself though.

    If you're interested in jumping on the cmake bandwagon, I'd happily convert the build for you.
    The problem is, we're stuck with Makefiles for gcc anyway so I don't see any point in using two different build systems. I have enough trouble keeping one straight!

  • David Betz wrote: »
    DavidZemon wrote: »
    David Betz wrote: »
    DavidZemon wrote: »
    Okay... nvm about cross compiling. Looks like the Makefile isn't quite setup for that.
    No, it's not yet. I'm afraid it may inherit that support from the propeller-gcc Makefile. I need to make propeller-load build by itself though.

    If you're interested in jumping on the cmake bandwagon, I'd happily convert the build for you.
    The problem is, we're stuck with Makefiles for gcc anyway so I don't see any point in using two different build systems. I have enough trouble keeping one straight!

    Ah that's right... bleh :(
  • DavidZemon wrote: »
    David Betz wrote: »
    DavidZemon wrote: »
    David Betz wrote: »
    DavidZemon wrote: »
    Okay... nvm about cross compiling. Looks like the Makefile isn't quite setup for that.
    No, it's not yet. I'm afraid it may inherit that support from the propeller-gcc Makefile. I need to make propeller-load build by itself though.

    If you're interested in jumping on the cmake bandwagon, I'd happily convert the build for you.
    The problem is, we're stuck with Makefiles for gcc anyway so I don't see any point in using two different build systems. I have enough trouble keeping one straight!

    Ah that's right... bleh :(
    Do you still require a patch to cmake or will the standard cmake install work as-is?

  • David Betz wrote: »
    DavidZemon wrote: »
    David Betz wrote: »
    DavidZemon wrote: »
    David Betz wrote: »
    DavidZemon wrote: »
    Okay... nvm about cross compiling. Looks like the Makefile isn't quite setup for that.
    No, it's not yet. I'm afraid it may inherit that support from the propeller-gcc Makefile. I need to make propeller-load build by itself though.

    If you're interested in jumping on the cmake bandwagon, I'd happily convert the build for you.
    The problem is, we're stuck with Makefiles for gcc anyway so I don't see any point in using two different build systems. I have enough trouble keeping one straight!

    Ah that's right... bleh :(
    Do you still require a patch to cmake or will the standard cmake install work as-is?

    That patch I mentioned a long time ago was my own mistake. The implemented a breaking change in v3.4 that I didn't notice. Once I became aware I was able to code up a simple if/else based on the version and execute the proper command for each. It was also specific to PropWare.
  • DavidZemon wrote: »
    David Betz wrote: »
    DavidZemon wrote: »
    David Betz wrote: »
    DavidZemon wrote: »
    David Betz wrote: »
    DavidZemon wrote: »
    Okay... nvm about cross compiling. Looks like the Makefile isn't quite setup for that.
    No, it's not yet. I'm afraid it may inherit that support from the propeller-gcc Makefile. I need to make propeller-load build by itself though.

    If you're interested in jumping on the cmake bandwagon, I'd happily convert the build for you.
    The problem is, we're stuck with Makefiles for gcc anyway so I don't see any point in using two different build systems. I have enough trouble keeping one straight!

    Ah that's right... bleh :(
    Do you still require a patch to cmake or will the standard cmake install work as-is?

    That patch I mentioned a long time ago was my own mistake. The implemented a breaking change in v3.4 that I didn't notice. Once I became aware I was able to code up a simple if/else based on the version and execute the proper command for each. It was also specific to PropWare.
    Okay, as long as no "sudo" patches are required, I'd be happy to have propeller-load and proploader be converted to cmake. We could also convert lib although Eric currently owns that project. As I said, gcc, binutils, gdb, etc will have to continue to use make.

  • David Betz wrote: »
    DavidZemon wrote: »
    David Betz wrote: »
    DavidZemon wrote: »
    David Betz wrote: »
    DavidZemon wrote: »
    David Betz wrote: »
    DavidZemon wrote: »
    Okay... nvm about cross compiling. Looks like the Makefile isn't quite setup for that.
    No, it's not yet. I'm afraid it may inherit that support from the propeller-gcc Makefile. I need to make propeller-load build by itself though.

    If you're interested in jumping on the cmake bandwagon, I'd happily convert the build for you.
    The problem is, we're stuck with Makefiles for gcc anyway so I don't see any point in using two different build systems. I have enough trouble keeping one straight!

    Ah that's right... bleh :(
    Do you still require a patch to cmake or will the standard cmake install work as-is?

    That patch I mentioned a long time ago was my own mistake. The implemented a breaking change in v3.4 that I didn't notice. Once I became aware I was able to code up a simple if/else based on the version and execute the proper command for each. It was also specific to PropWare.
    Okay, as long as no "sudo" patches are required, I'd be happy to have propeller-load and proploader be converted to cmake. We could also convert lib although Eric currently owns that project. As I said, gcc, binutils, gdb, etc will have to continue to use make.

    Okay. So long as you're okay with having GCC then be a mix of GNU Make + CMake, I'm down for converting as much as possible - no root required. Obviously Make can invoke the appropriate CMake commands, but I thought from your previous comment you meant that you wanted the build system to be consistent for PropGCC and all of its children.
Sign In or Register to comment.