I have a little bit of experience with embedded projects (although it's been a while) so I thought I'd chime in on what I'm familiar with. Forgive me if some of my advice you already know.
My first and most important piece of advice is that datasheets are your friend. You'll be using them a lot.
Octacone wrote:
4. How hard would it be to hook up some external RAM, flash storage, some other fancy peripherals to it?
It entirely depends on the peripheral and interface, especially since you say you want to avoid any third party libraries. External RAM / flash with a parallel interface is about as easy as it gets. For parallel SRAM (which is what I'd recommend) you just connect the address lines to some of your chip's I/O and read / write the data via some other I/O. You'll need a few other I/O pins for control signals and off you go. Parallel flash is just as easy to read and only marginally more complicated to write data. You generally have to erase either the entire chip or the page that you want to write first. Then you send the chip a short sequence that says you're about to write data to it and away you go. Again, datasheets are your friend here.
Digikey and
Mouser both have nice search features you can use to find parts (I like digikey's just a little bit better). It's easy to find parallel SRAM or flash up to 4 Megabits in a DIP package. The AS6C4008-55 is a good choice at the high end for SRAM and the SST39SF040 is a good flash chip. The latter has a 5v interface though, which could be a problem depending on what microcontroller you pair it with. Bear in mind that memory chips are usually spec'ed in terms of bits instead of bytes.
Also, bear in mind that microcontrollers usually employ a Harvard architecture, which means they will only be running code directly from their internal flash memory, so you can't rely on external memory for that. In practice though, it's very unlikely that you would need to.
I²C is probably the second-easiest way to interface peripherals, and many chips will have some kind of built-in support for this. It's also pretty easy to bit-bang.
Octacone wrote:
3. Has anyone tried writing an embedded OS for such a device? I guess it doesn't really need one, since it is a microcontroller.
5. Is it capable of software multitasking?
Look into
FreeRTOS.
You might also want to take a look at the embedded project that first got me interested: the
Uzebox. This employs a special-purpose kernel which draws graphics and plays sound and allows game developers to write games in C. It also has a very nice community around it.
Another piece of advice I have is once you've picked out a potential chip, you should make sure you can setup a toolchain for it and successfully compile a project. Sometimes the software is the weak link with embedded devices and you don't want to find that out after you've waited for a chip to be delivered and designed and built your hardware around it.
Also, make sure to find the errata for that chip and read it. Some errata will even make certain features completely unusable but the manufacturer's marketing is still not above listing those features in the product specs or datasheets (Microchip is particularly guilty of this).
Octacone wrote:
PIC programmers seem to be really expensive, looks like I'll have to make my own. Any suggestions? What should I be worried about?
Bootstrapping is one of the most tedious things to do. I have actually made my own JTAG programmer which I used to install a bootloader on a PIC32 which allowed for uploading code via USB. Keep in mind that if you go this route, you'll most likely need to make your own software and hardware to upload the bootloader to the chip. Once you've accomplished that though, the rest is easy. The Microchip documentation for device programming and bootloading is really good, and if I recall correctly, they give you all the source code and software you need for a USB bootloader. It's still a lot of work, however. In practice, you only need to use JTAG or ICSP to get the bootloader programmed, then you probably won't need to use JTAG or ICSP anymore, so it's a lot of work just to avoid buying a dedicated programmer.
I can elaborate some more on this if you think it would help, but after shelling out $50 for the PIC programmer, I personally think it's well worth it. I don't know if there's the kind of command-line support you'd want for it though. I do know that you can get that kind of support with AVR chips, and for those you can build or buy a very cheap (but slow) programmer that uses some kind of USB-to-ttl cable.
Octacone wrote:
I guess they would require some complex circuitry in order to get them to work on a perfboard.
It's really not too complex. A good datasheet will give you a minimal circuit to get the chip up-and-running. It's usually called "typical application" or "basic connection requirements." For example, the datasheet for the PIC32MX1XX/2XX 28/36/44-PIN FAMILY (I just chose that at random) has all you need to know under section 2.0 Guidelines for Getting Started with 32-bit MCUs. You typically just need a few capacitors and maybe a couple of resistors. Slower chips and 8-bit chips tend to have less external requirements, but even a fast, 32-bit chip won't have many critical requirements. A high-speed PIC32 does require a single tantalum capacitor that needs to be installed very close to the chip, so putting it on the other side of the board directly under your chip might be necessary. This is all spelled out in the datasheet.
Even if it isn't called out specifically in the datasheet, you always want to use at least one
decoupling capacitor for every chip in your circuit. This is just a capacitor between VCC and GND that you put as near the chip as possible, typically in the range of 0.1uF to 1uF (the exact value isn't very critical).
My final piece of advice is don't try to use a crystal to build an oscillator circuit, especially if you don't have a scope. Instead, just spend a little more ($2) and buy an "oscillator" in a package. I don't know why more people don't do this. This will save you all the headache of calculating load capacitors (which you really can't do accurately with a prototype anyway) and will eliminate a potential problem that is nearly impossible to diagnose without an oscilloscope.
Hope some of this helps you. Hardware development is lots of fun!
Cooperative multitasking is very easy to implement but requires tasks to return control to the scheduler. It has the problem that if one task gets into an infinite loop, the whole system is stuck. Preemptive multitasking is the better type for an actual OS, a physical interrupt returning control to the scheduler regardless of what the user code is doing. I guess preemptive is probably easier to debug for the same reason. Cooperative multitasking makes IPC simpler.