Skip to main content

2019 Blog Intro

I have had a few blogs throughout the years. They usually do not last and/or are not maintained. They fall victim to my dwindling inspiration. This year however I promise to commit myself to this blog and its readers no matter how few. I believe the lack of content will be mitigated by the fact that this blog will be mostly about micro-controller programming and projects relating to electronics. This vast area of interest will produce no shortage of content.

About this blog:

What you will find here is an array of tutorials concerning microcontroller programming at the register level using C. The flavor of choice used here is the popular STM32 brand. This blog will also contain knowledge about specific electronic engineering topics, such as but not limited to power electronics, robotics, and anything else that sparks my interest. You will not find basic electricity tutorials like explanation of Ohm's law, there exist a plethora of great websites tackling those topics. What I will cover will  closely resemble upper division college course topics. Furthermore I have a personal section of the blog where I simply document my experiences in school / work / life or just express my opinions on tech etc.

About me:

At the time of this writing I am an electronic engineering student in south Florida. I am fairly interested in embedded systems and power electronics. I did not have the opportunity to go to college right after high school because life had other plans for me. During the time in between high school graduation and finally starting college at age 25 I had numerous interests and jobs. I briefly day-traded e-mini futures on the Chicago Mercantile Exchange ( like trading stocks but you need less money to actually make money). I worked at a restaurant as a busser. I worked installing granite kitchen tops. I worked many more odd jobs. At some point I was on and I stumbled on a "word clock" project that required the use of an Arduino. I quickly fell in love with the Arduino and with electronics in general. Even as a kid I loved programming but now my programs were controlling physical things. I have always been curious, infinitely curios and I cannot stand not knowing how something i'm interested in works. Calling the Arduino function and not knowing what they really do bothered me. Burning Arduino boards and blowing up transistors and not knowing why this was happening also bothered me. The opportunity for college presented itself and I ran towards it at full speed with no doubt in my mind what I wanted to study. I quickly abandoned the Arduino platform because I knew if I wanted to become a real engineer I needed to learn the hardware and how to really program microcontrollers, no employer is going to accept an Arduino library in thier product, not to mention there are hundreds if not thousands of different microcontrollers out there. I jumped on the ARM Cortex wagon and specifically the STM32 to learn how to program microcontrollers. Once you master one vendor it is easy to program any other chip because you realize at the end of the day it is nothing more than just registers and bits being shifted in and out.
I am also very interested in power electronics. For some reason programming microcontrollers feels so easy and I dont feel like a real engineer. Power electronics however challenges me at every step of the way and I appreciate that very much. 
Oh I also played around with photography... I will make a post showing some of my work.


Popular posts from this blog

Interface a Rotary Encoder the right way.

So whilst reading my favorite odyssey found here I stumbled onto something I never spotted before. It turns out that the general purpose timers support hardware interfacing with an incremental encoder. This means no more interrupts and no need to increment whatever variable you had. Now all you have to do is get the value from the Count register in the timer. Did I also mention it takes care of figuring out which direction you are turning it? Amazing! Lets talk about it.

Encoder Interface Mode Verbatim from the reference manual of the STM32F103 page 392 or Section 15.3.12  "Encoder interface mode acts simply as an external clock with direction selection. This 
means that the counter just counts continuously between 0 and the auto-reload value in the 
TIMx_ARR register (0 to ARR or ARR down to 0 depending on the direction). So the user 
must configure TIMx_ARR before starting. In the same way, the capture, compare, 
prescaler, trigger output features continue to work as normal."

STM32L0/F0/F3 I2C : Part 3 RX TX via DMA

Most modern microcontroller come with a peripheral called DMA which allows for an even more hands-off approach. The Direct Memory Access controller will get a tutorial of it's own in the future. However, it is so simple to use that I can easily explain the required bits in this tutorial without feeling like I will overwhelm the reader. In this iteration of the I2C series I will cover how to TX and RX date on the peripheral in conjunction with the DMA controller. 

First let me briefly explain in a high level what the DMA controller does. It allows you to transfer data in 3 ways: Peripheral to memoryMemory to peripheralMemory to memory. What does this mean? For example, when you receive data on I2C in your RXDR register, you can have the DMA controller move that data received into an array. At the end of the day your variables are just memory locations, so if you have declared an array it has an address associated with it, this is address is what the DMA considers  "Memory"…

STM32 I2C Does it suck?

Recently I have been annoyed with  bugs in the I2C implementation in ST's F1/L1/F40/F2 series, and  any microcontroller made by ST before 2012. There appears to be, what I can only describe as, a race condition when attempting to receive data in I2C interrupt(low priority)  or polling mode.

Just to be clear a race condition is defined as , verbatim from wiki: "the behavior of an electronics, software, or other system where the system's substantive behavior is dependent on the sequence or timing of other uncontrollable events. It becomes a bug when one or more of the possible behaviors is undesirable."
I was humming along trying to make my YouTube tutorials when I arrived to the I2C protocol implementation. I have used I2C with the F1 series plenty of times, however I have never had the need to receive data from a slave. However for the sake of completeness I decided to implement an RXing routine in I2C for my tutorial. Only to find statements like this in the referen…