Brief update:
Today I verified that I have a functional /dev/ttyAMA0 on my RPi 2. I installed minicom on the RPi 2 and Tachyon on my QS board, both as described in earlier posts. When I started up minicom, and then did a reset on the QS board, Tachyon came alive, I did a quick '16 BLINK' and the P16 LED started to blink.
I guess now I can play with Tachyon from my RPi 2 with the QS board attached to the RPi 2 UART, and now what do I do? I am wondering how hard it would be to load a Tachyon binary from the RPi 2 too the QS board and have it run, then start up minicom to access the running Tachyon.
I guess with a Propeller HAT in place, you could attach different devices/sensors to test them out, as long as Tachyon has drivers for them. Hmm this could open up some interesting ideas, and experiments, and...
Run minicom and make sure Tachyon works, quit without reset (^A Q), and then run the following in a shell and then type in Tachyon commands. Does it work? If it does, then stty is your problem.
minicom is an interesting program, but it does not have a visible cursor, or at least I do not know how to turn it on/off. Since I have minicom working as expected(less visible cursor), I gave Propforth a try, it did not work because minicom, when set at 230400, is not working. At this point it is to much of hassle to try to get the UART(/dev/ttyAMA0) to work at 230400 BAUD. The other thing that I noticed is, if you change the processor speed, on the RPi, like setting it to Turbo, you might run into problems with getting a correct BAUD rate when you run a serial terminal program, unless of course the program can sense and deal with that.
For the time being I will now be running Tachyon, because the default is now 115200, and it is working with my setup. The problem to work out now is how to get propman to load binaries to the /dev/ttyAMA0 port. It seems minicom can deal with the port, but propman can not, although with a Propeller HAT attached, it has been reported to work, not sure what the problem is here.
The next thing that I will try is to attach my DNA-RTC board, load up Tachyon and see what Tachyon finds available to work with. Now I am starting to give in on my stand not to purchase a Propeller HAT until it comes with those headers pre assembled. It will probably take me a couple of weeks to get the job done, and lots of hours to check for cold solder joints, but what the heck...
I went ahead and gave propman a try on the RPi 2, I downloaded the Dave Hein version of Tachyon(fixed CHECKSUM error), and propman is showing a [BAD CHECKSUM] error with the binary file. This is really baffling, when using the Propeller Tool, it seems to load the binary file correctly, but with propman it shows an error. Now I am wondering if the binary file produced by openspin, for the RPi, is some how producing a binary file to specifically work with propman on an RPi system? Since I do not have a Linux system running on an x86 box, I wonder if the results are repeatable?
I went ahead and gave propman a try on the RPi 2, I downloaded the Dave Hein version of Tachyon(fixed CHECKSUM error), and propman is showing a [BAD CHECKSUM] error with the binary file. This is really baffling, when using the Propeller Tool, it seems to load the binary file correctly, but with propman it shows an error. Now I am wondering if the binary file produced by openspin, for the RPi, is some how producing a binary file to specifically work with propman on an RPi system? Since I do not have a Linux system running on an x86 box, I wonder if the results are repeatable?
Ray
Have you tried downloading from the link since that time? It's been updated several times already since then, all with the normal default baud rate of 115200.
From RPi I downloaded Tachyon from the Dropbox, when I tried that, propman came back with a CHECKSUM error. At that point I downloaded the Dave Hein version, which also came back with a CHECKSUM error. I guess that verifies that propman is having problems with the Tachyon binary file. Hopefully somebody with a Linux x86 system can verify the problem.
Maybe I should do a reverse thing, download the Spin file of Tachyon to the RPi, do an openspin to get a binary and then test that out. But then my earlier test of a test1.spin -> test1.binary did not work, propman came with a "could not find a propeller chip". I think I may just have to work with Tachyon preloaded on the QS board or any other board they I may test.
I haven't tried anything with propman on the RasPi. I've been using the p1load that is part of the propeller-hat repository in the Pimoroni github account. I probably have a propman on one of my RasPi's from when I installed PropellerIDE....just need to find it.
From RPi I downloaded Tachyon from the Dropbox, when I tried that, propman came back with a CHECKSUM error. At that point I downloaded the Dave Hein version, which also came back with a CHECKSUM error. I guess that verifies that propman is having problems with the Tachyon binary file. Hopefully somebody with a Linux x86 system can verify the problem.
Maybe I should do a reverse thing, download the Spin file of Tachyon to the RPi, do an openspin to get a binary and then test that out. But then my earlier test of a test1.spin -> test1.binary did not work, propman came with a "could not find a propeller chip". I think I may just have to work with Tachyon preloaded on the QS board or any other board they I may test.
Ray
I don't have propman (??) but I use BST on Linux and to double check I accessed the binary directly from the dropbox folder without any problems. Sounds like propman is having an issue with checksums for some reason.
I've just located PropellerManager in github but I won't have any time to check it out tonight. I have used David Betz's p1load in Linux without issues and I believe it compiles and works fine on an RPi.
Just to test the ability to load tachyon to the QS from the RPI, why not just connect the QS to the RPi with USB, using p1load? Get that simple setup working before trying to get the whole thing to work via '/dev/ttyAMA0'. Always go back to something you know that works when you are stalled with methods that don't...
Once you get the QS loaded and are able to communicate with it via minicom, SimpleIDE's terminal or other method (via USB), you can then re-attach vi the RPI's GPIO and try communicating via '/dev/ttyAMA0', knowing that the QS is properly loaded with Tachyon. Later, you can work on propman's ability to load the QS. In other words, get one thing working at a time, working from the "known" -step by step, to a point where your method breaks down. Then others can help you sort through one problem at a time.
Just my $.02... Please ignore, if it seems I'm offending.
Haha!! Dennis, I meant physically, not logically. There's no command in the world (except from the wife) that can make that happen quickly!
I have a few RasPi's sitting around..one of them must have PropellerIDE on it! I just grabbed the source from github so I'll build it on my Prop Hat Pi.
edit: ARRRRGGHHHH!!!!! It's a QT project! Why does everybody have to make things so difficult today!!!!! So much for putting it on my mini-footprint RasPi A+
Ray, the p1load that is used with the Propeller Hat software has been working fine!!! I'll try it with the Tachyon binaries. Propman won't be happening any time soon on my little Proppeller Hat test RasPi.
Actually what I am trying to do, sometimes I am not so sure, is test the things that are associated with Propeller IDE, like propman and openspin. One time there was a post that stated, why don't you just download openspin and propman to the RPi and get on with it, or something like that. Or when I make a statement like, Propeller IDE is not ready for prime time, their are defensive posts. Well, I guess somebody has to do the real time testing, and figure what is useable and what is not. Or do I have that idea all screwed up.
So I guess now I will have to verify that openspin and propman work with a USB connected board, I really am trying to eliminate the amount of cords that are connecting the boards in my system. Hopefully I will not be slipping back to just using SimpleIDE via the USB, or just preload the boards with a binary file. Ah, more exciting experiments to be...
pi-propeller-load works fine over the UART on the GPIO on /dev/AMA0, this has been verified by others than me. It does require a further GPIO pin to be connected to the Prop to provide the reset signal. https://github.com/ZiCog/pi-propeller-load
Ray, I get what you are trying to do...it's noble, needed and frustrating. None of this is "plug and play" and some of the hoops are more than the average bear with a Propeller board should need to jump through to program it.
I found my Pi with PropellerIDE on it - PropellerIDE v0.25.1 and p1load (v.009) - it's not the version that uses propman. It looks like I need to do an update. (which is a another good user test!) For the record, this combination worked just fine programming a QuickStart with a USB connection to the P1.
On my PropHat Pi, I have the latest OpenSpin and p1load (v0.1-18-g76f6814, Feb 23 2015) and it works fine loading the Propeller Hat across the serial port. My RasPi A+ can't support a USB connected Propeller board at this time; USB port is tied up with WiFi.
Continuing with my tests, I disconnected my wires(P31/P30) from the QS board, and plugged in the USB cable between RPi and the QS board. I created a small test1.spin file:
Compiling test1.spin
Done.
Program size is 28 bytes
pi@raspberrypi ~/programs/test $ propman test1.binary
Using GPIO pin 17 for hardware reset
Connecting to 'ttyAMA0'... [ NOT FOUND ]
pi@raspberrypi ~/programs/test $
It looks like propman, when used from the command line, always tries to use /dev/ttyAMA0. I wonder if there are some switches for propman to direct it to use /dev/ttyUSBxx. Maybe all that is strictly handled within Propeller IDE. Interesting stuff.
It looks like propman, when used from the command line, always tries to use /dev/ttyAMA0. I wonder if there are some switches for propman to direct it to use /dev/ttyUSBxx. Maybe all that is strictly handled within Propeller IDE. Interesting stuff.
Ray
What does PropellerIDE have to do with this? You didn't use it at all in either of those two commands you ran.
Another interesting discovery, since the Propeller IDE does not do any keyboard input, you can still create a Spin file with an external editor then use the Propeller IDE 'Open' to load that file, which I did. Now in Propeller IDE the /dev/ttyUSB0 shows up as a selection. I picked /dev/ttyUSB0 and did a 'RUN' and ...
nothing.
Below is the code.
So I buy my Propeller HAT for the RPi, set it up, fire up Propeller IDE, and it does not work as expected. Would be nice to have an alternative method to use the product wouldn't you agree? Or am I still missing something?
Do what? You have something very broken there. If that is true I would not move any further forward till your system is fixed.
If by system you mean Propeller IDE, that is why I am experimenting with alternative ideas. I am still very interested in getting a Propeller HAT for the RPi, but...
If were to buy a Propeller HAT for the RPi today, how would I use it? Probably would have to figure out some way of loading Spin binary files so I could at least see and LED blink. Since there is no indication as to when the Propeller IDE will be fixed, at least for the RPi, then alternative methods have to looked at. The search goes on.
As I think I mentioned someplace above (OR MAYBE THE OTHER PROP-HAT THREAD), your favorite editor, the latest OpenSpin ant the p1load in the Pimoroni github repository works great.
I'm going to try the latest p1load from the github repo when I'mI'm back by my RasPi.
Since it's a RasPi A+, I want small footprint software.
...your favorite editor, the latest OpenSpin and the p1load in the Pimoroni github repository works great.
As soon as I figure out how to get, and set up p1load, I think I will try to get Geany too be the IDE. If that does not work then I guess doing it from the command line might be a temporary solution.
My setup is, I have xrdp running on the RPi, and I use mstsc in Windows 7 to log in. Everything else works in this manner, including SimpleIDE, Geany, etc.
I've installed PropellerIDE 0.30.1 on my RasPi2 Desktop - it has no keyboarding issues with the RasPi having a physically connected keyboard and driving the HDMI display. I haven't compiled an loaded a program with it yet. (next test)
I installed it to get a copy of Propman to put on my headless A+ to compare to p1load. Before the propman binary I copied would run, I needed to install some of the QT pieces. Once that was done, propman gives me the [ BAD CHECKSUM ] message with my tiny little Spin program compiled with the latest OpenSpin. This program loads just fine with the latest p1load. Maybe a propman issue with checksums??? I need to compile and load some Spin code with PropellerIDE 0.30.1 on my RasPi desktop to verify this. First, yard work is calling!!!
Again, the latest openspin and p1load work just fine with Propeller Hat - and without having to load a bunch of additional QT libraries!!
Taking a hint from the previous post, I reworked my RPi system, using an HDMI monitor, local keyboard and mouse, Propeller IDE works as expected. I reattached the QS board via P31/P30/RESn and now the files compile and run as expected using /dev/ttyAMA0. This is a big relief, but a PIA, because I like to work from my Windows 7 desktop. So for a dedicated RPi setup, so far so good. Hopefully more than one system setup will be supported in the future. Sorry for the bad press.
Further testing, for us here in the USA, make sure you have the right keyboard setup, otherwise more headaches. The one annoying thing with the classic mode, I guess that is what it is called, when you use '_', that gets washed out. So, below my version of blinker.
Since Propeller IDE does not open, load, and run binary files, I guess, a command line solution should be available. It is said that p1load does this but, how do you get that installed on the RPi, and able to run it from the command line, easily?
So far my dedicated(PIA) RPi desktop setup, has a functional Propeller IDE working as expected, although working with binary files should have been added also, I would have expected.
Writing small programs and getting some weird behavior from Propeller IDE. For one how do I get the program below to show up in the terminal window? Still using the QS board on /dev/ttyAMA0. Other things that occur, occiasinaly when you hit RUN, Propeller IDE closes; when you do a build, the building info window opens up and just hangs there; those are just a few items, and I am not even giving Propeller IDE a good workout. Not sure if you can start any serious programming with this just yet.
Ray
'IOprog.spin
CON
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000
OBJ
'term : "Extended_FDSerial"
term : "FullDuplexSerial"
misc : "tools"
PUB Start
term.Start(31,30,0,115200)
misc.waitms(1000)
Main
PUB Main
repeat 5
term.str(string("This is the IOprog!"))
misc.waitms(1000)
Comments
Today I verified that I have a functional /dev/ttyAMA0 on my RPi 2. I installed minicom on the RPi 2 and Tachyon on my QS board, both as described in earlier posts. When I started up minicom, and then did a reset on the QS board, Tachyon came alive, I did a quick '16 BLINK' and the P16 LED started to blink.
I guess now I can play with Tachyon from my RPi 2 with the QS board attached to the RPi 2 UART, and now what do I do? I am wondering how hard it would be to load a Tachyon binary from the RPi 2 too the QS board and have it run, then start up minicom to access the running Tachyon.
I guess with a Propeller HAT in place, you could attach different devices/sensors to test them out, as long as Tachyon has drivers for them. Hmm this could open up some interesting ideas, and experiments, and...
Ray
For the time being I will now be running Tachyon, because the default is now 115200, and it is working with my setup. The problem to work out now is how to get propman to load binaries to the /dev/ttyAMA0 port. It seems minicom can deal with the port, but propman can not, although with a Propeller HAT attached, it has been reported to work, not sure what the problem is here.
The next thing that I will try is to attach my DNA-RTC board, load up Tachyon and see what Tachyon finds available to work with. Now I am starting to give in on my stand not to purchase a Propeller HAT until it comes with those headers pre assembled. It will probably take me a couple of weeks to get the job done, and lots of hours to check for cold solder joints, but what the heck...
Ray
Ray
Have you tried downloading from the link since that time? It's been updated several times already since then, all with the normal default baud rate of 115200.
Here is a direct link to the current Explorer binary if you are having problems locating it.
BTW, there are lots of "drivers" for Tachyon, although some can hardly be called a driver, there is so little to them
Maybe I should do a reverse thing, download the Spin file of Tachyon to the RPi, do an openspin to get a binary and then test that out. But then my earlier test of a test1.spin -> test1.binary did not work, propman came with a "could not find a propeller chip". I think I may just have to work with Tachyon preloaded on the QS board or any other board they I may test.
Ray
I haven't tried anything with propman on the RasPi. I've been using the p1load that is part of the propeller-hat repository in the Pimoroni github account. I probably have a propman on one of my RasPi's from when I installed PropellerIDE....just need to find it.
I'll try and test.
I don't have propman (??) but I use BST on Linux and to double check I accessed the binary directly from the dropbox folder without any problems. Sounds like propman is having an issue with checksums for some reason.
I've just located PropellerManager in github but I won't have any time to check it out tonight. I have used David Betz's p1load in Linux without issues and I believe it compiles and works fine on an RPi.
On an RPi2:
dgately
Ray,
Just to test the ability to load tachyon to the QS from the RPI, why not just connect the QS to the RPi with USB, using p1load? Get that simple setup working before trying to get the whole thing to work via '/dev/ttyAMA0'. Always go back to something you know that works when you are stalled with methods that don't...
Once you get the QS loaded and are able to communicate with it via minicom, SimpleIDE's terminal or other method (via USB), you can then re-attach vi the RPI's GPIO and try communicating via '/dev/ttyAMA0', knowing that the QS is properly loaded with Tachyon. Later, you can work on propman's ability to load the QS. In other words, get one thing working at a time, working from the "known" -step by step, to a point where your method breaks down. Then others can help you sort through one problem at a time.
Just my $.02... Please ignore, if it seems I'm offending.
dgately
I have a few RasPi's sitting around..one of them must have PropellerIDE on it! I just grabbed the source from github so I'll build it on my Prop Hat Pi.
edit: ARRRRGGHHHH!!!!! It's a QT project! Why does everybody have to make things so difficult today!!!!!
Ray, the p1load that is used with the Propeller Hat software has been working fine!!! I'll try it with the Tachyon binaries. Propman won't be happening any time soon on my little Proppeller Hat test RasPi.
So I guess now I will have to verify that openspin and propman work with a USB connected board, I really am trying to eliminate the amount of cords that are connecting the boards in my system. Hopefully I will not be slipping back to just using SimpleIDE via the USB, or just preload the boards with a binary file. Ah, more exciting experiments to be...
Ray
pi-propeller-load works fine over the UART on the GPIO on /dev/AMA0, this has been verified by others than me. It does require a further GPIO pin to be connected to the Prop to provide the reset signal.
https://github.com/ZiCog/pi-propeller-load
OpenSpin works fine on the Pi
https://github.com/parallaxinc/OpenSpin
Now, as far as I know that loader goodness has been adopted by other loaders so mine should be redundant now. I have no idea I have not tried them.
I found my Pi with PropellerIDE on it - PropellerIDE v0.25.1 and p1load (v.009) - it's not the version that uses propman. It looks like I need to do an update. (which is a another good user test!) For the record, this combination worked just fine programming a QuickStart with a USB connection to the P1.
On my PropHat Pi, I have the latest OpenSpin and p1load (v0.1-18-g76f6814, Feb 23 2015) and it works fine loading the Propeller Hat across the serial port. My RasPi A+ can't support a USB connected Propeller board at this time; USB port is tied up with WiFi.
Ray
What does PropellerIDE have to do with this? You didn't use it at all in either of those two commands you ran.
Another interesting discovery, since the Propeller IDE does not do any keyboard input, you can still create a Spin file with an external editor then use the Propeller IDE 'Open' to load that file, which I did. Now in Propeller IDE the /dev/ttyUSB0 shows up as a selection. I picked /dev/ttyUSB0 and did a 'RUN' and ...
nothing.
Below is the code.
So I buy my Propeller HAT for the RPi, set it up, fire up Propeller IDE, and it does not work as expected. Would be nice to have an alternative method to use the product wouldn't you agree? Or am I still missing something?
Ray
' test1.spin CON _CLKMODE = xtal1 + pll16x _XINFREQ = 5_000_000 MY_LED_PIN = 16 PUB Start DIRA[MY_LED_PIN] := 1 repeat OUTA[MY_LED_PIN] := 1 waitcnt(cnt + clkfreq) OUTA[MY_LED_PIN] := 0 waitcnt(cnt + clkfreq)If were to buy a Propeller HAT for the RPi today, how would I use it? Probably would have to figure out some way of loading Spin binary files so I could at least see and LED blink. Since there is no indication as to when the Propeller IDE will be fixed, at least for the RPi, then alternative methods have to looked at. The search goes on.
Ray
I'm going to try the latest p1load from the github repo when I'mI'm back by my RasPi.
Since it's a RasPi A+, I want small footprint software.
Ray
Are you using Propeller IDE over VNC?
Ray
I've installed PropellerIDE 0.30.1 on my RasPi2 Desktop - it has no keyboarding issues with the RasPi having a physically connected keyboard and driving the HDMI display. I haven't compiled an loaded a program with it yet. (next test)
I installed it to get a copy of Propman to put on my headless A+ to compare to p1load. Before the propman binary I copied would run, I needed to install some of the QT pieces. Once that was done, propman gives me the [ BAD CHECKSUM ] message with my tiny little Spin program compiled with the latest OpenSpin. This program loads just fine with the latest p1load. Maybe a propman issue with checksums??? I need to compile and load some Spin code with PropellerIDE 0.30.1 on my RasPi desktop to verify this. First, yard work is calling!!!
Again, the latest openspin and p1load work just fine with Propeller Hat - and without having to load a bunch of additional QT libraries!!
Ray
Ray
' test1.spin CON _CLKMODE = xtal1 + pll16x _XINFREQ = 5_000_000 MY_LED_PIN = 16 WAIT_TIME = 500 OBJ misc : "tools" PUB Start repeat misc.high(MY_LED_PIN) misc.waitms(WAIT_TIME) misc.low(MY_LED_PIN) misc.waitms(WAIT_TIME) ' DIRA[MY_LED_PIN] := 1 ' repeat ' OUTA[MY_LED_PIN] := 1 ' waitcnt(cnt + clkfreq) ' OUTA[MY_LED_PIN] := 0 ' waitcnt(cnt + clkfreq)'' Tools PUB wait(time) waitcnt((80_000_000 * time) + cnt) PUB waitms(time) waitcnt(((80_000_000 / 1000) * time) + cnt) PUB high(pin) DIRA[pin] := %1 OUTA[pin] := 1 PUB low(pin) DIRA[pin] := %1 OUTA[pin] := 0So far my dedicated(PIA) RPi desktop setup, has a functional Propeller IDE working as expected, although working with binary files should have been added also, I would have expected.
Ray
Download the source and build it. Build instructions in the README.txt file.
This functionality should be in the other loaders by now. Like the one supplied with prop-gcc or whatever pimoroni uses. I have never tried those.
Ray
'IOprog.spin CON _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 OBJ 'term : "Extended_FDSerial" term : "FullDuplexSerial" misc : "tools" PUB Start term.Start(31,30,0,115200) misc.waitms(1000) Main PUB Main repeat 5 term.str(string("This is the IOprog!")) misc.waitms(1000)