Some personal issues.

Standard

Well, hello again. So last time (I’m too lazy to link… so help yourself), we saw a bit about the internals of the Texas Instruments CC254x BLE firmware. Well, today I try to put down how I managed to compile the firmware using the IAR Workbench and RedBea Lab’s Biscuit firmware. It was pretty messy. There are problems that have to be resolved and while at it, I intend to resolve some personal issues.

Talking about problems, I have one too many. First, a cigarette. So what? I run everyday for ~2Kms. For a former chain smoker, who has just started to make something good of his pathetic life, 2Kms is a fucking achievement. And so is compiling the code for the BLE firmware. I started by obtaining the Biscuit firmware from here. If you have read my previous post (I’m really worried about you if you did), you might know that you have to install the IAR Workbench to compile and run the code. Assuming that you have installed the Workbench and the TI BLE library (I’m sorry, I couldn’t find the Git link I was talking about), I’ll try and describe the implementation of the Biscuit firmware. I’ll briefly (if time and consciousness permit) describe how to compile the code. So unzip the firmware and open up IAR Workbench.

The IAR Workbench. I'm using the 30 trial version (Lisenced!),

The IAR Workbench. I’m using the 30 day trial version (Licensed!),

So, click on open and select “workspace”. The workspace file is simply a synonym to a project description file (you have them in Android projects and many other IDEs).

So whatever, I’m listening to Sing by Blur… it reminds me of a very small room where I lived in utmost secrecy. Well, I’m not going into that but the gist of it is, attachments are an issue with me. I mean ok, you like someone, you talk to them, you have a good time and then when you’ve had enough, you should be like “hey that was a great run with you… I hope we meet again some day.”. But no, that does not happen. Maybe I’m too lame that I get attached or too promising to get someone attached to me or maybe both. Both I guess… thats pretty fucking stupid. I’m so freakin’ attached that without thinking I opened up to a random person from my past. That too completely… well that IS *he* stupid. And not stopping at that, some other random person is so fucking attached to me that it is getting hard to breathe… well that IS *he* also fucking stupid.

Coming back to the IAR Workbench. Open the workspace file from the Biscuit directory (after you unzipped the Biscuit source code). To do that, search for a file ending with “.eww”. Viola! you imported the whole project.

The source code!

The source code!

Now lets start hacking. The important files are, biscuit.c, Biscuit_Main.c and OSAL_Biscuit.c. The last one is the OS Abstraction Layer, the second is the entry point of the firmware and the first one is the actual firmware. The TI docs very clearly explains how it all glued together. The following code:

const pTaskEventHandlerFn tasksArr[] =
{
  LL_ProcessEvent,                                                  // task 0
  Hal_ProcessEvent,                                                 // task 1
  HCI_ProcessEvent,                                                 // task 2
#if defined ( OSAL_CBTIMER_NUM_TASKS )
  OSAL_CBTIMER_PROCESS_EVENT( osal_CbTimerProcessEvent ),           // task 3
#endif
  L2CAP_ProcessEvent,                                               // task 4
  GAP_ProcessEvent,                                                 // task 5
  GATT_ProcessEvent,                                                // task 6
  SM_ProcessEvent,                                                  // task 7
  GAPRole_ProcessEvent,                                             // task 8
  GAPBondMgr_ProcessEvent,                                          // task 9
  GATTServApp_ProcessEvent,                                         // task 10
  BiscuitPeripheral_ProcessEvent                                  // task 11
}

Here, we register every layer’s even processing function. It is taken from OSAL_Biscuit.c The purpose of this file is to initialize every layer of the protocol stack and finally boot the application. They have used a very ingenuous trick. By making the order of initialization as the order of defining the event processors, they can now give unique task IDs to each process of each layer. That’s like very cool. We don’t have to change anything in this as such. The second file Biscuit_Main.c:

int main(void)
{  
  /* Initialize hardware */
  HAL_BOARD_INIT();

  // Initialize board I/O
  InitBoard( OB_COLD );

  /* Initialze the HAL driver */
  HalDriverInit();

  /* Initialize NV system */
  osal_snv_init();

  /* Initialize LL */

  /* Initialize the operating system */
  osal_init_system();

  /* Enable interrupts */
  HAL_ENABLE_INTERRUPTS();

  // Final board initialization
  InitBoard( OB_READY );

  #if defined ( POWER_SAVING )
  osal_pwrmgr_device( PWRMGR_BATTERY );
  #endif   

  /* Start OSAL */
  osal_start_system(); // No Return from here

  #if defined FEATURE_UBL_MSD
  extern void appForceBoot(void);
  appForceBoot();
  #endif

  return 0;
}

calls the osal_start_system() function. The osal_start_system then calls the task initialization routine from OSAL_Biscuit.c. The system is now up and the application has started running (BiscuitPeripheral_Init() in OSAL_Biscuit.c).

The application initialization routine is quite straightforward. It is divided into blocks. The GAPRole_Set/GetParameter() function interacts with GAP API to set or request certain parameters of the GAP layer. TI distributes the GAP API’s documentation in an interactive HTML form so I cannot basically tell you all the parameters. The used parameters are aptly named, so even if you study theoretically about Bluetooth Low energy from basic beginners’ guide, you’ll know what those parameters are (well thats my perception cuz I did that).

The interesting part is the event processing routine. It is called BiscuitPeripheral_ProcessEvent(). It takes two parameters, task ID and the event that occurred.

Again, there is an ingenuous hack. The second parameter, events is a bit map.

if(events & SYS_EVENT_MSG) {
        // a system event has occured.
        uint8 *pMsg;
        if((pMsg =osal_msg_receive(biscuit_TaskID)) != NULL) { // allocate the message
            biscuitPeripheral_ProcessOSALMsg((osal_event_hdr_t *)pMsg); // defer to OSAL message processing function
            VOID osal_msg_deallocate(pMsg); // deallocate the message
        }
        return (events ^ SYS_EVENT_MSG); // unset the SYS_EVENT_MSG from the events bitmap.
    }

This particular case checks for the system events. It defers the event processing to some other system message processing routine. It then removes the particular event from the bitmap (the return value XOR’s the system event message).

Well apart from that, coming back to attachments. So this random person whom I’m attached to, is pretty fucking annoying. Fine, I maybe be cribbing but really I knida loose myself if this random person is not around (even though the distance is great between us). I kinda expect something back because I’m attached. I want this random person to be as fervent as I’m. But that cannot happen. That random person cannot possibly act the way I want. In fact any random person will do that. Obviously… a random person has their free will! Well, when the fuck will I understand that? What I think should happen cannot and will not happen between this random person and me. I’m a random person too from this random person’s perspective and I have my own free will… I took this random person a bit too seriously. My bad folks…

Well ok… coming down:

void uart_data_received(uint8 *buf, uint8 len)
{
    Biscuit_SetParameter(TX_DATA_CHAR, len, buf); // data recieved. Char2 is set.
}

This function is responsible for reading commands from the phone. In the accompanying Android app that comes with the BLEMini, you can search for the routine that sends command to the BLE device. RBLService.java is responsible for that. It basically sets a GATT Parameter of the Biscuit’s service. The TX_DATA_CHAR is the data transmitted by the phone. It is sent to pin TX of the device. This data can then be used by the Arduino to do what ever you want. If you scan through the code, you can see that there are arrays and structures that you can modify. Like:

static uint8 scanRspData[] =
{
    // complete name
    0x08,   // length of this data
    GAP_ADTYPE_LOCAL_NAME_COMPLETE,
    'B','i','s','c','u','i','t',   // TODO: change this to Nyx

    // connection interval range
    0x05,   // length of this data
    GAP_ADTYPE_SLAVE_CONN_INTERVAL_RANGE,
    LO_UINT16( DEFAULT_DESIRED_MIN_CONN_INTERVAL ),   // 100ms
    HI_UINT16( DEFAULT_DESIRED_MIN_CONN_INTERVAL ),  
    LO_UINT16( DEFAULT_DESIRED_MAX_CONN_INTERVAL ),   // 1s
    HI_UINT16( DEFAULT_DESIRED_MAX_CONN_INTERVAL ),  

    // Tx power level
    0x02,   // length of this data
    GAP_ADTYPE_POWER_LEVEL,
    0       // 0dBm  
};

You can change the name of the device here. I modified to say:

    // complete name
    0x04,   // length of this data
    GAP_ADTYPE_LOCAL_NAME_COMPLETE,
    'N','y','x', ...

Pretty cool huh? But what is not cool is the other random person who is attached to me. Dude, I was just being good to this random person. Does it really mean that I’m responsible for this random person?! Fuck no man! This is the moment where humans should be like “Ohh well… I had a great time with you and cherish your every memory. I hope we meet again someday, till then have a great life.”. Simple… good bye and ok I will, some day listening to High Hopes, will recall their memories and call them maybe. But thats that. Why on earth am I held guilty that this random person is attached to me? For being good? Well damn it then.

So I’m gonna drop dead anytime now, so I’ll run through the compilation. It will be redundant for me if I reproduce the already available document. Refer to the final chapters of the Software Developer’s Guide linked above. But I was not able to compile the source directly. Copy the unzipped Biscuit firmware folder to your TI Library’s Project’s directory. Then follow the steps in the guide. That too did not help me. So I did something ingenuous. I merged the Biscuit source with the SimpleBLEPeripheral application firmware. That required me to hack the above mentioned files according to the new application firmware. I basically removed the Biscuit specific services and used the stock SimpleBLEPeripheral service. Then hacked the source for SimpleBLEPeripheral service to have some features of Biscuit’s original service.

Code compiled… awesome. Now, do whatever the fuck you want, you cannot upload the firmware. Not yet. You have to convert the generated hex file to a bin file.

Refer to this discussion on TI’s forums. There are many options there. You should search options yourself, as this is what I did. I really cannot explain in words what each option means. Search the TI’s forums, you’ll end up with something.

So well… I’m a big fucking loser rambling, as of this moment, 1604 words. But really, it does actually bother me that one can have such profound and intense feeling for someone. So intense that you build your thoughts around them without knowing that whatever you’re thinking is actually just… shite. Well… whatever, I let it out… its all good. Tomorrow is a new day. Have a great night folks!

May the force be with thee!

Ninja.

Advertisements

One thought on “Some personal issues.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s