arduino and propeller communication as a button

johnproko

I can find a way to measure temperature with the propeller and thus moved to the second best solution to provide the the temperature from the analog reading of the arduino.
It goes like this: arduino measures the analog value and breaks it down into 4 digits (DA.BC). Depending on the temperature these value will trigger a high/low state in the arduinos digital pins (35.22C will be 3pulses of D, 5 of A, 2 of B and 2 of C). Then the propeller will run an if statement until the Portal closes (4 pins for the data and one to open/ close the if statements). The problem is that propeller is constantly showing the message that is suppose to be shown only if the portal is open.
For the test im using a simple high/low from the arduino with 1s open, 5s closed.
For the propeller:
int SO;
int main()
{
SO = input(16);

while(1)
{
if (SO == 1)
{
print("Hello from ard");
pause(500);
}
}

I have attached a photo showing the wiring between them. Any ideas why it is failing to do that? I read in the forum that one can use one wire to transfer data between them. Is there anyone that has a photo of the wiring and a sample code?

DavidZemon

If your temperature sensor is an analog sensor, I highly recommend you use an "ADC" (analog-digital converter) with the Propeller and skip the Arduino entirely.

There are a few common ADCs with objects already written for the Propeller. The OBEX has lots, Simple comes with functions for whatever chip the Activity Board uses (and maybe others?) and PropWare comes with a class that works with any MCP3xxx series device.

Once you have the temperature stored as a voltage, it's a simple math equation to convert to degrees F/C. The datasheet for your thermometer will tell you what the math is, and we here on the forums would be happy to help you decipher it if needed (we'll of course need the part number or datasheet though).

johnproko

It is a simple thermistor. I would like to skip the arduino, of course, yet it cannot really understand how adc works. I am doing all the coding in C and that adds more problems as well.
Nevertheless I would like to know about arduino - propeller communication.

tomcrawford

On your picture, I can't see where you have a common ground between Arduio and the breadboard.

johnproko

The grounds are connected together. GND arduino to GND propeller.

johnproko

Actually I cannot understand why there is no database with everything in it, every problem one has is not unique. Someone else has it as well. OBEX is only for spin. For the arduino there is codebender.cc or the arduino database.
We are not all computer programmers or electricians in order to understand, and I lack the time to read a 300page book when My daily job requires reading 500 pages of accounting laws that tomorrow will have changed and I need to start over again.
No offence :-)

Electrodude

johnproko wrote: »

I am doing all the coding in C and that adds more problems as well.

johnproko wrote: »

OBEX is only for spin.

Then why don't you use Spin? It has less problems than C (when used on the Prop, at least), and is better supported and there are more drivers written for it.

johnproko

Because Spin look even more complicated while C is more close to human language (at least looks). Plus C is used in arduino making it more easy to understand.

DavidZemon

First understand that I, as the author of PropWare, am biased toward the PropWare libraries. There are ways to do this with the Simple libraries provided in SimpleIDE as well, but I don't like them as much (or else I wouldn't have written PropWare). I will leave it to other members to provide a detailed how-to with Simple.

johnproko wrote: »

It is a simple thermistor. I would like to skip the arduino, of course, yet it cannot really understand how adc works. I am doing all the coding in C and that adds more problems as well.

I promise, doing it in C won't add any more problems . (Of course... that's pretty subjective). You don't need to understand the nitty-gritty details of how ADCs work. Simply understand that a voltage with a range goes in (the thermistor signal) and out comes a stream of bits, representing the temperature as a binary number. Interpreting that stream of bits is the hard part.
Buuuut... that's what libraries are for! You don't have to do the hard part of interpreting the stream of bits because you can download code that does it for you. If you don't own any ADCs yet, then I recommend you purchase an MCP3208. It's cheap, it's simple, it's extremely common, and it has lots of channels to measure lots of different different things. Here you can purchase one for a whopping $3.50.
Once you have it in your hand, you can use PropWare (instructions for using with SimpleIDE here) to communicate with it (API docs here).

Your code might look something like this:

#include <PropWare/mcp3000.h>

using namespace PropWare;

Pin::Mask MOSI = Pin::P01;
Pin::Mask MISO = Pin::P02;
Pin::Mask SCLK = Pin::P03;
Pin::Mask CS     = Pin::P04;

int main () {
  SPI spi(MOSI, MISO, SCLK);
  MCP3000 adc(&spi, CS, MCP3000::MCP320x);

  int thermistorValue = adc.read(MCP3000::CHANNEL_0);

  while (1) {
    print("Current thermistor value = %i\n", thermistorValue);
    pause(500);
  }
}

johnproko wrote: »

Nevertheless I would like to know about arduino - propeller communication.

For this, you might be better served by using standard serial communication instead of creating your own custom protocol. UART is a good serial protocol for chip-to-chip communication. UART is the same protocol that the Propeller and the Arduino use for communicating with your computer. The only difference is that you are going to want to use different pins when communicating with a chip than when communicating with your computer.

The unfortunate thing is that you have been tricked. To make your life easier, certain UART functions were invoked without you ever knowing. Specifically, those are the initialization functions, including the ones that set the pins. This is because most users want to use the same pins at the same baud rate and all the same settings, all the time. So the library author does this behind the scenes so that your life is easy.

For instance, how does this code work???

#include "simpletools.h"

void main () {
  print("Hello, world!\n");
}

And Arduino has a similar concept with its Serial library

void setup() {
  Serial.begin(9600);
}

void loop() {
  Serial.println("Hello, world!");
}

Where did print/Serial come from? How does it know where to print? How does it know how fast to print? What is this MAGIC?!?!?

To communicate between two different chips, you'll need to be able to answer these questions. You need to:

1) Instantiate a (new) serial object. This is the object that is capable of serial communication on custom pins.
2) Configure the pins on the new serial object.
3) Configure the baud rate on the new serial object.
4) Transfer from the Arduino to the Propeller.
5) (Optional) Echo a reply from the Propeller to the Arduino.

I'll start with the Arduino. I found here the documentation for SoftwareSerial's constructor. It shows that we should be able to write some code like...

// Define which pins are used for what
const byte RECEIVE_PIN = 2;
const byte TRANSMIT_PIN = 3;

// Instantiate a custom instance "propellerComms" _and_ set the pins for this instance.
// Notice that this line of code completes steps 1 and 2
SoftwareSerial propellerComms(RECEIVE_PIN, TRANSMIT_PIN);

void setup () {
  // Set the baud rate to 9600. This completes step 3
  propellerComms.begin(9600);
}

void loop() {
  propellerComms.println("Hello");

  delay(1000);  
}

This code should send "Hello\n" out of pin 3 on the Arduino once every second. So now, let's set up code on the Propeller to receive it. We're going to use PropWare::FullDuplexUART for this.

#include <PropWare/uart/fullduplexuart.h>

using namespace PropWare;

const Pin::Mask RECEIVE_PIN = Pin::P16;
const Pin::Mask TRANSMIT_PIN = Pin::P17

int main () {
  // Again, we're completing steps 1 and 2 with this line of code
  FullDuplexSerial arduinoComms(TRANSMIT_PIN, RECEIVE_PIN);
  // And step 3 here. The baud rate _must_ match the baud rate set on the Arduino
  arduinoComms.set_baud_rate(9600);

  // We'll also configure a pin to blink an LED so you know when you've received something
  Pin ledPin(Pin::P23, Pin::OUT);

  const int BUFFER_SIZE = 128;
  char stringBuffer[BUFFER_SIZE];
  while(1) {
    arduinoComms.fgets(stringBuffer, BUFFER_SIZE);
    pin.toggle();
  }
}

Okay, this is all I have time for at the moment, but it should (might) work.

tomcrawford

In the code you posted in the original posting, you only look at input(16) once. You might try moving that inside the while(1) loop.

twm47099

John,
I've written a SIMPLEIDE C library and demo programs. They are attached to:
forums.parallax.com/discussion/comment/1315065/#Comment_1315065

I think the instructions for using the library are pretty clear, but ask if necessary.

There is a demo using the 3208 8 channel 12 adc. It should also work with the 3204, but you probably have to change the pins defines.

JasonDorie

TomCrawford already stated this, but here's the code change:

int SO;
int main()
{

  while(1)
  {
    SO = input(16);
    if (SO == 1)
    {
      print("Hello from ard");
      pause(500);
    }
  }
}

Your original version read the input once, then continuously checked the resulting value and printed the output. Nothing ever changed that value again, so the output was continually displayed. By moving the "SO = input(16)" statement inside the while loop, you now update the SO variable every loop iteration, immediately before deciding whether to display the message.

johnproko

yeah my bad. Copied the code and deleted some others.
Still the code doesnt change the result. A high pulse from the arduino is not triggering the if statement.

JonM

I had done something similar where I had a QuickStart board running the ping sensor and ping servo and an Intel Galileo control the motors so when the QS detected a close object, it set a separate pin high for Left, right, Back and such which the Galileo detected and directed the motor direction. What I had found is that I had to put a pull down (maybe up) resistors in between the pin from the QS and the Arduino header pin on the Galileo. Otherwise the pins would float causing all sorts of strangeness.