GPIO Reset Functionality

[Gadgetoid]

propeller-load in the propgcc repository supports a -D flag which accepts device options- one of these allows reset via a GPIO pin and is essential for getting the loader to function on devices like the Raspberry Pi.

https://code.google.com/p/propgcc/source/browse/loader/src/propeller-load.c

This functionality came from here, I think: https://github.com/ZiCog/pi-propeller-load

Unfortunately pi-propeller-load includes a lot of spin/propgcc compilation in its default Makefile, making it a dog to compile as standard.

[dbetz]

Here we see the problem. People have complained that propeller-load is too complex, too many options. Now, we're talking about adding those options to p1load which threatens to make it just as complex. I intend to support the GPIO method of resetting the Propeller in p1load but I'm not sure I'm going to do it by dragging in all of the .cfg file complexity of propeller-load.

Also, you say propeller-load is painful to compile because of its use of propgcc and OpenSpin. If add two-pass loading to p1load we will at least require the use of OpenSpin. The use of propgcc can be avoided though.

The bottom line is that if you want a simple loader you have to limit the number of features. What we could shoot for though is a moderately complex loader that has better organized source code and better internals documentation.

[Gadgetoid]

You're quite right. Propeller-load includes a myriad features that could easily be labelled "bloat", and I certainly wouldn't want p1load to mirror the overtly complex ".cfg" file complexity you mention.

I think requiring OpenSpin is acceptable and understandable, it's nowhere near as complicated as propgcc, and it feels more correct to keep this tool bound to the original language of the Propeller.

[dbetz]

Well, the config files serve a purpose. In fact, very similar files are used by avrdude which is the loader that the Arduino uses. They have allowed us to handle many different boards without requiring the user to specify a myriad of options on the command line. In any case, I'm not planning to add config files to p1load anytime soon if ever. A lot of the complexity handled by the config files in propeller-load has to do with the XMM memory model which is not used by Spin.

[dbetz]

Oops. Didn't mean to close the issue. Hit the wrong button. Sorry! :-)

[Gadgetoid]

Interesting- I had wondered what on earth the config files were for. Unlike the Arduino- with a range of different potential micros- we basically just have a single target.

[dbetz]

Not really. We have different clock settings for different boards, different baud rates needed, different pins used for VGA, PS2 keyboards, etc, and for XMM modes, very different external memory hardware.

[Gadgetoid]

I've been trying to test why p1load wont actually detect a Propeller when using GPIO reset. As far as I can tell it's correctly toggling the reset line correctly, so I think it may be a problem elsewhere. I can find a Propeller board connected via USB on /dev/ttyUSB0, but nothing on /dev/ttyAMA0.

[dbetz]

Hi Philip,

I’m currently traveling on business and won’t be back to my test station until late this evening. I’ll try to do some more work to resolve the GPIO and RaspberryPi issues with p1load over the weekend. Sorry for the trouble!!

David

On Feb 6, 2015, at 11:39 AM, Philip Howard notifications@github.com wrote:

I've been trying to test why p1load wont actually detect a Propeller when using GPIO reset. As far as I can tell it's correctly toggling the reset line correctly, so I think it may be a problem elsewhere. I can find a Propeller board connected via USB on /dev/ttyUSB0, but nothing on /dev/ttyAMA0.

—
Reply to this email directly or view it on GitHub #2 (comment).

[Gadgetoid]

Oh it's absolutely no trouble, I'm just trying to provide as much helpful input as possible by trying to isolate the problem.

It's strange that pi-propeller-load works, but it's got a slightly different implementation of the communication protocol. I believe it uses hwfind() in PLoadLib, here: https://github.com/ZiCog/pi-propeller-load/blob/9244681e7a35083d8a66af071f710cef85730bf6/src/PLoadLib.c#L143

In the p1load code, the RBit() seems to continually return -1, indicating that there's nothing in the receive buffer.

[dbetz]

Yes, I’m aware that the protocol code is different. My plan was to make the code in p1load/ploader.c be a reference C implementation of the Propeller download protocol without any dependencies on the serial driver being used. PLoadLib is pretty tightly coupled with the osint_xxx.c serial drivers.

On Feb 6, 2015, at 12:22 PM, Philip Howard notifications@github.com wrote:

Oh it's absolutely no trouble, I'm just trying to provide as much helpful input as possible by trying to isolate the problem.

It's strange that pi-propeller-load works, but it's got a slightly different implementation of the communication protocol. I believe it uses hwfind() in PLoadLib, here: https://github.com/ZiCog/pi-propeller-load/blob/9244681e7a35083d8a66af071f710cef85730bf6/src/PLoadLib.c#L143 https://github.com/ZiCog/pi-propeller-load/blob/9244681e7a35083d8a66af071f710cef85730bf6/src/PLoadLib.c#L143
In the p1load code, the RBit() seems to continually return -1, indicating that there's nothing in the receive buffer.

—
Reply to this email directly or view it on GitHub #2 (comment).

[Gadgetoid]

I don't know what you did, but I just built the latest code at Brett's suggestion and tested:

pi@maxim ~/Development/p1load $ ./bin/linux/p1load -Dreset=gpio,17,0 -r ../Propeller-HAT-Testing/led_pwm_demo.binary
Using GPIO pin 17 as Propeller reset (LOW).
Found propeller version 1 on /dev/ttyAMA0
Loading '../Propeller-HAT-Testing/led_pwm_demo.binary' (468 bytes)
Loading hub memory ... 468 -- OK

It works! Yay!

[bweir]

Yay!!

[dbetz]

I’m glad it’s working for you now. Thanks for helping with the testing!

On Feb 8, 2015, at 7:21 PM, Philip Howard notifications@github.com wrote:

I don't know what you did, but I just built the latest code at Brett's suggestion and tested:

pi@maxim ~/Development/p1load $ ./bin/linux/p1load -Dreset=gpio,17,0 -r ../Propeller-HAT-Testing/led_pwm_demo.binary
Using GPIO pin 17 as Propeller reset (LOW).
Found propeller version 1 on /dev/ttyAMA0
Loading '../Propeller-HAT-Testing/led_pwm_demo.binary' (468 bytes)
Loading hub memory ... 468 -- OK
It works! Yay!

—
Reply to this email directly or view it on GitHub #2 (comment).

[Gadgetoid]

It's a bit of a fudge to tie it in with Propeller IDE on the Pi, but doable. I remap and grant access to serial like so:

pi@daos ~ $ cat fixserial
#!/usr/bin/env bash
sudo usermod -a -G dialout pi
sudo usermod -a -G tty pi
sudo ln -s /dev/ttyAMA0 /dev/ttyUSB99

And wrap the call to p1load like so:

pi@daos ~ $ cat p1load
#!/usr/bin/env bash
echo "Loading: $@"
sudo /usr/bin/p1load -Dreset=gpio,17,0 "$@"

[dbetz]

I don’t think you need to be in the tty group. Also, once you’ve added yourself to the dialout group, you won’t need sudo to run p1load either. I haven’t needed to create the symbolic link from USB99 to AMA0 but then I am running p1load from the command line. I’m about to check in changes to make gpio,17,0 the default setting for the RaspberryPi so you shouldn’t need that parameter either.

On Feb 8, 2015, at 8:12 PM, Philip Howard notifications@github.com wrote:

It's a bit of a fudge to tie it in with Propeller IDE on the Pi, but doable. I remap and grant access to serial like so:

pi@daos ~ $ cat fixserial
#!/usr/bin/env bash
sudo usermod -a -G dialout pi
sudo usermod -a -G tty pi
sudo ln -s /dev/ttyAMA0 /dev/ttyUSB99
And wrap the call to p1load like so:

pi@daos ~ $ cat p1load
#!/usr/bin/env bash
echo "Loading: $@"
sudo /usr/bin/p1load -Dreset=gpio,17,0 "$@"
—
Reply to this email directly or view it on GitHub #2 (comment).

[dbetz]

Ugh. I'm wrong and now p1load doesn't seem to work for me at all on my new install of Raspian. I added myself to the dialout, tty, and gpio groups but I still seem to need to use sudo to run p1load. Also, even then, it doesn't work. I get errors like this:

dbetz@raspberrypi ~/p1load $ sudo ./bin/linux/p1load fibo.binary -r -t
Using GPIO pin 17 as Propeller reset (LOW).
^Cerror: can't find a port with a propeller chip

I have no idea what's going wrong. I guess I need to find a document somewhere that talks about using gpio pins.

[dbetz]

Well, I realized that I had forgotten to disable the serial console. I did that and now for some reason my wlan0 interface is not getting an IP address. I have the SSID and password set correctly. In fact, it worked before. It just didn't work after I rebooted after disabling the serial console. I suppose I must have broken something but I'm not sure what.

[dbetz]

I'm not sure what is going wrong with my wifi network but I tried p1load on the console and it seems to work fine. The default of reset=gpio,17,0 seems to be working and auto port detection seems to also. I can't figure out how to get p1load to work without sudo though. It doesn't seem to help to add myself to the dialout, tty, and gpio groups. What else is needed? Anyone know?

[Gadgetoid]

It's pretty normal for things on Raspberry Pi to require "sudo", it's sort-of become the lay of the land due to GPIO being either impossible without it, or it being extremely complex to set up permissions otherwise. It's a horribly bad habit, but it's not going to die :(

As for "ln -s /dev/ttyAMA0 /dev/ttyUSB99" - this is a kludge to get around the fact that the current Propeller IDE will only look at ttyUSB* devices, and ignores all other serial ports.

[bweir]

gulp I'm gonna be fixing that one pretty soon, but I've been holding off
because once I start really looking at the serial stuff, it's going to be a
can of worms I can't close until I've replaced Qext with QSerialPort. I
can't tell if anyone is even maintaining Qext anymore.

[Gadgetoid]

A better solution for a run-as-root-wrapper:

sudo chown root /usr/share/propelleride/bin/p1load
sudo chmod 4755 /usr/share/propelleride/bin/p1load