serial communication

P!-Ro

I'm hoping to have serial communication occur between a prop and a pic, but I do not have any experience with it. Anybody wish to fill me in?

BTW--my intent is to transfer the numbers 1-20 (maybe more later) that would specify servo positions·controlling the·valve·on my gas engine. Then the pic could·then replicate it automatically without waisting a cog.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PG

Mike Green

The Prop end is easy. There are several serial I/O driver objects in the Object Exchange, anything from Simple_Serial to FullDuplexSerial. Simple_Serial is, well, simple and will probably do the job. Like all such objects, they come either with instructions in the source code comments or in a sample or demo program included.

The PIC end is another thing entirely. It depends on the particular PIC you're using and whether it has a built-in hardware UART (Universal Asynchronous Receiver Transmitter) or whether the work has to be done in software. If you're using something like C or Basic for programming, the I/O library that comes with the compiler will probably have one or more serial input routines. You'll have to consult the manual for details.

The easiest thing to do is to run the PIC off the same supply voltage as the Propeller so all you need between the two is an optional 1K series resistor which protects the Propeller and PIC I/O pins from a programming error that makes both I/O pins outputs and of opposite polarity. It can happen.

P!-Ro

I'm using the Pic16F684 and the PICC Lite compiler. I tried looking for a library on it but I couldn't find any. My guess is that I will have to do it all with code, though. So if this is the case, how would I start trying to do this? I'm sure I would need to check the times of each change in pin state to tell that there are two ones or zeros together, but the best I can think of is incrementing a variable for this. Surely there is a better way?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PG

Mike Green

Look at how Simple_Serial does it. It's all written in Spin and is commented, so it should be relatively easy to understand.

P!-Ro

Unfortunately I do not know how to convert the propeller code to something compatable for the Pic. I asked a similar question on another forum and they said I would be better off working with the Arduino since it has a stronger fan base and would be easier to find information on. What do you think?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PG

BradC

Pi Guy said...
Unfortunately I do not know how to convert the propeller code to something compatable for the Pic. I asked a similar question on another forum and they said I would be better off working with the Arduino since it has a stronger fan base and would be easier to find information on. What do you think?

I think you'd be better off foregoing the second processor and simply doing it with the Propeller.

If you are going to go in-depth enough with a completely different architecture, perhaps you'd be better off going a bit deeper with the Propeller and re-writing some of your drivers to save a cog or two. I recently consolidated a few drivers into a single cog. I now have one assembly cog that performs duty as :

- RTC (with millisecond counter)
- 11 Channel 10-Bit A/D at 150K Samples/Sec (with 8 sample smoothing)
- 8 outputs on a 74HC595

And it's still idle most of the time and nearly half empty.

You can cram an awful lot of code into a single cog if you push it hard enough.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?

P!-Ro

Right now I'm trying to simplify the workload on the Prop in my project so I won't need to use multiple prop chips, although I probably will In the future. Here Is the workload I expect it to have in the next few months (maybe more since I need to get many of the parts)
digital compass
accelerometer
two servos with sonar modules on top
multiple ir object detectors--maybe about 20 or so to cover the front of my robot
GPS
radio transmitter/reciever
2 servos controlling my engine
motor for the brakes
motor for the steering
and in the far future a camera or two as well
Explain why I wish to use other micros as well?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PG

Mike Green

One cog can handle all the servos (Servo32v6). One cog can handle the radio transmitter/receiver and the GPS (4-port serial I/O). The sonar modules (PING?) are rarely triggered together, so one cog could handle both part of the time. The compass and accelerometer are probably both SPI and could be handled serially by another cog. The IR detectors would be attached to some kind of I/O expander which could be either I2C or SPI and could be read by the same cog reading the compass.

That's only 4 cogs and one of them is free much of the time. Even if you wanted multiple micros, the other ports of the serial I/O driver could handle that I/O (to talk to the other micro).

P!-Ro

It's more complex than that, really. I'm hoping to save the positions of ping (it will be a different one, really) on an SD card for distance/servo position and figure out the length of objects by taking the raw length, figuring out how long the 30 degree cone is at that length, subtracting half for one side and doing the same for the other depending on it's own distance, and taking those measurements and turning them into x y coordinates which I will then use to figure out the speed and turning strength needed to make the minimum amount of distance away from the object possible (say 3').

One other thing I didn't add to the top list is a program to measure engine rpm as well as actual wheel output. This way I can know true output speed as well as know how much slippage is occurring on the clutch. If there is too much, the robot may need to find a different way around to prevent it from burning up.
These are some other features things the robot will have:

Band protection:
It will use an IR detector on each side of the robot to detect IR signals from a band on the wrist of each person working around the robot. If the robot is in motion and can detect signals from one of these bands, it will automatically shut off the engine.

Emergency break activator:
If something occurs that cuts power or if there is another reason for lack of break usage, a signal possibly from another micro other than the prop will activate the breaks with a small battery pack separate from the rest of the electrical system.

Advanced people and animal detection:
I may use one or multiple IR heat sensors to detect people or animals in front of the robot.(sorry I didn't add this to the above list)

Operator input:
Above the control box there will be an LCD and possibly later a uOLED screen that will display run options, with a keypad allowing for input.

Warning lights:
If something should break down when the robot is in a dangerous area, such as on a road, many warning LEDs will flash informing other drivers of the robots presence.

Also, if I get it working with a camera, I intend to have it able to detect the difference between a rock, gravel, and paved road to change its speed and other actions accordingly, as well as be able to tell surfaces it can and can't drive on by color. I will also use it to attempt tasks such as possibly following a car using its color, and maybe also to try to find people with shirt color.

Some fun tasks in the future such as mounting a paintball gun and other fun things will also require it to predict paintball movements through the air and decide gun positions, as well as be able to know changing location of itself and it's target as it moves along.

For now one prop is fine, but I truly don't expect it to stay that way.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PG