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).