Firmware for uC | Communication Interface

In the last post, we had little introduction of how the firmware is going to act. With that picture in mind, now we will go a little deeper.

Android <==> BtBee <==> USART <==> uC

USART Communication

    Atmega16 contains one USART device. In this section we'll learn how to use it for receiving information. For using any of the peripherals in the uC, we need to do 

           + Switch ON the peripheral.

           + Configure the peripheral.

           + Use it.

Switching ON the USART

    Switching ON the USART involves, setting the TXEN and RXEN bits.

UCSRB |= _(RXEN) | _(TXEN);    /*enable the device */

Configuring the USART

   Configuring involves setting the Baud-rate of the USART device. In Atmega16, it can be done by writing the calculated Prescaler value into USART Baud Rate Register(UBRR). UBRR is a 16 bit register. UBRRH and UBRRL represents the higher and lower bytes of the UBRR.

UCSRC |= _(USBS);               /* use 2 STOP bits */
UCSRC |= _(UCSZ0) | _(UCSZ1)    /* use 8 DATA bit mode */

int baud_prescale = F_CPU/(16*baud) - 1;
UBRRL = baud_prescale & 0x00FF;
UBRRH = RSHIFT(baud_prescale, 8) & 0x00FF; 

Using USART

   USART device provides a data register named USART Data Register(UDR), which act as a buffer. There are two separate register for transmission and reception. UDR refers to one when used for transmission and another for reception.

unsigned char received_data = UDR ;
UDR = data;

Interrupt 

   We have seen the snippets for transmission and reception of data through USART. Using Interrupt mechanism in conjunction with USART provides a way for efficient use of the micro-controller time. For you to realize how useful the interrupt mechanism, here is an example. Here our purpose is to receive a byte of information through USART.

   You can just copy the contents of the UDR register at any time you want. If you do so, mostly the copied content will not the correct information, but some garbage value. We have wait for the USART device to complete reception and then copy the data. It is done as follows.

unsigned char USART_receive()
{
   while(UCSRA&(1<<RXC) );
   return UDR;
}

    USART indicates the reception of data by setting the RXC bit of UCSRA register to 1. We have to continuously monitor the RXC bit, and when it becomes 1, we return the data, i.e contents of UDR.

    By enabling the Interrupt mechanism, we can make the USART to interrupt the processor when, RXC becomes one i.e. when the reception is complete. This means that, the micro-controller can do some useful job without wasting its time in monitoring a single bit.And when the processor is interrupted, it will halt the operation, whatever it does and serves the Interrupt, and after serving the interrupt it can continues is operation where is was left.

    And of course, we have code the Interrupt Service Routine, a special function which is called when the interrupt occurs. There can be several interrupts, with several priorities. In avr-gcc, the interrupt service routines are coded as follows.

ISR(USART_RXC_vect)
{
   UCSRA &= ~(1<<RXC);  /* clears the RXC bit */
   return UDR;
}

    where the ISR and USART_RXC_vect is a predefined macros by avr-gcc. Here is the list of predefined interrupt vector names specific to a controller.
   List of Interrupt Vectors

Read more ►

Firmware for uC | Introduction

   This post marks the beginning of a new article series discussing the development of the firmware, we coded for the atmega16 micro-controller(we call it the, ORGAN) used in the project.

   The firmware will not do anything unless the android(we call it the, BRAIN) asks it to do so. After lot of thinking, and experiments interrupt driven method is chosen  for implementation. When it receives a command usually one the predefined set of values defined through these directives.

file: athena.h

/************************************************************
 * Actual operations                                        *
 * they are used as indices for                             *
 * <category>_<operation>_<direction> function pointer array  *
 ************************************************************/

/*  LOCOMOTION OPERATIONS */
#define LOCO_FORWARD      LOCO_CONT_BEGIN +  01
#define LOCO_BACKWARD     LOCO_CONT_BEGIN +  02
#define LOCO_TURN_RIGHT   LOCO_CONT_BEGIN +  03
#define LOCO_TURN_LEFT    LOCO_CONT_BEGIN +  04
#define LOCO_TURN_AROUND  LOCO_CONT_BEGIN +  05
/*  CAMERA HANDLING */
#define CAM_LOOK_UP       CAM_CONT_BEGIN + 01
#define CAM_LOOK_DOWN     CAM_CONT_BEGIN + 02
#define CAM_LOOK_RIGHT    CAM_CONT_BEGIN + 03
#define CAM_LOOK_LEFT     CAM_CONT_BEGIN + 04
/* ARM CONTROL */
#define ARM_CONTRACT      ARM_CONT_BEGIN + 01
#define ARM_DILATE        ARM_CONT_BEGIN + 02
#define ARM_UP            ARM_CONT_BEGIN + 03
#define ARM_DOWN          ARM_CONT_BEGIN + 04

where the values of <category>_CONT_BEGIN are,

#define LOCO_CONT_BEGIN 00                               /* 00 */
#define LOCO_CONT_LEN   10
#define LOCO_CONT_END   LOCO_CONT_BEGIN + LOCO_CONT_LEN  /* 10 */

#define CAM_CONT_BEGIN  LOCO_CONT_END                    /* 10 */
#define CAM_CONT_LEN    10
#define CAM_CONT_END    CAM_CONT_BEGIN + CAM_CONT_LEN    /* 20 */

#define ARM_CONT_BEGIN  CAM_CONT_END                     /* 20 */
#define ARM_CONT_LEN    10
#define ARM_CONT_END    ARM_CONT_BEGIN + ARM_CONT_LEN    /* 30 */

So when the brain send one of these commands to the organ, the organ do the job for a fixed time frame and stop. (do not worry about the communication interface b/w brain & organ. we will come to that in next post.) What is now important is, firmware does the job for a fixed time duration when it is asked to do.

Read more ►