Archive for the 'Software' Category

At left is a simple EMSL AtmegaXX8 Target Board (same board I have written about before) 3 bit up/down counter circuit.

Push the left button? Counts down. Push the right button? Counts up.

Simple.

Sort of.

The switches are fully debounced using an extremely elegant algorithm that I ran across while trying to figure out how to efficiently debounce switches with an AVR controller.

Specifically, the software uses a vertical stack count to efficiently debounce up to 8 switches in very few instructions and only 3 bytes of memory.

Read on for schematic and a description of the software…

Read the rest of this entry »

So, by now, you are well aware that Sony was charging $150 ($100 for the right version of Vista + $50 for the cleaning service) and that they dropped the $50 charge because, well, it was asinine. Or a mistake.

Not going to go there. What I found interesting is this:

The Fresh Start feature is described on Sony’s site as a system optimization service where specific VAIO applications, trial software and games are removed from your unit prior to shipment.

Once selected, the feature is described in the BTO options (along with anywhere from 1 to 5 “None” items. Huh?) as Fresh Start™ (removal of specific VAIO® applications, trial software and games).

Wait. What? removal? are removed from?

That implies that they were installed in the first place. So, Sony is installing the software and then removing it afterwords?

That seems a bit odd. And potentially error prone. What are the chances that the uninstall process actually uninstalls everything?

Seems odd. I suspect that Sony ended up in this situation because they have a contract somewhere that stipulates what must be installed on their systems. And Fresh Start works by finding a value-add loophole somehow that allows Sony to subsequently remove the bits o’ adware and call it a product.

Whacky.

Well, multitasking would be stretching it…

When writing AVR micro-controller code, you typically end up with something like this:

int main(void) {
	... initialization code ...
	while(1) {
		... main loop that never exists here ...
	}
}

The main loop spins forever and is generally the bit of code that updates various output ports based on program state. It might likely also read inputs, too. And it might contain bits of code that delays execution for a while. And it is very likely rife with conditionals that’ll cause any given pass through the loop to very in execution time.

Not a very good place to do time sensitive stuff like, say, debouncing a button press or responding to other user events.

Read the rest of this entry »

Before dealing with switches and debouncing switches, I wanted to add a second LED to the circuit.

Trivial:

#include <avr/io.h>
#include <util/delay.h>

int main(void) {
    DDRB = 255U; // Make all PB* -- PORT B -- pins output
    PORTB = 0x0; // turn all PB* -- PORT B -- pins off.

    while (1) {
        PORTB = 0x1; // B0 on, B1 off
        _delay_ms(200);
        PORTB |= 0x2; // B0 and B1 on
        _delay_ms(100);
        PORTB = 0x2; // B0 off, B1 on
        _delay_ms(200);
        PORTB = 0X0; // All off
        _delay_ms(2500); // 2.5 seconds off
    }
}

Each on/off port is represented by a single bit. So, each of the pins in PORTA, PORTB, PORTC, or PORTD — assuming they are in straight digital input/output mode and whatever AVR chip you are targeting has enough pins to have 4 port sets — will be controlled by a single bit in one of four bytes.

Clearly, some macros to toggle bits are in order. Now, it turns out that macros to toggle bits are a big source of contention amongst the AVR development community. They hide too much magic, or so they say, and, if you are going to be programming embedded systems, you ought to be comfortable with C level bit twiddling, damnit.

Read the rest of this entry »

At left is a big pile of mushrooms that Roger found in our yard after a heavy rain. That rather large pile pretty much shot out of the ground overnight, as far as we could tell.

As we wandered about, we realized it was but one of many piles of shrooms of similar magnitude in around our house and, even, in the neighborhood.

Fungus is awesome stuff. Lurking about under the soil until the fruiting conditions are just right and then — boom — shroom city!

I reprocessed this particular photo with Aperture 2.0 using the RAW 2.0 processor combined with the various other tools. The results are far, far more pleasing (to me) than anything I could have done with Aperture 1.x.

Awesome update. Congratulations and a huge thank you to the team that worked so hard on it!!

This was the first photo that I shoved through the Aperture 2.0 pipeline. I really wasn’t happy with what I could do with it in Aperture 1.x; it just didn’t feel right.

It was striking how different the result was from simply switching to the 2.0 RAW processor. The background was brighter and there was considerably more gradation in the color fringes on the out-of-focus lights. From there, I could increase the contrast and still maintain the shades of white on the lights.

Or something like that. I’m pretty clueless about this stuff, but I totally dig Aperture 2.0. It just feels more efficient and more effective.

When analyzing an Objective-C application with Dtrace, one big challenge is how to introspect any objective-c objects that are passed as parameters into the various trace points.

While you can use the Objective-C provider (documented on the dtrace man page) to trace particular methods of specific classes, it doesn’t really help for actually introspecting an instance or class.

By “introspecting”, I mean “printing out the damned class name”, for example.

Full monty on the click through.

Read the rest of this entry »

Jim Correia asked on cocoa-dev:

Can you offer any advice for the times when I must write my own accessor, but want it to have similar behaviors to the autogenerated accessor? In particular, I’m thinking about the default atomic behavior. Is this simply wrapping the work in a @synchronized(self) block? Something else?

First, some context. Jim is referring to Objective-C 2.0’s properties and, more specifically, to the behavior of methods automatically synthesized by the compiler.

By default, synthesized accessors are atomic. Atomic does not mean thread safe.

Read the rest of this entry »

Update: CocoaHacks was quite a bit of fun. Not only did I demonstrate the rather silly little hack, but I ran it fully garbage collected. With one simple change (that should be in the next release), the MacFUSE framework works just fine with Garbage Collection enabled!

The best compliment came from Amit Singh; something along the lines of “That is absolutely the strangest filesystem I have seen.”

In any case, my little hack repository has been updated to be GC only. retain/release/autorelease/dealloc are dead to me (in this project, anyway).

If you want to build MacFUSE with GC enabled, simply set Objective-C Garbage Collection to “Supported” in Xcode in the MacFUSE framework project’s build settings.

At left, is a screenshot of the Finder browsing the Objective-C classes active in the runtime of a little Cocoa app that I wrote this evening.

The little app is called RuntimeFS and it contains a simple bit of code that traipses through the Objective-C runtime and collects information about the Objective-C classes encountered. This information is then barfed up by the elegantly simple delegate like API required by MacFuse to create a filesystem.

Let me restate that: MacFuse kicks ass. The Objective-C API is trivially easy to use. Trivially easy. I implemented this little hack in less than two hours, not having looked at the MacFuse API before. Nor did I read the docs; just looked at this example and one header file. I have implemented filesystems in a couple of different languages. Filesystems are hard. Or was. Not anymore.

I dropped the source code in the “Silly” directory of my public SVN repository.

Because, really, this is quite a silly hack. And hack it is — it doesn’t crash, but that is about all the quality assurance analysis I have done.

Free as in “MIT License” free. Have fun. I’m accepting patches, of course.

Future Stuff

If I were to go anywhere with this, the first thing I would do would be to move the subclasses into a subdirectory and then add other subdirectories to contain additional data.

Specifically, I would add directories like -1- Instance Variables, -2- Class Methods, -3- Instance Methods, -4- Subclasses, -5- Documentation (or something), etc…

The naming convention serves two purposes. First, it sorts nice like. Secondly, the names are invalid as class names and, thus, it makes handling the metadata vs. class directories trivially easy while also eliminating potential namespace conflicts.

In Leopard, Apple added a new tool to the developer tool suite called Instruments. It is a timeline based debugging and performance analysis tool. With a full suite of tools to analyze all kinds of dimensions of performance, correlating all data onto a timeline that can be inspected and navigated at will. And it remembers prior runs so you can compare results before and after changes.

And it fully consumes dtrace.

Clicking through the screenshot at right will show a run of Instruments with a single analysis instrument active.

I created a custom instrument that encapsulates the dtrace script I discussed in Objective-C: Using dtrace to trace messages-to-nil.

I ran the resulting instrument against TextEdit.

What can’t be conveyed by that screenshot is exactly how “live” the data can be examined. You can click and drag on the timeline to select a subset of the run, details of the selected instrument are shown in the table in bottom right, and any given row can be selected to show the backtrace active at the time the sample was taken.

I didn’t want to clutter up the screenshot with lots of data and, thus, didn’t demonstrate the awesomeness that is being able to relate data across multiple instruments, correlated by time.

That’ll be in the next Mac OS X / Software related post.

Click on through for an explanation with screenshots as to exactly how to convert the dtrace script to an instrument.

Read the rest of this entry »

Update: There are [at least] two different Objective-C messagers. objc_msgSend() and objc_msgSend_stret(). All of what is written here applies to both however objc_msgSend_stret() is the problematic one when it comes to messages to nil; it is the one used to return structures and, thus, the one that does not necessarily guarantee a zero return.

In my last post on the subject, Adrian Milliner posted a short dtrace script that would log the backtrace for all invocations of objc_msgSend where the first paramater — the target — was nil.

The script is as follows:

pid$1::objc_msgSend:entry
/arg0==0/
{
  ustack();
}

Once saved to a file (in this case objc-nil-trace.d, the trace can be applied to any running Cocoa process via:

sudo dtrace -s objc-nil-trace.d <pid>

The <pid> argument should, obviously, be the process ID of the process to be traced.

It works well enough and is certainly faster than a conditional breakpoint in GDB (likely, orders of magnitude faster), but it is far from a complete solution.

Read the rest of this entry »