Thank you for the kind words, hope that the 'computer emergency' was resolved to your wife's satisfaction
I've been tracking your "next large robot" thread - I can't even begin to imagine building something that large and cool, I simply don't have the metal workshop capacity for it!
I've been wanting to build a small hexapod for quite a while, but could not justify the price. Fortunately, after Ebay deep-diving about a month ago, I found an affordable option. I received my indexpensive hexapod chassis and Tower Pro MG995 servos a few days ago, and spent most of yesterday building most of it.
Rich,
You are most welcome - I was surprised that I received several inquiries (in addition to yours) for assembled and tested boards, the prevailing thought I picked up on was "inexpensive or bust".
All,
In case anyone is interested, I started a "HexPi" page where I will talk about my small (one of DriverBob's hexapod's feet is almost bigger than my whole bot!) here:
I hope to get the other three legs mounted and roughly calibrated today.
Then I'll google to find hexapod code, especially for Propeller based hexapods. The heavy math (inverse kinematics) will move to the Pi, which will also handle vision and Wifi.
If you will provide separate power for the servo headers at VBAT on the screw terminal, you can inject power at the "PI5V" terminal of the power selection headers SV2 and SV3.
If you are certain you will never mount RoboPi on a Pi, you can inject 5V at pins 2&4 of the Pi header (first two pins on the upper left of the pcb as shown on p.5 of the build manual), ground can be attached in many places, including pins 9 & 14 of the Pi connector, the GND screw terminal etc.
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.
So popping back in here because my new PCBs for the BeagleBone are tested and working electrically. The BBBlack is booting, on wireless, and and the buffer / RTC / and power control all work! (I'm very excited tonight). Forgive me but I am somewhat retarded in the ways of source control.... how do I get ahold of the new loader source? Is it possible to change the GPIO number now since #17 is not viable on my PCB for this purpose? I carved out a GPIO for the reset but until I have a loader that can use the one GPIO pin I designed for I can't get a program onto the mounted propeller chip. It sounded like that may be what you guys were working on but I'm not completely sure from the dialog.
David has put my changes for using the UART on the Raspberry Pi GPIO header into the propeller loader that is included with propgcc.
You can get the sources here: https://code.google.com/p/propgcc/source/checkout
You need to have the Mercurial version control program installed and use the command "hg clone https://code.google.com/p/propgcc/" that will fetch the source code.
In there you will find a loader directory.
Be warned that I have not had a chance to test this loader yet so it may not work or it may eat your system:)
If you want to change that GPIO 17 you will have to find it in the code hack it there.
Gotcha. I'll be VERY unhappy with you if it eats my system
I'll see what I can do with it this month. If it's possible to keep the GPIO designation fairly generic (since in the filesystem it's just an integer-named folder) then it should be fairly easy to adapt to various ARM platforms beyond the Pi. Does this require the loader to be run with root privileges or would the user be required to export the GPIO prior to the loader doing it's thing?
I got the RoboPi all soldered together, did voltage checks and everything came out OK. I went to put on the PropPlug and this is a 5 pin header on the board and the Parallax Propellor Plug uses a 4 pin plug. Was the board designed for another type of prop plug? If so, where can I get one? I always assumed that the plug I had would be OK since it was from Parallax. I haven't had to use it for quite a while and didn't realize the mismatch.
I got the RoboPi all soldered together, did voltage checks and everything came out OK. I went to put on the PropPlug and this is a 5 pin header on the board and the Parallax Propellor Plug uses a 4 pin plug. Was the board designed for another type of prop plug? If so, where can I get one? I always assumed that the plug I had would be OK since it was from Parallax. I haven't had to use it for quite a while and didn't realize the mismatch.
There are later a couple more calls to gpio_write() to assert and deassert the reset when programming.
There are a couple ways this could go. Define the reset GPIO number based on defines of RASPBERRY_PI, BBBLack, BBWhite, BOBS_ARMBOARD, blah blah. That seems quick-n-dirty to get it to work on any platform as the gpio_<whatever> functions all seem appropriate to any ARM Linux work. The problem of course is that there is no standard pin to use so thus no one pin that would be defined for a given board. For instance I'll use 48 on my BBBlack but there may be nobody else on earth that does.
Instead we could just define the pin number directly and let the user be responsible to set that define properly for their implementation but that's a little opaque because those numbers are not necessarily the easiest things to determine.
There could be a separate mapping of some type that converted say the constant P9_15 to the value 48. I do something similar in a class I use for GPIO pin access in C++. I have an enum table that goes from header_pin to GPIO number. I also want to build another table to go from the string "header_pin" to GPIO number so config files are easy to create with pin definitions that are immediately obvious to the board user. So how to do that in a scaleable fashion here would be a good question but probably better suited to another thread since the issue of getting it working with Pi is solved and it should be simple for me to hack that to work with BBBlack.
UART 1,2,4,5 have RTS available, so I suspect the generic ioctl() for pulling RTS low, then raising it is all you need.
Yeah those pins are snagged for other GPIO use for me but that would be a good idea for me to change on a follow-up design. I may be able to re-route some other pins to fill in for those and that would allow using ttyO2 without alteration. I had heard rumors that those functions (RTS/CTS) really didn't work so it seems like a candidate to test.
FYI, I may produce a "RoboBone", however I am not sure the market is large enough to generate enough sales.
So far, my only product for the BeagleBone is "EZasBone":
It seems to be popular enough that supply was being gobbled up as fast as it was produced. What the numbers in comparison to RPi are I have no idea, but the BBBlack does suffer from a poor out-of-the-box distro (Angstrom), and is a bit more technically demanding to interface to. It's also not got the community resources of the RPi yet. Your EZasBone board is interesting to me. That would allow a bit of fudging for developing my mainboard a bit further and trying some things to see if they are viable to include in the design. I may order that.
I was family-napped for the Thanksgiving long weekend.
Thanksgiving?!? That is one hell of a captivity period!
Yeah those pins are snagged for other GPIO use for me but that would be a good idea for me to change on a follow-up design. I may be able to re-route some other pins to fill in for those and that would allow using ttyO2 without alteration. I had heard rumors that those functions (RTS/CTS) really didn't work so it seems like a candidate to test.
It seems to be popular enough that supply was being gobbled up as fast as it was produced. What the numbers in comparison to RPi are I have no idea, but the BBBlack does suffer from a poor out-of-the-box distro (Angstrom), and is a bit more technically demanding to interface to. It's also not got the community resources of the RPi yet. Your EZasBone board is interesting to me. That would allow a bit of fudging for developing my mainboard a bit further and trying some things to see if they are viable to include in the design. I may order that.
Thanks for the kind words on EZasBone!
The BBB a great board - and like you, I have my doubts about the on-board Linux - however there is one big "gotcha"
TI has a "license" for the board that prohibits embedding it into products.
We know that won't affect one-offs or personal use of it, but it does threaten litigation if you embed it into a larger system and sell that.
This has had a certain cooling effect on people (other than circuit co) making products for the BBB.
YAY!! I finally built one of my RoboPi's (and a SchoolBoard)
YAY!! It works as a standalone Propeller!! (It even runs PropForth in case you were curious )
Now, I have it connected to a RasPi and my lack of C knowledge could be getting me in trouble.
I copied your .h and .a files over to my RasPi in my working directory
pi@tornado ~/src/robo_pi_c $ ls -l
total 20
-rw-r--r-- 1 pi pi 459 May 5 18:52 led_test.c
-rw-rw-r-- 1 pi pi 9876 May 5 19:03 RoboPiLib.a
-rw-rw-r-- 1 pi pi 1397 Mar 24 16:08 RoboPiLib_v0.71.h
pi@tornado ~/src/robo_pi_c $
pi@tornado ~/src/robo_pi_c $ gcc led_test.c RoboPiLib.a
RoboPiLib.a: could not read symbols: Archive has no index; run ranlib to add one
collect2: ld returned 1 exit status
pi@tornado ~/src/robo_pi_c $
I then ran ranlib as suggested "ranlib RoboPiLib.a"
and got the same results.
What am I missing (other than a nice Python module to use with the RoboPi)?
Thanks!!
EDIT: As some forumites might say about other languiages, at this point, I'd been looking at C long enough to make my eyes bleed!
I'm still having my C library issue from the post above so I've switched over to Python (my eyes don't bleed!).
For anyone playing with RoboPi and a RasPi (or just a RasPi), there is a really nice Python GPIO package...it's called RPIO and it builds on the original GPIO module with a bunch of nifty features.
One nice thing it has is a command line tool to issue GPIO commands on the RasPi. The command is 'rpio' and it lest you set pins for input or output, set them high or low, etc. So with it, you can put together a nice little shell script like so:
to force a reset on your RoboPi board. Sometimes a handy thing while playing.
I also too the "special" propeller-load that uses AMA0 and renamed it prop-load-ama0 so I can have both loaders (AMA0 and ttyusb) in /opt/parallax/bin and load the RoboPi on AMA0 and also any other Prop I plug into a USB port.
It all works a famously! Now, I need to go off and decode/recode the RasPi library routines from C to Python so the world can be a little better place and I can talk to my RoboPi.
YAY!! I finally built one of my RoboPi's (and a SchoolBoard)
YAY!! It works as a standalone Propeller!! (It even runs PropForth in case you were curious )
Now, I have it connected to a RasPi and my lack of C knowledge could be getting me in trouble.
I copied your .h and .a files over to my RasPi in my working directory
pi@tornado ~/src/robo_pi_c $ ls -l
total 20
-rw-r--r-- 1 pi pi 459 May 5 18:52 led_test.c
-rw-rw-r-- 1 pi pi 9876 May 5 19:03 RoboPiLib.a
-rw-rw-r-- 1 pi pi 1397 Mar 24 16:08 RoboPiLib_v0.71.h
pi@tornado ~/src/robo_pi_c $
pi@tornado ~/src/robo_pi_c $ gcc led_test.c RoboPiLib.a
RoboPiLib.a: could not read symbols: Archive has no index; run ranlib to add one
collect2: ld returned 1 exit status
pi@tornado ~/src/robo_pi_c $
I then ran ranlib as suggested "ranlib RoboPiLib.a"
and got the same results.
What am I missing (other than a nice Python module to use with the RoboPi)?
Thanks!!
EDIT: As some forumites might say about other languiages, at this point, I'd been looking at C long enough to make my eyes bleed!
I'm still having my C library issue from the post above so I've switched over to Python (my eyes don't bleed!).
For anyone playing with RoboPi and a RasPi (or just a RasPi), there is a really nice Python GPIO package...it's called RPIO and it builds on the original GPIO module with a bunch of nifty features.
One nice thing it has is a command line tool to issue GPIO commands on the RasPi. The command is 'rpio' and it lest you set pins for input or output, set them high or low, etc. So with it, you can put together a nice little shell script like so:
to force a reset on your RoboPi board. Sometimes a handy thing while playing.
I also too the "special" propeller-load that uses AMA0 and renamed it prop-load-ama0 so I can have both loaders (AMA0 and ttyusb) in /opt/parallax/bin and load the RoboPi on AMA0 and also any other Prop I plug into a USB port.
It all works a famously! Now, I need to go off and decode/recode the RasPi library routines from C to Python so the world can be a little better place and I can talk to my RoboPi.
Python is so nifty! Except for not having time to play with it much, I'm putting all the pieces together today.
I've been working on it between work work and I've gotten it to light up an LED! (Once you can control an LED, you can control the world!!)
It won't be pretty python and probably won't be an official module but by the end of the weekend it should have all the functionality of your C library. :thumb:
I'll post it here and probably put a link to a github repository when it is functional.
I'll be using the C libraries mostly for validation to make sure both our codes work the same....beyond that, I can't see much reason (personally, of course) to use C!
Is there something special I should be doing to use the RoboPi board as a stand alone? Using a program that I know works on the Professional development board, I don't get any errors loading the program to the RoboPi board but the Parallax Serial Terminal returns special characters only. The characters are consistant each time I load the program. The only difference seems to be the development board uses a FTDI chip and your board uses the protoplug. Any ideas of what might cause something like this to happen? I suspect it's an issue with the initialization routines but I haven't been able to figure it out
Is there something special I should be doing to use the RoboPi board as a stand alone? Using a program that I know works on the Professional development board, I don't get any errors loading the program to the RoboPi board but the Parallax Serial Terminal returns special characters only. The characters are consistant each time I load the program. The only difference seems to be the development board uses a FTDI chip and your board uses the protoplug. Any ideas of what might cause something like this to happen? I suspect it's an issue with the initialization routines but I haven't been able to figure it out
Python is so nifty! Except for not having time to play with it much, I'm putting all the pieces together today.
I've been working on it between work work and I've gotten it to light up an LED! (Once you can control an LED, you can control the world!!)
It won't be pretty python and probably won't be an official module but by the end of the weekend it should have all the functionality of your C library. :thumb:
I'll post it here and probably put a link to a github repository when it is functional.
I'll be using the C libraries mostly for validation to make sure both our codes work the same....beyond that, I can't see much reason (personally, of course) to use C!
I've updated RoboPiLib to v0.80, RoboPi User Manual to v0.60, and RoboPi Build Manual to v0.98 ... as usual, you can download the latest version from the product page at
If it is working fine in single pin mode, I see no reason to waste a pin. I'm sure any spare pins can be put to good use!
I'm being a slacker on my Python code - I got distracted by something shiny!
RoboPi did participate in a over the web demo the other night. I pointed a Dlink surveillance camera at my little LED board with the Pi and RoboPi connected to it and exposed my Pi to the Internet so I could SSH to it. So I could log into the Pi, run some Python scripts and the LED would react accordingly and we watched it over the Internet....lots of technology put into play just to blink an LED!! It all worked and was fun to do and that's what counts. More work is in order to clean up my Python module but the concepts all work, so that is good!
I need to grab the new stuff from you so I'm up to date. Ahh, so little play time!!
Comments
Thank you. When I reload my debit card I'll send you an email today or tomorrow.
Rich
Thank you for the kind words, hope that the 'computer emergency' was resolved to your wife's satisfaction
I've been tracking your "next large robot" thread - I can't even begin to imagine building something that large and cool, I simply don't have the metal workshop capacity for it!
I've been wanting to build a small hexapod for quite a while, but could not justify the price. Fortunately, after Ebay deep-diving about a month ago, I found an affordable option. I received my indexpensive hexapod chassis and Tower Pro MG995 servos a few days ago, and spent most of yesterday building most of it.
Rich,
You are most welcome - I was surprised that I received several inquiries (in addition to yours) for assembled and tested boards, the prevailing thought I picked up on was "inexpensive or bust".
All,
In case anyone is interested, I started a "HexPi" page where I will talk about my small (one of DriverBob's hexapod's feet is almost bigger than my whole bot!) here:
http://www.mikronauts.com/robot-zoo/hexpi-hexapod-pi-robot/
I hope to get the other three legs mounted and roughly calibrated today.
Then I'll google to find hexapod code, especially for Propeller based hexapods. The heavy math (inverse kinematics) will move to the Pi, which will also handle vision and Wifi.
I'll be making a slight change to the RoboPi API to support some upcoming firmware features and simplify documentation.
The current API allows treating the eight analog inputs as digital inputs for digitalRead(24..31)
This will not be supported starting with the next API release, which is expected later this week.
You can always use (analogRead(ch)>512) as the equivalent of reading the analog channel as a digital input.
If you are certain you will never mount RoboPi on a Pi, you can inject 5V at pins 2&4 of the Pi header (first two pins on the upper left of the pcb as shown on p.5 of the build manual), ground can be attached in many places, including pins 9 & 14 of the Pi connector, the GND screw terminal etc.
So popping back in here because my new PCBs for the BeagleBone are tested and working electrically. The BBBlack is booting, on wireless, and and the buffer / RTC / and power control all work! (I'm very excited tonight). Forgive me but I am somewhat retarded in the ways of source control.... how do I get ahold of the new loader source? Is it possible to change the GPIO number now since #17 is not viable on my PCB for this purpose? I carved out a GPIO for the reset but until I have a loader that can use the one GPIO pin I designed for I can't get a program onto the mounted propeller chip. It sounded like that may be what you guys were working on but I'm not completely sure from the dialog.
David has put my changes for using the UART on the Raspberry Pi GPIO header into the propeller loader that is included with propgcc.
You can get the sources here: https://code.google.com/p/propgcc/source/checkout
You need to have the Mercurial version control program installed and use the command "hg clone https://code.google.com/p/propgcc/" that will fetch the source code.
In there you will find a loader directory.
Be warned that I have not had a chance to test this loader yet so it may not work or it may eat your system:)
If you want to change that GPIO 17 you will have to find it in the code hack it there.
I have no idea if it will work on a Beagle bone.
I'll see what I can do with it this month. If it's possible to keep the GPIO designation fairly generic (since in the filesystem it's just an integer-named folder) then it should be fairly easy to adapt to various ARM platforms beyond the Pi. Does this require the loader to be run with root privileges or would the user be required to export the GPIO prior to the loader doing it's thing?
Glad to hear of your progress! Your PropPlug will work just fine.
RoboPi is designed for use with any of: PropPlug, SerPlug or Raspberry Pi
Pins 1-4 are identical to what PropPlug needs (1 is Vss), the 5th pin provides 3.3V for SerPlug (see http://www.mikronauts.com/serplug/)
When RoboPi is stacked on a Raspberry Pi, the Pi programs RoboPi.
Ok, so in looking at the code:
There are later a couple more calls to gpio_write() to assert and deassert the reset when programming.
There are a couple ways this could go. Define the reset GPIO number based on defines of RASPBERRY_PI, BBBLack, BBWhite, BOBS_ARMBOARD, blah blah. That seems quick-n-dirty to get it to work on any platform as the gpio_<whatever> functions all seem appropriate to any ARM Linux work. The problem of course is that there is no standard pin to use so thus no one pin that would be defined for a given board. For instance I'll use 48 on my BBBlack but there may be nobody else on earth that does.
Instead we could just define the pin number directly and let the user be responsible to set that define properly for their implementation but that's a little opaque because those numbers are not necessarily the easiest things to determine.
There could be a separate mapping of some type that converted say the constant P9_15 to the value 48. I do something similar in a class I use for GPIO pin access in C++. I have an enum table that goes from header_pin to GPIO number. I also want to build another table to go from the string "header_pin" to GPIO number so config files are easy to create with pin definitions that are immediately obvious to the board user. So how to do that in a scaleable fashion here would be a good question but probably better suited to another thread since the issue of getting it working with Pi is solved and it should be simple for me to hack that to work with BBBlack.
See http://beaglebone.cameon.net/home/serial-ports-uart
UART 1,2,4,5 have RTS available, so I suspect the generic ioctl() for pulling RTS low, then raising it is all you need.
For initial testing, you could just use a PropPlug, however 1/2/4/5 should work easily.
For the console uart 0, you would have to use a generic I/O for reset (like GPIO#17 on the Pi) as you wrote above.
FYI, I may produce a "RoboBone", however I am not sure the market is large enough to generate enough sales.
So far, my only product for the BeagleBone is "EZasBone":
http://www.mikronauts.com/proto/ezasbone/
I intend to try RoboPi with my BBB's, however I am not likely to have time to do that for a while.
Right now, I am working on:
- next rev RoboPi API, RoboPiObj, RoboPiLib (for Pi)
- next rev RoboPi User Manual
- RoboPiPyLib (port of RoboPiLib to Python)
And my "play" time is for:
- HexPi - my first hexapod build, based on RoboPi and a Pi
- the "Better Mousetrap" Servo Tester, RoboPi based (stand-alone)
RoboPiBoneLib should only be a re-compile of RoboPiLib, as all it uses is standard serial code, and does not need flow control.
I was family-napped for the Thanksgiving long weekend.
Yeah those pins are snagged for other GPIO use for me but that would be a good idea for me to change on a follow-up design. I may be able to re-route some other pins to fill in for those and that would allow using ttyO2 without alteration. I had heard rumors that those functions (RTS/CTS) really didn't work so it seems like a candidate to test.
It seems to be popular enough that supply was being gobbled up as fast as it was produced. What the numbers in comparison to RPi are I have no idea, but the BBBlack does suffer from a poor out-of-the-box distro (Angstrom), and is a bit more technically demanding to interface to. It's also not got the community resources of the RPi yet. Your EZasBone board is interesting to me. That would allow a bit of fudging for developing my mainboard a bit further and trying some things to see if they are viable to include in the design. I may order that.
Thanksgiving?!? That is one hell of a captivity period!
You have a lot of choices my friend
Thanks for the kind words on EZasBone!
The BBB a great board - and like you, I have my doubts about the on-board Linux - however there is one big "gotcha"
TI has a "license" for the board that prohibits embedding it into products.
We know that won't affect one-offs or personal use of it, but it does threaten litigation if you embed it into a larger system and sell that.
This has had a certain cooling effect on people (other than circuit co) making products for the BBB.
Yep!
But good food & family time was great
YAY!! It works as a standalone Propeller!! (It even runs PropForth in case you were curious
Now, I have it connected to a RasPi and my lack of C knowledge could be getting me in trouble.
I copied your .h and .a files over to my RasPi in my working directory
I wrote a tiny .c program based on your examples
pi@tornado ~/src/robo_pi_c $ cat led_test.c #include "stdio.h" #include "RoboPiLib_v0.71.h" #define LED_0 0 #define LED_1 1 #define LED_2 2 int main(int argc, char *argv[]) { pinMode(LED_0, OUTPUT); pinMode(LED_1, OUTPUT); pinMode(LED_2, OUTPUT); while(1) { digitalWrite(LED_0,1); digitalWrite(LED_1,1); digitalWrite(LED_2,1); sleep(1000); digitalWrite(LED_0,0); sleep(1000); digitalWrite(LED_1,0); sleep(1000); digitalWrite(LED_2,0); sleep(1000); } } pi@tornado ~/src/robo_pi_c $I compiled it and got this: I then ran ranlib as suggested "ranlib RoboPiLib.a"and got the same results.
What am I missing (other than a nice Python module to use with the RoboPi)?
Thanks!!
EDIT: As some forumites might say about other languiages, at this point, I'd been looking at C long enough to make my eyes bleed!
For anyone playing with RoboPi and a RasPi (or just a RasPi), there is a really nice Python GPIO package...it's called RPIO and it builds on the original GPIO module with a bunch of nifty features.
One nice thing it has is a command line tool to issue GPIO commands on the RasPi. The command is 'rpio' and it lest you set pins for input or output, set them high or low, etc. So with it, you can put together a nice little shell script like so:
to force a reset on your RoboPi board. Sometimes a handy thing while playing.
I also too the "special" propeller-load that uses AMA0 and renamed it prop-load-ama0 so I can have both loaders (AMA0 and ttyusb) in /opt/parallax/bin and load the RoboPi on AMA0 and also any other Prop I plug into a USB port.
It all works a famously! Now, I need to go off and decode/recode the RasPi library routines from C to Python so the world can be a little better place and I can talk to my RoboPi.
sorry for the delayed response, I am in the states with limited internet, without a RoboPi or Pi!
Try
gcc led_test.c -o led_test -l RoboPiLib.a
sudo led_test
The spin source for the RoboPi firmware is easy to read, it should be very easy to get python talking to RoboPi over pyserial.
The next version of the firmware will drop reading ain0..ain7 with digitalRead(24..31)
Hi Bill,
That, gave me this:
It doesn't seem to like the .a file as either a library (-l) or an archive as in my original attempt.
I even copied the .zip over to the Raspi and unzipped it there to get fresh copies.
I'm sure it's more my lack of C/unix development knowledge than most anything else.
On the Python front, getting Python to talk to your firmware is going well.
Enjoy your travels! Nothing earth shattering to be concerned with here. I'm just playing in my spare time. No worries.
Very interesting, my memory says that worked for me!
I should have brought a Pi and RoboPi on my trip.
I will get back to you as soon as I am back in my lab.
Looking forward to seeing what you do with RoboPi!!!
I am back in Vancouver now, and will find out why the library did not link for you tonight or tomorrow.
How's the python interface going?
I've been working on it between work work and I've gotten it to light up an LED! (Once you can control an LED, you can control the world!!)
It won't be pretty python and probably won't be an official module but by the end of the weekend it should have all the functionality of your C library. :thumb:
I'll post it here and probably put a link to a github repository when it is functional.
I'll be using the C libraries mostly for validation to make sure both our codes work the same....beyond that, I can't see much reason (personally, of course) to use C!
Great question, more for me to put into the next version of the manual
RoboPi uses a 6.250MHz crystal (so that it runs at 100MHz) so your Spin code should start with
CON _clkmode = xtal1 + pll16x _xinfreq = 6_250_000Note the _xinfreq
You were getting special characters as the baud rate was incorrect if your code specified 5_000_000 for _xinfreq
Best Regards,
Bill
I was able to reproduce your issue with RoboPiLib.a ... and I fixed it
Head over to the product page at
http://www.mikronauts.com/raspberry-pi/robopi/
to download RoboPiLib_v0.80.zip
which includes the header, and both .o and .a versions of RoboPiLib.
The source is too ugly to release at this point, but will eventually be up on the product page.
Looking forward to seeing your python code!
Bill
You are welcome!
Everyone:
I've updated RoboPiLib to v0.80, RoboPi User Manual to v0.60, and RoboPi Build Manual to v0.98 ... as usual, you can download the latest version from the product page at
http://www.mikronauts.com/raspberry-pi/robopi/
I just finished testing cheap HC-SR04 distance sensors with RoboPi in one pin mode - works fine.
Do you guys see any need for supporting a two pin mode with these inexpensive ultrasonic range sensors?
I said I'd support the two pin mode in the latest user manual, but I am thinking of dropping support for it (less documentation, one I/O saved)
Currently, I plan to support:
Parallax Ping
SeeedStudio range sensor (red)
HC-SR04
(and compatible sensors)
Syntax:
distance_in_mm = readDistance(SENSOR_TYPE, pin)
Any pin can have a distance sensor on it
I'm being a slacker on my Python code - I got distracted by something shiny!
RoboPi did participate in a over the web demo the other night. I pointed a Dlink surveillance camera at my little LED board with the Pi and RoboPi connected to it and exposed my Pi to the Internet so I could SSH to it. So I could log into the Pi, run some Python scripts and the LED would react accordingly and we watched it over the Internet....lots of technology put into play just to blink an LED!!
I need to grab the new stuff from you so I'm up to date. Ahh, so little play time!!