Monday 31 October 2016

Validation cases for GATT interaction

I knew that when testing a BLE device, GATT will play a pivotal role. Hence I spent today learning about how it was implemented in Linux and through what channels is it supposed to work.

Friday 28 October 2016

Validation strategies

I continued the work from the previous days in solidifying the testing strategies for BlueNRG on Linux.

Thursday 27 October 2016

Using BLE on Linux

Today I browsed the web to find various use cases where BLE could be and is used in Linux. This was followed by trying out some of these use cases my self.

Wednesday 26 October 2016

Strategies for Linux and BlueNRG

I explored various strategies to test BlueNRG on Linux and debated their feasibility with my mentor.

Tuesday 25 October 2016

Testing BlueNRG on non Linux platforms

Today was about testing the chip in hand on non linux platforms to make sure that is working fine and also to learn just how the final outcome should look like with BlueNRG. We tried testing it with Android apps and then the IAR workbench on windows.

Monday 24 October 2016

Shifting to BeagleBone Black

The 2089b board was just not working out. We tried switching the board, arranging a new board, trying to fix the old ones but nothing seemed to work. All we had was one working board and that was busy elsewhere. So after a long discussion it was decided that the whole development be moved to the Beaglebone black. So today was all about shifting everything to BBB. It was like the training so far had run a full circle.

Friday 21 October 2016

Trouble in paradise

After reviewing the code flow, revisiting the connections, I tried to bring the board back up to start over. This time the board wouldn't start. Back to square one with the board.

Thursday 20 October 2016

Code flow in IAR

I learnt about the code flow of some of the BlueNRG application by running it on IAR and debugging through the code even though it was working.

Wednesday 19 October 2016

X-nucleo on Linux

After making the apt connection I tried seeing how the X-nucleo board for BlueNRG was being treated by Linux. The device was expect-ably unacceptable in recognition and behavior.  

Monday 17 October 2016

Wake up & Code

I have lost count on the number of drafts I have saved on this blog. Drafts with tempting titles, promising potentials but a lethargic author. You'll find that this post has been conveniently labelled as my daily dairy but you know as well as I do that it's probably not a dairy account of my activities and it's definitely not daily. I take pride (maybe misplaced) in what I post here. Quantity is least bit of my concerns regarding this blog. I am consistently agitated by such an example of lack of creativity and discipline i.e. this blog. This makes me constantly sad yet consistently careless about any of this, so I digress.
Dreams are a projection of desires on the murky canvas of night empowered by the unshackled nature of sleep. Mostly a dream is all about the statement of “what”, the beauty of which is rarely bothered by the enquiries of “how” or the suspicions of “why”. The easiest way to claim success or reach the end of an abyss is to experience a dream of the corresponding genre. This paragraph is getting out of context, this article is getting out of hand; so I digress again.
Often when one dreams about something, weird things happen. Everything is either so easy or even the most trivial things seem taxing. But for the intent of this post I am going to focus on when dreams apply leaps and leave gaps in order to get from one point (in the dream) to another. For example if I am dreaming about travelling on a plane then my brain would automatically abstract out certain details so as to stay on the main topic i.e. travelling on a plane. I wouldn’t have to sleep through an entire taxi ride from my home to the airport, would I? The dream would just make things happen. One moment I’d be getting ready for the journey and the next moment I’d boarding the plane. Easy as pie. My point is the automatic abstraction of details that happen in a dream. And of course when one wakes up then things become normally difficult. Every details starts to matter and every action consumes resources like time and effort. The idea (dream) of travelling on a plane becomes much more painful when one encounters facts like:
There is too much luggage. Public transport won’t do it this time. A separate vehicle is needed specifically to carry all of this to the airport. I don’t have a separate vehicle. Booking a cab seems to be the logical thing to do. To book a cab I need the app. To download the app I need internet. Mobile data will take too much time. Need to find Wifi. Need to know the password. Need to download the right app. Need to know how to use that app. Need to be aware of any first time offers the cab company may be offering. Etc, etc, etc, you get the picture.

You see how the details start to pile up on you as soon as one starts to actuate a dream.


A similar pattern can be observed in the life of a "logician by ambition and programmer by default". The fundamental of any programming assignment can be classified into two categories:
  1. Coming up with a solution (forming an algorithm) or simply understanding an already existing solution (learning an algorithm).
  2. Implementing/ actuating the solution (coding the algorithm).

The above procedure (also an algorithm in its right) is vulnerable to the same implications I described earlier. Code is to an algorithm what reality is to a dream. Meaning that just like a dream tends to abstract finer details focusing on the intent rather than the implementation, an algorithm too tends to be intentionally obscure for the purposes of being bold and clear rather than being detailed and clumsy. As an example consider an algorithm that can tell you the order in which you should go about completing your to do list (topological sort). The algorithm is simple enough:
  1. List down all of your tasks.
  2. Assign dependencies, like what tasks needs to be done in order to attempt a particular task.
  3. Make a graph of this scenario where tasks are the nodes and the dependencies are directed edges.
  4. Start scanning the graph for a node that does not have any dependency (an in coming edge), when you find one, do that task and remove it from the graph with all the edges originating from that node.
  5. Repeat the above step on all the remaining nodes until no node remains in the graph.
  6. Once the graph is empty, all your tasks are complete.
Of course the algorithm sounds simple and elegant but coding it invites many painful considerations:

How do I take input from the user regarding what are the various tasks? How do I make my program understand which tasks are dependent on others? The algorithm said something about graphs, how do I represent graphs using my basic data types? I know, using adjacency lists. Wait, how do I form the adjacency lists? Should I include the right header to handle lists or should I use simple arrays? Should I represent each task with a class or just leave them be a string containing the name of that task? How do I keep track of the number of dependencies left for each particular task? How to adjust the graph for when some task is complete. How do I store the order in which each task was completed? Etc, etc, etc, you get the point (or in this case the paragraph).


I don’t know if have been able to describe how I feel 

about this. Feelings are always hard to describe. 

Sunday 16 October 2016

An Orphan on my blog

"I have lost count on the number of drafts I have saved on this blog. Drafts with tempting titles, promising potentials but a lethargic author. You'll find that this post has been conveniently labelled as my daily dairy but you know as well as I do that it's probably not a dairy account of my activities and it's definitely not daily. I take pride (maybe misplaced) in what I post here. Quantity is least bit of my concerns regarding this blog. I am consistently agitated by such an example of lack of creativity and discipline i.e. this blog. This makes me constantly" 

The above is a draft I saved some time ago. I forgot what this post was supposed to be about. It would have helped if I didn't save it as a draft amidst a sentence. Anyway, the title was "Wake up & Code" and I really don't know why I started writing what I wrote. It's a shame this one didn't cultivate to completion but then again considering the author, it's probably for the best.

Friday 14 October 2016

Interrupt handling on SPI

The way in which data was being sent from BlueNRG was not as expected. So we suspected that may be we need to jump into interrupts in order to get the data. Our thinking was that when BlueNRG had some data to send it will give an interrupt. We weren't quite sure as the writing in the documents was not clear to me (my mentor had not studied it). So I set up this whole routine in my code that would deal with interrupts and handle them aptly.
The results were ample to say the least. BlueNRG was giving many interrupts which could mean that either it was ready to send data and was notifying aggressively or that something was off in the hardware connections. I stayed optimistic and debugged the whole situation so that at the end of the day I could present it to my mentor and she could then give some insight as to why the behavior is as it is. As it turns out it was a problem in the hardware connection that was sending so many interrupts. I came to realize that when I tried the code without connecting the interrupt line and the interrupts would still show.

Thursday 13 October 2016

DTS entry for the driver

Earlier when I was trying to get the response from BlueNRG I missed a very important step that was preventing that from happening. I forgot making an entry in the DTS for the 2089b board which I did today.

Wednesday 12 October 2016

A welcomed distraction

Today I was not working on my code. Instead I was helping out another mentor of mine in the patch work for the driver he has completed. Since I had researched on doing patch work using git email it was that was being consulted. It felt good. I felt important. Things worked out. Hence it was a welcomed distraction.

Tuesday 11 October 2016

My name is Govind and I am not a Gaurav

Communication is fundamental. Agree? Yes.
To carry communication, language is a necessity. Agree? Of course.
A language is nothing if doesn’t have nouns. Agree? Sure, whatever.
Out of all nouns from any language the most intimate and innate are names. Agree? Sort of? Alright.

Someone great and dead said a long long (int) time back, the following:

What is in a name?

That someone too had a name that has outlived him, uplifted his work and turned his influence into a pandemia. No, I am not talking about Lord Voldemort.
Have you ever been called by a name which is not yours but has the same number of syllables, starts with the same alphabet and sounds nothing like your name? I have. Not once, not twice but at least a thousand times in my otherwise believable life. I am not crazy. If anything I am being modest.
To understand what lead me to write this->article on this->day, we need to back up a bit.
I was bright in school (don’t mind the tense). This would cause the teachers calling my name a frequent phenomenon and a cheerful one at that. Out of these one particular teacher was very supportive and encouraging. She almost put me on a pedestal, presenting me as an inspiration to others, using my name as a symbol of all that is good. But obviously she was not accurate in any estimation she had of me, not even my name. She called me Gaurav. I didn’t correct her as that seemed rude at the time. This little amusing discrepancy continued for four years. But it is okay isn’t it? Such things happen, someone confuses your name in their head and the wrong name gets stuck with you. The thing is she is not the only one to make the same mistake.
I have been called Gaurav by not one, not two but at least ten people in my otherwise believable life. And these are people I can safely say knew me well. Unlike the teacher, others were not in the habit of using this misnomer. Generally things would be going normally, I’d be myself and everyone else would be perfectly lucid when suddenly out of the blue, someone would say Gaurav. And just then I’d say to myself: It happened again.
The culprits of this harmless crime range from friends, acquaintances, teachers and relatives. Such variety of criminals is strange but what’s even stranger is the consistency of the crime i.e. the constant (char * misnomer = ) “Gaurav”. I don’t understand why is it always Gaurav? Curious.
Signing off,
“You know who” Sharma.

Starting frames of BlueNRG

After sending raw data, it was time to send some meaningful data over SPI to BlueNRG and see if it responds properly. In my case I had to send a start up sequence that wakes the x-nucleo from sleep. On receiving this data packet, the x-nucleo is supposed to send back its buffer length and register status in the same SPI transaction. This meant that I had to setup a rotational data structure to send at one end and receive from the other. 

Monday 10 October 2016

Sending data through SPI

I worked writing simple routine that would just send data over SPI to the connected device. At this point, the data being sent is meaningless. The important thing is getting the channel to work. Once I am able to transfer data then I can safely pivot to writing some meaningful code on top of this. I fiddled around with code that sends data and learnt how exactly SPI works. It was cool to be able to write some code and then see it in action only to improve it.

Bathroom Programmer

The entirety of this blog piece is a desperate attempt to bring about some coherence to a made up, potential possessing, loose analogy. The analogy I’ll be attempting to draw is between a well-established kind of being in the society i.e. bathroom singers and a relatively new brand of programmers also known (to me only) as bathroom programmers.
The name bathroom singer has the word bathroom in it for quite literal reasons. But I’d to like think there is more to this word than being just an associative noun. In my opinion, bathroom here serves as an adjective. An adjective quantifying the geographical as well as the demographical range of the singer being. What I mean is that singing whilst using the bathroom may just be a severe symptom but people exhibiting this symptom are not the only bathroom singers out there. Trust me, I’d know on behalf of being one. We can still use the word bathroom because it’s hilarious but a more inviting and honorable definition of a bathroom singer should be a singer being a singer only when there is no one around and nowhere to be.
Without wasting any more of your precious and my pretentious time, let me offer a tentative definition of a bathroom programmer:
A programmer being a programmer only when there is no one around to test the program and no place to use it.
While the whole point of singing is the expression of emotions for the purposes of either be entertaining or be entertained; the point of programming is mostly just having a point. But just as a bathroom singer causes amusement to only himself, our bathroom programmer solves a problem made up only by himself.
Most of us have had a consistent run as a clandestine rock star; performing under the influence of a variety of emotions or none of them at all; transcended from the mediocrity that is most lives; aiming at an escape so short it escapes as soon another thought enters the conscience. Then there are some, talented with limitless limits; working with short spanning discipline; trying to have a similar escape.
Another important issue in art circles of any radius is that of authenticity. An artist is rarely appreciated if all he has to show are reincarnations of someone else’s work. But imitating others is the bread and butter of a bathroom singer/ programmer. A bathroom programmer will often hear about some cool little thing someone else did, then he would probably look up how they did it. This would of course be followed by an attempt to redo the entire thing or mostly only the easiest subset. The difference between the original and the latest is often just quality, quantity, efficiency, applicability, meaning and purpose.

It’s hard to let someone else in on your side art isn’t it? Especially if that someone is renowned in the very same field. You would probably feel embarrassed too if you’re asked to show your favorite program that you rarely shut up about in your little friendly circle, in front of an accomplished singer with the most melodious voice. I might have stretched that last bit, impressing some singer dude is easy. You just arrogantly ask them if they want to play tic-tac-toe using your “software project”. What’s actually hard is impressing someone who has been around computers enough to see through your poor design, vision and implementation. Moreover these computer people probably won’t even appreciate you singing. They’re awful. I want to be one of them.

Friday 7 October 2016

ACI

Application controller Interface is the protocol used by BlueNRG to communicate between the host and the controller. It is sort of like HCI but only a superset of it. It works only for ST BT devices and uses SPI as the transport layer.

Thursday 6 October 2016

DTS entry preparation

I prepared all the essential information that needed to go into the DTS file for the driver to work.

Wednesday 5 October 2016

SPI connection between host and X-nucleo

Moment of truth. Connecting electronic stuff to more electronic stuff. Today I made connections with the X-nucleo and the chosen host: 2089 board for the SPI communication to happen. This may have been a trivial thing for an electronic student but for me it was a great opportunity learn. Hence I prepared my self to be enlightened by the whole thing. I was enlightened but just a little lightly. It wasn't that big of a deal as I thought it would be. I had to connect a bunch of tiny wires to a bunch of pins and that was it.

Tuesday 4 October 2016

Patch submission in Linux kernel

I studied and then documented the patch submission process in the Linux kernel.

Monday 3 October 2016

Patch work on gmail

Today I worked getting the git send-email setup to work on gmail. The idea is to  first get it to work on gmail and then slowly reproduce the same results on the ST mail servers. This task would be seamless if done on a public network but since the patches are to be sent from with in the company network, I had to wrestle through some settings and then find a combination that would allow patches to be sent directly from a git repository to any given email address from a gmail id.