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
It's not much help, but I've been getting on okay with Propeller IDE- lots of code written and certainly no random closing. Have you found your issues in the tracker ( https://lamestation.atlassian.net/browse/IDE-90?jql=project%20%3D%20IDE ) or raised them? I'm building and using Propeller IDE a lot on the Pi to work on my own documentation/tutorials so I'm eager to help make it better.
On another note; Forth is tremendously popular here! I really need to give it a more detailed look. I'm particularly interested in the concept of embedding Forth into Python to be uploaded and run on-demand on the Propeller so it can be "re-tasked" depending on circumstances. I'd really like to explore its use as a co-processing, realtime IO driver in collaboration with the Pi. Possibly more because it would be interesting than useful, but you never know!
That one really caught me by surprise. So, why is your installation that much different then my installation? I have not done any weird things, that I know of, with my installation on a Rapsberry Pi 2 board, the only thing different is that I am using a 16 GB Class 10 uSD card.
As for Forth, I wanted to see how that interpreter could fit in with the Propeller HAT idea. I could see that in some cases when you wanted to test out different devices/sensors, this could be just the thing. Both Propforth and Tachyon have a lot of drivers, as part of the system, so it would be a hard choice to make as to which one I would use.
Not knowing what is causing the random closings, I do not feel that I could use Propeller IDE for any serious work. I do not understand why the Propeller IDE project is not concentrating on a relatively bug free, functioning, basic system, that applies to all installations, then they could start adding all the other good stuff. And maybe more status updates, more frequently, would not hurt.
That one really caught me by surprise. So, why is your installation that much different then my installation? I have not done any weird things, that I know of, with my installation on a Rapsberry Pi 2 board, the only thing different is that I am using a 16 GB Class 10 uSD card.
As for Forth, I wanted to see how that interpreter could fit in with the Propeller HAT idea. I could see that in some cases when you wanted to test out different devices/sensors, this could be just the thing. Both Propforth and Tachyon have a lot of drivers, as part of the system, so it would be a hard choice to make as to which one I would use.
Not knowing what is causing the random closings, I do not feel that I could use Propeller IDE for any serious work. I do not understand why the Propeller IDE project is not concentrating on a relatively bug free, functioning, basic system, that applies to all installations, then they could start adding all the other good stuff. And maybe more status updates, more frequently, would not hurt.
Ray
As to which Forth to use that comes down to what you expect of it I guess. Tachyon though was started not as an academic attempt at creating a Forth but rather at creating an interactive target resident interpreter/compiler that would allow code to be written almost completely in high-level rather than having to resort to assembler, which almost invariably with the Propeller means launching another cog, even if it's only a handful of instructions. So without the need to resort to assembler the code would be able to handle most realtime tasks but do so with a small memory footprint since the Prop only has 32K of RAM and 32 I/O there isn't any efficient or practical way to expand memory. The other thing is that the "command line" is compiled word by word ready to execute on a line terminator unlike traditional Forths which interpret and execute word by word after the line is received (slow). This compiled command line method also permits use of "compile only" constructs such as DO LOOP FOR NEXT IF ELSE THEN BEGIN UNTIL etc on the command line so it's possible to execute a one-line command such as:
$80 $20 DO I EMIT LOOP
That said, Tachyon happens to be Forth, although unconventional because that turned out to be the best fit I could find for the Prop which would allow me to get on with the job of creating commercial products based on the Prop and being able to develop the code while interacting with the hardware to debug and tune the code. The fact that I can talk to any product in the field and enhance it on the spot allows me to evaluate and improve the product easily. The proof of that pudding is in not just the "drivers" but also the complete modules I have for FAT32 file-systems including virtual memory and networking servers based on the WIZnet chips among many many other technologies that can be squeezed all together into a single 32K unenhanced Prop with room and cogs to spare. Is there anything else that even comes close?
I just bumped into a couple of more problems, the 'BURN' command is not working from the icon selection or the menu selection. It throws up a build info window, as if its doing something, but it does not burn. The other problem is, when you open up the terminal, and try to do a 'RUN', nothing happens except that the build info window hangs. Not sure if I am using the terminal window correctly. It seems that the jazzed version of Propeller IDE used the terminal as a visual for your program testing. And yes I did have another random closing with this session of testing. Cannot believe how screwed up my installation is :-)?
I am considering removing the Propeller IDE program from the RPi and maybe trying a new installation. I know that on my Windows 7 system, I can just do an 'uninstall' and it does a good job of removing a program. How do you do a complete remove of an installed program, like Propeller IDE, on the Raspberry Pi? It has to be a complete remove so as to insure you do not have any hangers-on code too insure that the next install is clean.
I am considering removing the Propeller IDE program from the RPi and maybe trying a new installation. I know that on my Windows 7 system, I can just do an 'uninstall' and it does a good job of removing a program. How do you do a complete remove of an installed program, like Propeller IDE, on the Raspberry Pi? It has to be a complete remove so as to insure you do not have any hangers-on code too insure that the next install is clean.
Ray
If you're using a Linux distribution (like e.g. Debian, RedHat, SuSE, Ubuntu etc.) as you typically would on a Linux system, then you'd be using the distribution-specific package manager (aptitude, yum, etc.) to install or remove packages, assuming that the software in question came in such a package. If it didn't, then you're on your own. If .e.g. it came as a tar ball, then to keep things manageable, you should have un-tarred (extracted the files) in a directory meant for such a purpose, e.g. /opt/<program's name> . In that case you can simply remove that directory and you're not worse off.
I'd think you're better served asking Linux specific questions in a Linux forum, no?
Well, no. PropellerIDE is a Propeller specific package developed by people who hang out on this very forum.
Admittedly this thread is very confused, is it about Forth or the Propeller HAT or Propeller IDE or what?
As far as I understand PropellerIDE is maintained on github so any problems with it, on whatever platform, should be reported to the issue tracking system there.
Admittedly this thread is very confused, is it about Forth or the Propeller HAT or Propeller IDE or what?
I am just describing my problems, with an IDE that should be used to load a Forth program onto the Propeller HAT. Also trying to address the questions that will come up before hand. I am trying to do a fine balance between to much detail and not enough detail.
I am just a new guy that just stumbled onto this forum and got some info on a new product called Propeller HAT for the Raspberry Pi. So, I decided before I make the purchase I will try to do a product simulation using some of the tools and products (sitting in a box collecting dust in my closet) that are available. As I was bouncing through this process I noticed that Propeller IDE itself was not working as expect, or was I not using the software correctly (never the software fault)? Solution: ask and describe (maybe I should do this on BETA news, they probably will have the answer). At the end of this process I am confused about the software as it applies to the Propeller HAT, the hardware as it applies to Forth, and how the heck do I get this thing off of my system ( a secret Linux people will not mention, reinstall the OS).
I just did that on my RasPi and it appeared to remove everything.
Re-install the OS??? How barbaric!!! (but easy to do if you need to - the beauty of the little RasPi that could!!)
I guess I need to re-install PropellerIDE now.....thanks, Ray!! When I do reinstall it, Iwill need to sit down and program some Propellers to see how it works. I've had no issues yet.
If you do find an issue with PropellerIDE, it would be a good idea to open up an issue on the GitHub so the PropellerIDE development team (Brett, who volunteered and probably has a paying gig to support his hobbies) can address it. The development team may not have time to scrub the forum for reported PropellerIDE issues.
I did a 'sudo dpkg -r propelleride', which removed the propelleride from the menu, then I did 'sudo dpkg -i propelleride-0.30.1-armhf.deb', to re-install, tried a couple of the programs that I already had, and the same ole problem is occurring. So, either my OS is messed up or...
Start from scratch, I hope I have better luck this time, if not, then what, throw away my Raspberry Pi?
As a side note, I remember a post, Parallax stating that they are paying for development of Propeller IDE. Maybe that was just for Propeller IDE 0.25.0, I could be wrong though.
I did a fresh install of the RPi OS and Propeller IDE. The Propeller IDE, you can RUN a program, but you cannot BURN it to the EEPROM. Since the Propeller HAT does not have an EEPROM, I guess that is not such a bad thing. So their is no way you would be able to BURN Tachyon to the EEPROM let alone load the binary to be RUN. This leads to a question, how are you suppose to use Propeller IDE, with a QS board attached via /dev/ttyAMA0? Is the Propeller IDE, that I have installed, is bound to the Propeller HAT?
I just disconnected the QS board from /dev/ttyAMA0, and hooked up the USB cable. I tried to RUN the blinker.spin program, nothing is blinking. I did a BURN of the program, it seems to overwritten the program that was on the EEPROM, but when you do a reset, no blinking LED.
I looks like Propeller IDE is a partially functioning program, sort of tied in for the Propeller HAT, hopefully this occurring for other people, otherwise...
Other than that the Propeller IDE looks great. I am almost afraid to go any further with this, but I will.
I'm confused as to why there is no "eeprom" on the hat yet looking at the pictures of the hat it seems that there is a eeprom there. I found the schematic and they have a eeprom loaded (for propeller hat compatibility whatever that means) although it has it's write protect pulled up and if I can read the part number on the photo it looks like a 24LC32 for some strange reason. That makes no sense to me and I'd be inclined to swap out the eeprom for a 24LC512 and pull the write-protect low.
The other part that I'm confused about is why you would need the IDE to run Forth since you only need the serial communications working and any good text editor for programs and scripts since there is no need for the RPi to compile anything as that is always done on the Prop in Tachyon.
Not having a proper eeprom on the hat seems illogical and certainly defeats the purpose of running Forth as that would otherwise have to be loaded each and every time.
That EEPROM is nothing to do with the Propeller chip. It's part of the Raspberry Pi "HAT" (Hardware Attached on Top) specification:
In a nutshell a HAT is a rectangular board (65x56mm) that has four mounting holes in the (nicely rounded) corners that align with the mounting holes on the B+, has a 40W GPIO header and supports the special autoconfiguration system that allows automatic GPIO setup and driver setup. The automatic configuration is achieved using 2 dedicated pins (ID_SD and ID_SC) on the 40W B+ GPIO header that are reserved for an I2C EEPROM. The EEPROM holds the board manufacturer information, GPIO setup and a thing called a ‘device tree‘ fragment – basically a description of the attached hardware that allows Linux to automatically load the required drivers.
There is no need for an EEPROM for the Propeller on a HAT. Simply load up the Propeller from the Pi at boot time or whenever one want's to run an application that uses it. Pimoroni has examples of Python libraries that load binary blobs to the Prop automatically when imported into a users application.
As the mention of "device tree" above suggests the Linux kernel itself can load "firmware" to the Prop as it does for WIFI dongles and many other devices. It makes the HAT's auto-detected devices. I have no idea if anyone actually uses that feature.
Not everyone is capable of using Forth so having a Spin, C or other compiler for the Prop that runs on the Pi is handy. That naturally leads to wanting to have the IDE running on the Pi as well. Why not?
While there certainly is no NEED for an EEPROM with a Propeller, it has become a standard and often expected peripheral. I believe the latest Tachon requires it for dictionary space, greatly expanding the capabilities of the language, Tachyon and Propforth uses it to save the updated image so you don't need to reload your words each time the Prop boots; the C servo routines from the Learn site use it for calibration tables for the encoders so you don't need to recalibrate each time you reboot, users often retain data in EEPROM in all languages. Adding one seems like a small change to the cost in a v1.1 to make it a more "standard" Prop configuration.
I'll be adding one to my breadboard once I find the drawer those little buggers are hiding in.
The "loadable blob" feature is really slick and works well embedded in a Python program. Using the Hat EEPROM to expand on that sounds very interesting.
You have convinced me that HATs carry Propellers and designed for prototyping/flexibility should carry EEPROMS. If only for hardware calibration data and such like.
I've used this setup with great success in our demos, we're planning to stock and sell the 24LC512-I/P DIP EEPROMs separately, and possibly with appropriate pull-up resistors.
Propeller HAT is aimed at being an extremely low barrier to entry for people wishing to tinker with the Propeller chip alongside their Pi, rather than a complete standalone platform. The omission of an EEPROM is intentional both for cost, and for educational benefits.
However, it's certainly not impossible that an SMD EEPROM landing could be included on the underside- unpopulated and ready for a 24LC512T-I/SM which comes in a SOIC-8 package that shouldn't be too hard to solder. Would you consider that worth doing?
Unfortunately, to call it "Propeller HAT" we have to have the slightly confusing HAT EEPROM on-board, even though it currently does precious little.
A bit of a dilemma. Is your target market going to be into soldering that EEPROM on there? Would having the pads and hence the documentation to go with it just confuse an put people off? I'm all for keeping things simple.
A bit of a dilemma. Is your target market going to be into soldering that EEPROM on there? Would having the pads and hence the documentation to go with it just confuse an put people off? I'm all for keeping things simple.
You're certainly not wrong on the confusion front- this is why I favour just letting people use the breadboard, since the number of people who want to solder *anything* is vanishingly small. The number of people who want to try and solder SMD could probably be counted on one hand. But since it costs very little to add an un-populated landing it might be worth it for "growing room".
I personally love the idea of running Forth on the Propeller HAT, so I'm inclined to listen when people with the same goal find the lack of an EEPROM limiting, but since the original goal of the project is to open up the Propeller to new audiences- potentially ones who would even know what Forth is- then perhaps I shouldn't let myself get distracted.
I remember a 3D red/green book I had years ago- on the back cover it had two separate phrases that would appear depending on which eye you closed, they were along the lines of: You can please some of the people some of the time. But you can't please all of the people all of the time.
However, it's certainly not impossible that an SMD EEPROM landing could be included on the underside- unpopulated and ready for a 24LC512T-I/SM which comes in a SOIC-8 package that shouldn't be too hard to solder. Would you consider that worth doing?
I think it's a good idea. To keep confusion at a minimum, only document the SMD landing in an addendum to online or print docs. Label the addendum as an "Advanced User" section. But, please label the physical landing with the chip ID and pinout.
Comments
It's not much help, but I've been getting on okay with Propeller IDE- lots of code written and certainly no random closing. Have you found your issues in the tracker ( https://lamestation.atlassian.net/browse/IDE-90?jql=project%20%3D%20IDE ) or raised them? I'm building and using Propeller IDE a lot on the Pi to work on my own documentation/tutorials so I'm eager to help make it better.
On another note; Forth is tremendously popular here! I really need to give it a more detailed look. I'm particularly interested in the concept of embedding Forth into Python to be uploaded and run on-demand on the Propeller so it can be "re-tasked" depending on circumstances. I'd really like to explore its use as a co-processing, realtime IO driver in collaboration with the Pi. Possibly more because it would be interesting than useful, but you never know!
As for Forth, I wanted to see how that interpreter could fit in with the Propeller HAT idea. I could see that in some cases when you wanted to test out different devices/sensors, this could be just the thing. Both Propforth and Tachyon have a lot of drivers, as part of the system, so it would be a hard choice to make as to which one I would use.
Not knowing what is causing the random closings, I do not feel that I could use Propeller IDE for any serious work. I do not understand why the Propeller IDE project is not concentrating on a relatively bug free, functioning, basic system, that applies to all installations, then they could start adding all the other good stuff. And maybe more status updates, more frequently, would not hurt.
Ray
As to which Forth to use that comes down to what you expect of it I guess. Tachyon though was started not as an academic attempt at creating a Forth but rather at creating an interactive target resident interpreter/compiler that would allow code to be written almost completely in high-level rather than having to resort to assembler, which almost invariably with the Propeller means launching another cog, even if it's only a handful of instructions. So without the need to resort to assembler the code would be able to handle most realtime tasks but do so with a small memory footprint since the Prop only has 32K of RAM and 32 I/O there isn't any efficient or practical way to expand memory. The other thing is that the "command line" is compiled word by word ready to execute on a line terminator unlike traditional Forths which interpret and execute word by word after the line is received (slow). This compiled command line method also permits use of "compile only" constructs such as DO LOOP FOR NEXT IF ELSE THEN BEGIN UNTIL etc on the command line so it's possible to execute a one-line command such as:
$80 $20 DO I EMIT LOOP
That said, Tachyon happens to be Forth, although unconventional because that turned out to be the best fit I could find for the Prop which would allow me to get on with the job of creating commercial products based on the Prop and being able to develop the code while interacting with the hardware to debug and tune the code. The fact that I can talk to any product in the field and enhance it on the spot allows me to evaluate and improve the product easily. The proof of that pudding is in not just the "drivers" but also the complete modules I have for FAT32 file-systems including virtual memory and networking servers based on the WIZnet chips among many many other technologies that can be squeezed all together into a single 32K unenhanced Prop with room and cogs to spare. Is there anything else that even comes close?
Ray
Ray
If you're using a Linux distribution (like e.g. Debian, RedHat, SuSE, Ubuntu etc.) as you typically would on a Linux system, then you'd be using the distribution-specific package manager (aptitude, yum, etc.) to install or remove packages, assuming that the software in question came in such a package. If it didn't, then you're on your own. If .e.g. it came as a tar ball, then to keep things manageable, you should have un-tarred (extracted the files) in a directory meant for such a purpose, e.g. /opt/<program's name> . In that case you can simply remove that directory and you're not worse off.
I'd think you're better served asking Linux specific questions in a Linux forum, no?
Admittedly this thread is very confused, is it about Forth or the Propeller HAT or Propeller IDE or what?
As far as I understand PropellerIDE is maintained on github so any problems with it, on whatever platform, should be reported to the issue tracking system there.
I am just a new guy that just stumbled onto this forum and got some info on a new product called Propeller HAT for the Raspberry Pi. So, I decided before I make the purchase I will try to do a product simulation using some of the tools and products (sitting in a box collecting dust in my closet) that are available. As I was bouncing through this process I noticed that Propeller IDE itself was not working as expect, or was I not using the software correctly (never the software fault)? Solution: ask and describe (maybe I should do this on BETA news, they probably will have the answer). At the end of this process I am confused about the software as it applies to the Propeller HAT, the hardware as it applies to Forth, and how the heck do I get this thing off of my system ( a secret Linux people will not mention, reinstall the OS).
Ray
Therefore, it should be uninstalled with dpkg.
I just did that on my RasPi and it appeared to remove everything.
Re-install the OS??? How barbaric!!! (but easy to do if you need to - the beauty of the little RasPi that could!!)
I guess I need to re-install PropellerIDE now.....thanks, Ray!!
If you do find an issue with PropellerIDE, it would be a good idea to open up an issue on the GitHub so the PropellerIDE development team (Brett, who volunteered and probably has a paying gig to support his hobbies) can address it. The development team may not have time to scrub the forum for reported PropellerIDE issues.
Start from scratch, I hope I have better luck this time, if not, then what, throw away my Raspberry Pi?
As a side note, I remember a post, Parallax stating that they are paying for development of Propeller IDE. Maybe that was just for Propeller IDE 0.25.0, I could be wrong though.
Ray
I just disconnected the QS board from /dev/ttyAMA0, and hooked up the USB cable. I tried to RUN the blinker.spin program, nothing is blinking. I did a BURN of the program, it seems to overwritten the program that was on the EEPROM, but when you do a reset, no blinking LED.
I looks like Propeller IDE is a partially functioning program, sort of tied in for the Propeller HAT, hopefully this occurring for other people, otherwise...
Other than that the Propeller IDE looks great. I am almost afraid to go any further with this, but I will.
Ray
The other part that I'm confused about is why you would need the IDE to run Forth since you only need the serial communications working and any good text editor for programs and scripts since there is no need for the RPi to compile anything as that is always done on the Prop in Tachyon.
Not having a proper eeprom on the hat seems illogical and certainly defeats the purpose of running Forth as that would otherwise have to be loaded each and every time.
In a nutshell a HAT is a rectangular board (65x56mm) that has four mounting holes in the (nicely rounded) corners that align with the mounting holes on the B+, has a 40W GPIO header and supports the special autoconfiguration system that allows automatic GPIO setup and driver setup. The automatic configuration is achieved using 2 dedicated pins (ID_SD and ID_SC) on the 40W B+ GPIO header that are reserved for an I2C EEPROM. The EEPROM holds the board manufacturer information, GPIO setup and a thing called a ‘device tree‘ fragment – basically a description of the attached hardware that allows Linux to automatically load the required drivers.
https://www.raspberrypi.org/introducing-raspberry-pi-hats/
There is no need for an EEPROM for the Propeller on a HAT. Simply load up the Propeller from the Pi at boot time or whenever one want's to run an application that uses it. Pimoroni has examples of Python libraries that load binary blobs to the Prop automatically when imported into a users application.
As the mention of "device tree" above suggests the Linux kernel itself can load "firmware" to the Prop as it does for WIFI dongles and many other devices. It makes the HAT's auto-detected devices. I have no idea if anyone actually uses that feature.
Not everyone is capable of using Forth so having a Spin, C or other compiler for the Prop that runs on the Pi is handy. That naturally leads to wanting to have the IDE running on the Pi as well. Why not?
I'll be adding one to my breadboard once I find the drawer those little buggers are hiding in.
The "loadable blob" feature is really slick and works well embedded in a Python program. Using the Hat EEPROM to expand on that sounds very interesting.
I've used this setup with great success in our demos, we're planning to stock and sell the 24LC512-I/P DIP EEPROMs separately, and possibly with appropriate pull-up resistors.
Propeller HAT is aimed at being an extremely low barrier to entry for people wishing to tinker with the Propeller chip alongside their Pi, rather than a complete standalone platform. The omission of an EEPROM is intentional both for cost, and for educational benefits.
However, it's certainly not impossible that an SMD EEPROM landing could be included on the underside- unpopulated and ready for a 24LC512T-I/SM which comes in a SOIC-8 package that shouldn't be too hard to solder. Would you consider that worth doing?
Unfortunately, to call it "Propeller HAT" we have to have the slightly confusing HAT EEPROM on-board, even though it currently does precious little.
You're certainly not wrong on the confusion front- this is why I favour just letting people use the breadboard, since the number of people who want to solder *anything* is vanishingly small. The number of people who want to try and solder SMD could probably be counted on one hand. But since it costs very little to add an un-populated landing it might be worth it for "growing room".
I personally love the idea of running Forth on the Propeller HAT, so I'm inclined to listen when people with the same goal find the lack of an EEPROM limiting, but since the original goal of the project is to open up the Propeller to new audiences- potentially ones who would even know what Forth is- then perhaps I shouldn't let myself get distracted.
I remember a 3D red/green book I had years ago- on the back cover it had two separate phrases that would appear depending on which eye you closed, they were along the lines of: You can please some of the people some of the time. But you can't please all of the people all of the time.
I think it's a good idea. To keep confusion at a minimum, only document the SMD landing in an addendum to online or print docs. Label the addendum as an "Advanced User" section. But, please label the physical landing with the chip ID and pinout.
dgately