Embedded communication is the process of sending information between two MCUs or from one circuit to other. For a communication to happen there needs to be a transmitter and a receiver. Communication may be in one direction or in both directions, there are different classifications according to this, but the basic classification is Synchronous and Asynchronous communication.
Synchronous: means sender and receiver use the same clock signal. Asynchronous: means sender provides a synchronization signal to the receiver before starting the transfer of each message.
Assignment:
Individual
- Design and build a wired &/or wireless network connecting at least two processors
Group
-Send a message between two projects
Software :
-Eagle
-Thunkable
-Arduino IDE
Materials :
-FR1 Board
-Electronic Components
-Bluetooth
Accomplised
-Understood the communication protocol between devices
-Explored wired and wireless communication
-understood Charlieplexing
-Created an app to use with Bluetooth
-Combined application interface and networking together.
Communication protocols are formal descriptions of digital message formats and rules. They are required to exchange messages in or between computing systems and are required in telecommunications.
Communications protocols cover authentication, error detection and correction, and signaling. They can also describe the syntax, semantics, and synchronization of analog and digital communications. Communications protocols are implemented in hardware and software. There are thousands of communications protocols that are used everywhere in analog and digital communications. Computer networks cannot exist without them.
There are two types of communication protocols which are classified below:
1. Inter System Protocol
2.Intra System Protocol
1.Inter System Protocol: The inter system protocol using to communicate the two different devices. Like communication between computer to microcontroller kit. The communication is done through a inter bus system.
Different categories of Inter system protocol:
UART Protocol
UART stands for universal asynchronous transmitter and receiver .UART Protocols is a serial communication with two wired protocol .The data cable signal lines are labeled as Rx and Tx. Serial communication is commonly used for transmitting and receiving the signal. It is transfer and receives the data serially bit by bit without class pulses. Ex: Emails, SMS, Walkie-talkie.
USART Protocol
USART stands for universal synchronous and asynchronous transmitter and receiver. It is a serial communication of two wire protocol. The data cable signal lines are labeled as Rx and TX. This protocol is used to transmitting and receiving the data byte by byte along with the clock pulses. It is a full-duplex protocol means transmitting and receiving data simultaneously to different board rates. Different devices communicate with microcontroller to this protocol.
Ex:-Telecommunications.
USB Protocol
USB stands for universal serial bus. Again it is a serial communication of two wire protocol. The data cable signal lines are labeled D+ and D-.This protocol is used to communicate with the system peripherals.USB protocol is used to send and receive the data serially to the host and peripheral devices.USB communication requires a driver software which is based on the functionality of the system.USB device can transfer data on the bus without any request on the host computer.
Ex: Mouse, Keyboard, Hubs, switches, pen drive.
2.Intra System Protocol: The Intra system protocol is used to communicate the two devices within the circuit board. While using this intra system protocols, with out going to intra system protocols we will expand the peripherals of the microcontroller. The circuit complexity and power consumption will be increases by using intra system protocol. Using intra system protocols circuit complexity and power consumption, cost is decrease and it is very secure to accessing the data.
Different categories of Inter system protocol
I2C Protocol
I2C stands for inter integrated circuit. I2C requires only two wires connecting all peripherals to microcontroller.I2C requires two wires SDA (serial data line) and SCL (serial clock line) to carry information between devices. It is a master to slave communication protocol. Each slave has a unique address. Master device sends the address of the target slave device and read/write flag. The address is match any slave device that device is ON, remaining slave devices are disable mode. Once the address is match communication proceed between master and that slave device and transmitting and receiving the data.
SPI Protocol
SPI stands for serial peripheral interface. It is one of the serial communication protocol developed by Motorola. Some times SPI protocol is also called a 4-wire protocol. It requires four wires MOSI, MISO, SS, and SCLK.SPI protocol used to communicate the master and slave devices. The master first configures the clock using a frequency. The master then selects the particular slave device for communication by pulling the chip select button. That particular device is selected and starts the communication between master and that particular slave. The master select only one slave at a time. It is full duplex communication protocol. Not limited to 8 bit words in the case of bit transferring.
SPI with single and Multiple Slaves
CAN Protocol
CAN stands for controller area network .It is a serial communication protocol. It require two wires CAN High (H+) and CAN low (H-). It was developed by the Robert bosh company in 1985 for in vehicle networks. It is based on a message oriented transmission protocol.
There are several different ways to make an android app these days. As days progress, makers have `come up with simpler solutions to create apps. As I am new to programming and have almost had zero knowledge I had to use a method that involved less coding, and the only viable option for that, which I knew of was MIT app inventor. But then I googled in the attempt to find out any other software that offers the same. That's when I came across Thunkable. Thunkable runs on MIT app inventor. It is the same as MIT app inventor because the makers of thunkable belonged to the team that made MIT app, they broke off to make their own platform.
The software works exactly the same as MIT app but the there certain (minor) differences between the two, like the user interface, some features etc making the Thunkable app slightly better. I went on to use Thunkable for my purpose and the tutorials for thunkable is also great.
The tutorials are split as beginners, intermediate and advanced depending on the user's knowledge and capabilities. I started with the beginner tutorials to get the hang of the software and its UI. It was pretty simple to understand and proceed on.
Thunkable
1. Choosing platform for the app
2. A Gmail account is a must to use this app
3. The next step is to create the app itself
Once the app opens up this is the screen that you are greeted with.
Thunkable
Thunkable - UI
To explain the user interface of the app,(Refer image above)
1.The palette:
This is where all the blocks are. The blocks are categorized into their functions like user interface, connectivity, sensors. Etc. To use them one has to simply drag and drop onto the screen.
2.Screen.
This is an imitation of the phone screen itself. All user interface blocks that are placed here is what will make the app. The look of the app has to be arranged here.
3.Components
All the blocks that are used in the making of the app are displayed here in the component section. If they are nested, that also is displayed here.
4.Properties.
The properties of each block can be controlled from here. The controls include color, size, orientation, images etc.
5.Menu bar
Here the app menu provides an option with, saving the app, creating a new app etc while the test menu provides real-time testing options. The export option is to export the app as apk or provide a QR code that helps to download the app. The help sections are linked to the docs.
6.UI and Programming
This bar helps to shift between designing the app and working of the app. The blocks shifts to a new window where the functioning of the app is configured.
Thunkable VS MIT
This is the comparison between the UI of MIT app inventor and thubkable. I found thunkable to be cleaner.
So now to actually make the app.
First I wanted to change the color of the main screen. This I did with the option available In the properties tab
Screen
Now to arrange icons on the screen, the app does not have a grid system. Instead of the palette menu, there is a layout which has to be configured and anything within the layout can be arranged. So made a horizontal layout and placed a list finder inside for connecting Bluetooth.
Layout
To I replaced the list finder with a custom image that I had downloaded from
Then I made another horizontal layout, to notify if the Bluetooth is connected or not. Put a label block in it. Layout again and put an image there. Just as an icon for led array which I had designed. Now to place the buttons for the array. I placed the button and replaced with a custom image. I then spaced them out with intermediate spacers. Once the first row seemed okay repeated for the same for 5 rows
There are other elements like non-visible elements. The sensors, connectivity comes in that category. They are a part of the app but do not have a block or icon. Now since my app had Bluetooth, I have Bluetooth and clock as non-visible elements.
Non-Visible Components
The spacing and the heights and widths may not always be correct. It's by trial and error that I came to this layout and also it depends on what one wants, or how he/she intends to design it.
Now that my user interface is done I shifted to the blocks area to do the actual "programming " of the app.
This is the block screen
Block Editor
Block Editor
To explain about the block window
1.The built-in gives more option for content and conditions. The screen is where all the components are displayed. The blocks are again basically dragged and drop.
2.The screen is where the blocks are placed and components are built
3.If there are any overlaps or warning during the building of the components, is displayed here
4.This provides an option to shift to screens, if there more than one, or to add and delete screen
Block Editor
Placing block
First I started with making the Bluetooth connection. I Couldn't understand the Bluetooth connection myself. So I had a few references to educate myself.
So to explain what I've done. I've chosen the list picker and set two controls to it. What it must do before a client is picked and what it must after a client is picked. So the first part is when the list picker is clicked it will show all the Bluetooth connections available, their name and address.
Then once the client is selected, the label will display "CONNECTED" in green color if the connection failed it will display "NOT CONNECTED" in red. Now, this establishes a connection with the Bluetooth device. Now we'll have to configure how the received data should be handled.
Clock Configuration
Here we bring in the clock parameter.By default, the clock is set at 1000ms. Which means it will keep checking for data for that interval of time. So when the Bluetooth is connected, we check for the value in the loop. If the value is greater than 0, then we check what data is available to be received and input case, we should check if the led is on or not. If the value is greater than 0 then the label will display led is on and if not led is off
Button Configuration
Now to program the buttons. Now I wanted to the button to send a character or a number when they are pressed. So when the Arduino program reads the character received it will light up that particular led. So made it in such a way that when the led is pressed a number is sent out. I assigned different numbers for each led.
Button Configuration
This is how I made the app for controlling LED array.
Charlieplexing
I tried to do Charlieplexing in my output week but failed. I was determined to correct it this time and find out where I went wrong. So I started reading about Charlieplexing and found these two profiles on fabacademy who had done excellent documentation on Charlieplexing.
This helped me understand Charlieplexing better and realize where I went wrong. There is a formula to calculate the number of pins and the no of LED's they can control. I missed out on this in my previous week. I used 3 pins to control 9 led's where in actuality its possible to control only 6 led's with 3 pins
Each LED is controlled in a different way by powering up each pin separately.
By understanding this we can come with a set of combinations to light up individual lights separately and once that's understood its easy to form characters.
Now each grid has two values. Sending high and low to appropriate pins will light up that square. So in case to for a letter A, boxes such as CA,DA,AB,EB,AC,BC,DC,EC,AD,ED,AE and DE must be lit up. So having understood Charlieplexing, I went on to design the board using eagle. To find out how to design using eagle please click here
Scheme
Board
Used attiny 44 as a microcontroller with 2 power supply options. Once the design was done, exported the image and took it to Krita to makes final png for milling. To know how to use Krita please click here.
These are the final png files
Trace & Cut
The size was about 5cm x 5cm. I milled the board and it took about 30 mins.
Milled Board
The drill bit was worn out a little. So the edges and the surface of the board were not very smooth. Even after trying to mill the board again resulted in the edges were rough. Nonetheless, the board was workable. I soldered the board and it did take time and patience to solder the board with so many LED's and resistors.
Soldered Board
Now its time to program and check the board.
Programming
The rest of the assignment is solely depended on programming. First I needed to check if the LED array is working. I used my FabISP to program and YAY I was able to upload the bootloader. Then I uploaded the following program and it was a delight to watch.
It was great to see how the LED’s were glowing especially after my failure with the first attempt.
Now that the Charlieplexing is working I needed to check if I'm able to use my app to control the board before I jump to master and slave communication. I had to check several references to do this. There were several factors involved in the Bluetooth, app, programming etc.
// start by ensuring all pins are at input and low
pinMode(LED_A, INPUT);
pinMode(LED_B, INPUT);
pinMode(LED_C, INPUT);
pinMode(LED_D, INPUT);
pinMode(LED_E, INPUT);
digitalWrite(LED_A, LOW);
digitalWrite(LED_B, LOW);
digitalWrite(LED_C, LOW);
digitalWrite(LED_D, LOW);
digitalWrite(LED_E, LOW);
}
To break down the code. I first defined what my Rx and Tx pins are going to be to talk to my Bluetooth device. Then setting the led ports. The band at which the Bluetooth has to communicate. Then in the loop, the character that's is received from the Bluetooth is read. So if the character is "1" then BA is high. (Refer matrix chart). Hence I did the same for rest of the characters as well. Once the code was uploaded I connected my Bluetooth with my led array and fired up the app on my phone.
Pinout
Connection
I connected my phone to the Bluetooth and I didn't have any problem.
Screenshot of App
And then I pressed each button and YAY again, the led was glowing. I tried with each led and it was successful. !!!
And then I pressed each button and YAY again, the led was glowing. I tried with each led and it was successful. !!!
Networking
Now to do network communication I decided to use my TRI board that I made during week 7. The idea is to communicate with using Bluetooth to the TRI board and led array board, which will be controlled using the app that I had made. Now that I already have all the boards, it's just about programming them and connecting them together.
The LED array is already programmed, I didn't change much In the program, but I wanted to program the TRI board to light up different colors when even numbers are present. So the LED would light up when 2, 4 and 6 are pressed. This is the code for that
Code
#include <SoftwareSerial.h>
#define RxD 2
#define TxD 3
#define DEBUG_ENABLED 1
#define LED_A 0
#define LED_B 1
#define LED_C 4
SoftwareSerial blueToothSerial(RxD,TxD);
void setup() {
pinMode(RxD, INPUT);
pinMode(TxD, OUTPUT);
blueToothSerial.begin(9600);
pinMode(LED_A,OUTPUT);
pinMode(LED_B,OUTPUT);
pinMode(LED_C,OUTPUT);
}
void loop()
{
int recvChar;
//check if there's any data sent from the remote bluetooth shield
if(blueToothSerial.available()>0)
{
recvChar = blueToothSerial.read();
if(recvChar == 1)
{
digitalWrite(LED_A,LOW);
}
else if(recvChar == 3)
{
digitalWrite(LED_B,LOW);
}
else if(recvChar == 5)
{
digitalWrite(LED_C,LOW);
}
else
{
digitalWrite(LED_A,HIGH);
digitalWrite(LED_B,HIGH);
digitalWrite(LED_C,HIGH);
}
}
}
Once the code was uploaded I connected the device. So the overall idea is to communicate with the different board by wired and wireless modes. Here the Bluetooth is like the master which provides a command for the TRI board and LED array board.
Pinout
I then connected all the boards together and tested it out.
Connection
And yes the program and the boards worked in perfect synchrony with each other.
Update:
Now that I was able to talk to two boards, I decided to add another board to the set. But this time I had a problem with Programming. Took me a while to figure out the problem. I made my MISO and MOSI pins as RX and TX by doing so I had to sacrifice the RGB LED's function. I was able to power up only one color led and not all of them. Anyhow, I was able to communicate with all the three boards. Here I the schematic connection of all the boards and the video for the same.
Pinout
Networking Update:
Networking between boards has not been completely achieved using the wireless methods that I have tried above. Hence I'm trying out a new program and method with reference from the following student's assignment.
The major difference between the what I had done and this method is addressing. I have simply assigned Rx / Tx to different boards and that doesn't actually network. In this method of networking, I assign an address to each board and ask them to do a specific task when they are called upon.
As I had mentioned I took reference from Jari to complete my assignment and he had used a hub board to connect all the wires. This was very interesting because the previous times I tried I had a lot of frustration with the wires and connectors, Milling this board would mean the task and the wiring would get simple. So I went ahead to design and mill the board for myself.
Designing Hub
And once the design was done I milled and soldered the board.
Mill and Solder
Programming
As I had done earlier I used the boards of my previous weeks to complete the assignment. I used one master and 2 slaves and controlled the slaves using the LDR on the master board.
The master board has an Attiny 45 and slave 1 has Attiny 45 and slave 2 had Attiny 44. The idea is when the LDR is at a certain range it sends out a character and if the not it sends another character. This is addressed to each slave board depending on the condition.
Master Code:
The first part of the code is declaring the pins. Then when LDR is great than the given value then it sends out the character "d" which would be the address of Slave 1 and if it below the range then it would send character "r" which is the address of Slave 2.
Code
#define ldr 3
#include<SoftwareSerial.h>
SoftwareSerial ms(1,2); // rx , tx
void setup()
{
pinMode(2,OUTPUT);
pinMode(1,INPUT);
pinMode(0,OUTPUT);
ms.begin(9600);
pinMode(ldr,INPUT);
}
void loop()
{
int x =digitalRead(B);
x=map(x,0,1023,0,100);
if( x <= 40)
{
digitalWrite(0,HIGH);
//digitalWrite(1,LOW);
ms.write('r');
}
else if( x > 40)
{
// digitalWrite(1,HIGH);
digitalWrite(0,LOW);
ms.write('d');
}
}
Slave 1 & 2:
The slave codes are pretty much the same except for the address and the input pins. First, we set the Rx and Tx pins and then the address of the slave is set. Inside the loop, we read for the incoming byte. Of the bite is the same as the address of the salve then the led glows else it remains low. The RGB LED is of common anode type hence it's always high, giving it a low signal is what will turn it on. The code has Print.ln which will display the data on the serial monitor.
Code
#include <SoftwareSerial.h>
SoftwareSerial mySerial(2, 1); // RX, TX
const char node = 'd'; // network address
const int ledPin1 = 4; // the number of the LED pin
int incomingByte;
void setup() {
mySerial.begin(9600);
pinMode(ledPin1, OUTPUT);
pinMode(2, INPUT);
}
void loop() {
if (mySerial.available() > 0)
{
incomingByte = mySerial.read();
if (incomingByte == node)
{
digitalWrite(ledPin1, LOW);
pinMode(1, OUTPUT); // open line to write
mySerial.println(node);
pinMode(1, INPUT);
}
else{
digitalWrite(ledPin1, HIGH);
}
}
}
This is the pinout for the boards
Pinout
The following picture explains the different states of the board.
Slave 1 & Slave 2
Video For Networking
Conclusion
My assignment for this week was slightly different from what was expected. I combined last week assignment with this week. I made an app, designed an led array and used Bluetooth for wireless communication and also wired communication to talk my slave board. It was a culmination of output week, Programming and interface week and networking and communication week. It was hard to put everything together, but it was quite rewarding in the end. It was really great to see how things come together and interact with each other. I believe this is the beginning of making greater things, as they don't involve just one process but a synchronous performance of multiple processes.
The assignment was to send a message between two projects. The boards that were used in the assignment was a modification of my original board that I had designed in output week. We decided to use an IR sensor and when an object is within a certain range one LED blinks and when the object gets closer both the LED glow. My contribution to the group work included, helping in programming the boards and making the circuit diagram for documentation.
WEEK 14
Networking and Communications. This week is about how to make two boards talk to each other. The lecture started with communication protocols and then Neil spoke about Open systems interconnections. Then he went on to speak about the different modes in which communication can happen, wired, wireless their bandwidths, capacities etc. Explaining each with examples and board files.