Deja Blabspace

Well Apple finally released the iPhone SDK and it’s pretty darn cool. Like many others I had some trouble getting my hands on it initially due to problems with Apple’s web infrastructure (ever heard of scalable architectures guy?). Anyway Apple seems to be setting up the distribution properly, selling iPhone apps at a 70/30 split with the developers getting the bigger chunk. This is a much better deal than you will find at say, the AT&T MEdia Mall… cell carriers tend to give you an even split at best.

So far I’ve managed to get an app running in the iPhone simulator, but I’m a little disappointed that Apple has chosen to limit access to their paid developer program, at least for now. What this means for me (and other potential independent iPhone developers) is that I still can’t run my code on an actual iPhone. This kindof sucks, since what I want access to is the accelerometer data, and that doesn’t appear to be supported in the simulator, even in awkward or roundabout ways. So I guess I’m still stuck for now unless I want to jailbreak the phone, which I would prefer not to do.

Hopefully Apple will process through the backlog of developer requests and agree to take my $99 soon. Until then I will keep learning about audio and other aspects of the iPhone that I can explore in the simulator.

I managed to learn enough Cocoa to create my first real Mac application. It’s a simple little thing that reads the accelerometer values in the laptop and displays them in a window. Here’s what it looks like:

This is a big milestone, now to play with audio!

If you’d like to try the app on your own Mac laptop you can download it here. I only tested it on my MacBook but it should work on any MacOSX laptop running 10.4 or higher.

Looks like I’m not the only one thinking about the iPhone as a potential musical instrument:

http://www.youtube.com/watch?v=x74rvGzfWYE&feature=related

A very cool idea, but it seems like a better learning tool than it does an instrument for performance. Anyway I had better get busy!

I know what you’re thinking, it’s been months and I haven’t found time to experiment with the PICs. You’re right, but one of the projects that originally got me interested in PICs was building an accelerometer-enabled musical device, and I’ve recently stumbled onto new technology that should allow me to do this in the software world. Writing software is really a lot more up my alley than building hardware, so this might be a much easier path to getting the gadget I want.

The technology I’m talking about is the iPhone, and its counterpart the iPod Touch. Both of these devices have on-board accelerometers and sound-generation capabilities. Apple has been dragging their feet on releasing an SDK for these platforms, though, so there is currently no legal way to write these apps, but that hasn’t stopped those who are hardcore.

There is a community of folks who’ve already cracked these devices and figured out the frameworks used for native applications and mapped all of the native calls. This is all the info you really need to write native code for the device, and that’s what many of them are doing. In the course of learning about this community and their amazing work I discovered that the iPhone uses Cocoa for native apps, the same framework used in MacOS X, coded in Objective-C, so it seems like there is a lot of crossover between writing Mac apps and iPhone apps.

So far the source files I’ve looked at for iPhone apps developed by the hacker community look very similar to the source for a Mac app, the only difference appears to be a separate object tree but with very similar objects (NSApplication becomes UiApplication, etc). I’m hoping that this means that time spent learning to code Mac applications will be time well spent when I can actually start coding my app for the iPhone.

There is also the business of learning the audio APIs in order to generate the sound. In my Mac development explorations I’ve learned that this is normally the domain of a software module called an Audio Unit (AU) which is a plugin format that many Mac users will already be familiar with. Apparently the application framework makes it fairly easy to use audio units within your app, so this is another area to explore for the sound generation part of the application. Hopefully the mobile APIs (if and when they are released) will also support Audio Units, but even if they only have general MIDI there are a lot interesting things one could do.

So far I have to say the Mac programming environment is a very different style than the Microsoft one. They do all of the same things, pretty much, but the way they get around to doing it is a different mindset. Cocoa feels very lowercase, whereas the Microsoft stuff is all very uppercase, if you know what I mean. I guess that makes sense when you consider that Cocoa comes from the very unixy NeXTSTEP line and the Microsoft stuff has a bit of VMS in it. Anyway it has been nice to see how the other half lives, I hope I continue to enjoy it as much as I have been lately

I got two PICs this week from Digikey (see this picture of the PICs in tube packaging), but as it turns out there is a lot to know about PICs and how to write code for them. It took a lot of web searching and poking around to find the right C compiler.

I should probably start with the basics. As it turns out there are several families of PICs made by Microchip:

• Baseline (PIC10, some PIC12, and some PIC16s) - The oldest PIC tech. Extremely cheap but the specs suck regarding memory and ease of use. The real distinguishing characteristic is that they use 12-bits to store opcodes and their arguments, 8 bits for addressing (or other args) and 4 bits for the instruction itself. Not what you would call robust, but for some applications it would be more than enough.
• Midrange (PIC12, PIC16) - These are a step up from the baseline in that they now use 14 bits for opcode and args, so the amount of directly addressable memory goes up quite a bit. There is a lot of info and tutorials, etc, floating around the net on these PICs as they’re very popular among hobbyists.
• High End (PIC17, PIC18) - Now we’re up to 20 bits for opcodes and args, starting to look more like a ‘real’ computer. These PICs have also grown up enough to have a decent hardware stack and other features to make it more friendly to C compilers, which is why I chose this class.
• Cutting Edge (PIC24, dsPIC) - These are true 16-bit architectures, so it’s a bit like having a first generation PC on a chip.

If you’re writing your code in assembly there is a lot of common ground in the tools you would use, it seems like MPASM (the assembler that comes with the MPLAB IDE) can build code for all of the devices. If you’re looking to write code in C, though, each family of chips has its own set of tools, and sometimes multiple set of tools from different manufacturers. All of the tools offered by Microchip are available at this URL.

In order to write in C for my 18F4320 chips I needed to download the C18 Compiler from Microchip. This is a commercial product, but there is a student version available that’s fully functional for 60 days, and even after 60 days the only thing it does to cripple you is to take out certain code optimizations.

The documentation is pretty good so far, I decided to start in the logical place, with the Getting Started Guide. Researching all of this stuff has been a long process and I’m excited that I’m almost to the point where I can write some code and flash it to the PIC!

I ordered two PIC18F devices from Digikey, part number PIC18F4320-I/P. These PICs appeared on the kitsrus.com list of supported PICs for the K128 programmer, which is the one I got from Carl’s Electronics. Here is the datasheet for that PIC. This is also one of the PICs that you can code in C, so that might end up saving some time.

I am now officially learning Flash.  Adobe has provided a pretty nice IDE for it in their CS3 suite, so far I’m impressed.  In addition to the manual Adobe is now providing video tutorials, which are actually pretty helpful when you’re trying to get the general idea about how the program works and where things are.  They don’t get very in-depth, though, so you’ll still need the manual.

I’m interested in building games, so I also found the Flash Games Wiki to be very enlightening.  They have a good article on collision detection, which seems like the first major problem in developing a Flash game.

Now that I’ve got the programmer and some spare time I decided to download and start playing with Microchip’s MPLAB IDE for writing PIC code.  Although the software is free I found it a bit difficult to find on Microchip’s website, I had to search via Google to find the download.  If you need it, you’ll find it here.

MPLAB includes the assembler necessary to build the binary files that get flashed on to the PIC chips.  I’ve only started playing around with it, but I did find a nice tutorial on PIC assembly to help me along. So far I’ve managed to compile the code in the tutorial that flashes an LED on and off, but I haven’t picked a PIC yet, so no code has been flashed or tried.  I may go over to HSC tomorrow and see what they’ve got.

Well I managed to finish assembling my DIY 149E, but when I finally plugged it into the USB port on my laptop I got a ‘USB Over Current’ message and the port was promptly shut down. I figured that I had probably shorted the USB connector, so I checked the soldering job on the connectors, scraped away a tiny bit of solder and retried it, but I got the same results. At this point I figured that the short may well be on the other side of the board, and that I should pull the USB connector off the board and try again. The only problem was that I was already a bit tired and burnt out from all the assembly, so I decided to say fuck-it and buy a PIC programmer that’s already assembled.

I know this is really sheer laziness, but putting the thing together isn’t really what I wanted to do in the first place, though it was fun in that twiddly sort of way. What I really want is to be able to put code on PICs and use those PICs in more interesting projects. It’s worth it to me to have a programmer that I know should work well, especially while I’m still learning.

So what I actually ended up with was the DIY 128 kit, pre-assembled from Carl’s Electronics. I just received the programmer today, and it’s a much more compact design which should fit my needs nicely. It is also powered by the USB itself, so no need for a power supply. In short, a neat little portable programmer.

Carl’s did a great job assembling it and even provided a little protective case. All I had to do was insert the firmware IC into the socket. Yay! Now I can move on to actually making something useful with it

Lately I’ve been very interested in building electronic toys and gadgets. A few weeks back I started noticing that people are using accelerometers for some interesting projects.  One in particular that caught my eye was Mobzombies, a game that runs on tiny mobile PCs in which you avoid the virtual zombies on-screen by moving in real physical space.  Using accelerometers the tiny PC can keep track of exactly where you’re moving and use that as a human interface device for the game.

After watching the video on the Mobzombies site I couldn’t help but think that playing the game is very impractial… what if there’s a wall where you would need to go to dodge a zombie?  Seems like one could easily fall down some stairs or trample someone while focused on the game.  The idea, though, is very intriguing.  I decided to come up with some potential projects of my own to take advantage of this technology.

As I began putting ideas together it occurred to me that I’d like to be able to make inexpensive toy-type devices that would not require something as powerful as a mini-PC to run them.  This is what led me to discover the wonderful world of programmable interrupt controllers (PICs).  PICs are great because they are cheap (generally less than $10) and can provide enough processing horsepower to run any of the toys I’ve been considering making.  They come in hundreds of varieties, and some even include cool things like analog-to-digital converters (ADCs) and serial interfaces for communicating with other chips or even a PC.

As I did more research I found out that the device you need to put your code on a PIC, the ‘programmer’, was a pretty expensive piece of hardware (starting at around $400).  I did notice that there were kits available to build your own programmer, so that’s where I decided to start.

I was pleasantly surprised to find that my local Fry’s Electronics actually had one of these kits in stock.  The one I ended up with was the DIY 149E, which seems to be the design that everyone selling PIC Programmer kits is using. Despite what the instructions say, putting this device together is a bit of challenge for a novice like myself.  There are about 100 things that need to be soldered to the board provided in the kit, so it just takes quite a bit of time even if you’re already good at soldering.  At this point I’m about 90% finished mounting the components.  Once I’m finished building it I’ll need to get it working with the PC via USB interface, and then I can actually starting writing code for these devices.

The programming environment is a fairly simply assembly language, these PICs seem to have about 40 or so instructions.  I’ve done assembly stuff before so this shouldn’t be a huge obstacle, but at some point I might opt to find one of the C compilers that will generate PIC code.

Some projects I’d like to try when I get it all working:

• A box which generates random melodies in particular keys, and outputs via MIDI or an onboard sound chip
• A device with an LCD, VFD, or TFT display that uses an accelerometer to give the user a ‘window’ into an invisible virtual world that moves as the device moves
• A 3D pointer device that could interface with a PC via Bluetooth and be used to manipulate on-screen objects in a 3-dimensional virtual world, and possibly used as a game controller