Serial via max232a 4800Baud 7E2

Can Arduino handle this serial protocol? if so? examples please

retexas: Can Arduino handle this serial protocol? if so? examples please

Yes http://arduino.cc/en/Serial/Begin

That appears to only be a mega solution. So to be clear I cant use 4800 7E2 and a max232a part with a nano, because the second argument is not recogonized or supported?

You just misread the page. Serial.begin(4800, SERIAL_7E2); will work on the UNO and Nano.

Sorry for the long pauses but the forum and my browser (IE) don’t like each other and constantly hangs.
Anyway I lifted this code then added your suggested change and it will not complile. Your thoughts?

#include <SoftwareSerial.h>

SoftwareSerial mySerial(10, 11); // RX, TX

void setup()
{
// Open serial communications and wait for port to open:
Serial.begin(4800,SERIAL_7E2);
Serial.println(“Goodnight moon!”);

// set the data rate for the SoftwareSerial port
mySerial.begin(4800,SERIAL_7E2);
mySerial.println(“Hello, world?”);
}

void loop() // run over and over
{
if (mySerial.available())
Serial.write(mySerial.read());
if (Serial.available())
mySerial.write(Serial.read());
}

Compiler report:

sketch_mar13b.ino: In function ‘void setup()’:
sketch_mar13b.ino:12:34: error: no matching function for call to ‘SoftwareSerial::begin(int, int)’
sketch_mar13b.ino:12:34: note: candidate is:
In file included from sketch_mar13b.ino:1:0:
C:\Program Files (x86)\Arduino\hardware\arduino\avr\libraries\SoftwareSerial/SoftwareSerial.h:92:8: note: void SoftwareSerial::begin(long int)
void begin(long speed);
^
C:\Program Files (x86)\Arduino\hardware\arduino\avr\libraries\SoftwareSerial/SoftwareSerial.h:92:8: note: candidate expects 1 argument, 2 provided
Error compiling.

So the question you asked is not the question you wanted answering. Big supprise you did not get the right answer is it?

I thought it was pretty clear question really, "Can Arduino handle this serial protocol? if so? examples please" "This" being 4800 7E2. You both offered suggestions of "Serial.begin(4800,SERIAL_7E2);", I appreciate the help and had actually tried this before I hit the boards in search of expertise. The Compiler barks "note: candidate expects 1 argument, 2 provided, Error compiling."

So to help Clarify, I have a NANO, using pins 7,6 (or whatever you recommend) wired to a max232a using .1uF caps. Using realterm on a win 7 machine as my com tool, the communication works (passes text) until I try and add the second argument, or get specific on the Baud rate. Reseaching on the web I stumbled across something called UCSROC and was moderately successful using the "UCSROC=UCSROC B00101100; but the Arduino, Serial monitor readback had a few char. that corrupted.

The goal, is to interface this Nano to a high end scientific device. Ultimate goal is to tickle the device and store the readback to an sd card, but baby steps first. The handshake.

Now, armed and enhanced with this knowledge, would you consider providing "Examples" (and a little less sarcasm/scolding), of how you would approach this, so we can establish a baseline approach and move forward.

Serial takes the 2 parameters, SoftwareSerial takes one?

http://arduino.cc/en/Reference/SoftwareSerialBegin

jimmy

of how you would approach this, so we can establish a baseline approach and move forward

I’d take the source that I have for SoftwareSerial, amend it to seven bit, even parity and two stop bits and go from there.

I thought it was pretty clear question really,

It was a very clear question; simply incomplete and hence misleading, given the actual context.

In regards to SoftwareSerial, Any suggestions on how to amend the library? I'm looking at it and I'm not seeing anything clearly defined as word length , parity or stopbits called out? I'm looking for some guidance here, Am I in the wrong place on the forum? This is my first project, maybe a little more handholding is necessary and would be appreciated..

Thanks mixographer , By serial, your suggesting the built in lib. under communications like "SerialEvent", is that a safe assumption?

I'm looking at it and I'm not seeing anything clearly defined as word length , parity or stopbits called out?

Well, take it one direction at a time - I suggest the tx side. Key here is the method SoftwareSerial::write. There is no parity calculation, so start with that - the transmit loop isolates the individual bits, so that should be simple. It's fairly clear that it sends 8 bits, so I'd add a private variable (set by "begin") to change the number of data bits - use that instead of the mask-based loop control. It's assumed that there's a single stop bit - your new private variable could hold information about that too. Delaying for two bit periods at the end (indeed, for any number of stop bits), instead of just one is trivial.

Now that my friend is good advice and much appreciated... Not sure I fully understand it all, at this point, but jumping in.

Thank you

Thanks, but thats not working, I guess, I will need to search elsewhere for someone with code examples

but thats not working

What is the "that" that is not working?

"That approach," I need code samples to work with, Otherwise I'm just hunting and pecking.

Hi,

What I was trying to say was that there are two different ways to do serial comms and you seem to be confusing them. There is 'Serial' and 'SoftwareSerial.' They're different. SoftwareSerial take 1 parameter which is the speed. Serial can take an additional parameter to set the format and parity, like 7 bits/even/2.

jimmy

mixographer: Hi,

What I was trying to say was that there are two different ways to do serial comms and you seem to be confusing them. There is 'Serial' and 'SoftwareSerial.' They're different. SoftwareSerial take 1 parameter which is the speed. Serial can take an additional parameter to set the format and parity, like 7 bits/even/2.

jimmy

But there's absolutely no reason you can't improve SoftwareSerial to be compatible with HardwareSerial. You have the source.

Otherwise I'm just hunting and pecking

You'll do that a lot whatever you're learning - I don't see a problem with that.

I agree, I was just clarifying what I had said.