Rx Tx When is the data read?

I'm starting a new project. I have an arduino mega 2560. I need some guidance regarding how the read n Transmit works. I don't need help with the coding right now.
I need some help understanding this.

I'm making a project in which the arduino reads from many sensors and displays on the lcd one buy one.

// Reads temp. sensors => displays on lcd
// Reads light sensors => displays on lcd
// Put the Rx Tx code here??

In the mean time I'm confused. If a bluetooth module is connected, and normal hex data is sent like "FF" or "A0" how is the data read in between rest of the code?
The data can be sent at any instant. What if the other part of the code is being executed while the data is being sent. Will it read?

xpleria:
The data can be sent at any instant. What if the other part of the code is being executed while the data is being sent. Will it read?

The data goes into a small buffer. You can use Serial.available() to find out how many characters are waiting in the buffer. When you do a Serial.read() you get the oldest character in the buffer (or -1 if the buffer is empty) and the character is removed from the buffer.

Thanks for the info was really useful. Please tell me if what I've interpreted is right.

I would like to know how the data is stacked in the buffer.
In case hex characters are sent one by one as follows
A5
9EB7
FD
and using the value obtained in serial.available() (3 in this case) , I create a for loop.
If I use serial.read() in the loop, then I'll get FD first, then 9EB7 and finally A5. Is this right?

Also what is the max amount of data that can be stored in the buffer..?

9EB7 is not a 'character' so I'm guessing the hex is being sent one ASCII character at a time.

Given the limited information provided, my guess for the order of received characters would be:

A5\n9EB7\nFD\n

If Serial.available() returns the value 3 the buffer probably contains:

A5\n

Unless you know exactly how the data is sent you can't really code for it. I would write a simple debugging loop that printed every byte out in HEX, that way you know what you're dealing with.


Rob

What I'm dealing here with is data sent from androidphone via Bluetooth. I have two options.

  1. Send ASCII characters
  2. Send hex value

I don't really have to do anything with ASCII characters.

What I need is the hex values. First 4 bits tell the task. Rest 4 bits are control bits.that appear on 4 pins. Explaining this gets too complex.

In simple words every time a byte is sent, say F6 I need to perform a task based on the first nibble.

Something like

//read data
//evaluate
if (firstnibble == F ) {
//perform task
a = bitRead(secondnibble, 0);
b = bitRead(secondnibble, 1);
c = bitRead(secondnibble, 2);
d = bitRead(secondnibble, 3);
digitalWrite(pin1, a);
digitalWrite(pin2, b);
digitalWrite(pin3, c);
digitalWrite(pin4, d);
}
//15 more ifs. I could use switch too.

this code needs go into a for/while till all the data is read and the evaluated.

What's the difference between the firstnibble F case and E? I'm wondering if you can make the whole thing data driven and avoid the big switch statement. Does it just impact which pins are impacted by the secondnibble data?

its actually complex to explain what I'm trying to accomplish here.

To make it simple I've just showed 8 bit data. I'll be actually dealing with 16 bit data.
The very first nibble tells me what to display on the lcd. Like 0000 = light, 0001 = fan etc. (I feel its better to send codes rather than the word for faster execution)

Second nibble goes to 4:16 decoder and the last 8 bits to output pins.

  1. Send hex value

That could mean anything although to me it means send two ASCII bytes representing the HEX value of a byte. IMO it does not mean send a binary value although it may do.

So you still need to verify the exact format of the data.

Assuming then that at some point you have a clean byte then you can perform a switch on the upper nibble, but I would try to organise the hardware so this

a = bitRead(secondnibble, 0);
b = bitRead(secondnibble, 1);
c = bitRead(secondnibble, 2);
d = bitRead(secondnibble, 3);
digitalWrite(pin1, a);
digitalWrite(pin2, b);
digitalWrite(pin3, c);
digitalWrite(pin4, d);

becomes

PORTx = myByte & 0x0F;

Rob

Thats a very good simplification Rob. Thank you.

Any idea how I can split these bytes. Say ABCD is sent.
Would serialRead() read both bytes together or byte by byte?

Well that depends on how ABCD is sent as I said. You could get 'A', 'B', 'C', 'D' or AB and CD as binary values, you could even get CD then AB depending on the whim of the transmitting device, and there may be new line chars etc. You have to know that before there's much point writing code. If documentation does not spell it out explicitly (and it almost never does) then write a short test program to print the values.

Regardless serialRead() only receives a single byte at a time.

There are various ways to split bytes and nibbles, for example

word = 0xABCD;

lbyte = word & 0xFF;
hbyte = word >> 8;

Will create two bytes from a 16-bit word.

There are also two macros that do this but I haven't used them and can't remember their names.

(I feel its better to send codes rather than the word for faster execution)

Second nibble goes to 4:16 decoder and the last 8 bits to output pins.

Yes codes are normally better. As I said if you have control over the hardware try to organise pins so the data maps directly to the physical pins.


Rob

Well said Rob. Really appreciate the help. Thanks everyone.

Summary:
To know how data is being read first I can write it to an lcd so I know how data is being received. Depending on that write the code.
Also PORTx = 0xFF is a much better implementation and faster than what I mentioned.