I've merged your code into the default branch and it builds. I just have to figure out how to modify the Makefile to build either the normal Linux version or the RaspberryPi version.
I kind of had the idea that the Raspberry Pi version is a "normal linux version". We only need one version. GPIO can be detected at run time.
If you are not running on an ARM SOC machine you probably don't have /sys/class/gpio/* so GPIO cannot be used even if the serial device is called /dev/ttyAMxx and GPIO is selected in the configs or command line.
This is why I was not sad when I lost my old version. That memory mapped the GPIO control registers into user space and wrote to them directly, hate to think what that might do on non-raspi ARM SOC machines!
I thought about testing uname -a at run time but then what if we use this on a different ARM machine, a Beagle Bone say?
I kind of had the idea that the Raspberry Pi version is a "normal linux version". We only need one version. GPIO can be detected at run time.
If you are not running on an ARM SOC machine you probably don't have /sys/class/gpio/* so GPIO cannot be used even if the serial device is called /dev/ttyAMxx and GPIO is selected in the configs or command line.
This is why I was not sad when I lost my old version. That memory mapped the GPIO control registers into user space and wrote to them directly, hate to think what that might do on non-raspi ARM SOC machines!
I thought about testing uname -a at run time but then what if we use this on a different ARM machine, a Beagle Bone say?
I thought about that but was nervous just assuming that that directory wouldn't be on anything other than a Pi.
I don't think it matters. It's like a device a program uses. Everything is a file in Unix right? The user has to enable access to a serial port device file and now they have to enable access to this GPIO virtual file if they want to use it.
I don't think it matters. It's like a device a program uses. Everything is a file in Unix right? The user has to enable access to a serial port device file and now they have to enable access to this GPIO virtual file if they want to use it.
Yes but what if that device is used differently on a different system?
It's the same as if the user would select a serial port for propeller loading that is actually used on their machine for a modem or controlling the PLC on their nuclear material processing centrifuges!
If they have a system with GPIO support in /sys/class/gpio that is used for something else then why are the pointing propeller loader at it?
Ultimately we should also have a means for the users to select the GPIO number as well in case they want to use something other than 17.
It's the same as if the user would select a serial port for propeller loading that is actually used on their machine for a modem or controlling the PLC on their nuclear material processing centrifuges!
If they have a system with GPIO support in /sys/class/gpio that is used for something else then why are the pointing propeller loader at it?
Ultimately we should also have a means for the users to select the GPIO number as well in case they want to use something other than 17.
I've merged your changes into the default branch and pushed the new code. The gpio code is under the RASPBERRY_PI conditional. Perhaps we can consider making this the default for Linux but for now you have to enable it by defining RASPBERRY_PI when compiling the loader. Your enhanced support for methods other than dtr and rts for resetting the Propeller is always enabled.
I fixed another minor bug in the original code where deasserting the reset signal was actually asserting it.
And another thing, I added your gpio files to the repository but they aren't included in the build. You'll have to add them if you define RASPBERRY_PI. I'll look into fixing the Makefile later.
I got wifey-napped yesteday afternoon (something about weekends should be for family, not Propeller or Pi stuff - imagine that), so Pi library / manual work got pushed forward to today.
I had to add a new function to the API - RoboPiExit() - to shut down the serial link, as when I separated the test program from the library code it complained about not finding the handle for the serial port for close() ... oops! Fixed.
I'll re-compile on the Pi (I used a faster box for developing it) and post RoboPiLib_v0.71.zip to the product page.
Then I'll add more beef to the manuals, and start writing demos, and making videos of my bots in action.
This is the initial version of the library, and will be expanded over time. I intend to release the source code after I’ve cleaned it up and added more error checking and comments
You need to have the RoboPi firmware installed on RoboPi in order for the library to work.
There is also an early version of the RoboPi user manual on the product page.
I will keep updating the documentation, library and add demo programs.
Should I offer a 16GB "Raspbian - RoboPi" SD card pre-configured for Propeller / RoboPi development?
I know this is an old question on this thread, but as I am starting to work with my RoboPI card I thought I would go through and read more and I saw this.
Answer: Yes, I would be glad to pay for a pre-configured SDCard
I think I am figuring out a lot of this stuff but I bet having that would have, and perhaps will, save me time.
I have a question: Is there a way to get the .eeprom file on to the prop chip via the Raspberry PI. I don't have a propplug, I guess I can get one. But I am wondering how I am going to get code on to propeller chip.
I would like to program the PI in C with Code::Blocks IDE. I am assuming I can do that with the .libs included if I load the eeprom. I could use more help getting started.
What you need is a Propeller loader that uses the UART on the Raspi GPIO header rather a USB/Serial dongle. Then all you need is 4 connections directly from Raspi to Propeller, Tx,Rx, Reset, GND.
Luckily that is what we have been working on and David Betz has included a version of such a loader in the propgcc source repository, see post #188 above.
We haven't done any testing in that loader at all yet. Given that Bill has his Prop/Pi boards out now I'm going to push the loader to the top of my TODO list. Can't even look at it till tomorrow though.
George there is a setup example to setup the RaspberryPi to run SimpleIDE. I don't have a link right now but it is on Parallax's Learn site. I have used the Pi to run a Spin program on the Prop.
Edit: I use a USB connection from the Pi to a Propeller development board and choose usb0 in the upper right of SimpleIDE.
Thought I'd at least checkout the default branch of propgcc and give it a quick compile. I can't build propgcc any more. The release branch builds but not the default.
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I/home/heater/propeller/propgcc/gcc/lto-plugin -I/home/heater/propeller/propgcc/gcc/lto-plugin/../include -DHAVE_CONFIG_H -Wall -Werror -g -O2 -c /home/heaterl/propeller/propgcc/gcc/lto-plugin/lto-plugin.c -fPIC -DPIC -o .libs/lto-plugin.o
/bin/bash ./libtool --tag=CC --tag=disable-static --mode=link gcc -Wall -Werror -g -O2 -module -bindir /opt/parallax/libexec/gcc/propeller-elf/4.6.1 -Wc,../libiberty/libiberty.a -o liblto_plugin.la -rpath /opt/parallax/libexec/gcc/propeller-elf/4.6.1 lto-plugin.lo
libtool: link: gcc -shared .libs/lto-plugin.o ../libiberty/libiberty.a -Wl,-soname -Wl,liblto_plugin.so.0 -o .libs/liblto_plugin.so.0.0.0
/usr/bin/ld: ../libiberty/libiberty.a(argv.o): relocation R_X86_64_32S against `_sch_istable' can not be used when making a shared object; recompile with -fPIC
../libiberty/libiberty.a: could not read symbols: Bad value
collect2: error: ld returned 1 exit status
make[3]: *** [liblto_plugin.la] Error 1
make[3]: Leaving directory `/home/heater/propeller/build/gcc/lto-plugin'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/heater/propeller/build/gcc/lto-plugin'
make[1]: *** [all-lto-plugin] Error 2
make[1]: Leaving directory `/home/heater/propeller/build/gcc'
make: *** [/home/heater/propeller/propgcc/../build/gcc/gcc-built] Error 2
I have a question: Is there a way to get the .eeprom file on to the prop chip via the Raspberry PI. I don't have a propplug, I guess I can get one. But I am wondering how I am going to get code on to propeller chip.
I would like to program the PI in C with Code::Blocks IDE. I am assuming I can do that with the .libs included if I load the eeprom. I could use more help getting started.
In reference to the section in the RobotPi user manual which describes how to disable the raspi serial console, I would suggest that the best approach to changing the serial console is to download Andrew Scheller's script (github.com/lurch/rpi-serial-console) which allows you to enable/disable the serial console as well as change the baudrate at will.
I don"t know if any raspi/propeller user has noted that the current version of raspian includes Wofram's Mathematica. This offers multiple possibilities for advanced data/graphing processing. See the Wolfram Language site for raspberry pi examples.
Another useful addition to the raspi is ATLAST (elinux.org/Forth) - Autodeck Threaded Language Application System Toolkit. This Forth version was implemented in C by John Wood (www.fourmilab.ch/atlast/atlast.html), a founder of Autodeck. He provides an excellent answer to the question -"Why Forth?". (He also mentions Dave Betz in his document.) ATLAST is designed to allow C coded primitives to be added to the language. Examples are given for the Gertboard.. Bill's RobotPi functions could be added to ATLAST, allowing interactive programming on the raspi side. Using TACHYON or PropForth on the propeller side would facilitate interaction with the raspi.
In reference to the section in the RobotPi user manual which describes how to disable the raspi serial console, I would suggest that the best approach to changing the serial console is to download Andrew Scheller's script (github.com/lurch/rpi-serial-console) which allows you to enable/disable the serial console as well as change the baudrate at will.
I don"t know if any raspi/propeller user has noted that the current version of raspian includes Wofram's Mathematica. This offers multiple possibilities for advanced data/graphing processing. See the Wolfram Language site for raspberry pi examples.
Another useful addition to the raspi is ATLAST (elinux.org/Forth) - Autodeck Threaded Language Application System Toolkit. This Forth version was implemented in C by John Wood (www.fourmilab.ch/atlast/atlast.html), a founder of Autodeck. He provides an excellent answer to the question -"Why Forth?". (He also mentions Dave Betz in his document.) ATLAST is designed to allow C coded primitives to be added to the language. Examples are given for the Gertboard.. Bill's RobotPi functions could be added to ATLAST, allowing interactive programming on the raspi side. Using TACHYON or PropForth on the propeller side would facilitate interaction with the raspi.
I am glad that they arrived safely. Funny that you should ask about assembled boards...
I've been asked by others for quotes on assembled and tested boards, so I built a batch of 10 boards in order to know if my regular assembly guys quotes (which I asked for) were reasonable.
As soon as I get a chance to test them (Monday) I could make 7 - 8 assembled and tested boards available for immediate sale.
I won't know exactly how much I need to charge until I after I test them, and see how much time testing/fixing a small batch takes for me (as a limit for the assembly guys <grin>).
I'll post assembled and tested pricing here and on the product page, probably late Monday afternoon.
The raspberry pi foundation has just released a little "raspi on a module" board that pretty much has nothing but the Soc and RAM on it and plugs into a DIMM socket.
Yep, I saw that yesterday, and it caused wheels to turn... (poor hamsters collapsed from exhaustion last nite).
Caused me to spend more time on the Pi forums yesterday than on here!
Too bad it (and its developer board) won't show up until June!
I'll go read Clock Loop's post.
All kidding aside, when I saw the announcement, I started looking into the Broadcomm data sheets, as it exposes enough I/O to make it worthwhile to study the available pins in great detail.
Now I have to find an affordable source for so-dimm sockets....
Basically, you can bet I'll make boards for it
I also saw that <$6000 pick and place thread in General... very tempting. Would be very useful for P1+ / P2...
The raspberry pi foundation has just released a little "raspi on a module" board that pretty much has nothing but the Soc and RAM on it and plugs into a DIMM socket.
Finally started putting together the first of 6 kits. The instructions are pretty clear and easy to follow. No issues with the assembly of the first board. I haven't assembled a circuit with discrete components for a while (I mostly design and build SMT boards now) so it took a bit of practice to get the right amount of solder on the pads, I tended to go with too little solder.
I would have finished except for a wife 'computer emergency' that ended up taking up more time than I expected to resolve. Looking forward to testing this board and it's brothers on my robot.
Comments
If you are not running on an ARM SOC machine you probably don't have /sys/class/gpio/* so GPIO cannot be used even if the serial device is called /dev/ttyAMxx and GPIO is selected in the configs or command line.
This is why I was not sad when I lost my old version. That memory mapped the GPIO control registers into user space and wrote to them directly, hate to think what that might do on non-raspi ARM SOC machines!
I thought about testing uname -a at run time but then what if we use this on a different ARM machine, a Beagle Bone say?
It's the same as if the user would select a serial port for propeller loading that is actually used on their machine for a modem or controlling the PLC on their nuclear material processing centrifuges!
If they have a system with GPIO support in /sys/class/gpio that is used for something else then why are the pointing propeller loader at it?
Ultimately we should also have a means for the users to select the GPIO number as well in case they want to use something other than 17.
And another thing, I added your gpio files to the repository but they aren't included in the build. You'll have to add them if you define RASPBERRY_PI. I'll look into fixing the Makefile later.
I got wifey-napped yesteday afternoon (something about weekends should be for family, not Propeller or Pi stuff - imagine that), so Pi library / manual work got pushed forward to today.
Stay tuned for important messages!
I've build RoboPiLib.a :-)
I had to add a new function to the API - RoboPiExit() - to shut down the serial link, as when I separated the test program from the library code it complained about not finding the handle for the serial port for close() ... oops! Fixed.
I'll re-compile on the Pi (I used a faster box for developing it) and post RoboPiLib_v0.71.zip to the product page.
Then I'll add more beef to the manuals, and start writing demos, and making videos of my bots in action.
http://www.mikronauts.com/raspberry-pi/robopi/
This is the initial version of the library, and will be expanded over time. I intend to release the source code after I’ve cleaned it up and added more error checking and comments
You need to have the RoboPi firmware installed on RoboPi in order for the library to work.
There is also an early version of the RoboPi user manual on the product page.
I will keep updating the documentation, library and add demo programs.
I've uploaded v0.51 of the RoboPi User Manual to the product page at
http://www.mikronauts.com/raspberry-pi/robopi/
You can find it towards the bottom of the page.
This update adds some more sample code, details on PWM, and how to use a Sharp IR distance sensor.
There will be a new version of RoboPiLib next week.
I know this is an old question on this thread, but as I am starting to work with my RoboPI card I thought I would go through and read more and I saw this.
Answer: Yes, I would be glad to pay for a pre-configured SDCard
I think I am figuring out a lot of this stuff but I bet having that would have, and perhaps will, save me time.
BTW: really like the robopi.
I would like to program the PI in C with Code::Blocks IDE. I am assuming I can do that with the .libs included if I load the eeprom. I could use more help getting started.
Thanks.
What you need is a Propeller loader that uses the UART on the Raspi GPIO header rather a USB/Serial dongle. Then all you need is 4 connections directly from Raspi to Propeller, Tx,Rx, Reset, GND.
Luckily that is what we have been working on and David Betz has included a version of such a loader in the propgcc source repository, see post #188 above.
We haven't done any testing in that loader at all yet. Given that Bill has his Prop/Pi boards out now I'm going to push the loader to the top of my TODO list. Can't even look at it till tomorrow though.
Edit: I use a USB connection from the Pi to a Propeller development board and choose usb0 in the upper right of SimpleIDE.
Edit2: I have downloaded the Broadcom C library to use with C programs from here. http://www.airspayce.com/mikem/bcm2835/
George, I'll email the old loader I use to you once I get back to the lab (tonight) I don't have the sources to it, which is why I have not posted it.
Thought I'd at least checkout the default branch of propgcc and give it a quick compile. I can't build propgcc any more. The release branch builds but not the default.
[/code]
Here is the link to the SimpleIDE (old version, I believe Heater compiled it) that I currently use:
http://dl.dropbox.com/u/81267937/SimpleIDE-0-8-4.armv6l.raspberrypi-linux.tar.bz2
Here is the propeller-load that I use:
http://forums.parallax.com/showthread.php/141469-SimpleIDE-for-Raspberry-Pi-Raspian?p=1119240&viewfull=1#post1119240
While I have not (yet) tried it, the latest SimpleIDE/propgcc/openspin build SHOULD work with that older propeller-load at the link above.
You will need to disable the tty on the serial port, and the boot messages - see link below:
http://elinux.org/RPi_Serial_Connection#Preventing_Linux_using_the_serial_port
I don"t know if any raspi/propeller user has noted that the current version of raspian includes Wofram's Mathematica. This offers multiple possibilities for advanced data/graphing processing. See the Wolfram Language site for raspberry pi examples.
Another useful addition to the raspi is ATLAST (elinux.org/Forth) - Autodeck Threaded Language Application System Toolkit. This Forth version was implemented in C by John Wood (www.fourmilab.ch/atlast/atlast.html), a founder of Autodeck. He provides an excellent answer to the question -"Why Forth?". (He also mentions Dave Betz in his document.) ATLAST is designed to allow C coded primitives to be added to the language. Examples are given for the Gertboard.. Bill's RobotPi functions could be added to ATLAST, allowing interactive programming on the raspi side. Using TACHYON or PropForth on the propeller side would facilitate interaction with the raspi.
NickL
I got my kits in on time!!! I have all of the parts I need but of course, I am going to have to do some digging, which could take a long, long time.
Do you have the assembled boards ready to go?
Rich
I'll add your suggestions to the manual and/or FAQ - they are good ones.
I am glad that they arrived safely. Funny that you should ask about assembled boards...
I've been asked by others for quotes on assembled and tested boards, so I built a batch of 10 boards in order to know if my regular assembly guys quotes (which I asked for) were reasonable.
As soon as I get a chance to test them (Monday) I could make 7 - 8 assembled and tested boards available for immediate sale.
I won't know exactly how much I need to charge until I after I test them, and see how much time testing/fixing a small batch takes for me (as a limit for the assembly guys <grin>).
I'll post assembled and tested pricing here and on the product page, probably late Monday afternoon.
Best Regards,
Bill
I was delayed by non-Pi matters and building test rigs for electrical testing
- the batch of assembled 10 RoboPi's all passed my initial electrical testing (power, vreg, no shorts on p0-p23) on the first try
- I stuffed five of them and will start full functional testing of those shortly
We have a little job for you
The raspberry pi foundation has just released a little "raspi on a module" board that pretty much has nothing but the Soc and RAM on it and plugs into a DIMM socket.
As Clock Loop has suggested we should now create a Propeller board with a DIM socket in which to plug the raspi module:
http://forums.parallax.com/showthread.php/155117-Raspberry-Pi-Ideas?p=1258382&viewfull=1#post1258382
See the Raspberry Pi Compute Module announcement here:
http://www.raspberrypi.org/raspberry-pi-compute-module-new-product/
Thank you for thinking of me :-)
Yep, I saw that yesterday, and it caused wheels to turn... (poor hamsters collapsed from exhaustion last nite).
Caused me to spend more time on the Pi forums yesterday than on here!
Too bad it (and its developer board) won't show up until June!
I'll go read Clock Loop's post.
All kidding aside, when I saw the announcement, I started looking into the Broadcomm data sheets, as it exposes enough I/O to make it worthwhile to study the available pins in great detail.
Now I have to find an affordable source for so-dimm sockets....
Basically, you can bet I'll make boards for it
I also saw that <$6000 pick and place thread in General... very tempting. Would be very useful for P1+ / P2...
Due to requests for assembled and tested RoboPi pricing, here it is:
qty.1-24 $99.95 each
qty.25-50 $95.00 each
For forum members handy with a soldering iron, who already have dip props, eeproms, and mcp3208's you can save a lot with "RoboPi Lite Kit" at $24.95
If you don't have the chips, "RoboPi Full Kit" is $49.95
All prices are in USD, and do not include shipping and handling.
Shipping & Handling to Continental US:
$16.50 for 1-4 "RoboPi Lite" kits
$16.50 for 1-2 "RoboPi Full" kits
$16.50 for 1 "RoboPi Assembled & Tested"
Above Shipping & Handling includes tracking and $100 insurance using "Tracked Small Package" shipping vi CanadaPost.
Larger orders ship Canada Post Expedited parcel, which is also reasonably priced.
I would have finished except for a wife 'computer emergency' that ended up taking up more time than I expected to resolve. Looking forward to testing this board and it's brothers on my robot.