Slashdot Mirror

Eh... what??? It's already been done, been available for years. Nearly all the popular PIC microcontrollers and the AVR microcontrollers have Flash, CPU, and static RAM on chip.

Granted, those are 8-bit processors with no more than 64k or so of Flash, and no more than a few Kb of SRAM, but they're surprisingly powerful and useful. You can get 'em in clock rates of 50 MHz or more and all kinds of nifty on-chip peripherals are available... my favorites are the on-chip ADC and USB controllers! Plus the whole thing can be had for about $3, and Microchip (which makes the PIC) is *amazingly* generous in giving away free samples to anyone who asks (I've gotten so many of them I actually feel a bit guilty!).

You *ARE* correct that having external address and data lines does take up a lot of pins on a microprocessor. Having the memory onboard with a microcontroller is very nice, greatly reduces pin count. My favorite AVR microcontroller is available in a 28-pin DIP package, which is great for prototyping, and up to 25 of those pins can be used for general purpose digital I/O. Handy that!

Frankly, I don't see a great advantage to combining something like a 32-bit ARM CPU with a few megs of Flash and SDRAM in one package. The development of those products is inevitably more expensive and complex than for simpler 8-bit embedded systems. And as you say, different products are required to produce them. Most of the integrated applications seem to go in a slightly different direction: for example, many companies today sell a wireless-router-on-a-chip which combines a MIPS or ARM CPU, ethernet switch, DRAM controller, and 802.11g transceiver. Just add Flash, DRAM, and baseband wireless :-)

Like these?

http://www.atmel.com/products/AVR/

256-Kbyte self-programming Flash Program Memory, 8-Kbyte SRAM, 4-KByte EEPROM, 16 Channel 10-bit A/D-converter. JTAG interface for on-chip-debug. Up to 16 MIPS throughput at 16 MHz. 1.8 - 5.5 Volt Operation.
64KB/100-pin version: ATmega640
128KB/64-pin version: ATmega1281
128KB/100-pin version: ATmega1280
256KB/64-pin version: ATmega2561

64-Kbyte self-programming Flash Program Memory, 4-Kbyte SRAM, 2-KByte EEPROM, 8 Channel 10-bit A/D-converter. JTAG interface for on-chip-debug. Up to 16 MIPS throughput at 16 MHz. 1.8 - 5.5 Volt Operation.
100-pin version: ATmega6450
32KB/64-pin version: ATmega325
32KB/100-pin version: ATmega3250

The novelty of GNU Radio is that instead of just the HDTV decoder being software, the tuner is too. If the application(TV, fm radio, HDTV, etc) you want falls inside the frequency range your hardware can sample, you can build a software tuner. The novelty of this hardware is that the cheapest prior solution started in the several of thousands -- generalized a/d converters intended for scientific data sampling, like: http://www.atmel.com/dyn/products/devices.asp?fami ly_id=611

Why not make a CPU with a built-in FPGA, then load bits of the kernel into that hardware?

Call me crazy, but that might be more efficient than just throwing more cores at the problem.

Here's one: Atmels' 20 MIPS processor + FPGA

The problem is, fast processors are now SO cheap that the applications for a part like this are incredibly limited - you end up with the wrong FPGA and the wrong uP for more than it would probably cost you to buy the right architecture as discrete chips.

Maybe you'd be also interested in Atmel's AVR broad line of 8-bit RISC processors. You can find more information here.

IMHO and compared to PICs, they have a very clean architecture (=> smaller code size & a rather high speed for 8-bit uCs). There is also a GNU GCC port which AFAIK does not exist for PIC processors.

No, I don't want to start a flamewar, and no, I'm not an employee of Atmel, just a hobbyist using their uCs :)

This is great and all, I just don't see why this is front page news. I would consider ARM-DSP hardware with Linux support mainstream rather than a bold step taken by TI. A random grab from sponsored adds on google:
http://www.sandorlabs.com/
http://www.compulab.co.il/
http://www.plexxa.com/
http://www.atmel.com/products/AT91/
http://www.xbow.com/
http://www.lynuxworks.com/

All products seem to support Linux on ARM/XScale and (at least) some in combination with a DSP.
Sure, Texas instruments is a heavyweight in the embedded world, but is this just another clueless ScuttleMonkey post or did I miss something?

You didn't mention the kinds of noise you're interested in keep out, or what kind of data your sensors return. I will therefore assume, "all" noise and many kinds of sensors.

The best approach to keeping something as electrically noisy as a PC from spoiling your results is to put it in another room and connect it only with radio or light. This also addresses the sound issue.

If the bandwidth on your sensors is low enough for RS-232 serial data, then you're in luck, dozens of manufacturers sell simple in-line isolators like this.

If the cable it's running through is still picking up too much noise then using fiber converters on both ends (like this) will let you bridge the gap with glass which is pleasantly resistant to electrical noise.

If you're currently capturing your data with a bunch of low sample rate A-D converters, and have a large wad of sensor lines going to the attachment-pod on the PCI card, now would be the time to get your university's micro controller enthusiasts to create a sensor polling device. On something like the Atmel 8515.

Such a sensor converter will run for days on batteries, and produces very predictable low amplitude noise that is easy to isolate. It comes with an 8 channel 10-bit A-D, and the best part is they are available in an easy to breadboard 40-pin dip for $4.58 through digikey (here search on ATMEGA32-16PJ-ND).

If the bandwidth of your sensors is too great for RS-232, the same tricks can be played with RS-485 transceivers which will do speeds into the megabits, and are available as cheap dip packages.

For speeds beyond the few megabits realm a "custom data gathering CF card" and a Wifi capable IPAQ running Familiar springs to mind as a good starting point. But here we're getting into the question of "What exactly is it you're doing on the Windows box?"

--Art

Amen.

See this closeup of CPU with heatsink removed: http://xbox360.1stgame.nl/13.html

and accompanying EEPROM datasheet: http://www.atmel.com/dyn/products/product_card.asp ?part_id=3035

Most anyone (here (I'd hope)) can build a working galvanic vestibulator in their home for under $5. It's just a 0.1hz~70hz squarewave sinking ~20 milliamps of current through your neck. You can easily do that with a 555 in astable mode (R1=2kOhm,R2=26kOhm,C=.1uF--it'll have a frequency of about 27hz and a duty cycle near %50), a 9v battery or two, some pennies, cotton, and a bit of saltwater. Place the ghetto electrodes beind your ears. Play with the frequency in the above range by using knob potentiometers. I've found ~15-30hz to be best.

Even more fun can be had with a cheap Atmel ATtiny2313 8bit microcontroller (or PIC if you're that type). They cost about ~$2 each but you can sample them from large manufacturers for free (I've sampled 9 ATtiny2313 for free now). They can be programmed right from the serial port in simple (you can ignore the LEDs, but hey leave them in and you have a persistance of vision toy too), or slightly less simple manners.

If you just want to test the effect out then just the 9vs, a few pennies, some cotton, salt water, and a little wire will do. Simply series the batteries and make electrodes out of the materials previously mentioned, warm water works best. Apply the electrodes to your mastoid proccesses and you'll feel the 'acceleration'...and a bit of stinging, but not too bad. (It'd be best if you had a soldering iron, but you could go without if really needed.)

• comp.arch.fpga Google archive of Usenet groups, where people interested in FPGA hang out.
• Opencores A set of free IP cores that can be implemented in FPGAs
• Comprehensive tutorial on FPGA
• A comprehensive list of FPGA CPUs
• A good FPGA tools overview
• FPGAworld news, jobs, forums, demos etc.(http://www.fpgaworld.com)
• FPGA Basics by Ray Andraka
• Fpga4Fun various fpga projects
• FPGA Boards
• AP100 PCI Platform FPGA Development Board
• Information about signal processing on FPGA by RF Engines
• FPGA manufacturers
  • Xilinx Xilinx has traditionally been the FPGA leader. Their general philosophy is to provide all the features possible, at the cost of extra complexity.
  • Altera Altera is the second FPGA heavyweight. Their philosophy is to provide the features that most people want while keeping their devices easy to use.
  • Lattice Lattice's focus is on low-cost, feature-optimized FPGAs and non-volatile, flash-based FPGAs.
  • Actel (http://www.actel.com/) and QuickLogic have antifuse (programmable-only-once) products.
  • Cypress
  • Atmel
  • Debian FPGA.

How does 2048 bit RSA on a SecurCore ARM processor sound? Sounds good to me.

What makes this robot unique is the use of the Kondo ICS-KRS series of servo motors that provide feedback not just PWM-based position control. Many hobby roboteers would be glad to learn about dozens of servos on the market that give you position feedback without having to hack the heck out of the servos and possibly insert a tiny15 into the gearbox in order to get some position feedback.
There are a couple of Korean companies that make servos that are communicable via serial, these are Robotis and Megarobotics. Probably all other servos on the market are one-way controled by PWM.

The schematic of the Replica I is very interesting. There are three processors on the board -- there is the main 6502, of course, but the keyboard and the video output get their own processors. I thought it would be neat to compare how they stack up...

Main processor:
6502 @ 1MHz. 32K SRAM, 8K ROM.
0.3-0.5 MIPS, 3 registers + 256 zero-page registers

Keyboard processor:
ATMega8515 @ 8MHz, 512 bytes RAM, 8.5K EEPROM
8 MIPS, 32 registers, hardware multiplier. Would be 16 MIPS if a faster crystal was used.

Video processor:
ATMega8 @ 14.318 MHz, 512 bytes RAM, 8.5K EEPROM
14 MIPS, 32 registers, hardware multiplier.

So, basically, the auxillary processors are 20-40 times faster, more powerful, and have the same ROM size as the main processor. But, this is the way iit had to be -- it would have hard to find a modern microcontroller that is significantly slower than the 6502.

The schematic of the Replica I is very interesting. There are three processors on the board -- there is the main 6502, of course, but the keyboard and the video output get their own processors. I thought it would be neat to compare how they stack up...

Main processor:
6502 @ 1MHz. 32K SRAM, 8K ROM.
0.3-0.5 MIPS, 3 registers + 256 zero-page registers

Keyboard processor:
ATMega8515 @ 8MHz, 512 bytes RAM, 8.5K EEPROM
8 MIPS, 32 registers, hardware multiplier. Would be 16 MIPS if a faster crystal was used.

Video processor:
ATMega8 @ 14.318 MHz, 512 bytes RAM, 8.5K EEPROM
14 MIPS, 32 registers, hardware multiplier.

So, basically, the auxillary processors are 20-40 times faster, more powerful, and have the same ROM size as the main processor. But, this is the way iit had to be -- it would have hard to find a modern microcontroller that is significantly slower than the 6502.

Here are a few companies already producing silicon:

Chipcon
Freescale
Atmel
CompXs

Just FYI

A lot of the companies involved in space hardware do really cool stuff. (No pun intended. :) Atmel are not the cheapest company around, but then they sell stuff to the ESA and NASA, so why would they need to care? Even so, I wish they were a bit more geek-friendly.

I this case they made a small module with an ARM7 on it - running a .net runtime.
Did you even read the article :)

Anyway. There are some of this kind of modules around - some with java runtimes.

Atmel has a series of small footprint risc processors with flash, eeprom, sram and various pheripheral io. Easy to program, easy to use.
http://www.atmel.com/dyn/products/param_table.asp? family_id=607&OrderBy=part_no&Direction=AS C

There is also a 6 pad PIC processor http://www.microchip.com/stellent/idcplg?IdcServic e=SS_GET_PAGE&nodeId=2060

None of these runs .net or java as far as i know, but this would be a nice christmas project ;)

Lego Mindstorms can be a great way to start. But it can be limiting. It comes with only 2 motors. It can control only 3 motors and have 3 sensors. The programming environment can be limiting too, but there are other options on the web to help.

If you think your friend would be interested in something a little more complex, I can point you to some other resources...

There are some robot kits on the market. A pretty good one is: SumoBot Robot ~$150

Or you could get a platform and controller board seperately:
Tracked Motorized Platform ~$60
Controllers The OOPIC II Starter package ~$70 is a decient starter

A number of hobby clubs in Colorado like the Atmel Atmega Microcontrollers for building custom robot board such as the DARC Board.

The Portland Robot Group has a lot of great information for people starting out with hobby robotics.

My robot blog with lots of pictures.

The HC11 has been nearing the end of its life for years now. You'd be nuts to use that chip in a new design.

Consider using an AVR chip. Its a nice, modern RISC (32 registers, compared to the shitty HC11's handful). They are much cheaper, have a shitload more memory and peripherals, and tons faster (16/24 MIPS). Even a common-as-dirt PIC chip would be better then this.

The tools are much better for PICs and AVRs because they are much more popular.

Atmel (http://www.atmel.com/) produces chipsets for GPS units. I'm sure other manufacturers have similar products.

Before you start working on something this complicated, you should make sure that you have access to the necessary technology. You cannot design, assemble and test GHz equipment at home.

If, on the other hand you just want something cheap to play with, you should Google for a GPS module. These are complete GPS units, integrated on a small PCB. As they are intended to be built into other systems, they don't usually have their own power supply, the UART is TTL or CMOS level (requires a MAX232 to connect to a PC), and needs an external antenna. Getting one of these to work is not impossible, even with very simple equipment (breadboard/soldering iron).

• Package size: The AT91SAM7A is impressive in how much it packs into a 64-pin TSSOP package, but Atmel's 8-bit ATtiny15L is also impressive in what it packs into an 8-pin SOIC. And if that's too big, Microchip just released the PIC10F 8-bit microcontroller in a 6-pin SOT23 package. Don't sneeze.
• Price: 8 bit MCUs are still cheaper, most under $1 in quantity, while the AT91SAM7A is $3 in quantity.
• Power supplies: The ATtiny15L works with one supply between 2.7V to 5.5V, so it could run off a loosely-regulated supply, or straight off batteries, eliminating the need for a regulator. The AT91SAM7A needs a 3.3V core supply, and a second 5.0V supply if any of the I/O pins need the higher voltage. There are some parts that you still can't get in 3.3V.
• Power consumption: That ATtiny15L takes 3.0 mA active and 0.001 mA sleeping. The AT91SAM7A uses 0.24 mA sleeping and up to 78 mA when running (those figures are buried in the full data sheet). Good to know when battery life is an issue.
• Compiler support: both ARM and AVR architectures are supported by GCC.
• Architecture: Both AVR and ARM architectures are RISC architectures.
• Clock: The AT91SAM7A can run up to 8 MHz with an external crystal or 30 MHz with an external oscillator (using an internal PLL). The AVRs can run to 8 MHz on an internal oscillator (no extra parts) or 16 MHz from an external oscillator (though the ATmega26 has a trick where you can run at 16 MHz from the internal oscillator).

I would have loved to compare to the AT91SAM7S described in the article, but data sheets weren't available on the web site. All that said, I think the more impressive product is on the horizon: the AT91SAM7X series with built-in Ethernet.

Best of luck to the uClinux folks trying to pack everything into 64K of RAM. I've never tried to use less than 1 MB. A better choice, IMHO, would be something like eCos, which can be stripped down more, because in embedded systems, you don't always need a POSIX-style file system hierarchy.

While there have been many advances in 32-bit MCUs, it would be foolish to assume that the 8-bit MCU market is still stuck in the land of the 6502/8051/6800 CISC architectures. It's had its share of advances as well. And nobody really wants to use a 32-bit MCU for a mouse or keyboard.

I have to point out the incredibly useful Atmel AVR series of microcontrollers. Inexpensive ($2 to $8 each), easy to program (there's a GCC port readily available), entirely Flash-based, and pretty powerful for eight-bit microcontrollers. There's a large hobby development community over at AVRFreaks; if you're interested in homebrewing some great projects, check it out!

The HC series of microcontrollers ..

I was referring to the 74HCxxx series of logic chips, which cost cents each but are a little bit more modern than a power hungry 555.

I defy you to find a microcontroller at that price

The lowest cost 8-bit microcontrollers by Atmel, Microchip, Ti, Motorola are around 1$ or less. And you already get quite a bit for that amount of money. Motorola announced the first MCU priced 50cents in high volume years ago.

For example the Atmel 90s1200 should be around 1.30US$ in single quantities. 8 Pin microcontrollers (ATTiny 11, PIC12C509) are even cheaper.

Your idea of using surplus is only good is you have whatever said surplus already laying around. I don't happen to have any of the old parts you mention (gameboys, zip drives, scanner, etc.) lying around, or you have a large enough surplus supply (electronic goldmine, ocean state electronics, ebay but prices get whacked quickly) on the market.

Experimenting with cheap 8-bit microcontrollers such as Microchip's PIC or Atmel's AVRs is quite cheap, and typically all you need is a chip and one (really cheap if want) device - a programmer to transfer the (binary/hex) programs from your PC to the microcontroller's flash memory.

You will quickly outgrow Radio Shack unless you need a part right now and you don't have the right one in your own stock pile, often referred to as a "junk box" regardless of actual physical size. You should be getting the free catalogs (or CDs) from Digikey, Mouser, Newark, and Jameco. These all have usable online ordering systems and reasonable minimum order & shipping fees. UK geeks check G3SEK's UK Component and Tool Suppliers web page.

Many useful projects can be made for less than $100 even if you need to buy all the parts. After you build a collection of common parts (common resistors, capacitor values, PIC 16F628, AVR AT90S2313, red & green LEDs, 2N2222A, 2N3904, 2N3906, 2N4401, 2N4403, 2N4416, 4N25, 1N4148, 1N4001, 1N4007, etc.) and tools this cost will go down.

The real question is do they assume a general audience or do they assume a "knowledgeable user" is their target market? If the stuff is purely "cookbook" & kit building (AmQRP kits as an example) with little or no encouragement (and knowledge transfer) for the average Make reader to explore and expand it won't survive IMHO. BTW AmQRP kits on their own are pretty limited at expanding your knowledge, but combined with the AMQRP Homebrewer magazine and Conference Proceedings they do teach a lot. There is also the QRP-L mailing list which is very useful for technical questions (and has a rich archive)

I think it should be what Nuts and Volts magazine tries to be, but without the "legacy" dead weight and filler articles. A gentler introduction to most of the Circuit Cellar type stuff.

If people think this will recreate the Homebrew Computer Club, I expect they will be mistaken, but if you expect it to awaken the curiousity and encourage youth to learn about electronics, then I hope it is a brillent success.

In the end, I am curious and not quite sure what to expect of Make. It could be really lame if all it ends up being is computer geeks pretending to be electronic engineers (or electronic hobbyists). I hope that at least 10% of it expands what I know, which is more than I can say of books like Hardware Hacking Projects for Geeks (O'Reilly) and Hardware Hacking: Have Fun While Voiding Your Warranty. I am more interested in reading stuff like Hacking the Xbox (An Introduction to Reverse Engineering) by Andrew "bunnie" Huang which starts simple but gets into FPGAs and reverse engineering.

If you're already designing an external microchip, why not design a whole little recorder?
ACK. Shouldn't be too hard. For example, use an Atmel AVR 8-bit microcontroller and a DiskOnChip flash memory (really cheap for the 8-16MB range) + an electret microphone. All neccessary parts for 10EUR/$ and great flexibility.

I would also have severe privacy concerns with always-on recording and later editing.

One thing is for sure. If they can get this to work and if heat production can be cut down, this would make computing equipment and electronics much smaller.

That is why this kind of technology is used in embeded systems for years. Stack EEPROM and RAM on eachother in one housing to save space.

I wouldn't use a laptop, then you have to have a robot big enough to carry it around. You are also pretty much limited to the parallel port for I/O.

Look into microcontrollers (the most common are the Microchip PIC and Atmel AVR

A microcontroller will give you heaps more I/O pins, and PWM for driving motors, serial ports, analog/digital converters etc Both PICs and AVRs are available with all sorts of combinations of features.

There are plenty of resources available for both, look in newsgroups and search with google. GCC for the AVR is available for linux and windows so you can easily write C/C++ code for them. Also look into AVRfreaks
Look at the newsgroup comp.robotics.misc for other people doing similar things.

Good luck!
-Daniel

From Atmel: 8051.

Some drivers/latches from Micrel.

And of course some LED blocks from Sun LED.

The 8051 handles incoming serial data as well as acting as a 'RAM DAC' to load the lines on the Micrels which act as line drivers to the LED displays.

The Micrel's can be bit-banged in a serial-ish protocol which corellates to outputs on the 8-16 pins on each micrel (ie: think of it as programming a multipin output chip via a serialish link).

The 8051 constantly changes which row of LED block its updating and goes about it's business. Ideally, the 8051 should be changing rows 70 times a second for a good clean refresh rate.

These really aren't any different from the LCD modules you can pick up from Jameco, Hosfelt, or MPJA (or perhaps Digikey).

And lets not forget Find Chips for all of your parts searching needs.

I'm always on the search for embedded development tools for Linux. Although once in a while I have to deal with a windows based tool (which I run under win4lin), most of the time I am happily coding, compiling/linking and debugging under Linux.

I actually cut my teeth in embedded programming with the Intel 8048/8052 (yes the original 12 clocks per instruction). Those were the days - little or no embedded peripherals (the 8048 had no UART, or stack pointer for that matter), handful of bytes of RAM, a few kBytes or Flash, programming required 21V. Today's micros have much more horsepower, a lot more memory and (more importantly) lots of embedded peripherals. What is also very nice is that most modern micros can be programmed with a single bit banger from the parallel port using their ISP (In-Service Programming)!

Although the PIC micro was a great entry level micro (I first used them back in 1991, IIRC), I personally recommend the Atmel AVR as an entry level device.

Even though the AVR is 8 bits, it packs a hell of a lot of computing power into the instruction set (16 MHz means nearly 16 MIPs). I would call the AVR a pseudo 16 bit micro because many of the registers can be combined to act as 16 pointers/indexes. In fact the stack pointer is 16 bits, allowing a stack up to 64-4 kBytes (although the parts currently only have 8 kBytes of internal RAM, the ones with an external bus can have the stack (.bss or .data for that matter) outside the chip. BTW, don't get confused with the 8051 derivatives with fake out 16 bit access, the AVR has true 16 bit pointers allowing data and the stack to be located anywhere within the RAM memory range.

Just like the PIC, the AVR needs minimal components to operate. In fact, if you can live with an inaccurate clock, you can actually run the part without a crystal because of the on-chip R/C oscillator. Since there is an on-chip power on reset, you don't even need an R/C reset circuit.

As for development tools under Linux, you can find the sources for all the GNU AVR tools at my site. I also have a script that will build and install GCC, binutils, libc and GDB/insight for the AVR under Linux (and most unices). You can also find links to free programming tools that allow programming of parts in-circuit (via ISP or JTAG).

I hope this helps you on your way to embedded hacking under Linux. And remember there are a lot of other nice micros out there so keep looking, and have fun (and good luck with your engineering degree)!

I'm always on the search for embedded development tools for Linux. Although once in a while I have to deal with a windows based tool (which I run under win4lin), most of the time I am happily coding, compiling/linking and debugging under Linux.

I actually cut my teeth in embedded programming with the Intel 8048/8052 (yes the original 12 clocks per instruction). Those were the days - little or no embedded peripherals (the 8048 had no UART, or stack pointer for that matter), handful of bytes of RAM, a few kBytes or Flash, programming required 21V. Today's micros have much more horsepower, a lot more memory and (more importantly) lots of embedded peripherals. What is also very nice is that most modern micros can be programmed with a single bit banger from the parallel port using their ISP (In-Service Programming)!

Although the PIC micro was a great entry level micro (I first used them back in 1991, IIRC), I personally recommend the Atmel AVR as an entry level device.

Even though the AVR is 8 bits, it packs a hell of a lot of computing power into the instruction set (16 MHz means nearly 16 MIPs). I would call the AVR a pseudo 16 bit micro because many of the registers can be combined to act as 16 pointers/indexes. In fact the stack pointer is 16 bits, allowing a stack up to 64-4 kBytes (although the parts currently only have 8 kBytes of internal RAM, the ones with an external bus can have the stack (.bss or .data for that matter) outside the chip. BTW, don't get confused with the 8051 derivatives with fake out 16 bit access, the AVR has true 16 bit pointers allowing data and the stack to be located anywhere within the RAM memory range.

Just like the PIC, the AVR needs minimal components to operate. In fact, if you can live with an inaccurate clock, you can actually run the part without a crystal because of the on-chip R/C oscillator. Since there is an on-chip power on reset, you don't even need an R/C reset circuit.

As for development tools under Linux, you can find the sources for all the GNU AVR tools at my site. I also have a script that will build and install GCC, binutils, libc and GDB/insight for the AVR under Linux (and most unices). You can also find links to free programming tools that allow programming of parts in-circuit (via ISP or JTAG).

I hope this helps you on your way to embedded hacking under Linux. And remember there are a lot of other nice micros out there so keep looking, and have fun (and good luck with your engineering degree)!

I've been using the BASIC Stamp Tools for Linux for a while now. It uses the (unfortunately) beerfree parallax pbasic tokenizer so. If you don't want to use the BS, the Atmel AVR series is well supported by open source software, and really fast as well (native code vs. interpreted).

I've been using the BASIC Stamp Tools for Linux for a while now. It uses the (unfortunately) beerfree parallax pbasic tokenizer so. If you don't want to use the BS, the Atmel AVR series is well supported by open source software, and really fast as well (native code vs. interpreted).

The full x86 instruction set is large and complicated (some of the complexity because of its history). Adding an OS like Linux and all the hardware for a PC just adds a whole lot more stuff for a student to have to deal with.

If this is a learning exercise, wouldn't it make sense to reduce the clutter of the environment (OS, PC hardware) and isolate the learning to only what is relevant. Why not start with a simple 8 bit microcontroller like an Atmel AVR, TI MSP430 or prehaps Cypress PSOC? Once the teaching mission has been accomplished and students are comfortable with programming concepts and basic computer architecture ideas, step up to using a higher level language like C on these micro's, then step up to the PC environment including an OS like Linux. At that point, the learning options expand greatly.

This plan lets students acquire a deeper understanding at first, because they can explore the microcontroller completely - it is simple enough for a beginner individual to understand every aspect of its operation, unlike a PC. As a bonus, there is a great sense of accomplishment in fully understanding something instead of partially understanding it, and a stronger feeling of connectedness if you can make a micro do something physical.

Those of us whose introduction to computing was through simpler machines like the Apple II (it even came with a full circuit diagram!) must know what I'm talking about. I don't know if I'd be nearly as interested as I was in my youth if I were just starting out in computing today and my introduction was a PC. I'd probably just use it to play games, like most kids seem to do.

e'll only have to crack it once and then we'll all be set. :)

No, they want this new "Universal DRM System" to prevent exactly that.

22. What's TORA BORA?
This seems to have been an internal Microsoft joke: see the Palladium announcement. The idea is that `Trusted Operating Root Architecture' (Palladium) will stop the `Break Once Run Anywhere' attack

The whole thing runs on top of Trusted Computing. They are pushing for this new "Universal DRM system" becuase it is very very different. You will no longer own your own computer or your own devices. They will have a "Trust" chips inside that guarantee them control.

To "crack the system" you need to dig your own personal encryption key out of the chip soldered to your motherboard. Breif info on one such chip. See page one "Physical security circuitry" and page 2 where it says "if it has been removed from the PC in any way and can also take actions internally"? That means chip is tamper resistant and programmed to wipe your key if it detects you trying to get at it.

And lets say you do manage to dig out the key - every computer has a different key! If you dig out your key that only cracks that one machine. One key extracted, one PC liberated. The TORA BORA plan includes plans for "traitor tracing". If you aren't extremely carefull how you use that key they will detect it and revoke that key. Hell, they might even track you down and throw you in prison.

And before people say they simply won't buy computers with these control chips built in I suggest they look at my other post here. In a few of years you may be denied internet access unless you submit.

-

Most of the stuff I was building at the time, I would decide whether or not I wanted to go 8085, 65C02, or 68000 depending on how much processor power, electrical power, and cost tradeoffs, and go from there. (Yeh, I knew about the RCA 1802, and absolutely hated to code assembler for it.)

Looking back on it, I think the main reason I went Motorola for all my 32-bit stuff is I got ahold of one of the chip kits pretty soon after it came out, and learned enough to make functional devices with it. Then I was soundly in the rut with insufficient motivation to jump out. Intel made some neat stuff, but I considered the Motorola implementations much cleaner from a hardware point of view, despite the fact PC's were running Intel processors.

Today, my main choices are the ATMEL AVR/ATMEGA series , and the Motorola 320X0's. Incidentally, I think ATMEL has done a helluva job supporting us little guys in the trenches with all sorts of nifty tools on their website, development kits, and making sure places which deal a lot with us little guys, like Digi-Key , have a wide selection of product for us.

I do get concerned at Motorola though, as they seem to keep changing their product. To me, implementing a product in a design is a lot like my selection of building materials... if I do not have confidence that ten years from now, I will be able to obtain compatible materials, I go back to my design and change it to use something more generic. Yes, the 68000 is old hat - but it is exactly what I needed to do a job at hand. Example: I like to design with standard brick. I am quite leery of custom roofing material or exotic plumbing fixtures. Just because something is old does not mean you have to abandon making it. ( 68000 in the 64-pin plastic DIP package for PTH mounting ). To me, that makes just about as much sense as no longer making 100 watt incandescent light bulbs in an Edison base.

If any Motorola rep is out there reading this, please cut this out and hand it to management. You guys can really make us little guys in the trenches look bad when no sooner than we get our customer all geared up for production and the rug gets pulled on us. They blame me for it. ( Rightfully so, cause people like me should know who it is out there who won't stay on the ship long enough to complete the voyage. ) If you percieve that I am both disappointed and angry about discontinuation of this product, you are right.

Well you can run uCLinux on lower end CPUs. (16-bit and 32-bit cpus). Also the Dragonball is technically a 32-bit cpu. Of course it does not have an MMU, which can be a problem for standard linux.

I'm just waiting for an Open PDA that doesn't costs $300. I'm more worried about the bottom line than anything. Most people who want an open PDA want it to have more processing power, more colors and more IO ports than anything else available. This really goes against my own ideas of what makes a good PDA.

Here is what makes a good PDA (in order of importance):

Open Architecture - anyone can build applications to run on the device.

Small - should fit comfortable in a pocket. should be thin and try to have the biggest LCD possible for it's small size. (keep the border around the pda small. like the AgendaVR3)

Long Battery Life - should last for weeks on a charge with normal use.

Inexpensive - any high school or college student could pick one of these up and hack up some fun apps for it. This is good for making the list of available applications nice and long.

Standard IO ports - should have some standard connectors so we can get a solar-powered charger or hook it up to a PC with some commonly available connector (USB?, IRda, etc)

Different models for different people - I personally prefer a nice crisp monochrome LCD. They are low powered, inexpensive and easy to read in a variety of light conditions. And it fits with the way I use a PDA. Other people use PDAs quite differently and really need to have a nice strong backlight, crisp colors and high resolution.

Of course it is pretty easy for me to just go around telling everyone how to do their jobs. I am working on a small public domain OS geared towards PDAs. (starting with ARM7tdmi processors, which can draw as little as 22mA at 33MHz. It's comparable to ) Perhaps someone can use it someday for my ideal PDA.

If you're just looking to work with a small microprocessor/computer to get that nostalgic feel, just take a modern microcontroller and start breadboarding.

Microcontroller products from Microchip and Atmel fit the bill nicely.

For support and help with Microchip PIC microcontroller development, you can hardly go wrong with the MIT-PICList, and for Atmel AVR micros AVRFreaks is the place to go.

Then you'll probably find yourself over at DigiKey buying parts for your projects after you have gained some insight into just how cool it is to have a 40 MHz processor with 2K or more of FLASH RAM on-board in a 18-pin device right at your fingertips that only needs a PC and some imagination to program to act like just about any logic device.

Have fun twiddling those bits, boys and girls.

Many of the current MCUs are ball grid array (BGA) devices, which make them pretty hard to work with if you're not a professional, but a few can be had in PLCC or QFP packages, which means you can get an adapter board or socket.

You can also buy preassembled demo/development boards (this is the route I'm taking) and wire-up anything the board doesn't include by hand. Most of the MCUs on the market will have 32-bit memory busses (though they may not support more that 25 or 26 address lines), so you can attach just about anything you want to them.

This is exactly the kind of thing that Steve Ciarcia (of Ciarcia's Circuit Cellar) used to do: building personal computers from microcontrollers. Most of his designs used Z80 based devices, which was fine back in the mid- to late-eighties. Now, however, you can do a fair bit better.

As for speed, I don't know exactly what you're looking for, but the ARM devices can be had in speeds from 50MHz to 400MHz, and the same is true of the PPC and MIPS devices. That may not seem like much, compared to a 2GHz Pentium, but it's really quite nice.

Some good resources: Digi-Key is a reasonable source for all sorts of parts, Atmel makes some nice MCUs, programmable logic, and Flash RAM, Cirrus Logic makes some ARM MCUs and networking chips (amoung other things), Sharp, Samsung, Motorola, and AMD all make nice MCUs, Cogent Computers builds some nice development boards, and EarthLCD has good prices on LCDs and has an ARM based board in the works.

You might wanna use a Crystal Semiconductor CS-8900A if you wanna go directly to ethernet, or you may wanna use one of the AVR parts with the built-in UART if you wanna dialup. Yeh, you will have to write a little proggie to make tcpip packets... but you don't have to include everything... just the basic text stuff. Most likely somebody has already done so.

I am looking into these for some of the robotics stuff I work on. They look really nifty - especially when the whole shebang fits in so nicely with my motion control stuff. The ATMEGA series has a hardware multiply, so that makes the 32-bit Multiply - Add routine efficient enough for me to use for a lot of the DSP routines I need for control algorithms.

Lotsa links here...

First of all, the 2002 Burning Man project I did that involved a couple hundred RGB LEDs spinning in a persistence-of-vision-based nighttime animated display. Here is the best picture of it. This is the page about the development details.

The LEDs I used were manufactured by Kingbright. The model I used, the LF819EMBGMBC, is big (10mm) and relatively bright for an RGB LED. I couldn't find any U.S. retailers that actually told the truth about whether they stocked them, so I ended up buying 400 directly from Kingbright for I think a little more than $2.50 each. I still have a few left.

Atmel AVR microcontrollers are just a few bucks each, easily programmable with the STK-500 programmer, also cheap at around $80. I used the ATMega8, which was more than sufficient for my needs. I imagine the original Slashdotter could use one of the ATTiny MCUs, since it really needs only 3 or 4 I/O lines (fewer depending on how many helper circuits you decide to use).

The boards were manufactured by PCBExpress and I was very happy with them. The CAD/CAM software was Eagle, which except for some crashing/redrawing bugs was really amazing. The version I used was free. I tried to buy it but CadSoft has (had?) a fairly crazy pricing scheme that actually left you worse off in terms of acceptable usage if you paid them money than if you used the free version.

The best part of using the Atmel MCU was that GCC can cross-compile for it. So you're basically writing regular old C code but it runs on a little tiny piece of silicon. You'll want to subscribe to the quite active avr-gcc mailing list. Save every message from Marek Michalkiewicz; in my opinion he's the god of GCC-for-AVR development.

Ukelele's are such simple minded instruments (don't get me wrong, I've passed many the doobie to a nice Oo Ka ley ley song).

This is evidenced by the fact they could implement this with and RCX

For a real system, you're better writing it in on an Atmel 8 bit RISC microcontroller One friggen instruction per cycle. Not a few hundred or so.

using one of the nice embedded C Compilers

Geez does that Basic code look silly!

loop [

waituntil [switch 11] play_note 85 1 1

waituntil [switch 11] play_note 84 1 1

waituntil [switch 11] play_note 84 1 1

waituntil [switch 11] play_note 82 1 1

waituntil [switch 11] play_note 84 1 1

waituntil [switch 11] play_note 84 1 1

waituntil [switch 11] play_note 85 1 1

waituntil [switch 11] play_note 73 1 1

waituntil [switch 11] play_note 73 1 1

With an AVR, you could play the music like the Gypsie Kings with one processor! I'm talking multiple 12 strings!

You wouldn't need a beuwolf cluster..

But, it would be pretty cool.

All kidding aside, I wish I had the time to do this kind of stuff. Writing Java code for "Big Business" gets very boring, though, it feeds my family.

It looks as if these cars use may a
Microcontroller, perhaps not, but definitely an H-Bridge. And H-Bridge is a specialized push pull amplifier that can be used as a Motor controller. You can order this as Quad 2 Channel Drivers,
In a DIP Package.
Gee I'd love to
Hack one of these babies like
this fella
did.

But, it's really tough to find chips at those sizes.

On, the short battery life. I'm reminded of BEAM Devices which charge up a capacitor from a solar cell, then release the energy in a spurt, then go back to charging the capacitor. Here's a cool one

• You can use Steven Bolt's sp12 programmer which requires just a crystal and a few caps and resistors to build a stand-alone programmer, or requires nothing more than connectors and a few series resistors for an in-circuit-programming version.
• All parts are flash based, not just a select few.
• A low end established flash based part is available with a UART.
• Flash parts are available with PWM channels, A/D converters, 16 bit timers, SPI and analog comparators.
• A starter kit is available for $49 USD that comes with an in-circuit programming dongle and a demo board.
• The series includes devices with between 1KB and 128KB of flash program storage.
• (My favourite feature) GNU Binutils, GCC and even GDB target the AVR line. It's a joy to have access to a free and Free macro assembler and C compiler. Many micros come with free assemblers but these are often buggy and lack features, and it's very rare to get a free C compiler.

(Note that the latest binutils release supports the AVR, but the AVR GCC support is available as a patch to 2.95.2 at the location given above, or in the latest CVS & snapshots of GCC. The server hosting the patches seems to be down and has been for a short while, so Google's caching might come in handy. Google won't let me link directly to the cached version so just to to the cache of the first link for this search.)

• You can use Steven Bolt's sp12 programmer which requires just a crystal and a few caps and resistors to build a stand-alone programmer, or requires nothing more than connectors and a few series resistors for an in-circuit-programming version.
• All parts are flash based, not just a select few.
• A low end established flash based part is available with a UART.
• Flash parts are available with PWM channels, A/D converters, 16 bit timers, SPI and analog comparators.
• A starter kit is available for $49 USD that comes with an in-circuit programming dongle and a demo board.
• The series includes devices with between 1KB and 128KB of flash program storage.
• (My favourite feature) GNU Binutils, GCC and even GDB target the AVR line. It's a joy to have access to a free and Free macro assembler and C compiler. Many micros come with free assemblers but these are often buggy and lack features, and it's very rare to get a free C compiler.

(Note that the latest binutils release supports the AVR, but the AVR GCC support is available as a patch to 2.95.2 at the location given above, or in the latest CVS & snapshots of GCC. The server hosting the patches seems to be down and has been for a short while, so Google's caching might come in handy. Google won't let me link directly to the cached version so just to to the cache of the first link for this search.)

• You can use Steven Bolt's sp12 programmer which requires just a crystal and a few caps and resistors to build a stand-alone programmer, or requires nothing more than connectors and a few series resistors for an in-circuit-programming version.
• All parts are flash based, not just a select few.
• A low end established flash based part is available with a UART.
• Flash parts are available with PWM channels, A/D converters, 16 bit timers, SPI and analog comparators.
• A starter kit is available for $49 USD that comes with an in-circuit programming dongle and a demo board.
• The series includes devices with between 1KB and 128KB of flash program storage.
• (My favourite feature) GNU Binutils, GCC and even GDB target the AVR line. It's a joy to have access to a free and Free macro assembler and C compiler. Many micros come with free assemblers but these are often buggy and lack features, and it's very rare to get a free C compiler.

(Note that the latest binutils release supports the AVR, but the AVR GCC support is available as a patch to 2.95.2 at the location given above, or in the latest CVS & snapshots of GCC. The server hosting the patches seems to be down and has been for a short while, so Google's caching might come in handy. Google won't let me link directly to the cached version so just to to the cache of the first link for this search.)

• You can use Steven Bolt's sp12 programmer which requires just a crystal and a few caps and resistors to build a stand-alone programmer, or requires nothing more than connectors and a few series resistors for an in-circuit-programming version.
• All parts are flash based, not just a select few.
• A low end established flash based part is available with a UART.
• Flash parts are available with PWM channels, A/D converters, 16 bit timers, SPI and analog comparators.
• A starter kit is available for $49 USD that comes with an in-circuit programming dongle and a demo board.
• The series includes devices with between 1KB and 128KB of flash program storage.
• (My favourite feature) GNU Binutils, GCC and even GDB target the AVR line. It's a joy to have access to a free and Free macro assembler and C compiler. Many micros come with free assemblers but these are often buggy and lack features, and it's very rare to get a free C compiler.

(Note that the latest binutils release supports the AVR, but the AVR GCC support is available as a patch to 2.95.2 at the location given above, or in the latest CVS & snapshots of GCC. The server hosting the patches seems to be down and has been for a short while, so Google's caching might come in handy. Google won't let me link directly to the cached version so just to to the cache of the first link for this search.)

The ARM7TDMI core, on which both the Atmel AT91 series and this new chip are based, does not include an MMU.

The ARM7TDMI core, on which both the Atmel AT91 series and this new chip are based, does not include an MMU.

Actually, if you like the PIC, you'll love the Atmel AVR programmable microcontrollers. Much cleaner architecture than the PIC, no I/O pin weirdness with outputs not quite being outputs all the time, and a real serial-connected programmer is $49 instead of $400.
--