Programming Prop 1 with a C.H.I.P.
altosack
Posts: 132
in Propeller 1
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 :-).
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 :-).
Comments
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 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.
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.
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.
As you mention, there are use-advantages for CHIP in the field.
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.
In README.txt, it says to run "source setenv.linux" and then make. What should be in the file setenv.linux ? Mine is now: 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.
Fresh checkout. Still no luck
Okay, I had to define the OS variable prior to invoking make. that worked. No auto-detection.
http://david.zemon.name:8111/project.html?projectId=PropellerLoad&guest=1
If you're interested in jumping on the cmake bandwagon, I'd happily convert the build for you.
Ah that's right... bleh
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. 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.