System Level Design

Rationale

Our project inspiration came from a previous project both of us had worked on a previous year. At that time, we had both worked on separate projects involving a simple Pedometer using a MSP430 microcontroller. Unfortunately, due to time constraints and hardware failures, we were unable to complete the project. Unwilling to accept defeat, we attempted the project again, but with the intention of providing greater functionality, better user interface, and a working final product. While we understood that many smartphone apps provide a similar functionality, we wanted to see if we could provide comparable functionality without all the need for fancy hardware and expensive data plan.

From the beginning, we decided to use the ADXL345 digital 3-axis accelerometer, not only because of its expansive functionality and zero cost (due to borrowing the part), but also because we had extensive familiarity with the part which would reduce the start-up design time. Initially we had planned on using the built in interrupts and threshold functionality found on the ADXL345, but after determining that we would be using the Tiny Real Time (hereafter called TRT) multitasking kernel, we found that it was easier to poll the accelerometer for data.

Apart from data acquisition, our exercise measurement system provides two forms of data display and analysis. The more simple of the two involves a simple 16x2 character LCD screen. It provides all the necessary information to the user while the user is walking or running. This includes the number of steps taken, average speed, and total distance using the dead reckoning navigation technique. While we had hoped to improve upon our distance and velocity calculations using a GPS system as a potential improvement, we decided against the addition due to both limited time and the inability to use GPS indoors, where many potential walkers would be using the device.

Finally, our secondary data display and analysis device involves using the common SD card to log user data and plot them on MATLAB. This provides more than simply the above mentioned metrics displayed on the LCD but also the raw acceleration data before much of the noise canceling is performed. This allows for the more in-depth and curious user to look at the slight differences in walking style which may be found in persons suffering from anything ranging from a sprained ankle to more serious medical conditions. As a plus, the user can keep a record of all of his or her exercises to track changes over time.

Background Math

This project does not have conceptually difficult math. There are two main calculations that are taking place: detecting a step and determining distance. We tried a couple different methods of calculations, which can be read in Appendix B, but we want to focus on what's working in our final code.

When we break down what constitutes a step, we can focus on a single, critical event: the cessation of a foot's downward motion due to collision with some surface. From mechanics, we know that any change in an object's momentum is either due to an impulse from this collision. We can then say the following is valid:

$$\delta\rho = m\delta v = Ft$$

Furthermore, we know that the force applied looks like a spike. This external force is directly proportional to acceleration, per Newton's Second Law. Now, the implication of this is clear - by placing an accelerometer on each foot, we should be able to record these spikes directly from acceleration data and correlate them to a step.

To determine what a step is, we use a dynamic envelope threshold based on a running average of the acceleration data and call a step a point at which the acceleration exceeds this threshold. By implementing this, we can accomplish a few things - we reasonably assume that the spike will exceed the running average by a decent margin and we allow the threshold to change, which allows for sensing softer steps and prevents from overcounting steps. Even then, there will be instances when the acceleration spikes above the threshold due to noise and could be counted as a step in error.

To prevent this double counting, we add a simple timer. Depending on the pace someone takes, we can expect a minimum amount of time to pass between steps - logically, the faster someone runs, the quicker we can expect these steps. Arbitrarily, we impose two different values for this minimum time delay, 400 ms at a walking pace and 200 ms for a brisk pace and running. To determine which value to use when, we apply a bit more physics.

A logical assumption that can be verified is that as a person speeds up their pace, their foot will be travelling down with a greater velocity before stopping, which means a larger spike over a quicker time. If we take the acceleration and take the differentials to find the jerk, we will observe that the over time, a faster pace has a distinctly larger moving average of jerk. We set compare this average jerk to an arbitrary threshold to determine whether a larger or smaller delay is to be used.

Our method of determining distance is dependent on having accurate step data. Assuming we have accurate steps, we can use two parameters to determine a rough speed - pace or the rate of stepping, and the step length. Quite simply, the rough velocity will be the pace multiplied by the step length. This makes intuitive sense - if I take 4 steps a second and each step is about a half a foot, one can expect to travel 2 feet in a second. We now have a measure of speed, and we can easily integrate to find a distance.

For both essential components, there is a considerable amount of arbitrary values that are set - number of samples to use for the running average, different thresholds, the strides, etc. Almost all of these are derived from running numerous iterations of the code, tweaking parameters and attempting to see what worked best.

Logical Structure

The structure of this design centers around the ATmega644 and its three peripherals, namely the accelerometer, LCD screen, and SD card reader with MATLAB plotting. The peripherals can be divided into two broad categories of function: data input, and data output. As can be deduced, the accelerometer system was used for data acquisition, and the LCD screen and SD card were used to log or present data that would be meaningful for the user in real time or for future use.

Block Diagram

Hardware Design

This section will breakdown the hardware components of our project and discuss any details and decisions made. Datasheets will be referenced often, and the appendices will contain links to the relevant components. When possible, we will provide commentary on the usage of particular parts and insights for future projects.

Our schematics can be found for download in Appendix D

Atmel Mega644

Mega644 Board

We used a ATmega644 board mounted on a custom-made circuit board designed by Bruce Land. The circuit board provides some key functionality to the project. For the end result, we have access to pins for SPI communication, which is important for the functioning of our project. There's a voltage regulator to switch a 9V supply down to 5V for MCU operation, which allows us to use either power supply from the lab or a 9V battery. There's also the serial communications port which we used extensively for debugging purposes. The final implementation does not need the serial comm port to function properly, though.

By the end of the project, hardware issues came up with the programmer, which uses pins B5, B6, and B7. After blowing one Mega644, we had taken precautions to program only when peripherals were removed and run the pogram without the AVR programmer attached. Nevertheless, we discovered an issue related to the programmer pins with the help of David Ackerman and Jon Amazon. We ended up having to solder a quick header to pull pins up to 5V Vcc. These are simply 10k resistors that tie MOSI, SCLK, and MISO to Vcc.

Voltage Regulator

Our project revolves around the implementation of different peripherals and being able to communicate with them. From the very beginning of our project, the need for a voltage regulator was obvious. The ADXL345 accelerometers and the SD and microSD cards are rated to operate with 2.7-3.6 V supply, while the Mega644 and the LCD's use 5V supply. For this, we used the LP2951 voltage regulators found in lab.

We found Texas Instruments' datasheet related to the LP2951 to be extremely helpful and clear about the design and application of the regulator. From this datasheet, we were able to program the regulator to output 3.3 V with constant 5V supply. This was a simple circuit, with a resistive divider from the output voltage to the LP2951's feedback port. This sets the input to the regulator's error amplifier equal, which drives it according to the equation (from TI)

Software Design

The majority of our code was written in C using the Atmel MEGA644 with AVR Studio, as has been done throughout our class instruction. Additional code was written in a simpler MATLAB script to load data from the SD card and plot it . This section seeks to breakdown major components of our program and discuss the details and purpose of code. Whenever code is borrowed, we will explicitly reference the source (as well as provide links in the appendices), and if possible, provide any commentary and insight that can prove useful for future projects.

Our source code can be found and downloaded in Appendix C

SPI

A quick note before we begin discussion of our code: two of our peripherals use the SPI communication protocol extensively. The 4760 course website has a helpful introduction to SPI, especially with regards to its implementation in the MCU. For better understanding of what we discuss below, we suggest reading the information written by Professor Bruce Land.

To keep different slaves unique, we will need to use different pins to act as different chip selects. For the sake of ease, what proved easiest is to use B4, B3, and B2 in that order of additional peripherals. In the event that more slaves are needed, other pins can be programmed too, but one would need to refer to the Mega644 datasheet before selecting a pin.

To ease the ability for the MCU to select different pins, we use a couple macros adapted from SparkFun's arduino tutorial for ADXL. Our code only uses two of the macros, but we provide four of them: READ, SET, CLR, and FLIP, each with an input for port and an input for pin number. As the names imply, the macros read a pin, set a pin, clear a pin, and flip a pin. Using these macros is helpful, as it makes it clear to see and understand which particular pin is being altered.

One key detail for future projects - make a note of the default SPI pins that the MCU uses: B4 through B7. The variable indicating data direction DDRB must be set to include these four default pins - even when debugging another slave, B4 must be set as an output and pulled high for SPI communications.

Accelerometer

As the ADXL345 accelerometer was a major component of our project, a central part of writing and testing our program was to set up the chip and enable acquisition of data. Upon successful initialization, the ADXL345 will properly react to environmental conditions (eg - rotating the accelerometer to respond to gravity) and the data can be read off the chip. Communicating with the chip itself is not a difficult task. The MCU must preface any action, read or write, with the register address that is being accessed.

When initializing the accelerometer, the only register that must be written to is 0x2D, or POWER_CTL. If the measure bit is not set, the accelerometer will stay in standby mode and not output any data. Other than this register, no other registers are a necessity, as there are default settings for the accelerometer operation. For our project, the default settings were mostly sufficient. The only setting we made was to set the range to 8g at full scale resolution, giving us 3.9mg/LSB sensitivity.

Another setting we played around with was the data rate. For a lot of the time, we used a 100Hz output rate. Our goal was to try to reduce error by increasing the number of samples averaged. Doing so with a 100Hz rate would prove inhibitive to our processing speed, as we would need to wait 10ms to take new data. Instead, we upped the data rate to 800Hz so we could sample quicker. Because FIFO is not enabled by default, we end up dropping samples when we are not polling the accelerometer. To fix this, we just woke up our task stepData more often.

Reading data from the accelerometer was relatively simple. After initializing the chip, the user just needs to write the register address for the data and read out the data from the SPI shift register. An important note is that because the data is more than 8 bits, we need to concatenate the values, Thankfully, the address that is used as input will automatically increment to the next register after a successful read, and the data registers are adjacent. This means that we don't need to release the chip select before reading the next register. The accelerometer updates data registers when the chip is not selected, so keeping the CS bit low means the data won't refresh. This is quite significant - there is a substantial difference from reading a valid 0x00FF or 0x0100 to reading two data points and concatenating to "read" 0x01FF.

SD Card - SPI

The other peripheral that used the SPI protocol is the SD card reader. Here, the SPI is a low level I/O protocol that is used as communication between the MCU and the card reader. This implementation helps with the

The SPI capability for this is not significantly different from what's written above for the accelerometer, but there are a few distinct differences for software. One of the most obvious comes from the chip select. As this is a distinct slave, another pin is needed to act as the active low CS bit. For the SD card, we decided to use B3. There wasn't a particular reason to use this pin instead of B4, but as the SD card was added second to our program, it was moved down one. Another differences revolves around how data is read. Unlike the accelerometer, which writes the register address before taking action, the SD card appears to only have one SPI register. This observation is derived from the lack of any addresses in the low level rcvr() and xmit() functions found in mmc.c . Instead, the SD card appears to accept commands and transmit responses via SPI.

Other than these rather simple interfacing differences, the SD card still follows SPI protocol - the code will be remarkably similar to the ADXL. The differences do mean that there need to be unique write and read functions for the two peripheral.

The source code that enables the SD SPI usage is called mmc.c in our code. This is code written by ChaN for AVR interfacing with the FATFS module described below. In order for proper use, customization of this code is needed. We made the following modifications to the default 2010 version of mmc.c :

• Commented out significant parts of power_on() - the code for power_on initializes SPI communications, but our main code already calls this function from another source file.
• Redefined select and deselect based on our use of B3 instead of B4, and also changed around the implementation so that the act of selecting and deselecting the SD card made a bit more sense in terms of atomic actions. (The original code has select() deselect the SD card if it cannot establish a connection.)
• Change the power_status to return 1 by default - originally there's functionality associated with PORTE, which is not present on the Mega644.
• Comment out power_off() - if the disk cannot initialize, we do not want to disable SPI functions (we can still utilize the accelerometers), but rather just ignore any SD related code.

SD Card - FATFS

Using SPI allows I/O communication to the chip, but this is entirely low level. We want to use a mid level file architecture to ensure that data can be logged into files that are readable on other computers. After looking at some prior projects and discussion with lab TA's, we discovered FATFS, written by ChaN and discussed thoroughly by Frank Zhao. Regarding the software implementation, we really have very little to add.

FATFS is a module that was developed for embedded systems and microcontrollers to interface with file architecture peripherals like an SD card. Open source code is provided for various tasks - creating directories, opening files, making files, reading files, writing characters, etc.

A very useful functionality of this module is the inclusion of error codes. When debugging code or testing out hardware, these error codes (returned after every defined method) correspond to an error defined in ff.h and give great insight to whether issues were hardware oriented or software oriented.

For our program, we initialize the SD card at the very beginning of the code. Upon a button press, we attempt to open a file using f_open(). We set the flags to FA_WRITE | FA_CREATE_NEW so the system attempts to create a new file we can write to. If this is successful, we continue to data logging. If it isn't, it's possible the problem is that file already exists (the error code would correspond to FR_EXIST), in which case we increment a counter until we can open the associated file. If the file cannot be opened for whatever reason, we clear a flag that prevents our code from attempting the tasks of writing, synchronizing, and closing the file.

To write a line of data, we write our data to a character array, and then write this array to the file using f_write. However, the file is not properly synched with the disk yet. This is ok in some cases, but because our usage is as a data logger, we want to write this to the disk so that in the event of a system crash we still have some useful data. So everytime we write to file, we need to synch this object. f_synch is incredibly useful, as it can write data from file to the disk without the need to close and reopen the file.

When the user indicates the end of a file log, we simply use f_close to shut the file and end this data session.

Our project is geared toward logging data, but some projects might be aiming to read data from a disk instead. One useful project in particular would be the car mp3 player created by Chris Dolen and Matt Watkins in SP'11.

Data Acquisition and Calculations

The majority of the math behind the calculations has already been discussed in the section for background math. The only software details concerning our calculations we haven't discussed pertain to how to take step data and go to distance.

As mentioned then, our idea of distance is an integration of the speed, which is the pace multiplied by the step length. To find the pace, we use a method similar to determining rpm from Lab 4 of semester SP'12 . We can calculate the period of a step using simple timer based counters, and from this we can reasonably derive the "frequency" of stepping. As people may have an even step or may be changing speeds, we need to use the running average of the pace to give a reasonable measure of the speed throughout the data. At the same time, we need to make sure we can zero out the frequency in the event that a user steps and doesn't take another step. To do this, we arbitrarily impose the constraint that a step must occur within 2 periods based on the average frequency. If not, we will zero out these values. There will be a bit of an overshoot since the

Step length is rather arbitrary and will differ between people. Our numbers are currently calibrated around Tim, but in general, we can say that there are different step lengths based on pace. Similar to how we use a threshold to determine which delay to use when calculating the jerk, we use a similarly arbitrary threshold to differentiate between regions of walking - slow, normal, faster, and running. Each of these have their own step length that is empirically tweaked around.

Now that we have the pace and the step length, we have a function that calculates the differential distance as a differential slice of time multiplied by the multiplication of step length and step speed. And of course, we sum it up over time to give a measure for distance traveled.

MATLAB script

The MATLAB script is a separate .m file that should be included on the SD card. The purpose of this script is to generate some plots from the logged data that could be significant to the user (whatever they seek to know).

The script is really open to whatever the user wants to do with the data found on the SD screen. At the time of this writing, the script is really meant for debugging, and will graph step data over time, as well as acceleration data to determine if the step count was reasonably accurate. There are also graphs for the jerk and the average, so we can differentiate datasets between the speeds and observe when faster steps are occurring.

Button State

To give the user greater flexibility with the system, we implemented an active high button that would allow the user to start and end trial runs without necessitating a power cycle. With regards to the data logging, this allowed the user to safely open and close files. Because this end-point is user defined, it only made sense to include this with some form of button logic.

For the button logic itself, we use a basic button state machine. There are two main steady states: PUSH, and NOPUSH, clearly representing when a button is pushed and when it is not pushed. As might be expected, if a user were to never touch the button, it should stay in NOPUSH, and if the user is always holding it down, it should stay in PUSH. But a physical button will experience issues with debouncing, switching between analog high and low signals.

This means that we need to properly debounce the switch and determine when the button has been pressed (or not pressed) for a sufficient amount of time so as to enter steady state. We introduce two more transition states: MAYBE and MAYBENO, representing "maybe pushed" and "maybe not pushed." The transition states serve as the intermediate stage between steady states, so that on an edge, the transition can begin, but the value must be held for a proper duration in order to properly be debounced.

There were two software implementations possible for the button - an external interrupt based on a falling edge, or a periodic polling. Because of the issue with debouncing, the periodic polling seemed a more appropriate selection despite the sacrifice of some computer utilization. Instead of implementing this as another task, this became part of the Timer 0 ISR. This was a natural choice, as we already had the ISR set up for 1ms iterations. Adding a soft counter to mark off 30 ms (what our instruction in the course noted as being "long enough" for a debounce) was simple, enabling us to call a helper method buttonstate() every 30 ms.

While the code called in the ISR is simple, the implementation and effect this has on the rest of the code is more significant. Polling the button state from the ISR only tells us what state the button is in. There's no indication if a pushed button has been processed, though, so we must introduce a flag that lets the system know to process a button push. This is a rather simple flag - we set the flag in the ISR when the button is set to PUSH, and then we clear the flag after we process the button push. To process the button push, the flag must be set, and since that only happens on the transition to the PUSH state, each push will only be processed once.

Data State Machine

The reason we introduced the button was to add some functionality and give our system different states. That ensured that the user could control when data was being acquired versus idle. The state machine in this case was relatively simple - the system is either acquiring data or is idle. We used a variable named runstate and defined three states: IDLE, INIT, and ACTIVE (0, 1, and 2 respectively).

Program State Machine

The IDLE state, as can be reasonably deduced, represents the point when nothing should be happening. No accelerometer data, no data logging, no timer increments. The ACTIVE state is the other extreme, where we're reading data from the accelerometer, performing calculations, logging data, everything. In between, we have an INIT state that has only one task - to initialize or reinitialize different accelerometer, SD, and program settings. This includes the time of duration, the distance traveled, and the file that is being written to, among others.

The INIT state will automatically transition to the ACTIVE state, which is the state where data acquisition, calculations, and data logging will occur. We wanted the transition between states to occur in the stepData task, so that whenever the button was pushed and a program transition triggered, we could make sure that at least one more final dataset is logged properly.

TRT and Timing

The Tiny Real Time (TRT) multitasking kernel developed by Dan Henriksson and Anton Cervin is used as the backbone system. It is an earliest deadline first scheduler and allows for multiple tasks to run concurrently. Our system only uses two primary tasks: a task that performs all the sampling, calculations, and logging, and a task that prints relevant data to the LCD screen. The TRT system allows the user to multitask the slow LCD function by interleaving actions from another task in order to sample data from the accelerometer quickly enough.

LCD

The LCD code is relatively simple and based on test codes from previous labs of SP'12 . The LCD functions in of itself are not complicated, but integrating the code with the other tasks proved to be an interesting challenge. The LCD buffer updates the screen serially, one character per millisecond. With a 16x2 array, this update can be extremely slow compared to other running tasks. Therefore, special care needs to be taken with respect to the timing of how often the LCD function executes.

Using the TRT kernel, it is possible to concurrently execute the step data function while interleaving LCD functions in between. This allows for the step data function to execute without needing to wait the lengthy period of time for the LCD to update. Especially if more processor heavy functions are included in future updates, running the LCD concurrently will allow a significant speedup in sampling rate.

Semaphores need to be included in LCD functions related to the button push because the button push forces an interrupt to be triggered context switching the current task. The SEM_LCD_SHARED semaphore protects the variables when they need to be copied to the LCD. The copy to LCD commands that are relevant after a button press are therefore encased in semaphores to wait for the LCD to finish updating and vice versa. If the LCD buffer has not completely cleared, then this will cause a error that results in gibberish characters being displayed on screen. At best this can be cleared by pressing the button again to clear the screen but at worst, a hard reset may be necessary to solve the problem. This entire issue can be avoided by using semaphores.