Stack Exchange Network

Stack Exchange network consists of 175 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Visit Stack Exchange
15

Asynchronous serial (usually referred to as serial) communications is used to send bytes from one device to another. A device could be one or more of the following: Arduino PC GPS RFID card reader LCD display Modem Other Clock rate and sampling of data Unlike SPI / USB / I2C serial communications does not have a clock signal. The sampling clock is an ...


10

int Var = 55; //Do it in 2 lines e.g. Serial.print("L "); // String Serial.println(Var); // Print Variable on same line then send a line feed


8

Call serial.end() to stop receiving. Then call serial.begin(...) again when you want to start listening again.


8

Does anyone know if what I am trying to do is possible? Absolutely possible :) And if it is, what am I doing wrong? SoftwareSerial isn't capable of 115200 baud rate (despite "allowing" this as a setting). Some reports suggest as high as 57600 is workable, though in my experience 9600 is best for reliability. How to change the baud rate on the ESP8266 ...


7

You forgot the quotation marks, try #include "SoftwareSerial.h"


7

Yes. The serial port uses a ring buffer (also known as a circular buffer) for storing the incoming data until you want it. That buffer is 16 bytes in size on the smaller Arduinos and 64 bytes in size on the larger one. A similar ring buffer is used to store transmitted data until the port is ready to transmit it in the background.


7

Well you may try this: Start by uploading blink sketch to your Arduino then connect it to your ESP8266 like this: TX-TX and RX-RX. Now open Serial Monitor and send AT command and see if it responds. If so then you can control it using your Arduino by wiring it back to TX-RX and RX-TX. PS: Don't forget to set the line ending in the Serial Monitor to ...


7

The Serial object is the end of a chain of classes, each with a different set of functionality. Print -> Stream -> HardwareSerial => [Serial] Since you are reading from it the best class to use is Stream since that is the one that is the one that contains the reading functionality. You should pass it by reference or as a pointer since you don't ...


6

Short answer - no. It's not left out, on the contrary. But before addressing to the compiler error you mentioned, a small clarification: I downloaded the hardware from https://code.google.com/p/arduino-tiny/ The link you provided is not hardware, but software called the ATtiny core files. It contains the necessary files that will help you compile and ...


6

Personally I wouldn't go down this route. Instead I would pass a Stream object (as a pointer or a reference) to the constructor and use that. Then it is up to your sketch to define what that Stream object is and initialize it. That way if you want to use the same class on a hardware UART instead of a SoftwareSerial you just change the sketch, not the ...


5

It's not obvious what the exact query is but answering the subject line question: You can easily multidrop connect multiple serial / RS232 COM ports by having all slave RX inputs and the master TX output on one line, and all slave TX outputs connected by an OR network to a single line to the master's RX input. The master 'talks' to all slaves at once. ...


5

The trick here is to go "up a level". Both HardwareSerial and SoftwareSerial inherit from the Stream class. It is that class that provides the majority of the interface that you actually use. So you can provide a constructor with a Stream object alone and use that: class Foo { private: Stream *_dev; public: foo(Stream *dev) : ...


5

I think your problem is that you need 4 serial ports. With software serial that's just not going to happen: SoftwareSerial can only receive on one serial port at any given time. AltSoftSerial is limited to specific pins, and only one instance because there is only one set of pins NeoSWSerial is kind of between the two. More efficient than SoftwareSerial, ...


4

Take a look in the datasheet under the "20. USART0" section: http://www.atmel.com/images/Atmel-8271-8-bit-AVR-Microcontroller-ATmega48A-48PA-88A-88PA-168A-168PA-328-328P_datasheet_Complete.pdf I will list the names of the registers, what they are called, and then what your code is doing specifically: UBRR0H and UBRR0L together form the baud rate divider. ...


4

Well as usual it was something stupid (-__-) I changed the byte array for long and it worked perfectly. Here is the complete code working(): #include <IRremote.h> // IR Library - Encode/Decode void irSerial( char SerChar[] ) { // Receive array of characters char IDChar[]={'s', 'i', 'u'}; // List of Serial Char to identify position String ...


4

As pointed out by Edgar you should debounce the button. Perhaps increasing the delay() should do the trick. Try with 100-200 milliseconds. With this edit you can delete Once unless you are planning on using it somewhere else.


4

Just send your data to a tee: this is a type of pipe fitting where you push the data through one end and it goes out through the other two ends. As it happens, both Serial and Softserial (and almost anything that can print()) inherit from the virtual Print class. You can implement a tee as a Print that outputs to two Prints: class Tee : public Print { ...


4

do { r = XBee.read(); Serial.print(r); } while (r != -1); Think about it. Since you tested for XBee.available() you will have at least one iteration of this loop. And then you do a second read, and print it, before finding that the second character is -1. You need to re-order your loop, or your tests. The second character will be what ...


4

If you're going to talk to your ESP at 9600 baud - and that's about the upper limit for SoftwareSerial - you need to first change the ESP board's baud rate to 9600 baud. It is probably at 115200 right now. You can do that with either kind of serial. Even though SoftwareSerial can't receive at 115200, it can usually transmit (Uno -> ESP) that fast. You need ...


4

Since you are using all 8 bits of the serial data for your data there is nothing "in band" that you can use for a delimiter. Instead you will have to think outside the box somewhat and create some form of "out of band" data that can signal the end of a packte. One option (probably the simplest) would be to include the concept of time into your protocol. ...


4

The buffer is in the UNO's limited (2K) RAM; you'd be using 1/4 of it for the input buffer. If your app is small enough and simple enough (limited call depth, specifcally), there may still be enough RAM for your app to run successfully. If you have lots of globals (remember to include libraries when you're considering RAM use), allocate much memory from the ...


4

I learned that I needed to include Arduino.h header file apart from that I learned .ino files and .cpp files is that the .ino files transparently include particle.h for you. The other difference is that .ino files generate forward declarations for you. This is necessary when you’ve implemented a function later in the file than when you’ve first used it. ...


4

A little explanation about HEX and ASCII: About HEX Raw computer data consists of zeros and ones. For humans it is difficult to read a (long) row of zeros and ones. You can represent such a row (of a certain length) by a decimal number, but then the relation with the underlying bits is not directly clear. For this reason the hexadecimal (HEX) representation ...


3

Below you can find the code for a minimal bit-bang send serial implementation ideally suited for debugging. Code size is about 60 bytes. It gives 38400 baud for 1 MHz or 230400 baud on 8 MHz Attiny clock. I wrote it for an Attiny 85. ArminJo/AttinySendSerial_1Mhz_38400Bd


3

Most small micro controllers, AVR's included, have dedicated hardware for communicating with different serial devices. In arduino these are referenced with "Serial", "Serial1", "Serial2" and so on, depending on how many hardware serial ports your particular arduino has. Leonardo's are an exception, the first hardware port is "Serial1" and "Serial" refers ...


3

Add to @geometrikal. or #include <SoftwareSerial.h>


3

According to your comment: after commenting out those ifdef guards, it worked I would say that is a bug in the Adafruit_GPS library. As a matter of fact, the DUE is not using the AVR architecture (it uses ARM), that explains why #ifdef __AVR__ in Adafruit_GPS.h never passes; but then something else should be done specifically for the DUE (missing #else ...


3

I suggest you first find what your Yamaha is sending you. I have a sketch that decodes MIDI for the Uno (assuming you have a Uno lying around). Run that, and see if you got note on with velocity zero, or note off. Then you are a little closer to solving the problem. This part is quite wrong: do{ commandByte = mySerial.read();//read first byte ...


3

SoftwareSerial cannot talk to itself. Since it is implemented in software and not hardware it can either send or receive at one time, but not both. Look at the code for write in SoftwareSerial: size_t SoftwareSerial::write(uint8_t b) { ... cli(); // turn off interrupts for a clean txmit ... // Write each of the 8 bits for (uint8_t i = 8; i > ...


3

Yes, you can. That's the purpose of the SoftwareSerial - to allow you to complement the hardware TX/RX with other pins defined by software. One thing to note with SoftwareSerial - it's half duplex. It can either send or receive, it can't receive while it's sending.


Only top voted, non community-wiki answers of a minimum length are eligible