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.
Monday, 31 October 2016
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.
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:
- Coming up with a solution (forming an algorithm) or simply understanding an already existing solution (learning an algorithm).
- 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:
- List down all of your tasks.
- Assign dependencies, like what tasks needs to be done in order to attempt a particular task.
- Make a graph of this scenario where tasks are the nodes and the dependencies are directed edges.
- 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.
- Repeat the above step on all the remaining nodes until no node remains in the graph.
- 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.
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.
Subscribe to:
Posts (Atom)