I watched Propeller HAT's picture.
There is japanese strings in top right of board.
1st kanji(2 characters) mean pirate.
2nd katakana(2 characters) mean robot.
3rd kanji(2 characters) mean ninja.
4th hiragana(2 characters) monkey.
I understand 1st kanji because logo is pirate.
I have no idea about another kanji.
Has anybody been to the Pimoroni Learn site for the Propeller HAT? WOW. Maybe Parallax should hire those guys to start a PASM section. I was looking at the PASM code for doing an LED blinky, I think I started to understand PASM. :-) I like the way the code is commented, it is not terse like some of the other examples that I have seen. Now I am wondering how far Pimoroni is going to take that Learn section?
Next example, at the Pimoroni Learn site, maybe a double(separate cogs) LED blinky, with a pause subroutine, so you could set the pin numbers and pause times in the main program, if that section is actually called that. Just thinking out loud...
Ray
You've just made my day. Thank you. I wrote these tutorials as I was learning PASM myself, so I had a very fresh experience of the problems I ran into personally and how best, I hope anyway, to pass that knowledge on.
If I were irresponsible I'd ignore all of our other products and just focus on Propeller PASM tutorials, unfortunately I'm responsible for all of our Python software and for authoring a great deal of the learning portal. I do, however, have some more PASM and SPIN guides in the works and if you have any suggestions then I'll consider adding them to my TODO list.
@caskaz
PIrate
MOnkey
RObot
NInja
( Ninja is wrong? Uh oh! )
For anyone who hasn't looked at the Python code for Propeller HAT, I encourage you to give it a try. I've written a couple of Python libraries that contain embedded Propeller binaries, these are uploaded when you "import" the Python library and then communication is established over UART/Serial to control them.
I gave up on the Forth testing, and installed SimpleIDE 0-9-45 on the RPi+. Since I am not willing or able to do the soldering of the headers correctly, I will use my QS rev-A board as a stand in for the Propeller HAT until the HAT boards with everything soldered on become available. In the mean time I will be testing RPi+ <-> QS board via the GPIO Tx/Rx and P31/P30 connection.
I guess the first problem to address is, SimpleIDE reports, no Propeller chip to be found. The QS board is a rev-A board, do I have to fiddle fool around with this board to make it work? No, I will not use PropellerIDE until the quirks have been resolved.
So, I went ahead and installed PropellerIDE for the RPi 2 using the detailed instructions on the Pimoroni site, everything seemed to go as expected. I am using my RPi 2 as a headless unit, I use mstsc - Windows Remote Desktop WEB Connection to make access. When I started up a Propeller IDE session, the mouse pointer seemed to work, BUT there is no keyboard input, press the keys and nothing happens. I also went to raspi-config and did the keyboard mapping thing, that did not help. I also installed geany, just to verify that there was keyboard access, yes the keyboard works in a Geany session.
Is anybody else having the same problem? If you did how did you fix it?
Next thing I might try is using openspin and propman from the command line, if this works I might have too incorporate those into the Geany session and see how that goes. Yea, when you fire up Propeller IDE it looks good, but when you try to use it, the program starts to show a lot of quirks, maybe it just does not like me. Oh well...
...there is no keyboard input, press the keys and nothing happens. I also went to raspi-config and did the keyboard mapping thing, that did not help. I also installed geany, just to verify that there was keyboard access, yes the keyboard works in a Geany session.
Is anybody else having the same problem? If you did how did you fix it?
I have the same problem on an RPi 2... Have not yet found a solution. I'm wondering if there is something about Qt5 and the most recent Raspian version as Propeller IDE is the only program that is having this issue (I have not yet tried SimpleIDE on this Raspian version yet). This was not an issue on older Raspian versions.
I contacted Lamestation to make sure Brett is aware of this issue.
I went ahead and did a test run of the openspin and propman commands. It seems that the openspin command is working, a test1.binary file was created of the test1.spin file. With the propman command, when I do a 'propman test1.binary' it comes back with the following:
"using GPIO pin 17 for hardware reset"
"connecting to 'ttyAMA0'... [not found]"
Just to describe my setup again I have, on the RPi 2, the GPIO Tx and Rx connected to the QS board P31 and P30, there is also a wire connecting the grounds. I also tried a wire connecting the GPIO pin 17 to the QS board RESn pin, that made no difference. So, is there some other hardware connection that should be made? What else does propman need?
OK, so far what did I accomplish? I guess I verified that the openspin command works at the command line and when added to the Geany build instructions. Whoopee do...
Just to describe my setup again I have, on the RPi 2, the GPIO Tx and Rx connected to the QS board P31 and P30, there is also a wire connecting the grounds. I also tried a wire connecting the GPIO pin 17 to the QS board RESn pin, that made no difference. So, is there some other hardware connection that should be made? What else does propman need?
Ray,
Maybe you should look at the Propeller HAT schematic (you can find it in GitHub, with the rest of the Propeller HAT sources and example code) to see how it connects the Propeller circuit to the RPi.
I've had no problem getting propman to work with the Propeller HAT, though it does not work with my USB-conected QuickStart :-( So, I switch over to p1load to load the USB-connected QuickStart when I want to program it (another issue for Lamestation to look into).
One thing I like about the p1load or the propeller-load from SimpleIDE is that you can run it on the command line with the "-P" option and it will display known/working Propeller boards. I don't think propman has that option.
I looked at the Propeller HAT schematic in GitHub, everything is just to small for me to read. I tried to do a download, but it does not download as a pdf file, that was of no use to me. I did see something about the Propeller HAT using a UART to connect to the RPi, but I think, if I am not mistaken, the QS board P31/P30 pins at the header are setup to deal with a UART, and not a TTL. If P30 and P31 pins are TTL then that would explain why a direct connection to the RPi GPIO Tx/Rx UART is not working, I think. Since I am not an electronics hardware guy, I guess I am just speculating about all this stuff.
It seems like in some of the other threads, when statements are made about how easy it should work, are just pure speculation, at least I admit to that fact about speculating. At this point I am making an assumption that the P31 and P30 pins at the header, on the QS board, are TTL and a straight connection to a corresponding UART is not going to work, that is my theory until I am proven wrong.
So what is next, wait for a Propeller HAT that has the headers pre-soldered. Bye-bye.
At this point I am making an assumption that the P31 and P30 pins at the header, on the QS board, are TTL and a straight connection to a corresponding UART is not going to work, that is my theory until I am proven wrong.
I have made a direct connection from the UART pins on a Raspi GPIO header to a Propeller chip many times. It just works. What is the problem?
I looked at the Propeller HAT schematic in GitHub, everything is just to small for me to read. I tried to do a download, but it does not download as a pdf file, that was of no use to me.
HARDWARE COMMENT: The header pins on the Propeller Hat bottom out on the HDMI and USB connecter on the Model A+ and the HDMI connector on the B+. The female GPIO header on the Propeller Hat is one of the lowest profile I've ever seen on a RasPi hat which causes the issue. I stuck a piece of card stock on top of the RasPi to protect the pins and get on with the testing.
I downloaded and built the latest OpenSpin and copied it to /usr/local/bin (I won't be using *IDE on this RasPi)
I grabbed the GitHub repository for the Propeller Hat. I went to the p1loader directory and copied p1load to /usr/local/bin on my RasPi and changed the p1load owner/group/permissions as indicated in the Propeller Hat documentation.
I put the blinky example Spin program into a source file and compiled and loaded it thusly:
pi@prop-hat ~/src $ openspin p1-test.spin -o p1-test.bin
Propeller Spin/PASM Compiler 'OpenSpin' (c)2012-2015 Parallax Inc. DBA Parallax Semiconductor.
Version 1.00.76 Compiled on May 19 2015 11:05:20
Compiling...
p1-test.spin
Done.
Program size is 52 bytes
pi@prop-hat ~/src $ ls
p1-test.bin p1-test.spin
pi@prop-hat ~/src $ p1load p1-test.bin
(LOW).
Found propeller version 1 on /dev/ttyAMA0
Loading 'p1-test.bin' (52 bytes)
Loading hub memory ... OK
pi@prop-hat ~/src $
When I looked at my RasPi/Propeller Hat, the LED on pin 0 was BLINKING!
Yay, it works, it is cool!!!!!!
The Python libraries are giving me some grief currently.
I installed P1 via PIP. I have imports failing for the pins module that serialio.py is trying to use, the smbus module that io.py is trying to use.
The pwm.py module does load when I do
sudo python -im p1.pwm
Now, it's time to play since I went to all this trouble to test.
I really like the way you've done the IO modules and how the Python program can load up the needed "brains" into the Propeller. That's a very nice feature to make the Prop an easy, very smart I/O extension to the RasPi!
There's no EEPROM on the Propeller HAT, it's made with the assumption that the Pi's SD card is the best place to store your code-
This is rather unfortunate. I'd agree with the assumption, albeit the issue is that the RPi is very limited in terms of UARTs -- there's exactly one on the expansion bus, which is by default used as Linux console (i.e. boot message go out there). One can disable the use of the sole UART as console and as long as one doesn't mess with the boot system, that should be OK. I was planning on using (or rather currently am using) it to connect to a GPS module (to feed gpsd). I was hoping that I could get the RPi and the Propeller to talk via different paths, perhaps even SPI. Since the propeller can boot only via UART or EEPROM, I would need the latter.
That should have been a strong indicator that the HAT board was not complete. C'mon, I happily pay a buck more to get a well rounded product. Propeller HAT v1.1 perhaps?
That should have been a strong indicator that the HAT board was not complete. C'mon, I happily pay a buck more to get a well rounded product. Propeller HAT v1.1 perhaps?
The problem with a buck more in the material costs, is that it tends to equal 3 bucks more on the RRP. Those EEPROMs are expensive, and we didn't want to push the Propeller HAT price up to around £18. One of the projects goals is to open up the Propeller platform to more people- we're trying to do this with a low cost and good documentation.
I'd be interested to know if you think it's worthwhile! I still think 4 rows on a breadboard is a relatively small price to pay to add one yourself, though.
If you bend all the legs on one side and solder them together you can even free up the 4 rows on the top left. I appreciate this kind of practice is much more "Raspberry Pi" than it is "Propeller" but I value the learning experience it allows.
Also, I have projects running on Propeller HAT that don't use the EEPROM but do use pins 28 and 29 ( A 5x5x5 LED cube for example ), so I'd consider fitting an EEPROM permenantly to be a bug, not a feature!
The problem with a buck more in the material costs, is that it tends to equal 3 bucks more on the RRP.
Funny how this goes. Well, it seems unlikely that someone else would offer a competing product (in this very niche) soon. I'd think, as this is clearly targeted for the educational and tinkerer market, we're not counting pennies.
Those EEPROMs are expensive, and we didn't want to push the Propeller HAT price up to around £18. One of the projects goals is to open up the Propeller platform to more people- we're trying to do this with a low cost and good documentation.
Speaking of documentation, it would be too nice, if it would be mentioned that the [Propeller Hat isn't actually mechanically compatible with the Raspberry Pi. I have here a Raspberry Pi B (Revision 2, I believe) and the composite video output is in the way (same is true for a Banana Pi, but there I expected difficulties). A Raspberry Pi B+ is needed (I'd think A2, B2 would fit too, but couldn't test that yet, not sure about the A+).
I can only speak for myself, but I haven't soldered SMT devices yet. I'm willing to try, but through-the-hole would lower the level of anxiety. I'd almost suggested a socket, but I'm sure that's expensive too.
I'd be interested to know if you think it's worthwhile! I still think 4 rows on a breadboard is a relatively small price to pay to add one yourself, though.
Well, that's what I'm doing now. 4 rows on a breadboard would be a small price if there were many rows. Unfortunately the particular breadboard on the Propeller Hat is tiny with just 17 rows. I guess, it'll do for some quick tests.
If you bend all the legs on one side and solder them together you can even free up the 4 rows on the top left.
Ah, right, thanks for the tip.
I appreciate this kind of practice is much more "Raspberry Pi" than it is "Propeller" but I value the learning experience it allows.
Also, I have projects running on Propeller HAT that don't use the EEPROM but do use pins 28 and 29 ( A 5x5x5 LED cube for example ), so I'd consider fitting an EEPROM permenantly to be a bug, not a feature!
Well, all other boards I know of use those pins for I2C (for the EEPROM and potentially other slaves), so deviating from that scheme is just asking for trouble.
Well it does not work for me. You must be way more clever than I am.
Ray
Well, it might be stating the obvious, but when Heater speaks of direct connection he means crossed of course, i.e. Rx on RPi to Tx on Propeller and vice versa, null modem style.
When Heater talks of direct connection he does of course assume that people know which way around their Tx and Rx are and where their reset pin is.
Whilst I'm experimenting I would also assume a 200 ohm or so resistor in series, just in case of mishaps.
Quite possibly I assume too much.
There has been some talk here about how a ten cent part becomes a dollar on the final price and how a dollar is not important. My feeling is that your potential market scales with an inverse exponential of the price. That extra dollar can mean ten times less sales. That is why the end price of the Pi itself is so critical.
Comments
There is japanese strings in top right of board.
1st kanji(2 characters) mean pirate.
2nd katakana(2 characters) mean robot.
3rd kanji(2 characters) mean ninja.
4th hiragana(2 characters) monkey.
I understand 1st kanji because logo is pirate.
I have no idea about another kanji.
Anyone know these meaning?
BTW, ninja kanji is wrong.
Hey thanks for this! I've been meaning to learn how to use GIT properly for a while. Started today.
You've just made my day. Thank you. I wrote these tutorials as I was learning PASM myself, so I had a very fresh experience of the problems I ran into personally and how best, I hope anyway, to pass that knowledge on.
If I were irresponsible I'd ignore all of our other products and just focus on Propeller PASM tutorials, unfortunately I'm responsible for all of our Python software and for authoring a great deal of the learning portal. I do, however, have some more PASM and SPIN guides in the works and if you have any suggestions then I'll consider adding them to my TODO list.
@caskaz
PIrate
MOnkey
RObot
NInja
( Ninja is wrong? Uh oh! )
For anyone who hasn't looked at the Python code for Propeller HAT, I encourage you to give it a try. I've written a couple of Python libraries that contain embedded Propeller binaries, these are uploaded when you "import" the Python library and then communication is established over UART/Serial to control them.
Here's a doc covering the very, very basic Serial IO library: https://github.com/pimoroni/propeller-hat/blob/master/documentation/Serial-IO.md
I guess the first problem to address is, SimpleIDE reports, no Propeller chip to be found. The QS board is a rev-A board, do I have to fiddle fool around with this board to make it work? No, I will not use PropellerIDE until the quirks have been resolved.
Ray
So, edit your Spin code in the editor of your choice, then compile it with OpenSpin: https://github.com/parallaxinc/OpenSpin, then program your Prop over the UART on the GPIO header with pi-propeller-load: https://github.com/ZiCog/pi-propeller-load
I'm hoping all that stuff is working with SimpleIDE/PropellerIDE by now, but perhaps not, I have no idea.
Is anybody else having the same problem? If you did how did you fix it?
Next thing I might try is using openspin and propman from the command line, if this works I might have too incorporate those into the Geany session and see how that goes. Yea, when you fire up Propeller IDE it looks good, but when you try to use it, the program starts to show a lot of quirks, maybe it just does not like me. Oh well...
Ray
https://www.raspberrypi.org/magpi/
I have the same problem on an RPi 2... Have not yet found a solution. I'm wondering if there is something about Qt5 and the most recent Raspian version as Propeller IDE is the only program that is having this issue (I have not yet tried SimpleIDE on this Raspian version yet). This was not an issue on older Raspian versions.
I contacted Lamestation to make sure Brett is aware of this issue.
dgately
"using GPIO pin 17 for hardware reset"
"connecting to 'ttyAMA0'... [not found]"
Just to describe my setup again I have, on the RPi 2, the GPIO Tx and Rx connected to the QS board P31 and P30, there is also a wire connecting the grounds. I also tried a wire connecting the GPIO pin 17 to the QS board RESn pin, that made no difference. So, is there some other hardware connection that should be made? What else does propman need?
OK, so far what did I accomplish? I guess I verified that the openspin command works at the command line and when added to the Geany build instructions. Whoopee do...
Ray
Ray,
Maybe you should look at the Propeller HAT schematic (you can find it in GitHub, with the rest of the Propeller HAT sources and example code) to see how it connects the Propeller circuit to the RPi.
I've had no problem getting propman to work with the Propeller HAT, though it does not work with my USB-conected QuickStart :-( So, I switch over to p1load to load the USB-connected QuickStart when I want to program it (another issue for Lamestation to look into).
One thing I like about the p1load or the propeller-load from SimpleIDE is that you can run it on the command line with the "-P" option and it will display known/working Propeller boards. I don't think propman has that option.
dgately
It seems like in some of the other threads, when statements are made about how easy it should work, are just pure speculation, at least I admit to that fact about speculating. At this point I am making an assumption that the P31 and P30 pins at the header, on the QS board, are TTL and a straight connection to a corresponding UART is not going to work, that is my theory until I am proven wrong.
So what is next, wait for a Propeller HAT that has the headers pre-soldered. Bye-bye.
Ray
Ray
Ray,
If you download the propeller-hat repository zip, you get the schematic pdf (for free!)... https://github.com/pimoroni/propeller-hat/archive/master.zip
or get it right here: Propeller-HAT-schematic.pdf.zip
dgately
HARDWARE COMMENT: The header pins on the Propeller Hat bottom out on the HDMI and USB connecter on the Model A+ and the HDMI connector on the B+. The female GPIO header on the Propeller Hat is one of the lowest profile I've ever seen on a RasPi hat which causes the issue. I stuck a piece of card stock on top of the RasPi to protect the pins and get on with the testing.
I downloaded and built the latest OpenSpin and copied it to /usr/local/bin (I won't be using *IDE on this RasPi)
I grabbed the GitHub repository for the Propeller Hat. I went to the p1loader directory and copied p1load to /usr/local/bin on my RasPi and changed the p1load owner/group/permissions as indicated in the Propeller Hat documentation.
I put the blinky example Spin program into a source file and compiled and loaded it thusly: When I looked at my RasPi/Propeller Hat, the LED on pin 0 was BLINKING!
Yay, it works, it is cool!!!!!!
The Python libraries are giving me some grief currently.
I installed P1 via PIP. I have imports failing for the pins module that serialio.py is trying to use, the smbus module that io.py is trying to use.
The pwm.py module does load when I do
Now, it's time to play since I went to all this trouble to test.
I really like the way you've done the IO modules and how the Python program can load up the needed "brains" into the Propeller. That's a very nice feature to make the Prop an easy, very smart I/O extension to the RasPi!
The former sounds like I've messed something up, the latter can be fixed with:
This is rather unfortunate. I'd agree with the assumption, albeit the issue is that the RPi is very limited in terms of UARTs -- there's exactly one on the expansion bus, which is by default used as Linux console (i.e. boot message go out there). One can disable the use of the sole UART as console and as long as one doesn't mess with the boot system, that should be OK. I was planning on using (or rather currently am using) it to connect to a GPS module (to feed gpsd). I was hoping that I could get the RPi and the Propeller to talk via different paths, perhaps even SPI. Since the propeller can boot only via UART or EEPROM, I would need the latter.
Already ordered EEPROMs (not sure, whether they are DIP, if not that will be a first time experience soldering SMT...
That should have been a strong indicator that the HAT board was not complete. C'mon, I happily pay a buck more to get a well rounded product. Propeller HAT v1.1 perhaps?
The problem with a buck more in the material costs, is that it tends to equal 3 bucks more on the RRP. Those EEPROMs are expensive, and we didn't want to push the Propeller HAT price up to around £18. One of the projects goals is to open up the Propeller platform to more people- we're trying to do this with a low cost and good documentation.
What we could do, at basically zero cost, is include an SMD landing on the underside of Propeller HAT where power-users could populate their own EEPROM ( the 24LC512T-I/SM if I'm not mistaken: http://uk.mouser.com/ProductDetail/Microchip/24LC512T-I-SM/?qs=%2fha2pyFaduhUkPgxXMCe%252bQye%252bhbLgcaRzuN5mHI4%2fSM%3d )
I'd be interested to know if you think it's worthwhile! I still think 4 rows on a breadboard is a relatively small price to pay to add one yourself, though.
If you bend all the legs on one side and solder them together you can even free up the 4 rows on the top left. I appreciate this kind of practice is much more "Raspberry Pi" than it is "Propeller" but I value the learning experience it allows.
Also, I have projects running on Propeller HAT that don't use the EEPROM but do use pins 28 and 29 ( A 5x5x5 LED cube for example ), so I'd consider fitting an EEPROM permenantly to be a bug, not a feature!
Speaking of documentation, it would be too nice, if it would be mentioned that the [Propeller Hat isn't actually mechanically compatible with the Raspberry Pi. I have here a Raspberry Pi B (Revision 2, I believe) and the composite video output is in the way (same is true for a Banana Pi, but there I expected difficulties). A Raspberry Pi B+ is needed (I'd think A2, B2 would fit too, but couldn't test that yet, not sure about the A+).
I can only speak for myself, but I haven't soldered SMT devices yet. I'm willing to try, but through-the-hole would lower the level of anxiety. I'd almost suggested a socket, but I'm sure that's expensive too.
Well, that's what I'm doing now. 4 rows on a breadboard would be a small price if there were many rows. Unfortunately the particular breadboard on the Propeller Hat is tiny with just 17 rows. I guess, it'll do for some quick tests.
Ah, right, thanks for the tip.
Well, all other boards I know of use those pins for I2C (for the EEPROM and potentially other slaves), so deviating from that scheme is just asking for trouble.
Well, it might be stating the obvious, but when Heater speaks of direct connection he means crossed of course, i.e. Rx on RPi to Tx on Propeller and vice versa, null modem style.
Whilst I'm experimenting I would also assume a 200 ohm or so resistor in series, just in case of mishaps.
Quite possibly I assume too much.
There has been some talk here about how a ten cent part becomes a dollar on the final price and how a dollar is not important. My feeling is that your potential market scales with an inverse exponential of the price. That extra dollar can mean ten times less sales. That is why the end price of the Pi itself is so critical.
I am experiencing the same failure to import the "pins" module. Where should this module reside? Can't seem to find it in Python. Thanks!