Crack Hack: Assembly Code That's FUBAR

My definition of a "crack hack" is as follows: a very simply task performed on a microcontroller by a very contorted assembly code algorithm.

Here's the problem definition:
I'm sending data from the PC to the microcontroller (uP) via microcontroller's the asynchronous serial communication interface (SCI). Th SCI can only recieve 8-bits in its data recieve register.

Here's the "brute force" solution:
On the PC side, a list of parameter input values are prepared. At the moment, I don't care what parameters have been changed because I'm sending everything to the microcontroller. On the microcontroller side, the list is processed by storing the first byte that arrived to an allocated memory space, and any succeeding bytes are processed the same way. Here's an example if I'm not explaining myself properly:

PC, List: {A, B, C, D, E} = {$23, $E4, $5F, $1A, $79} --> transfer to uP
uP, SCI buffer: {$23} --> interrupt service routine (ISR)
ISR: LDAA sci_buf ; load Accumulator A with whatever is in the SCI buffer
STAA $6200,x ; store whatever is in Accumulator A into memory space at $6200+x
INX ; increment Index X
Rinse and repeat until the entire list is stored into the uP's RAM.

Now, here's the "crack hack" solution:
To store 8-bits of information, I'll need to send a total of 24-bits to the uP. The first 16-bits represents the address that the 8-bits are going to be stored. Also, the 16-bit address must be split up into two 8-bit portions where the first 8-bits represent the upper byte of the address and the second 8-bits represents the lower byte of the address. So, I'll be using the same transfer protocols as the "brute force" solution except the way the data is going to be processed.

The first 8-bits are sent to the uP and written to a temporary memory space. The second 8-bits are sent to the uP and written to another temporary memory space. These two 8-bits are written to an index register (Index X). The third 8-bits are sent to the uP and then is writen to its "permanent" memory space using the address in the index register.

The "crack hack" is a very brief description of what I want to do but it is going to get very messy, very quickly, especially in assembly. It's an interesting solution, if I can pull it off. To be safe, and to keep me sane, I'll use the "brute force" solution because it's very straight forward and very easy to implement. In retrospect, the "brute force" solution might actually perform better after I analyze the worst-case scenario for the number of clock cycles spent during the execution of the two proposed solutions.

Now, does anybody else have some "crack hacks" to suggest?


May the Strain and the Force be with you. (Hardware)

Ok, an electrical engineering related post. First, a little explanation of my post title. In my Instrumentation lab project, one part is designing suitable analog circuitry to generate a voltage signal that represents the change in the resistances of two active strain gages. This voltage signal is then converted by a microcontroller into a corresponding stress and force value and is displayed onto a LCD screen. But first, a small explanation on what is a strain gage.

-= Strain gage =-
A strain gage is a thin piece of metal fused to a strip of foil. Strain gages come in many shapes and sizes. The ones I happen to be using resembles a comb, the two ends or pads bent at 90 degrees to the comb teeth and pointing towards each other. Two wires are attached to the pads so that the strain gage's change in resistance can be measured. A strain gage functions on the principle of how a conductor's resistance can change by varying its length and/or surface area. In this case, we're concerned with how the length is compressed or stretched. Compressing the strain gage decreases its resistance meanwhile stretching it does the opposite.

-= The Analog Circuit =-
This is going to be difficult because I'm too lazy to draw the circuit so instead I'm going to describe it.

The strain gages are attached to a small metal blade so that they can both be used as active gages, one on top of the blade and one on the bottom. Pressing the lever downwards causes the top gage to lengthen while the bottom gage to compress. Pulling the lever upwards achieve the opposite effect.

First, a steady DC supply of 10V is required to properly balance the Wheatstone bridge (more on the later). The 10V DC supply is achieved by using a REF01, an IC that can generate a clean DC voltage using a dirty (due to power supply ripple) DC voltage as input. In our case, we're using a DC voltage of 20V as input and we're getting clean 10V to be used as a voltage reference. From the REF01 output, a voltage divider (resistors and a pot) is used to give us 3.5V to be used as a offset voltage. To decrease the amount of current drawn from our 10V reference voltage and , u741 op-amps are used as buffers (voltage followers).

Second, the strain gages and two 10kOhm resistors are used to form a Wheatstone bridge, with the resistors on the left half and the gages on the right half, so that they both form a voltage divider. The 10V reference is used to power the bridge so that at the strain gages and the resistors have a nominal output voltage of 5.0V. The gage and resistor output is then sent into a AD620, an instrumentation amplifier packaged into an IC. The beauty of the AD620 is that it is powered the same way as an op-amps and the gain is adjusted by an external resistor.

The instrumentation ampliier (IA) is powered by the 10V reference voltage, with the gage and resistor outputs as its inputs. The gain was chosen to be about 100, so that the tiny change in gage resistance is amplified to a decent output voltage. The 3.5V from the REF01 (refer to above) is used on the IAs offset pin, to push the IA output entirely into the positive range. This is done because the microcontroller A-to-D converter (ADC) can only handle the dynamic range of +5V to +0V. Now, the IA output is connected to Port E (the ADC) on the micrcontroller so that the software can interrpret the voltage into a stress and force value.

I'm getting sleepy so I'll explain the software next week.