Use on RPi 2 with GPIO Serial and a 96 MHz Propeller 1.

[BrianHoldsworth]

I'm trying to use proploader on a Raspberry Pi 2 with a Propeller HAT. The HAT has a 6 MHz crystal, and was originally created 5 or 6 years ago. The documentation for the HAT refers to propman, rather than this project.

I haven't tried using propman. With proploader I am doing a command like this:

$ proploader -D clkfreq=96000000 -s blink.binary -v

This doesn't work and I always get: "ERROR: Propeller not found on /dev/ttyAMA0".

I have disabled the serial console on my Pi. And there doesn't seem to be any conflict with accessing the serial device on the Pi side.

Is it possible that proploader is incompatible with the Propeller HAT, even though documentation indicates it worked fine with propman?

[PropGit]

proploader communicates via serial port or WiFi, but it sounds like you have a direct connection via RPi I/O pin.

I wasn't aware that propman had this feature, but you can find the propman (Propeller Manager) repository here: https://github.com/parallaxinc/PropellerManager

[BrianHoldsworth]

@PropGit Well, yes and no. The Propeller HAT uses the UART on the RPI's GPIO header. So it is just a serial port connected to the appropriate pins on the Propeller 1, much as you would do from any PC connecting to the Propeller.

I may need to install Raspbian (currently using Arch), and the PropellerIDE, and try with propman. If I can get that working, it would seem easier to speculate on what could prevent it from working with proploader, right?

[PropGit]

I see. Perhaps it's using the RTS signal rather than the DTR signal to reset the Propeller. Do you have an oscilloscope that you could use to monitor the Propeller's reset pin during download from PropLoader?

[BrianHoldsworth]

I think that could be the problem. The Propeller HAT schematic shows that GPIO 17 on the Pi is connected to the Propeller RESET. I think that GPIO 17 has the alternate function of being an RTS signal for the UART.

Is this a known difference between proploader and propman?

[drawkula]

p1load might help:
https://github.com/dbetz/p1load/blob/master/osint_linux.c#L57-L60

[BrianHoldsworth]

@drawkula Indeed. I compiled p1load and it works fine. So is there an actual issue with proploader not being "RPi GPIO UART compatible"?

I'm assuming that proploader would work on my RPi 2 if I was routing through a USB-Serial adapter from the Pi to the Propeller, instead of just plugging onto the GPIO header. Maybe that is too rare of a use-case to warrant support in proploader.

[drawkula]

Propeller loaders using USB ™should™ work on the PI+Linux like on every other Linux system.

[PropGit]

Proploader seems to have support for this. The help says to use the -D option to set the reset variable. I can't find documentation on exactly what, but looks like '-D reset=rts' based on code I see in the repo.

There's also direct mention (and configuration?) for RPi listed in the top entry in code I found with this search: https://github.com/parallaxinc/PropLoader/search?q=reset&unscoped_q=reset

[BrianHoldsworth]

@PropGit I tried proploader -D reset=rts ... but getting the same error.

Looking at the code linked above from p1load, it is actually handling three cases: DTR, RTS, and GPIO 17 on the RPi. So, perhaps my setup isn't even enabling any flow-control and just relies on code directly controlling GPIO 17 at the appropriate time(s).

[dbetz]

I have a propeller hat somewhere. I’ll find it and give it a try.

…

Sent from my iPhone

On Aug 13, 2020, at 4:04 PM, Brian Holdsworth ***@***.***> wrote:  I think that could be the problem. The Propeller HAT schematic shows that GPIO 17 on the Pi is connected to the Propeller RESET. I think that GPIO 17 has the alternate function of being an RTS signal for the UART. Is this a known difference between proploader and propman? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[dbetz]

Which model of RaspberryPi are you using? I found my Propeller Hat but it was plugged into an ancient Raspberry Pi 1 Model A+. I think the serial ports have changed in the more recent models. Which are you using?

[BrianHoldsworth]

@dbetz I'm using the RPi 2 Model B, which has the standard 40-pin GPIO connector used on all RPi's except the original, which had the 26-pin GPIO connector. Your A+ has the same connector. The RPi 3 changes which serial port peripheral on the SoC is connected to the GPIO (/dev/ttyS0 instead of /dev/ttyAMA0).

[dbetz]

I gave up on the Model A board and switched to a RPi 3 Model B. I have proploader built for the Pi. What command line did you use and what file are you trying to load? Any chance you could send it to me?

[BrianHoldsworth]

@dbetz Command-line is as described in my first post above. File I'm trying to load is the blink.binary file that I compiled using openspin on the Pi, from the blink.spin file included in the repo.

https://github.com/parallaxinc/PropLoader/blob/master/blink.spin

[dbetz]

Okay, thanks. That's what I'm doing as well. I'll work on this more tonight. I have everything built and installed so I hope it won't be difficult to get this bug fixed. Thanks for reporting it!

[BrianHoldsworth]

@dbetz Ah, well thank you and others for the help. Note I do have a workaround by using p1load instead. But I was hoping to consolidate my tools for Propeller 1/2 and hopefully rely on Sublime 3 (w/ some Propeller helpers)+openspin+fastspin (if I need multiple language support)+proploader.

[dbetz]

I'm afraid I'm having trouble configuring the serial port on my Pi. I enabled the serial port and disabled logins on it but I seem to only be able to open it once and after that it's listed as "busy" even though the previous invocation of proploader has exited and no one else is using the port. What's the trick of making the serial port available? I added the "pi" user to the "dialout" and "tty" groups.

[BrianHoldsworth]

@dbetz Several things may be required to ensure the GPIO serial port is free.

1. Remove any references to /dev/ttyS0 (or /dev/ttyAMA0) in /boot/cmdline.txt
2. Be sure to enable_uart=1 in /boot/config.txt
3. Make sure you disable any getty.service trying to use the serial port, or remove that entry from /etc/inittab (depending on your Linux distro, and how it manages getty).
4. If permissions issue seem to arise, you can always try as root.

[dbetz]

Okay, there is a bug that I'll fix in the morning. It has to do with the parsing of the "reset" parameter. You should be able to do this:

proploader -s -p /dev/serial0 -Dloader=rom -Dreset=gpio17 blink.binary

Unfortunately, the parser has a bug and that doesn't work. Also, I should probably make -Dreset=gpio17 the default for Raspberry Pi builds. I should also make it automatically find /dev/serial0. I guess the Pi doesn't use /dev/ttyAMA0 anymore.

Beyond that, you need the -Dloader=rom to bypass Jeff Martin's fast loader. The fast loader should work but requires that you tell proploader the clock settings for the board you're loading and the default assumes an 80mhz clock speed. That's why it doesn't work with the Propeller Hat which uses a 96mhz clock speed. Changing that requires more -D options or a board configuration file. I'll try to come up with an example of that as well.

[dbetz]

I looked at this again this morning and it turns out there isn't really a parsing bug although the syntax of the proploader command needs better documentation. This command works with the current code as long as you compile proploader with OS=raspberrypi:

proploader -s -p /dev/serial0 -Dloader=rom -Dreset=gpio,17 blink.binary

Of course, it would be better if "gpio,17" was the default value for "reset" on Raspberry Pi builds and the code should look for /dev/serial0 so it can be found by default as well.

[BrianHoldsworth]

Yes. This works for me too. I see I have a relatively obscure setup and it's an easy solution once you determine the reset behavior is the root problem. A couple things could have helped me:

1. More verbose error reporting that pointed me toward the reset step being ineffective.
2. More explanation in the command-line help about the options available with -Dreset and -Dloader.
3. Maybe, if this setup is not all that obscure, then some shortcut option that informs proploader that the serial connection is using the RPi GPIO connector,

BTW, I don't need to specify the port on my RPi 2, since proploader already detects /dev/ttyAMA0. Also, if I leave out theloader option, it still works after stepping the baudrate down to 115.2Kbps.

[dbetz]

What OS are you running on your Pi? I can't get /dev/ttyAMA0 to work but /dev/serial0 works fine. I hope that different versions of the Pi OS don't use different names for the serial ports.

[dbetz]

I've just pushed a change that allows this command to work on the Raspberry Pi:

proploader -s -p /dev/serial0 -Dloader=rom blink.binary

I still need to look into what is needed to get the fast loader to work on the Raspberry Pi. I also don't understand serial port naming on the Pi as I need to use /dev/serial0 but others seem to need /dev/ttyAHA0.

[BrianHoldsworth]

This page may be useful: https://www.circuits.dk/setup-raspberry-pi-3-gpio-uart/

I use Arch Linux ARM, which follows same naming.

[dbetz]

Thanks for the link. I'm using the OS that I downloaded from the Raspberry Pi site so I'm inclined to make proploader work with that by default since I imagine that is the most likely OS that our users will use. I hope they all have the same naming conventions.

[dbetz]

Okay, I see. It looks like /dev/serial0 should be a symbolic link to the appropriate port to use. On my system, it points to /dev/ttyS0 but on yours I imagine it points to /dev/ttyAMA0. Is that correct? In any case, I've changed the code to look for serial ports on the Raspberry Pi starting with "/dev/serial" and my Propeller Hat is now automatically detected and the following command works:

proploader -s -Dloader=rom blink.binary

[dbetz]

I tried getting the fast loader to work without any success. I used this command line:

proploader -s -Dclkfreq=96000000 -Dclkmode=pll16x blink.binary

Unfortunately, it tried many times at various baud rates but ended up falling back to the ROM loader.

[BrianHoldsworth]

@dbetz I've now been using PropLoader extensively with a different Propeller board (custom design) attached to an RPi. It works reliably with the notes above, using the -Dloader=rom option. Not having access to the "fast-loader" is something I'd like to resolve for this configuration.

As the original author, I'd like to recommend we either close or re-purpose this thread as a more specific issue of making the fast loader work with an RPi connected via the GPIO connector. I am currently using Propeller serial code to communicate with an RPi Zero at up to 1.5 Mbps with excellent reliability. In my ideal solution, I'd like to be able to load code on to the Propeller at a similarly fast baud rate.

What do you think regarding open of a new issue vs. continue this already lengthy thread?

[PropGit]

@BrianHoldsworth - I missed your proposal until now. Closing this issue and creating another more specific to the intended solution is indeed the best answer, as you've probably already decided. Please reference this issue from the new issue.

[BrianHoldsworth]

@PropGit Partially fixable using #52 . I say "partially" because there is probably still a matter of documentation to be added around the use of "-Dreset".