Slashdot Mirror

Technology has changed drastically since the 80's when I used to play Laser Tag, Photon, etc. These days you can buy fully programmable microcontrollers (Microchip PIC16F628A) for less than $2 a pop. I'm currently in the middle of a couple different IR projects with microcontrollers, so the potentials of this type of project are fresh in my mind.

I would create the entire thing from scratch, as opposed to modding existing equipment. The circuit would be extremely simple (a PIC, a transistor, a few resistors, IR emitters and detectors, and push buttons for firing, reloading, resetting, etc).

You could either just use IR LEDs, or get emitters that already modulate at some frequency. If you also encode data on your carrier then you could enable options like friendly fire, varying weapon damage, etc.

Some ideas that come to mind:

Use FM RF transmitters to relay all data back to a central data collection point to show game progress real-time.

Use an IR transmitter modulated with a special code to reset each player. This would reduce cheating.

Similar to above, use an IR transmitter (with a different code) that can be used to heal people. This unit could be placed in a fixed location, or you could have a medic type player that only has a weak weapon.

Use virtual ammo, implemented as above. Once your weapon is out of ammo you have to pick up additional ammo, which recharges your weapon.

Just like Medics in TFC, you could allow medics to infect enemy players. If a player is infected then they constantly emit a signal that would infect their teammates. Anyone infected will gradually loose health until they die. This could be implemented with a couple weak IR transmitters directly on the player. Of course medics on your own team can heal infections.

Put a IR receiver in the weapon and not just on the player. Thus if it is possible to shoot at someone, it is possible to be shot. That has always been my biggest gripe about laser tag - people holding their gun around a corner where you can't see their sensor.

I could go on and on, but I suppose that's enough rambling for now.

Dan East

Until I can get a Linux-in-a-chip system, that won't do for me. I'm looking from the hobbyist point of view, a system I can build with a dozen or so chips. I have lots of leftovers from the early days, things like 8088 CPU's and TTL chips. DOS is fine for building small interfaces that can communicate with a larger computer. Of course, I could use PIC's for that, but then what would I do with my collection of old chips?

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

I had the same problem a while ago. Most of the ones availible are cheap POS. If you have the time and expertise, or can find someone that does, you can build your own from a PIC microcontroller. Microchip even gives the software away, and the schematic. (One note about the schematic is that is has the clock and data pins to the PS/2 port backwards.)

Microchip's Application Note

Microchip even provides gives out samples for free, you just need to find someway to program it.

let x=0;
let x=0;

Why is it repeated? "In case it didn't get it right the first time".

Sadly, I've actually seen this. More sadly, this is because I wrote that code. Most sadly yet, it needed it--the processor didn't get it right the first time, and I was at a loss to figure out why.

This was a PIC18 microcontroller, actually not that long ago, with a project deadline approaching fast. The assembler program I was writing would occasionally experience what, if I didn't 'know better', would seem like hardware demons. Monkey with the code a bit, the bug would go away, and so I wrote it off as bad programming, i.e. "some incredibly stupid mistake that I'm not catching". With about a week to the deadline, things started to get very bizarre very fast. Things like RETURN instructions that didn't return, registers holding some random data after being cleared, and the behavior of code at location x being influenced by code at location (further than x) that hadn't been executed yet. In the obvious frustration that ensued, the almost-production code contained lines like the following (except for the mangled formatting of course; that's Slashdot's doing) :


call showREG ; debug - show what's in register REG
clrf REG ; debug - force REG contents = 0
call showREG
clrf REG
clrf REG
clrf REG
clrf REG ; WTF?!?!?
call showREG


In desperation I resort to the resort engineers resort to when no other resort remains, which is to Read The Friendly Manual (in this case, looking through the 300-some pages of datasheets). Brief mention is made of consulting their 'errata sheet' for the latest processor errata. I think I did go looking for this once long before, and decided this document was buried cleverly enough that I shouldn't waste my time continuing to look for it, since a measly 8-bit micro would never contain a showstopper like the Pentium FDIV bug (affecting 1 in every few zillion long divisions), right?

Y-y-y-yeeeeah. Anyway, I chase down the errata sheet for this micro, for real this time, and find the following smack on the first page:

Certain code sequence and placement may cause the corruption of a few bits in the instruction fetch when the part is used above 4 MHz. A corrupted instruction fetch will cause the part to execute an improper instruction and result in unpredictable outputs.

Microchip cannot predict which code sequences and placement will cause this failure. If this failure mechanism exists in your system, it should be evident during statistically significant preproduction testing (minimum suggested sample size 100 units) of your particular code sequence and placement.

Now, the rated speed of this chip is 40 MHz (not 4!), and we were of course running it at 40, because if we wanted to run slower, we'd have bought slower chips.

In the end, crisis narrowly averted by changing all the system clocks from 40MHz to 4MHz, hacking all the timing-dependent code to compensate, and demoing a slower (but working) prototype. (And of course, a lab-wide resolution not to buy chips from Microchip again.)

Lesson for today: Always look up those errata sheets, kids.

• No, the Roomba doesn't have a loud buzzer to warn people of its presence. Why? It's freakin' LOUD! If you don't here the Roomba running, you wouldn't hear the buzzer!
• Does the "real" Roomba(TM) carefully trace around furniture legs.(sic) Sure it does, provided they're large enough. I've got a four footed pedistal table in the dining room. It goes under there and around its feet just fine.
• Does it "remember" to go around the couch. NO, it just bounces around, util it is about outta juice, and then homes in on the power. No, that's not right, either. While it doesn't have an internal map of its environs, it's only $200. Yes, its motions look random, but it really has at least three different patterns: spiral, edge following, straight line until an obstacle is met. It has three different room size settings, which really just adjust a timer. Larger rooms get more time on the clock. Yes, it can run out of power, but no, it won't look for the charger. It just blinks a red LED and chimes a four-note tune that my wife and I have taken to mean, "I'm so tired!"
• It doesn't suck well with its tiny little impeller, but it has something a dustbuster doens't: sweeping roller brooms. The Roomba uses suction to pick up dander and dust, but larger items like coins, sand, furballs, etc., get picked up with the rubber flapper/brush roller combination. Quite effective on our wood floors.
• 
  
  By the way, what kind of behaviors do you want? Its brain is a Microchip PIC microcontroller with something like 256 bytes of memory. Whoopee!

• No, the Roomba doesn't have a loud buzzer to warn people of its presence. Why? It's freakin' LOUD! If you don't here the Roomba running, you wouldn't hear the buzzer!
• Does the "real" Roomba(TM) carefully trace around furniture legs.(sic) Sure it does, provided they're large enough. I've got a four footed pedistal table in the dining room. It goes under there and around its feet just fine.
• Does it "remember" to go around the couch. NO, it just bounces around, util it is about outta juice, and then homes in on the power. No, that's not right, either. While it doesn't have an internal map of its environs, it's only $200. Yes, its motions look random, but it really has at least three different patterns: spiral, edge following, straight line until an obstacle is met. It has three different room size settings, which really just adjust a timer. Larger rooms get more time on the clock. Yes, it can run out of power, but no, it won't look for the charger. It just blinks a red LED and chimes a four-note tune that my wife and I have taken to mean, "I'm so tired!"
• It doesn't suck well with its tiny little impeller, but it has something a dustbuster doens't: sweeping roller brooms. The Roomba uses suction to pick up dander and dust, but larger items like coins, sand, furballs, etc., get picked up with the rubber flapper/brush roller combination. Quite effective on our wood floors.
• 
  
  By the way, what kind of behaviors do you want? Its brain is a Microchip PIC microcontroller with something like 256 bytes of memory. Whoopee!

PIC processors can be insanely useful for this sort of thing and very cheap (most around $10) and easy to get, and once you've got the basics down (which can seem a bit daunting at first) they are very easy to learn and program to do pretty much whatever you want. The playstation mod chips are cheap miniture 8-pin PICs usually - just to give you an idea of what they can do, and some of the more advanced models have RS232 (i think) builtin so you can directly interface it with your PC. Add to that some cheap easy to use wireless modules (they just take a power supply and you stick the on/off binary signal in and thats all you need, takes 2 minutes) you can do some nifty remote controlled things. Basically anything from just switching something on and off or blinking some leds (which can be programmed in minutes) to full fledged computing can be done with these babys. They have loads of extras too - analog-digital converters, eeprom memory, high-current switching and more.

Remote key-loggers anyone? ;)

The PIC makers
More stuff

This one is pretty good.

My advice is to start with a pic 16F877a and use a bootloader. Life gets a lot easier this way, without having to slowly use the programmer every time.

If you go to the microchip website you can get free samples which should get you started.

Knowing some assembler is great if you're programming embedded microcontroller applications where every cycle counts (for example, programming PICs). But when it comes to large scale processors it's almost entirely irrelevent, mainly because of their incredible comparative speed and complexity. While it's easy to optimise assembler for a simple PIC, optimising assembler for an Athlon XP would be mind-blowingly complicated, and hence best left to compilers. C translates fairly easily into assembler - most embedded software engineers can visualise how to implement for, while, if etc. constructs in assember. C just saves a lot of time and effort. "Computer Science" is all about layers of abstraction - there really is no need to understand every little detail in order to implement a modern application. Only us nerds take pleasure in knowing-it-all (tm).

It's not really a transmitter as such. It's a backscatter device and as such, it's not transmitting- it's reflecting.

What do I mean by this? Picture a mirror. Now, picture putting an LCD immediately in front of the mirror. Operating the LCD impinges a modulation on the light, conveying information back to the light source.

In the above example, the mirror did not transmit any energy to convey information back to the carrier power source (the light...). It merely reflected it back.

With an EZ Pass style tag, it's the same sort of thing, only with RF power instead of light. Of course, the tag pulls some energy to power itself up and drive the modulation circuitry, but it's not actually transmitting in the traditional sense of the concept.

For more info, I suggest reading the following links:

http://www.rfid-handbook.de/rfid/types_of_rfid.htm l
http://www.microchip.com/download/appnote/rfid/006 80b.pdf
http://legwww.epfl.ch/research/pdf/back_scattf.pdf

Oh God they'll be able to know what couch I bought. Horror! Shock! Dismay! Wait, what's the effective transmitting radius of the RFID tags anyway (pdf here)? Won't "they" be able to see the couch at these sorts of distances?


And who the hell cares if they know what couch you bought? Can some rational person tell me why this is just so bad?

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.

Another good thing about Microchip.com: http://sample.microchip.com/.
Pick up to 5 items and have em FedEx'ed to your home. It's a great way to check out a new chip you where wondering about, and not spend the money on it. Granted, it's only 5-25$ per piece, but that's 5-25$ you might waste if you get a new chip to play with and end up toasting it.

Microcontrollers are extremely small, low-powered devices containing a CPU, some code/data memory peripheral interfaces. You might have seen them at work in your preferred game station mod chip...

I think Motorola, AMD and Intel also have a line of powerful 68xxx- and x86-, respectively, -based microcontrollers that might be closer to the capabilities of a PC processor.

There are also some chips that you can program in Basic (ugh) via a small interpreter in their boot code. It really depends on what you are planning to do.

Only one Billion ? Microchip shipped their 2 billionth a year ago, the last billion in just 30 months!

AVR's are buggy and soon to be obsolete microcontrollers. Invest in Microchip PICMicros (TM) instead.

Advantages of PICMicro(TM):

*True RISC Design. Only 35 instructions to Learn!
*20ma drive current per I/O pin
*40 Mhz operation (PIC18xxx, Using 4x PLL multiplier)
*Simplist In-Circuit Programming in the industry

Disadvantages of Atmel AVR(TM)

*Based on obsolete pseudo-RISC design
*Only 32 registers
*Badly Implemented Peripherials (ADC is slow and innaccurate, and EEPROM loses contents often)
*fragile - easily destroyed by ESD
*Poorly supported.

Don't Delay, Learn PICs (TM) Today!

PIC(TM) and PICMicro(TM) are registed trademarks of Microchip Technology

AVR's are buggy, obsolete microcontrollers. Invest in Microchip PICMicros (TM) instead.

Advantages of PICMicro(TM):

*True RISC Design. Only 35 instructions to Learn!
*20ma drive current per I/O pin
*40 Mhz operation (PIC18xxx, Using 4x PLL multiplier)
*Simplist In-Circuit Programming in the industry

Disadvantages of Atmel AVR(TM)

*Based on obsolete pseudo-RISC design
*Only 32 registers
*Badly Implemented Peripherials (ADC is slow and innaccurate, and EEPROM loses contents often)
*fragile - easily destroyed by ESD
*Poorly supported.

Don't Delay, Learn PICs (TM) Today!

PIC(TM) and PICMicro(TM) are registed trademarks of Microchip Technology

Actually you can get free samples of that PIC from Microchip sure you can only get 5, and you can only do it once, but for a hobby project it's easy enough. And yes, the shipping is free too. So that will knock almost $12 bucks off the price. That should make up for the other stuff, excepting the programmer, which is reusable, and therefore you can amortize the cost over various hobby projects ;-)

-Spyky

AVR's are buggy and soon to be obsolete microcontrollers. Invest in Microchip PICMicros (TM) instead.

Advantages of PICMicro(TM):

*True RISC Design. Only 35 instructions to Learn!
*20ma drive current per I/O pin
*40 Mhz operation (PIC18xxx, Using 4x PLL multiplier)
*Simplist In-Circuit Programming in the industry

Disadvantages of Atmel AVR(TM)

*Based on obsolete pseudo-RISC design
*Only 32 registers
*Badly Implemented Peripherials (ADC is slow and innaccurate, and EEPROM loses contents often)
*fragile - easily destroyed by ESD

Don't Delay, Learn PICs (TM) Today!

PIC(TM) and PICMicro(TM) are registed trademarks of Microchip Technology

AVR's are buggy and soon to be obsolete microcontrollers. Invest in Microchip PICMicros (TM) instead.

Advantages of PICMicro(TM):

*True RISC Design. Only 35 instructions to Learn!
*20ma drive current per I/O pin
*40 Mhz operation (PIC18xxx, Using 4x PLL multiplier)
*Simplist In-Circuit Programming in the industry

Disadvantages of Atmel AVR(TM)

*Based on obsolete pseudo-RISC design
*Only 32 registers
*Badly Implemented Peripherials (ADC is slow and innaccurate, and EEPROM loses contents often)
*fragile - easily destroyed by ESD
*Poorly supported.

Don't Delay, Learn PICs (TM) Today!

PIC(TM) and PICMicro(TM) are registed trademarks of Microchip Technology

AVR's are buggy and soon to be obsolete microcontrollers. Invest in Microchip PICMicros (TM) instead.

Advantages of PICMicro(TM):

*True RISC Design. Only 35 instructions to Learn!
*20ma drive current per I/O pin
*40 Mhz operation (PIC18xxx, Using 4x PLL multiplier)
*Simplist In-Circuit Programming in the industry

Disadvantages of Atmel AVR(TM)

*Based on obsolete pseudo-RISC design
*Only 32 registers
*Badly Implemented Peripherials (ADC is slow and innaccurate, and EEPROM loses contents often)
*fragile - easily destroyed by ESD

Don't Delay, Learn PICs (TM) Today!

PIC(TM) and PICMicro(TM) are registed trademarks of Microchip Technology

Actually a PIC microcontroller is VERY easy to program as you can do it in BASIC. Getting started with them is also VERY inexpensive. You can get the PCBs for a parallel programmer for free off the 'Net and the parts for it from any reputable electronics parts supplier. They also can be powered from the serial port if you want to keep it simple. A PIC can power a number of LEDs with nothing other than a current limiting resister on the ground side of the LED. The PIC microcontroller is about $5-$8 from Reynolds Electronics.

Microchip They offer low speed processors that can easily control that kind of thing from a serial port. Though, you will need to write your own code for it (sometimes the price you pay for doing it yourself.) You should be able to pick-up most of the parts you need for under $30 from Digi-key though the only part that might cost you a bit is the programmer for the processor. (I think you can actually build those too!)

A DAC or a pot would be a tremendous waste. What you want (as several people have mentioned) is Pulse Width Modulation. You can adjust the brightness by adjusting the duty cycle. I'd recommend an PIC or some such.

Check out Circuit Cellar Magazine -- they are a steady stream of articles and advertisements covering just the thing you want to do.

While you're reading it, also pay attention to PIC Chips and Basic Stamps, which would be a great way to control your orbs without needing a PC (especially the cheaper PIC chips from someone like Microchip Technology)

If you're married to the PC concept, you'll also find advertisements for devices which are controllable via USB. Kinda nice for furure serial-less PCs.

Lastly, though it's a bit out of date at this point, take a look at "Controlling the World With Yor PC" by Paul Bergsmann (ISBN: 1878707159). Great stuff about parallel port interfacing.

Good luck!

Since a lot of ppl are asking a lot of the same questions about RFID devices, I thought I'd answer some here.

More information can be had from Microchip, a leading manufacturer of RFID devices. A lot of this information is coming from their RFID Design Guide

1. What is an RFID tag?
An RFID tag is a very small microcontroller and radio transmitter/receiver. They typically consist of a single chip and a single coil which behaves as an antenna.

2. What does an RFID tag transmit?
Most RFID tags transmit a single large integer number, unique to that individual tag. A serial number, if you will. Some RF tags also have a very small amount of ROM/EEPROM, and so could transmit a little more info and can even be reprogrammed by the "reader".

3. How are they powered?
The RFID "reader" device emits RF energy. The RFID tag receives this energy and uses it to power itself. It's a lot like an old AM crystal radio. The device transmits its number over and over at a very high bps for a high level of data redundancy.

There is a whole shitload more technical modulation theory and stuff that goes on here which I'm leaving out. If you aren't a ham or other radio type person it would probably be meaningless. Again if you would like more info, look here.

Since a lot of ppl are asking a lot of the same questions about RFID devices, I thought I'd answer some here.

More information can be had from Microchip, a leading manufacturer of RFID devices. A lot of this information is coming from their RFID Design Guide

1. What is an RFID tag?
An RFID tag is a very small microcontroller and radio transmitter/receiver. They typically consist of a single chip and a single coil which behaves as an antenna.

2. What does an RFID tag transmit?
Most RFID tags transmit a single large integer number, unique to that individual tag. A serial number, if you will. Some RF tags also have a very small amount of ROM/EEPROM, and so could transmit a little more info and can even be reprogrammed by the "reader".

3. How are they powered?
The RFID "reader" device emits RF energy. The RFID tag receives this energy and uses it to power itself. It's a lot like an old AM crystal radio. The device transmits its number over and over at a very high bps for a high level of data redundancy.

There is a whole shitload more technical modulation theory and stuff that goes on here which I'm leaving out. If you aren't a ham or other radio type person it would probably be meaningless. Again if you would like more info, look here.

Since a lot of ppl are asking a lot of the same questions about RFID devices, I thought I'd answer some here.

More information can be had from Microchip, a leading manufacturer of RFID devices. A lot of this information is coming from their RFID Design Guide

1. What is an RFID tag?
An RFID tag is a very small microcontroller and radio transmitter/receiver. They typically consist of a single chip and a single coil which behaves as an antenna.

2. What does an RFID tag transmit?
Most RFID tags transmit a single large integer number, unique to that individual tag. A serial number, if you will. Some RF tags also have a very small amount of ROM/EEPROM, and so could transmit a little more info and can even be reprogrammed by the "reader".

3. How are they powered?
The RFID "reader" device emits RF energy. The RFID tag receives this energy and uses it to power itself. It's a lot like an old AM crystal radio. The device transmits its number over and over at a very high bps for a high level of data redundancy.

There is a whole shitload more technical modulation theory and stuff that goes on here which I'm leaving out. If you aren't a ham or other radio type person it would probably be meaningless. Again if you would like more info, look here.

They put in in people inside a capsule thats the size of a grain of rice and most of that size is the capsule. The devices consist of a single TINY microchip (grain of sand size) and a very tiny inductor (two grains of sand size).

The devices are powered by received RF energy, which the "reader" transmits. This isn't crazy, remember crystal AM radios? Did you know that you can listen to AM stations using a reciever that's powered BY the AM signal? Did you know that you can string a long wire parallel to the power lines and steal power from the electric company via electrical induction?

You can read ALL about commercial RFID systems at http://www.microchip.com/1010/pline/frequency/rfca ts/rfid/index.htm, which manufactures a whole line of the devices.

I've done some robotics work before. In my experience, embedded controls is usually the way to go. If you want to make some really simple robots, start off with a nice little PIC processor. There are tons of pages dealing with them on the internet, and they are pretty cheap (between 8 and 20 dollars). You don't need anything too extravagant like hard drives attached to your robot, and you can build a serial interface to let it talk to your PC. They also sell C compilers for them (there might be a free version as well).

Another good processor is the Motorola HC16 (or the HC12 or the HC11). This series has many output ports for controlling the different motors that you might decide to hook up to your robot. However, buying one with an Evaluation Board may be a little expensive though.

Also, read up on pulse width modulation and controls algorithms, you need to use them a lot to make your motors go. Unfortunately, the motors can be the most expensive parts of the robot. The ones with motion sensors on them can cost quite a bit (I think the ones that we used in the RPI Robotics Lab were something like $130 each). You might be able to just get a hobby motor for much less, but do some research into the interfaces between the motors and the processor before you make any decisions.

Finally, if you look in catalogs like Digikey, a lot of the vendors sell robot kits. Some of these are based on PIC processors and others are based on easier stuff like BasicStamps. They are not very expensive and can be quite fun to play with

Good luck, and have fun!
-Montag

I think that the /. crowd has a tendency to be eth0 centric. CAN is better suited for the types of control applications described here. CAN, or Controller Area Network, is more popular in Europe than the US.

CAN supports more nodes, and at a greater distance than Ethernet. The latency typically associated with Ethernet is not present. CAN is used for sensors, and controls, where ethernet is more suited for transferring blocks of data.

Also the CAN protocol is built into the hardware on many 8 and 16bit microcontrollers. In fact you don't even need a microcontroller to manipulate a light switch or toaster.

MCP250XX CAN Input/Output (I/O) Expanders feature a CAN port to connect to a CAN network, and input/output functionality that can be manipulated over the BUS without a microcontroller in the system.

Microchip has more info.

Granted, ethernet is everywhere, and TCP/IP is used in everything, but you can put a CAN card in your PC and have a gateway to your home automation network. You CAN also attach a CAN adapter via RJ45, USB or RS232.

For more information about using CAN in automation see the website www.can-cia.com

Beans

Actually, there are some PIC 18 series microcontrollers with 128KB Flash now.

Don't know the timeline here, but PFE is the basis of Microchip's MPLab IDE for their PIC microcontrollers. Do we know if he just switched to commercial development for PFE? I still have PFE, started using it from my Win3.1 days. Very good.

Many microcontroller families now have parts that include support for USB, as an on-board peripheral. With one of these, building your own USB device shouldn't be too hard. I say "shouldn't", because I have yet to try it out for myself. I've looked a bit on the PIC16C745 part from Microchip. It has on-board USB support, but only for "interrupt" transfers (suitable for e.g. a mouse or keyboard, but not for something requiring data streaming). It's fairly cheap ($5.45 in ones from DigiKey), too. Of course, it's a one-time-programmable part, which isn't very good for experimentation. It's also available in a EPROM version, for $11.74), though. And you'd need to learn the PIC instruction set, and get the required programmer hardware... Still, I think it looks like at least a possible way to get in to doing your own USB devices. There are USB-enabled micros from other manufacturers as well, but I haven't looked into them in any detail. Search the web.

Many microcontroller families now have parts that include support for USB, as an on-board peripheral. With one of these, building your own USB device shouldn't be too hard. I say "shouldn't", because I have yet to try it out for myself. I've looked a bit on the PIC16C745 part from Microchip. It has on-board USB support, but only for "interrupt" transfers (suitable for e.g. a mouse or keyboard, but not for something requiring data streaming). It's fairly cheap ($5.45 in ones from DigiKey), too. Of course, it's a one-time-programmable part, which isn't very good for experimentation. It's also available in a EPROM version, for $11.74), though. And you'd need to learn the PIC instruction set, and get the required programmer hardware... Still, I think it looks like at least a possible way to get in to doing your own USB devices. There are USB-enabled micros from other manufacturers as well, but I haven't looked into them in any detail. Search the web.

One of the best examples from my personal experience is a fairly large 8-bit assembly language project I did (for an embedded PIC16C76-based product). The project has approx 25000 lines of assembly code distributed in about two dozen files (which built about a dozen different flavors of the product, though virtually no code was duplicated due to common code being used by includes... it really was about 25k lines of assembly!)

The first time another programmer worked on it, he of course complained that it wasn't commented very well and lacked documentation.

In fact, a quick grep ';' *.src | wc compared to a wc of all the files revealed that 34% of the lines had a comment (the vast majority the whole line was a comment, as I tend to write blocks of prose above sections to explain what they do, rather than a comment for each register move).

But if 8500 lines of comments wasn't enough, there was an 11-page document I wrote about the design of this firmware... about half of it was a "roadmap" that described the "larger picture" of the firmware and how it was arranged into the various files. The other half documented specific tricks (like a 6-instruction sequence including a skip-past-a-skip that achieves a 16 bit add/subtract in that PIC part which lacks carry input). There was also a lengthy discussion of the overall strategy for managing the various bank-swapped memory of that processor and some other stuff about the real-time performance (that was a hard real time application).

Learning is painful for most people, and learning someone elses code seems to be absolute agony for many engineers & programmers. They always complain that you didn't document/comment the code enough, even in an extreem case like this!

The first thing you need to do is to understand all the logic gates and how they work, and then work with the various logic gate chips (the 74 series) to get various simple experiments working. This will get you familiar with HOW the circuits are passing information around, as well as give you some experience with wiring the components together in a useful fashion.

Whilst you're reading up on this you'll probably find that most electronics text books include chapters on computers.

My personal favourite "The Art of Electronics" by Horowitz and Hill walks you through an example of incorporating a 68008 (I think, I haven't actually got my copy of it available at the moment) into an instrument (ie. specialized rather then general purpose computer) they construct in chapter 11.

If you want to start off really simple (think more of really simple programable calculator kind of level) then something more along the lines of a PIC 16fxx microcontroller from Microchip is a good starting point, as you can have something up and running very quickly with just a breadboard, the microcontroller and a handful of discrete components (and maybe some LED's for output) using a PC to program the device, and then slowly add to the base design with some external memory, and LCD display, a numeric keypad for input, and so on ...

I would wager that most of the people doing assembly coding now are in highly specialized fields, especially embedded programming.

As an embedded systems designer I can tell you that even here in the embedded world, assembly x86 is nowhere to be found, except for maybe in the lowlevel init. Even there, though, it's used to get the environment ready for C and calls a C function to start all the real work, very much in the same manner as the Linux kernel source shows.

Assembly programming is everywhere in the embedded world, just not x86 or anything powerful enough to be able to use a C compiler. I routinely do large Microchip PIC systems entirely in assembler, but that's only because of one of two reasons: they're not suited for C (the 18Cxxx is a different story now), or I need every last word of program and data space.

Well, first let's assume that this is not another of those "Dear Slashdot: Will You Please Do My Homework For Me?" submissions. I realize you were trying to be brief and concise, but in order to proceed with this design you will have to nail down some details first.

For instance, how many strings? I would assume it's more than one octave and less than five or so. Also, how many polyphonics do you want to support? That is, how many strings can be "played" (i.e. beam interrupted) at once? You can make the hardware really simple if you only support one string at once. But it wouldn't be very useful. A design in which you support full polyphony, where any possible combination can be played, will be more complex but it will also be more realistic. The whole idea here is that you can vastly reduce the number of i/o lines required if you do some encoding or grouping of the strings, at the price of not allowing certain combinations of strings to be simultaneously addressed. If you want this instrument to be practical, you must think hard about the multiplexing (if you go this route.)

Another thing to decide early on is whether you want to deal with velocity data. A decent midi keyboard will sense how hard you press the keys, and include this data in the midi stream. It would be really neat to detect how fast your photodetectors are covered by the fingers (to simulate plucking the string violently vs. gently strumming it), but this would add greatly to complexity, so I suggest avoiding it.

Don't be afraid to use multiple PICs. If I were doing this design I would consider a two-tier design. Perhaps a three dollar 16F627 for each octave, with one i/o line per string (this gets around the multiplex issue.) Unfortunately I don't think you will be able to use interrupt-on-change for every string, so these first tier chips would periodically scan their 12 strings for an event. You can do the debouncing in software, but it's probably easier to buffer the photodetectors with Schmitt triggers. Each of the first tier chips would talk to a central second tier chip which aggregates the events and encodes them as a midi stream. Those 16f627's have up to 15 i/o lines, so that leaves 3 for communication with the master. You could use something standard like I2C, or just invent your own protocol. You might be able to do something as simple as one data line and one handshake line (if you have a common clock for the whole unit) from each slave to the master. The idea here is that rather than a single chip constantly trying to keep track of the state of a number of strings, the master simply receives a few bits of data from one of the slaves whenever there's an event.

Anyway, those are my initial thoughts. The first thing you design should be the general architecture stuff, don't get bogged down in details. Have a general block-diagram sketch of the whole thing before you start building anything. Keep a notebook, and record all your design ideas, sketches, schematics, specs, etc. in one place. It will make your life much easier.

Brian

For general PIC support, there are a couple active mailing lists, the big one is the piclist, and there is a website that will give you plenty of (3rd party) info on the PIC and the mailing list. There is even some GNU/Linux work being done with Linux, try out Gnupic. Of course, you can always go to the manufacturer.

An excellent source of information on RFID basics (quite technical, actually) is Microchip, Inc.
RFID Design Guides

NB, they're in PDF format.

Ken

In retrospect, XM should have really considered a smartcard system like that of DirecTV. Those are crackable but they are a lot more difficult. Putting the authenticator on a damn EEPROM chip was just a stupid move, and it is certain to result in large-scale piracy.

~wally

Seriously though I happened to notice the specs at http://www.slimdevices.com/features.shtml, and that the CPU is a Microchip PIC16F877 : For anyone who has used one of these, you quickly learned that using the term CPU related to one of these is a bit of a misnomer.

Seriously though I happened to notice the specs at http://www.slimdevices.com/features.shtml, and that the CPU is a Microchip PIC16F877 : For anyone who has used one of these, you quickly learned that using the term CPU related to one of these is a bit of a misnomer.

Uses a basic stamp for interfacing? What a piece of shit (not to be base or anything). I'm sorry but any product that needs a eeprom dedicated to interpriting serial BASIC code is not something I would buy (not to mention it is slow as hell).

If they needed to use basic, they should be using something like the PicBASIC Compiler, which will optimize the equivalent code and compile it into hex (so there's no need for a basic interpriter on the board). It still boggels the mind as to why they would use a basic stamp when something like picbasic (or just learn pic asm! It's not hard!) on one of the new higher end PIC Micros (like the 17Fx series... here) with 16K of flash memory. BS Stamps use one of these themselves (though I think they use the older 16F84), but the code is stored onboard as BASIC and then interprited through a seperate serial line and micro controller.

Other than that, i still think it's just stupid. There's only one good reason to have a computer in your car....

While their growth stagnates, Microchip has taken off...

I used to love my Linux laptop about 2 years ago, I felt so sophisticated. Tell you the truth I am running w2k on it now (A Sony Vaio), just wasn't worth the trouble. Then my box runs Linux (RH) and I do most of my java development on it, I am very happy with it.

I've been running Linux on my laptop for about a year now. Used to be Win98 but one day I just got sick of rebooting and reinstalling every 12-18 months. I'd been using Linux on all my servers and firewalls so I figured why not give it a try on the desktop?

I run Slackware 8.0 with XF4.1.0 with WindowMaker and KDE2.2.1 from CVS (I hack around on it a bit) -- the antialised fonts are great, the screen works perfectly, the video card, PCMCIA, sound and USB subsystems are all supported more or less flawlessly. I'm having issues with printing but I think I'm going to dump CUPS and try LPRng or something; I'm getting sick of fiddling with it.

I used to run Win4Lin daily to get the office aspects of my job done but now the only time I boot it is to run MPLAB, an IDE which drives the ICE I use in my embedded development. KOffice does 99% of my office needs and KMail/KNode work pretty damn good for POP3/IMAP and NNTP handlers. What Konqueror bungs up on Opera seems to take care of.

This laptop is about 3 or 4 years old now. It's a Hyperdata MediaGo 950AGP: Celeron 300, 256M RAM and a 10G drive. I get about 3 hours of battery life out of the thing, even watching DVDs (that was back in Windows when the ALI M3909 hardware MPEG2 decoder worked). If I'm doing heavy compiling then drop that time down about 40-50%. The notebook doesn't get overly warm in my lap and its sleep mode seems to be compatible with Linux for the most part. Hell, I take multiple-hour baths and surf the net/IRC with it (wireless card) -- I have one of those old wrought-iron claw-foot tubs which holds the heat forever and a 3/8" sheet of plywood goes across it to rest the notebook or any books and drinks I have. Yeah it's a little weird but it's a form of relaxation. :-)

So, at least for me, it hasn't been more hassle than its worth. Win98 was a hassle. Win2k won't work on this machine (the install freezes every time, Hyperdata support claims there is something not supported by Win2k). Linux has been a godsend for me. I've been offered notebook upgrades from work but I've really come to like this little one. I've even ordered plastic subassemblies a few times to repair cracks from overuse and misuse (I tend to pick it up by one corner and that strains one of the shell pieces).

aside: if anyone can find drivers or specs for the M3909 MPEG2 decoder I'd love to hear from you. I don't understand why they EOL a product and still refuse to give out data on it. A cel300 is a little weak for DVD/DivX decode so I'd at least like to try for half. Hell, this thing has an ATI Rage Mobility graphics chip in it; if ATI would release a Linux DVD player I'd be happy too!