I did have to reboot though, when I initially ran the IDE straight after install my Pi just sat there doing nothing.
That's what prompted me to reboot, so after the reboot I did the same command and it worked, stange.......
I can try it again from a fresh install of Raspbian if you like.
Hmm...I see. That is a bit strange. Disturbing even.
Nothing hung up the one and only time a ran the installer but then I was talking to it over the net with ssh from my Linux PC so not perhaps not the same situation.
I'll have to try it myself.
OK, I'll try it on a fresh install of raspbian when I get home this evening.
Regards,
Coley
Just curious. What was your command to install?
One of these is preferred. cd to package first.
$ sudo ./setup.sh ${USER}
$ su then $ ./setup.sh userid
The setup script today will copy propeller-gcc to /opt/parallax
I wonder if there is enough room in the root filesystem for everything.
Is Raspian big enough to handle this like other linux installs?
The Raspian image is for a 4GB SD card. I put it on an 8GB card and it has a config program that allows it to resize the fs to use the available space on startup.
Also I have installed a bunch of stuff since then so I have long since forgotten how much of the original 4GB fs was free.
The last time I built propgcc I had it on an NFS share from my PC. Not sure if it actually built any faster though.
Starting from a blank raspbian image copied to my SD card and then expanding the root fs to fill the card.
I'm using a 16GB class 10 SD card, not had any problems before but as I said I am a complete noob with all things Linux.
It actually worked this time but I have no idea why as I did exactly the same as yesterday (followed the instructions in the text file in the archive).
I used $ sudo ./setup.sh ${USER} to run the setup script.
I've actually tried both ways now and they worked so it must have been something I missed.
Now that it is running the only thing I don't seem to be able to do is to select a board type, the option is available but no boards are listed?
I've attached some screen-shots of recommended SimpleIDE v0-8-3 Properties settings since the user guide is a bit out of date. I need to update it for version 0-8-x .
For SPIN programs the board type will always be NONE for now.
The window shown is opened using the wrench on the tool bar.
I've attached some screen-shots of recommended SimpleIDE v0-8-3 Properties settings since the user guide is a bit out of date. I need to update it for version 0-8-x .
For SPIN programs the board type will always be NONE for now.
The window shown is opened using the wrench on the tool bar.
Well I checked that the paths were set in Properties (F6) and they appeared to be but it wasn't until I clicked OK that the board types appeared.
I think what happened is I must have clicked Cancel when the Properties dialogue was displayed when the application was run for the first time.
I'm, happy now, thank you for your help and for writing a great app!
Big thanks to Heater too for compiling this for the Pi.
My next job is to load something to the Prop but for that I need a USB hub which is on order....
Coley,
Are you up for making a connection from the Raspi onboard UART, on the GPIO header, to a Propeller?
I have an experimental hack of the loader to use that port but probably no time for testing anything just now.
Coley,
Are you up for making a connection from the Raspi onboard UART, on the GPIO header, to a Propeller?
I have an experimental hack of the loader to use that port but probably no time for testing anything just now.
Sure, just let me know the detail and I will have a look when I get home.
SimpleIDE or a user can send propeller-load any port string, so I suspect that what is being done in propeller-load now is just fine.
propeller-load does indeed accept any port device but I cannot get SimpleIDE to do so. The port selection dialog box is not editable so I cannot enter a device that is not discovered by the scan.
This is true on the Raspi and my PC Debian box.
@Coley,
The loader might have to wait a day, I stated writing instructions to run it but have run now myself.
propeller-load does indeed accept any port device but I cannot get SimpleIDE to do so. The port selection dialog box is not editable so I cannot enter a device that is not discovered by the scan.
I have some enhancements and will push them soon for 0-8-4. It would be nice to add a fix for this too.
What is the ttyACM* device called? I need a very brief and friendly name to associate with it.
Longer term adding a discovery filter for ports is better, but I don't have time right now. The port dialog will temporarily become editable.
My Raspian running Raspberry Pi has no such /dev/ttyACM0 device. What is it supposed to be? I have no USB adapters plugged in so the serial port list is completely empty.
By the way, I'd love to send you a raspi but it took long enough to get this one:) Just now I'm experimenting with building the Propeller tool chain on my PC under QEMU running a Raspian image. Not sure if it's any quicker. So if you want to build raspi Prop tools I could provide instructions for setting up QEMU for raspi.
My Raspian running Raspberry Pi has no such /dev/ttyACM0 device. What is it supposed to be? I have no USB adapters plugged in so the serial port list is completely empty.
Sorry about that, I mean /dev/ttyAMA* .... that's what you posted earlier. What is that?
jazzed- I'd be willing to send you the pi I just received yesterday to help further this along if you're interested. I don't have time right now to mess with it anyway. Just pm me your address.
Ah sorry, the Raspi has a /dev/ttyAMA0 which is the UART0 built into the ARM Soc. It comes out on pins on the GPIO header. Out of the box it is the kernel console and there is a getty running on it. I have disabled all of that so it is now free for Propeller programming use.
jazzed- I'd be willing to send you the pi I just received yesterday to help further this along if you're interested. I don't have time right now to mess with it anyway. Just pm me your address.
Thanks for the offer Don. Been trying to keep my recent RPi order a secret ... oops .... I should have something in a week or so.
Ah sorry, the Raspi has a /dev/ttyAMA0 which is the UART0 built into the ARM Soc. It comes out on pins on the GPIO header. Out of the box it is the kernel console and there is a getty running on it. I have disabled all of that so it is now free for Propeller programming use.
So what's a good short name for that? "ARM UART" "AUX Mini UART" "RPi Serial"?
In what I have read so far in the Raspi/Broadcom docs it is referred to as "UART0". The ARM Soc also has a "UART1" but so far I can't see that it comes out anywhere we can connect to and it has no device in dev.
These would be familiar names for raspi people.
It looks like neither RTS nor DTR (not available on chip anyway?) are connected to the RPi header.
I'm afraid a custom KLM (Kernel Loadable Module) will be required to emulate those pins.
Are you up to writing a KLM and scripts to insmod/install a port like /dev/ttyPropeller0 ?
Well, don't need to start from scratch of course, but the IOCTLs will need to be changed to set/reset some GPIO pin.
Is RTS actually on a GPIO but hidden?
propeller-load does indeed accept any port device but I cannot get SimpleIDE to do so. The port selection dialog box is not editable so I cannot enter a device that is not discovered by the scan.
This is true on the Raspi and my PC Debian box.
@Coley,
The loader might have to wait a day, I stated writing instructions to run it but have run now myself.
No problem, if you can you identify which of the GPIO (other than the UART) you are using then I can knock up a cable ready.
According to the schematic and the peripheral spec, it looks like RTS (0 or 1) can be put on GPIO0.
Connector GPIO0 is actually GPIO17 on the chip. Unfortunately it seems that only one UART can be used at a time.
Seems like a perfect opportunity to use a Propeller as a serial MUX board. No?
RTS is also available on GPIO31 which is a config bit. It might be easy to add a cap and transistor to that for reset.
Jazzed,
I already have a modified propeller-loader that uses GPIO17 for the Propeller reset. It could actually be any other free GPIO but I chose that as it has RTS functionality in some mode or other for whichever UART.
I have thought about tweaking the device driver to use that or other GPIO for RTS. That would mean we don't have to change propeller-loader. Perhaps I will purse that if these first experiments work out.
Serial MUX is a fine example of Prop usage with a Pi and the sort reason I want to get on with the "Propeller Pi" board.
Jazzed,
I already have a modified propeller-loader that uses GPIO17 for the Propeller reset. It could actually be any other free GPIO but I chose that as it has RTS functionality in some mode or other for whichever UART.
I have thought about tweaking the device driver to use that or other GPIO for RTS. That would mean we don't have to change propeller-loader. Perhaps I will purse that if these first experiments work out.
Excellent !
RTS reset is already supported in propeller-load and SimpleIDE. Guess you have to enable GPIO17 on the RPi chip though.
Not exactly. GPIO17 in the default set up is just another bit of IO that you can set to input or output and wiggle up and down. Totaly nothing to do with any UART.
So, I just hacked the propeller reset function in propeller-loader to wiggle that GPIO to reset the Prop instead of wiggling DTR or RTS.
Currently this is a hack. Actually some guys on the raspi forums insist that it is the correct way to do things and using RTS/DTR is a hack and misuse of a serial port.
Not exactly. GPIO17 in the default set up is just another bit of IO that you can set to input or output and wiggle up and down. Totaly nothing to do with any UART.
Have you seen the Peripherals spec page 102? Paragraph: 6.2 Alternative Function Assignments and Table 6-31 GPIO Pins Alternative Function Assignment
So, I just hacked the propeller reset function in propeller-loader to wiggle that GPIO to reset the Prop instead of wiggling DTR or RTS.
Currently this is a hack.
Actually some guys on the raspi forums insist that it is the correct way to do things and using RTS/DTR is a hack and misuse of a serial port.
Techically they are correct. High-jacking of these definitions for reset is no end of trouble in mult-OS serial applications. All 3 modern OS platforms behave differently The worst offender is MAC which will toggle the state of DTR after all applications have closed the port whether you like it or not.
No, I have not looked hard at the ALT funtionality yet. One step at a time.
It's messy which ever way. To use RTS it seems we need to create UART driver with that IOCTL. The user then has to install that. Probably it would have to be supplied with the package.
To use just a regular GPIO pin we have to allow the loader su permissions to memory map the GPIO registers
No, I have not looked hard at the ALT funtionality yet. One step at a time.
It's messy which ever way. To use RTS it seems we need to create UART driver with that IOCTL. The user then has to install that. Probably it would have to be supplied with the package.
To use just a regular GPIO pin we have to allow the loader su permissions to memory map the GPIO registers
I don't know what's best.
Just hacking propeller-load to use the GPIO pin is fine by me. There is a parameter that we pass to propeller-load to tell it which method to use -Dreset=DTR or -Dreset=RTS. Maybe another type can be added. That is much easier than adding a new KLM and setting up a new device.
Comments
Sorry but hacking on the loader got interrupted by my birthday. It should work with a PropPlug though.
All the great people are born in August!!!
I did have to reboot though, when I initially ran the IDE straight after install my Pi just sat there doing nothing.
That's what prompted me to reboot, so after the reboot I did the same command and it worked, stange.......
I can try it again from a fresh install of Raspbian if you like.
Regards,
Coley
Nothing hung up the one and only time a ran the installer but then I was talking to it over the net with ssh from my Linux PC so not perhaps not the same situation.
I'll have to try it myself.
Regards,
Coley
Just curious. What was your command to install?
One of these is preferred. cd to package first.
- $ sudo ./setup.sh ${USER}
- $ su then $ ./setup.sh userid
The setup script today will copy propeller-gcc to /opt/parallaxI wonder if there is enough room in the root filesystem for everything.
Is Raspian big enough to handle this like other linux installs?
Also I have installed a bunch of stuff since then so I have long since forgotten how much of the original 4GB fs was free.
The last time I built propgcc I had it on an NFS share from my PC. Not sure if it actually built any faster though.
I'm using a 16GB class 10 SD card, not had any problems before but as I said I am a complete noob with all things Linux.
It actually worked this time but I have no idea why as I did exactly the same as yesterday (followed the instructions in the text file in the archive).
I used $ sudo ./setup.sh ${USER} to run the setup script.
I've actually tried both ways now and they worked so it must have been something I missed.
Now that it is running the only thing I don't seem to be able to do is to select a board type, the option is available but no boards are listed?
Regards,
Coley
The paths must be selected correctly. Please see page 7 of the user guide: https://sites.google.com/site/propellergcc/documentation/simpleide
I've attached some screen-shots of recommended SimpleIDE v0-8-3 Properties settings since the user guide is a bit out of date. I need to update it for version 0-8-x .
For SPIN programs the board type will always be NONE for now.
The window shown is opened using the wrench on the tool bar.
Well I checked that the paths were set in Properties (F6) and they appeared to be but it wasn't until I clicked OK that the board types appeared.
I think what happened is I must have clicked Cancel when the Properties dialogue was displayed when the application was run for the first time.
I'm, happy now, thank you for your help and for writing a great app!
Big thanks to Heater too for compiling this for the Pi.
My next job is to load something to the Prop but for that I need a USB hub which is on order....
Thanks,
Coley
Are you up for making a connection from the Raspi onboard UART, on the GPIO header, to a Propeller?
I have an experimental hack of the loader to use that port but probably no time for testing anything just now.
Sure, just let me know the detail and I will have a look when I get home.
This is true on the Raspi and my PC Debian box.
@Coley,
The loader might have to wait a day, I stated writing instructions to run it but have run now myself.
I have some enhancements and will push them soon for 0-8-4. It would be nice to add a fix for this too.
What is the ttyACM* device called? I need a very brief and friendly name to associate with it.
Longer term adding a discovery filter for ports is better, but I don't have time right now. The port dialog will temporarily become editable.
Thanks,
--Steve
My Raspian running Raspberry Pi has no such /dev/ttyACM0 device. What is it supposed to be? I have no USB adapters plugged in so the serial port list is completely empty.
By the way, I'd love to send you a raspi but it took long enough to get this one:) Just now I'm experimenting with building the Propeller tool chain on my PC under QEMU running a Raspian image. Not sure if it's any quicker. So if you want to build raspi Prop tools I could provide instructions for setting up QEMU for raspi.
Sorry about that, I mean /dev/ttyAMA* .... that's what you posted earlier. What is that?
Don
Thanks for the offer Don. Been trying to keep my recent RPi order a secret ... oops
So what's a good short name for that? "ARM UART" "AUX Mini UART" "RPi Serial"?
These would be familiar names for raspi people.
It looks like neither RTS nor DTR (not available on chip anyway?) are connected to the RPi header.
I'm afraid a custom KLM (Kernel Loadable Module) will be required to emulate those pins.
Are you up to writing a KLM and scripts to insmod/install a port like /dev/ttyPropeller0 ?
Well, don't need to start from scratch of course, but the IOCTLs will need to be changed to set/reset some GPIO pin.
Is RTS actually on a GPIO but hidden?
No problem, if you can you identify which of the GPIO (other than the UART) you are using then I can knock up a cable ready.
Thanks,
Coley
Connector GPIO0 is actually GPIO17 on the chip. Unfortunately it seems that only one UART can be used at a time.
Seems like a perfect opportunity to use a Propeller as a serial MUX board. No?
RTS is also available on GPIO31 which is a config bit. It might be easy to add a cap and transistor to that for reset.
I already have a modified propeller-loader that uses GPIO17 for the Propeller reset. It could actually be any other free GPIO but I chose that as it has RTS functionality in some mode or other for whichever UART.
I have thought about tweaking the device driver to use that or other GPIO for RTS. That would mean we don't have to change propeller-loader. Perhaps I will purse that if these first experiments work out.
Serial MUX is a fine example of Prop usage with a Pi and the sort reason I want to get on with the "Propeller Pi" board.
Excellent !
RTS reset is already supported in propeller-load and SimpleIDE. Guess you have to enable GPIO17 on the RPi chip though.
Cheers.
So, I just hacked the propeller reset function in propeller-loader to wiggle that GPIO to reset the Prop instead of wiggling DTR or RTS.
Currently this is a hack. Actually some guys on the raspi forums insist that it is the correct way to do things and using RTS/DTR is a hack and misuse of a serial port.
Have you seen the Peripherals spec page 102? Paragraph: 6.2 Alternative Function Assignments and Table 6-31 GPIO Pins Alternative Function Assignment
Ya, that sounds fine.
Techically they are correct. High-jacking of these definitions for reset is no end of trouble in mult-OS serial applications. All 3 modern OS platforms behave differently
It's messy which ever way. To use RTS it seems we need to create UART driver with that IOCTL. The user then has to install that. Probably it would have to be supplied with the package.
To use just a regular GPIO pin we have to allow the loader su permissions to memory map the GPIO registers
I don't know what's best.
Just hacking propeller-load to use the GPIO pin is fine by me. There is a parameter that we pass to propeller-load to tell it which method to use -Dreset=DTR or -Dreset=RTS. Maybe another type can be added. That is much easier than adding a new KLM and setting up a new device.
Thanks,
--Steve