Bruce Perens (who did Busybox and Debian as well as defining "Open Source") has created an Open Hardware Journal (http://openhardware.org/journal/). Check out the first issue, I've got two articles in it! Ok ok, probably he needed more submissions which is why my stuff made the cut :-). But hey I'll take it!
The first article "An Open Hardware Platform for USB Firmware Updates and
General USB Development" is about the USB interface on the Lightuino. I chose that topic because this interface is a cheap and tiny way to put USB in many of your projects. The interface will talk SPI to your uP or some SPI chip, or I2C (although I did not use that in the Lightuino). And it will do serial (USB CDC ACM if you need the formal acronym) or emulate an input device (USB HID). Read the article for more info, and check out my code on github here: https://github.com/gandrewstone/toastedCypressUsb
My second article "A Return To Open Devices" is about my ideas around the philosophy and driving forces behind the open hardware movement. I'm sure the people who come to open hardware do it for many different reasons; this is simply my perspective.
Wednesday, November 2, 2011
Friday, September 9, 2011
DIY Surface Mount Workshop
A few days ago I held a workshop on do-it-yourself (aka cheap) surface mount electronics techniques at a Boston artspace/hackerspace called sprout & co (http://thesprouts.org/). This was organized through the Boston Arduino meetup group. Participants got to mount a tiny QFN-24 chip (a PCA9555 io-expander) onto a QFN breakout board and then we tested them by connecting them up to an Arduino. There was one bad chip; but once that was replaced everybody's boards worked!
Here are my notes from the workshop. If you did not attend, these notes are a good tutorial on how to get started cheaply! Also, if you'd like some of the QFN breakout boards, please contact me and I will sell you a few.
Surface Mount Tools (homemade/modified):
Toaster Oven:
Got mine from the dump. Keep it simple; you don't
need to mod it with fancy temperature feedback like some web posts suggest.
Hot air “pencil”:
$30 used heat
gun (ebay) with aluminum foil to narrow and speed the air jet. Secure the aluminum foil by wrapping steel wire around the nozzle. Shape the hole in the end by forming it around a pen with your fingers. This tool is indispensable for removing and replacing chips (rework), and works great!
Cheap plastic Mechanical Pencil:
Pencil lead solder paste onto pins;
eraser dabs off too much.
PCB Vice:
You can use any clamp like this. You can probably get one for less then $10 if you look around. Just drill a hole in your desk slightly smaller then the clamp bar and stick it in upside down.
Here it is holding the boards we made, with my breadboard-to-IDE-or-RJ-45 connector in the background.
Here it is holding the boards we made, with my breadboard-to-IDE-or-RJ-45 connector in the background.
But once you do this fairly often you'll want to upgrade to a Panavise.
Soldering Iron:
You CAN use a standard cheapo wide tip soldering iron for SMT rework -- even though you can't touch just a single pin, it is sufficient to heat a single pin.
However, knockoffs of the "Hakko 936" soldering iron are pretty cheap at $50; check Amazon or ebay. And they are all you'll ever need...
Tweezers:
You use these to hand "pick-and-place" chips. Buy them from a drugstore. But don't buy the cheapest pair you can find. Buy a set that looks totally overkill for plucking nose hairs :-) -- like they were milled out of a block of metal.
Magnifying glass/bright light:
You may need these to peek at the board as it is cooking, and for rework. I'm sure you can do it on the cheap. I have a "helping hands" for the glass:
Supplies:
Solder wire:
Get thin rosin core solder
Solder Paste:
Solder paste are tiny balls of solder in a flux mix that is viscous like toothpaste. It can be very expensive and require refrigeration. Don't buy that. Buy this Lodestar paste from DealExtreme. It does not require refrigeration, however, as a hobbyist you should refrigerate it so it will last you forever.
Flux:
Flux is a substance that cleans your PCB and lets the solder flow better. It is also available at DealExtreme. They often mis-name it "paste" but you'll know it is flux only because it won't be grey. Get "no-clean" or "neutral PH" (its almost all like that now).
Solder Remover Braid:
This braid is necessary to remove excess solder when doing fine SMT work. Solder suckers don't work!
Step 1:
Use an oven to solder a QFN-24 part onto a breakout board.
Mix a TINY bit of solder paste and flux to about a 60/40 mix. You don't need much. Put any extra back into the container since it contains lead so its good to generate as little hazardous waste as possible...
Too much paste and the solder will not wick onto the pads (it will stay on the non-metal parts of the PCB or create bridges between pads -- "pads" are the metal parts of the PCB that you are trying to solder the chip's wires "pins" to)
Too much flux and the pins won't be soldered.
Apply with your mechanical pencil (click out the lead). For
tiny QFN leads, just draw your pencil straight across all the leads. That is, cover the entire surface including between the
leads. This is important so let me emphasize: Don't try to keep the paste out of the 6mil space between the leads! That is impossible & when heated the flux will cause the paste to flow to the pads anyway.
But if there is a center square pad, use the pencil to
draw around that pad to clean any paste that would bridge the center pad to a lead (it is
very hard to fix that issue).
You need to apply a thin layer. You should be able to see the shape of the pads under the paste, but they should be obscured. But if the paste goes on clear, with just a few "dirty" spots you have too much flux in your mix.
Next, put the chip on with tweezers. Positioning is not critical; you can be off by a half-pin in any direction. When hot, the chip will actually float on the flux layer and surface tension will actually cause the chip to be sucked onto the pads! But if you are off by more then a half-pin, the chip might be sucked onto the wrong set of pads.
Now bake your board. You need to bake the board in a particular fashion, but its not rocket science.
Here is an example provided by Kester paste. It works fine for any paste:
Basically, you want to raise the board to 150C in a minute or two. Then wait for another minute or two so the entire board gets to that heat. This bakes out any water and lets everything expand (if you chip pops like a firecracker its ruined. You have too much water in those chips and need to bake the rest at low heat for hours to evaporate it out; its only ever happened once to me).
Next, you
bring the heat up to a max of 220-240C rapidly to melt all the solder
paste. Excessive exposure to this heat can harm the chips or melt
plastic parts so you want to keep this brief. At this point, use your
magnifying glass and a bright light to watch the paste on the board. It
will go from grey to bright shiny silver when melted (bubbling is just the flux moving around). Wait 10 more seconds after you see no more grey to make sure solder you can't see also melts. Then turn the oven off.
Now you have a choice. You can either wait with the oven door closed so the oven cools down slowly (as shown on the heat profile). Cooling slowly will mean there are fewer mechanical stresses on the board.
Or if you see any problems, you can open the oven door, pull out the tray and
reposition “tombstone” (sticking up) resistors and caps. Also if a chip is out of alignment (off by one pin for example), you can “tap”
the chip to make it position itself! When doing multiple bigger boards, you'll often find a few issues.
I'd imagine that while this cools the board faster, it is probably still less stressful then heating a portion of the board with your "air pencil". That is the only other way to reposition chips.
Debugging
Now that your board is baked and cooled, you need to visually inspect it. Look for bridges (2 pins connected) and unsoldered pins. A bridge will look more shiny then the other pins since it is a bigger solder blob. Unsoldered pins will look darker.
Unsoldered:
Apply a tiny bit of paste to solder pins. Heat the pin (and perhaps nearby pins) with an iron to melt the solder. Often you'll have added too much paste, so now check for bridges.
Bridges:
Use flux to cause the bridge to flow onto nearby pads/pins. This only works if the bridge is not caused by too much solder.
Use copper solder remover wire (braid) to
remove solder. I guess this is often misused. This is how you do it:
Touch braid to you can of flux to get a tiny bit on it)
Put the braid onto the bridge part so it complete covers it (and probably a bunch more pins).
Heat the braid by using the iron to press
it into the bridge where you want to remove the solder.
The braid won't work if its not hot!!! So heat it and cause its heat to melt the solder.
If the braid is at all silver, clip it and throw that part away; it has already sucked up solder.
Speed solder headers
Next we need to solder long headers onto the board. There is a fast technique to do a row of pins that I will show. Eventually you should be able to do about a pin per second or two.
First, clip/break the pin header so it contains the right number of pins.
Next put the headers in the solderless breadboard; and put the PCB on top. This gets them aligned correctly. Use the PCB to seat them into the breadboard. This will keep the board steady as you solder it.
Now its often good to solder the ends to make sure the PCB stays firmly seated against the pin header, but as you get better you can skip this step.
Now use the speed solder technique to do the rest. Here's a video:
Here I am doing pins on both sides of the iron, so heating 6 pins simultaneously. But you should stick with one side for now.
Use an overhand grip on the iron so it can be placed flush along the pins.
Heat 3 pins simultaneously.
Preheat pin -- using iron tip
Middle pin -- focus on soldering it
3rd pin -- continue to heat to make a good solder joint
I noticed most people using not nearly enough solder. Feed the solder so fast that there is a large constant blob of solder on the iron. This solder blob is essential to transfer heat to the pins. As you push your iron across the pins it will actually clean up this excess solder (if not, your iron is too cold, or you aren't using rosin core solder). Actually you may end up with a few bridges, but those are easy (and quick) to fix once the job is done. Just hold a "dry" iron against the bridge and it should grab the excess. And look for any holes you missed; as a beginner you'll have one or two!
Testing: Hook up the breakout board
Read the spec to hook up the board. Really. This is a great exercise and very important to get correct. Because if you are trying a new PCB, new software, and a new chip you want to make sure you get something right! :-) But ok, Ryan Feeney was kind enough to help you out with this image:
In this image, GND are the blue rows on both sides and 5v are the red ones (connect them to GND and 5v on your Arduino).
One other trick; if you don't have a handy 3.3v power supply, you can use a red LED to reduce 5v to 3.3v. This will work up to about 20mA; beyond that your LED will burn out so use multiples!
Testing: The sample sketch
The sketch I used is located at: http://i2cdevices.svn.sourceforge.net/viewvc/i2cdevices/latest/ioexpander/pca9555/pca9555.pde?revision=1
Someday I might actually put other i2c devices in there too! :-)
It should blink the LED.
Hot air rework exercise
Some of you got to do or see this, because we had a dead chip.
In this exercise we'll use the hot air "pencil" to remove a chip and then replace it with a new one.
First, use aluminum foil and metal boxes to cover and protect other chips (and plastic headers). Well, there is nothing really to protect in the breakout board except for the plastic vise jaws -- but for a "real" board you'll need this.
Heat the chip with slow motions of the heat gun. When the solder on the edges goes shiny, pluck/knock it off with tweezers.
If there is a lot of solder on the pads then clean it with flux and solder remover. Put a little more paste on the pads.
Touch the new chip in the flux can to just get a TINY bit of flux on its pads
Place the new chip right near, but not on, the pads. This will cause the chip to heat up with the pads. The chip's leads have to be hot enough to melt the solder or the solder won't stick to it! Its the SMT equivalent of a "cold" solder joint.
Reheat with the hot air "pencil". When the solder melts (it goes shiny) it should wick to the pads so there is no bridges. If there are bridges you have too much solder or not enough flux. When it wicks correctly, tap the chip with tweezers to move it into place. You should see it "snap" or "pop" into place as the surface tension of each pad/lead pulls the chip. Heat for maybe 10 more seconds to make sure all the chip's leads were hot enough and then you are done!
Thanks! Please go forth and build open source hardware!!
Thursday, June 16, 2011
RSD GameMaker
Recreational Software Designs GameMaker product was a program that ran on the IBM PC machines around 1991-1995, sold in the USA, UK and Korea. I recently became aware of some efforts by the community at diygamer, specifically Eric-Jon to gather information about the program. He has written 20 or so posts about games that users created, see http://www.diygamer.com/author/eric/, and also created a wiki that attempts to capture the history about the community at
http://www.aderack.com/game-maker/index.php?title=Main_Page .
I was the creator and major author of the software, and was helped by my father who handled most business issues, my brother who also did some coding, and my mother who did GUI testing and made some games. We also had a friend of my father who graciously spent a few weekends sitting with me giving guidance (Thanks Pete!)
It was basically a toolkit that let you create your own platform-style (of course we did not call it that back then!) games.
As the creator of a very small piece of history (but one that seems to have a major effect on those who used it well, spawning passions and careers around programming, graphics, and games -- Google "RSD GameMaker"), I shall indulge in a very small soapbox so you can hear my thoughts and ramblings on the subject :-).
I think perhaps that in retrospect GameMaker's history may be interesting for a few reasons.
The first Game Creation Engine?
First of all, it obviously was the "diygamer" tool of that time, so it anticipated the thriving community we have today with countless game engines, web sites and indie game companies. I hear that it was preceded by a game maker on the Commodore machine, but I had/still have no knowledge of that software. As far as I knew, we were the first game engine in existence and we allowed games to be built with absolutely no programming (and ran up against the limitations that imposed as well)! But in the interest of complete disclosure, I believe that at that time professional game companies were also buying game engines for major $ to aid in game development. Very little information is available about these professional engines since at that time -- a time of game-feature "brinkmanship" -- the information was closely held.
Anticipating Creative Commons and the Remix Culture
Second, we shipped the software with a bunch of sample games and encouraged users to borrow and reuse our content. We also worked with a BBS owner (bulletin board system -- it was a precursor to the internet) to have an "official" community sharing repository. Also, I deliberately (in fact I remember an argument about it) made no effort to protect a game's content -- anyone could load up anyone else's game in the editors. My feeling was that if you were sophisticated enough to build a game that really needed protection, you could wrap it in your own encrypted .zip file or something. This philosophy emerged from knowledge of shareware licenses, but AFAIK is probably the first adaptation of the philosophy for content, not code. Today, the "creative commons" has standard licenses covering all manner of content.
And a lot of people did reuse our stuff (and other game authors)! In that way it anticipated today's emerging remix culture. If I remember correctly (and I may not), I was the one who decided to share all of the content shipped on our CD and disks while my father should receive credit for encouraging the community, through user letters (yes back then we got HANDWRITTEN letters, I still have a huge stack of them), the community BBS, and the GameMaker Exchange (which was sort of a "mail us your game & we'll mail it to other people" thing). But of course as a family company these decisions were often made around the dinner table. We also decided to buy (and beg) some games from our best users and ship them with the 3.0 version of our product in a "remixable" license.
Teen Hackers!
Third it was really a major piece of software built by teenagers, mostly for teenagers. This probably makes it pretty unique, if not completely unique. It consisted of 16000 lines of "c" code, 2000 lines of hard core x86 assembler, and 1000 lines of C++ (versions 1 & 2 predated the emergence of C++). So about 20000 lines of code total. 'Sloccount' (a Linux software line counting program) puts this at 4.5 man-years of effort with a $600000 price tag (assuming developer salary $50k 2010 dollars). But we did it during high school and college.
Sure we had adult supervision (and funding and support -- I can't overemphasise how supportive my parents were!!!), but at the same time we wrote all the code and essentially came up with the content entirely ourselves (with our user's input of course). If GameMaker somehow fast-forwarded itself to 2010, it likely would have been entirely teenager-driven. However, in the internetless world of the '90's there were countless costs -- lots of expensive advertising, CDs to print (sorry no CD burners), boxes and user manuals made, mailers, and on and on. I remain amazed that my parents put that kind of cash at risk for this effort.
Breathing Life into the DIY Culture
GameMaker was part of the DIY and programming culture of the 90's. I would love to see what my users are doing now. You have to be a certain kind of person to look through a magazine full of ads for instant-gratification twitch games and pick the software that makes you WORK hard. I would guess that we managed to pre-select the most creative individuals; a feat that our educational system has a very hard time doing.
Also I think that it is probably possible to trace a certain (changing) subset of the population throughout US history. Call them tinkerers, creative minds -- just people who like to do their own thing. And I am proud to have been an enabler of this culture in the 90's.
I see it in automobiles and phone systems in the 50s and 60s to the transistor (hi-fi) radio kits (hobbiest electronics), to the early garage build-your-own computers of the mid-70s and early 80s, the software of the mid-80s to mid-90s, all the web software, blogging etc from the mid-90s to sometime in the 2000s, and finally the emerging custom open-source hardware culture of the 2010s (www.arduino.cc, www.adafruit.com, and my own www.toastedcircuits.com). I fully expect that 2020 will see ubiquituous desktop manufacturing with communities not focused on building desktop manufacturing machines (as exists today) but focused on what can be made. By 2050 we'll probably be designing our own plants and animals, probably with an incompatible biology for obvious reasons.
Software Archaeology
Finally, it is an interesting piece of computer archaeology as its "heyday" fortuitously happened at the end of the prehistoric times (as people years from now will see these dark ages before the emergence of the global hive mind and recording device we call the internet).
What can be recovered by reaching back across the curtain? This is quite an interesting question and many scholarly articles have considered it (I have read several articles in Scientific American on this subject over the past decade for instance). These articles tend to warn against electronic media for pretty obvious reasons. Quick summary: Your grandkids find a 3.5" floppy (or CDROM) in the attic. Will they even recognise it as electronic media? How will they read it without a disk drive? Even if they manage to get the bits, will modern computers be able to run the programs, read the documents, play the movies?
Well, for GameMaker, it turns out that quite a lot is possible! You can even play the created games in a Java simulator called "DOSbox" in the wiki posted in the first paragraph of this article. For me, it was quite a trip to play games (and see the GameMaker software on Youtube) that I created 15 years ago. You results may vary. Remember, these were games built 15 years ago mostly by teenagers! Please don't go in there expecting amazing stuff -- go in there amazed that these kids could put together this stuff at all! But if you hunt for gems of creativity I promise you'll find some.
Software Obscurity
And what did I do after GameMaker? Have I been washing windows for 20 years? No I've been writing vast quantities of code in various startup companies which have been sold for a sum total of approximately a half billion dollars. But all that code is gone. A company gets sold, the product is either canned or is successful for a few years. Then it is done. Can I get my code for the next project? No.
I have even attempted to purchase some from prior employers. No dice, price does not matter, the company is not in the business of selling its software, so its just not possible to find a manager willing to even consider the proposition. Because what if hidden in that chunk of software is something really important?
So if there ever was an argument for open source software and open source content then this is it! As engineers in corporate America (and elsewhere) we build machines for obscurity. We write novels to be read by no-one. We architect palaces of structured information that shall soon disappear.
Let's try to do that as little as possible.
G. Andrew Stone
2011
---
The next episodes of this little blog may delve in more detail about RSD and GameMaker's history, etc. Perhaps only interesting to those who actually used it.
http://www.aderack.com/game-
I was the creator and major author of the software, and was helped by my father who handled most business issues, my brother who also did some coding, and my mother who did GUI testing and made some games. We also had a friend of my father who graciously spent a few weekends sitting with me giving guidance (Thanks Pete!)
It was basically a toolkit that let you create your own platform-style (of course we did not call it that back then!) games.
As the creator of a very small piece of history (but one that seems to have a major effect on those who used it well, spawning passions and careers around programming, graphics, and games -- Google "RSD GameMaker"), I shall indulge in a very small soapbox so you can hear my thoughts and ramblings on the subject :-).
I think perhaps that in retrospect GameMaker's history may be interesting for a few reasons.
The first Game Creation Engine?
First of all, it obviously was the "diygamer" tool of that time, so it anticipated the thriving community we have today with countless game engines, web sites and indie game companies. I hear that it was preceded by a game maker on the Commodore machine, but I had/still have no knowledge of that software. As far as I knew, we were the first game engine in existence and we allowed games to be built with absolutely no programming (and ran up against the limitations that imposed as well)! But in the interest of complete disclosure, I believe that at that time professional game companies were also buying game engines for major $ to aid in game development. Very little information is available about these professional engines since at that time -- a time of game-feature "brinkmanship" -- the information was closely held.
Anticipating Creative Commons and the Remix Culture
Second, we shipped the software with a bunch of sample games and encouraged users to borrow and reuse our content. We also worked with a BBS owner (bulletin board system -- it was a precursor to the internet) to have an "official" community sharing repository. Also, I deliberately (in fact I remember an argument about it) made no effort to protect a game's content -- anyone could load up anyone else's game in the editors. My feeling was that if you were sophisticated enough to build a game that really needed protection, you could wrap it in your own encrypted .zip file or something. This philosophy emerged from knowledge of shareware licenses, but AFAIK is probably the first adaptation of the philosophy for content, not code. Today, the "creative commons" has standard licenses covering all manner of content.
And a lot of people did reuse our stuff (and other game authors)! In that way it anticipated today's emerging remix culture. If I remember correctly (and I may not), I was the one who decided to share all of the content shipped on our CD and disks while my father should receive credit for encouraging the community, through user letters (yes back then we got HANDWRITTEN letters, I still have a huge stack of them), the community BBS, and the GameMaker Exchange (which was sort of a "mail us your game & we'll mail it to other people" thing). But of course as a family company these decisions were often made around the dinner table. We also decided to buy (and beg) some games from our best users and ship them with the 3.0 version of our product in a "remixable" license.
Teen Hackers!
Third it was really a major piece of software built by teenagers, mostly for teenagers. This probably makes it pretty unique, if not completely unique. It consisted of 16000 lines of "c" code, 2000 lines of hard core x86 assembler, and 1000 lines of C++ (versions 1 & 2 predated the emergence of C++). So about 20000 lines of code total. 'Sloccount' (a Linux software line counting program) puts this at 4.5 man-years of effort with a $600000 price tag (assuming developer salary $50k 2010 dollars). But we did it during high school and college.
Sure we had adult supervision (and funding and support -- I can't overemphasise how supportive my parents were!!!), but at the same time we wrote all the code and essentially came up with the content entirely ourselves (with our user's input of course). If GameMaker somehow fast-forwarded itself to 2010, it likely would have been entirely teenager-driven. However, in the internetless world of the '90's there were countless costs -- lots of expensive advertising, CDs to print (sorry no CD burners), boxes and user manuals made, mailers, and on and on. I remain amazed that my parents put that kind of cash at risk for this effort.
Breathing Life into the DIY Culture
GameMaker was part of the DIY and programming culture of the 90's. I would love to see what my users are doing now. You have to be a certain kind of person to look through a magazine full of ads for instant-gratification twitch games and pick the software that makes you WORK hard. I would guess that we managed to pre-select the most creative individuals; a feat that our educational system has a very hard time doing.
Also I think that it is probably possible to trace a certain (changing) subset of the population throughout US history. Call them tinkerers, creative minds -- just people who like to do their own thing. And I am proud to have been an enabler of this culture in the 90's.
I see it in automobiles and phone systems in the 50s and 60s to the transistor (hi-fi) radio kits (hobbiest electronics), to the early garage build-your-own computers of the mid-70s and early 80s, the software of the mid-80s to mid-90s, all the web software, blogging etc from the mid-90s to sometime in the 2000s, and finally the emerging custom open-source hardware culture of the 2010s (www.arduino.cc, www.adafruit.com, and my own www.toastedcircuits.com). I fully expect that 2020 will see ubiquituous desktop manufacturing with communities not focused on building desktop manufacturing machines (as exists today) but focused on what can be made. By 2050 we'll probably be designing our own plants and animals, probably with an incompatible biology for obvious reasons.
Software Archaeology
Finally, it is an interesting piece of computer archaeology as its "heyday" fortuitously happened at the end of the prehistoric times (as people years from now will see these dark ages before the emergence of the global hive mind and recording device we call the internet).
What can be recovered by reaching back across the curtain? This is quite an interesting question and many scholarly articles have considered it (I have read several articles in Scientific American on this subject over the past decade for instance). These articles tend to warn against electronic media for pretty obvious reasons. Quick summary: Your grandkids find a 3.5" floppy (or CDROM) in the attic. Will they even recognise it as electronic media? How will they read it without a disk drive? Even if they manage to get the bits, will modern computers be able to run the programs, read the documents, play the movies?
Well, for GameMaker, it turns out that quite a lot is possible! You can even play the created games in a Java simulator called "DOSbox" in the wiki posted in the first paragraph of this article. For me, it was quite a trip to play games (and see the GameMaker software on Youtube) that I created 15 years ago. You results may vary. Remember, these were games built 15 years ago mostly by teenagers! Please don't go in there expecting amazing stuff -- go in there amazed that these kids could put together this stuff at all! But if you hunt for gems of creativity I promise you'll find some.
Software Obscurity
And what did I do after GameMaker? Have I been washing windows for 20 years? No I've been writing vast quantities of code in various startup companies which have been sold for a sum total of approximately a half billion dollars. But all that code is gone. A company gets sold, the product is either canned or is successful for a few years. Then it is done. Can I get my code for the next project? No.
I have even attempted to purchase some from prior employers. No dice, price does not matter, the company is not in the business of selling its software, so its just not possible to find a manager willing to even consider the proposition. Because what if hidden in that chunk of software is something really important?
So if there ever was an argument for open source software and open source content then this is it! As engineers in corporate America (and elsewhere) we build machines for obscurity. We write novels to be read by no-one. We architect palaces of structured information that shall soon disappear.
Let's try to do that as little as possible.
G. Andrew Stone
2011
---
The next episodes of this little blog may delve in more detail about RSD and GameMaker's history, etc. Perhaps only interesting to those who actually used it.
Sunday, October 10, 2010
Lattice XP2 Brevia Diamond Starter Project
Its a royal PITA to specify the pinout of a 144 pin part! So there is no point to doing this more than once -- across the entire internet.
Its unfortunate that Lattice does not provide one, but their Demo project does not specify the IOs since they are not used.
In my code repository is a Diamond project that specifies all XP2 IOs as used by the Brevia board. And it sets the XP2 part up with 3 clocks, 400mhz, 50mhz, and 25mhz. Of course you can change these clock values by editing the "pll" module.
You checkout the entire project (recommended), or browse and pull down the key files to add into your own project:
top.v: the "main" verilog file
starter1.lpf: the file that places the verilog symbols onto particular pins
pll.v: autogenerated pll module that sets up the 3 clocks.
Its unfortunate that Lattice does not provide one, but their Demo project does not specify the IOs since they are not used.
In my code repository is a Diamond project that specifies all XP2 IOs as used by the Brevia board. And it sets the XP2 part up with 3 clocks, 400mhz, 50mhz, and 25mhz. Of course you can change these clock values by editing the "pll" module.
You checkout the entire project (recommended), or browse and pull down the key files to add into your own project:
top.v: the "main" verilog file
starter1.lpf: the file that places the verilog symbols onto particular pins
pll.v: autogenerated pll module that sets up the 3 clocks.
Tuesday, October 5, 2010
Lattice Diamond on Ubuntu 10.04 64 bit
For some reason, Lattice provides its new Diamond GUI for the second most popular Linux distribution instead of Ubuntu, the most popular distribution.
Here is how to fix their mistake :-). Additionally, they only provide 32 bit binaries but I have a 64 bit system. So this how-to solves that problem as well.
Installing the IDE
Step 1: Download Diamond's .rpm located here, and apply for a license.
Step 2: Install "alien", the .rpm to .deb package converter.
sudo apt-get install alien
Step 3: install "getlibs"
This handy script will install the 32-bit version of libraries even if you are running 64-bit Ubuntu. Since Diamond is 32 bit you will have to install some 32 bit stuff.
click here for info (http://ubuntuforums.org/showthread.php?t=474790)
Step 4: Install 32 bit libraries (if on 64 bit Ubuntu)
apt-get install ia-32libs
sudo getlibs -p libmotif3
I am doing this from memory...if you run diamond (later step) and get a missing .so, please run "getlibs -l" to install that library and post a comment so I can update this HOW-TO!
Step 5: Run alien on the diamond RPM.
When the diamond RPM is downloaded, run alien on it:
alien -d diamond_1_0-base-135-i386-linux.rpm
Wait for a very long time. This will ultimately have an error and drop you back to the Linux prompt. It will not hang (be patient). However you will find that it created a subdirectory called "diamond_1_0-base-1.0" off your current directory. Everything we need is in there. I'll copy it to /usr/local so it is accessible:
sudo cp -r diamond_1_0-base-1.0/usr/local /usr/local
Step 6: Copy the license
You should have gotten a license file in your email stream from step 1.
Save that file into the diamond subdirectory: /usr/local/diamond/1.0/license/license.txt
Step 7: Run it!
/usr/local/diamond/1.0/bin/lin/diamond
if you get any missing libraries, please attempt to "getlibs" (see step 4) and post a comment here so others can benefit from your pain :-).
Installing the Lattice USB Programmer
Before you actually program your board, you'll have to install drivers for the programmer dongle.
The Lattice USB programmer uses libusb so that is convenient as no kernel module needs to be built. I think there is another programmer that uses the FTDI 2232 chip that does require drivers to be installed. This how-to won't cover that one, or the parallel port programmer (which I was unable to get working).
Step 1: install libusb
sudo apt-get install libusb-1.0-0
Step 2: Add the USB device to "udev"
sudo emacs /etc/udev/rules.d/10-local.rules
Append this line:
#lattice
BUS=="usb",ACTION=="add",SYSFS{idVendor}=="1134",SYSFS{idProduct}=="8001",MODE=="0660",OWNER=="root",SYMLINK+="lattice-%n"
Step 3: Plug in the USB device programmer
You should see a device in /dev named "lattice":
~$ ls /dev/lat*
/dev/lattice-6
Step 4: Fix permissions.
Shown here is an impermanent fix. Every time you turn off your computer or remove the programmer you'll have to re-run this, since the device is removed and recreated during these events. I'm sure that some of you Ubuntu/Linux wizards can tell me how to make it permanent...
sudo chmod a+rw /dev/lat*
That's it! The ispVM programming tool should auto-detect the cable now.
Have fun and post some OSS designs!
Here is how to fix their mistake :-). Additionally, they only provide 32 bit binaries but I have a 64 bit system. So this how-to solves that problem as well.
Installing the IDE
Step 1: Download Diamond's .rpm located here, and apply for a license.
Step 2: Install "alien", the .rpm to .deb package converter.
sudo apt-get install alien
Step 3: install "getlibs"
This handy script will install the 32-bit version of libraries even if you are running 64-bit Ubuntu. Since Diamond is 32 bit you will have to install some 32 bit stuff.
click here for info (http://ubuntuforums.org/showthread.php?t=474790)
Step 4: Install 32 bit libraries (if on 64 bit Ubuntu)
apt-get install ia-32libs
sudo getlibs -p libmotif3
I am doing this from memory...if you run diamond (later step) and get a missing .so, please run "getlibs -l
Step 5: Run alien on the diamond RPM.
When the diamond RPM is downloaded, run alien on it:
alien -d diamond_1_0-base-135-i386-linux.rpm
Wait for a very long time. This will ultimately have an error and drop you back to the Linux prompt. It will not hang (be patient). However you will find that it created a subdirectory called "diamond_1_0-base-1.0" off your current directory. Everything we need is in there. I'll copy it to /usr/local so it is accessible:
sudo cp -r diamond_1_0-base-1.0/usr/local /usr/local
Step 6: Copy the license
You should have gotten a license file in your email stream from step 1.
Save that file into the diamond subdirectory: /usr/local/diamond/1.0/license/license.txt
Step 7: Run it!
/usr/local/diamond/1.0/bin/lin/diamond
if you get any missing libraries, please attempt to "getlibs" (see step 4) and post a comment here so others can benefit from your pain :-).
Installing the Lattice USB Programmer
Before you actually program your board, you'll have to install drivers for the programmer dongle.
The Lattice USB programmer uses libusb so that is convenient as no kernel module needs to be built. I think there is another programmer that uses the FTDI 2232 chip that does require drivers to be installed. This how-to won't cover that one, or the parallel port programmer (which I was unable to get working).
Step 1: install libusb
sudo apt-get install libusb-1.0-0
Step 2: Add the USB device to "udev"
sudo emacs /etc/udev/rules.d/10-local.rules
Append this line:
#lattice
BUS=="usb",ACTION=="add",SYSFS{idVendor}=="1134",SYSFS{idProduct}=="8001",MODE=="0660",OWNER=="root",SYMLINK+="lattice-%n"
Step 3: Plug in the USB device programmer
You should see a device in /dev named "lattice":
~$ ls /dev/lat*
/dev/lattice-6
Step 4: Fix permissions.
Shown here is an impermanent fix. Every time you turn off your computer or remove the programmer you'll have to re-run this, since the device is removed and recreated during these events. I'm sure that some of you Ubuntu/Linux wizards can tell me how to make it permanent...
sudo chmod a+rw /dev/lat*
That's it! The ispVM programming tool should auto-detect the cable now.
Have fun and post some OSS designs!
Monday, October 4, 2010
Lattice FPGA -- They are beginning to get OSS
After a quite a bit of comparative evaluation I chose the Lattice XP2 FPGA and the Brevia demo board for a bit of hardware hacking. (In short, I wanted a non-volatile FPGA or large CPLD, and found that the XP2 and MachXO seemed better than the Altera and Xilinx offerings).
And I'm happy to say that unlike my prior complaints about Cypress, I do think that Lattice "gets it" around open source hardware.
Al is not perfect, but they seem to be moving rapidly in the right direction.
First off, they recently obsoleted their old GUI and released their "Diamond" GUI for both Windows and Linux. Its a little crunchy still on Linux. However, this is a major, probably very expensive, initiative and Lattice should be commended for letting Linux be part of it! While they officially only support Red Hat, check out this output coming from the "compiler":
Warning: You are running on an unsupported platform
'synplify_pro' only supports Red Hat Enterprise Linux 4.0 and above
current platform: Ubuntu 10.04.1 LTS
That's right! I managed to get it up on Ubuntu 64 bit (I'll provide a little HOW TO in my next post).
Secondly, they priced the board extremely well at $29.
Third, they provide a lot of free libraries (called "designs" or "IP" in the hardware world) so long as you only use them on Lattice parts. Personally, I can live with that. After all Lattice is in the business of selling chips. And you know if I decide to switch chips, I can implement the underlying library myself and still have benefited from using Lattice's library to get me prototyping my application code faster...
Fourth, the GUI/compiler is free (well, its a 1 year free license so I guess someday they could take that away) and command line accessible.
Fifth, the USB programmer uses libusb, so you don't even need to install a special driver. This makes it a lot easier to run on different linux distros.
This is a great first step!!! Its perfect for OSS hackers and students.
... but there is stuff Lattice needs to work on.
First, my biggest gripe is that the Brevia board ships with a parallel port programmer. But who has parallel ports anymore? And by the way, purchasing a USB->parallel converter WILL NOT work. Those converters do not translate all parallel signals. Lattice FAEs claim some converters work, but will not endorse a particular one so we are left guessing.
In fact I was unable to get the parallel port programmer to work.
Second, the USB programmer purchased separately costs $150!!! This is an evil bait-and-switch. Honestly I haven't priced components out, but in this market I'd bet that USB components are cheaper than parallel because its all about volume. So what is going on here!!?
However its standard JTAG so other programmers should also work...
Third, the ispVM device programming tool was poorly ported to Linux. In particular, you actually specify the old 8088 parallel port number 0x378 (or whatever) to identify the parallel port, not the device name (and again I never got it to work with the parallel programmer).
Fourth, they only offer RPMs. Lattice, even if you don't want to support every distro, its traditional to just jam your program in a big gzipped tarball archive so we can pull it down and install it by hand by coping it to /usr/local or something along those lines.
And finally, Diamond is still a little rough around the edges. For example, sometimes the editor stops working and I have to close and reopen my project. Even worse, I managed to get my project into an inconsistent state where some generated files thought that certain clock resources existed but I had removed them. The easiest way out of that was to create a new project :-(, and copy my source code over.
However Diamond is very new. I expect very good things.
All in all its a great start! Thanks Lattice!
Disclosure: I am in no way affiliated with Lattice, other than having bought their $29 Brevia board...
And I'm happy to say that unlike my prior complaints about Cypress, I do think that Lattice "gets it" around open source hardware.
Al is not perfect, but they seem to be moving rapidly in the right direction.
First off, they recently obsoleted their old GUI and released their "Diamond" GUI for both Windows and Linux. Its a little crunchy still on Linux. However, this is a major, probably very expensive, initiative and Lattice should be commended for letting Linux be part of it! While they officially only support Red Hat, check out this output coming from the "compiler":
Warning: You are running on an unsupported platform
'synplify_pro' only supports Red Hat Enterprise Linux 4.0 and above
current platform: Ubuntu 10.04.1 LTS
That's right! I managed to get it up on Ubuntu 64 bit (I'll provide a little HOW TO in my next post).
Secondly, they priced the board extremely well at $29.
Third, they provide a lot of free libraries (called "designs" or "IP" in the hardware world) so long as you only use them on Lattice parts. Personally, I can live with that. After all Lattice is in the business of selling chips. And you know if I decide to switch chips, I can implement the underlying library myself and still have benefited from using Lattice's library to get me prototyping my application code faster...
Fourth, the GUI/compiler is free (well, its a 1 year free license so I guess someday they could take that away) and command line accessible.
Fifth, the USB programmer uses libusb, so you don't even need to install a special driver. This makes it a lot easier to run on different linux distros.
This is a great first step!!! Its perfect for OSS hackers and students.
... but there is stuff Lattice needs to work on.
First, my biggest gripe is that the Brevia board ships with a parallel port programmer. But who has parallel ports anymore? And by the way, purchasing a USB->parallel converter WILL NOT work. Those converters do not translate all parallel signals. Lattice FAEs claim some converters work, but will not endorse a particular one so we are left guessing.
In fact I was unable to get the parallel port programmer to work.
Second, the USB programmer purchased separately costs $150!!! This is an evil bait-and-switch. Honestly I haven't priced components out, but in this market I'd bet that USB components are cheaper than parallel because its all about volume. So what is going on here!!?
However its standard JTAG so other programmers should also work...
Third, the ispVM device programming tool was poorly ported to Linux. In particular, you actually specify the old 8088 parallel port number 0x378 (or whatever) to identify the parallel port, not the device name (and again I never got it to work with the parallel programmer).
Fourth, they only offer RPMs. Lattice, even if you don't want to support every distro, its traditional to just jam your program in a big gzipped tarball archive so we can pull it down and install it by hand by coping it to /usr/local or something along those lines.
And finally, Diamond is still a little rough around the edges. For example, sometimes the editor stops working and I have to close and reopen my project. Even worse, I managed to get my project into an inconsistent state where some generated files thought that certain clock resources existed but I had removed them. The easiest way out of that was to create a new project :-(, and copy my source code over.
However Diamond is very new. I expect very good things.
All in all its a great start! Thanks Lattice!
Disclosure: I am in no way affiliated with Lattice, other than having bought their $29 Brevia board...
Saturday, August 7, 2010
Arduino/AVR vs Cypress/PSOC
I've recently been working on a simple PSOC (www.cypress.com/psoc) project using the CY8C64315 USB chip and can't help but compare it to the popular Arduino platform since it is pretty similar to the AVR 328P. These are my observations:
Feature Comparison
Cypress/PSOC 9, Arduino/AVR 5
Initially I chose PSOC because it has some great features packed into a tiny 16 pin QFN part at a cheap price. In particular it provides a full-speed USB device with very few external components -- not even a crystal! It runs at 24Mhz instead of the AVR's 20mhz and contains SPI, I2C, a bunch of IOs and so forth.
One issue is that it does not contain a serial UART (but other, bigger PSOC parts do), but I'm hoping to do a soft-serial implementation.
Perhaps its kind of silly but I didn't want my USB controller to be larger, more expensive, and have more pins than an embedded CPU itself (but when you get right down to it, it is in fact on par or more powerful than the 328p)! So the tiny part size combined with good features was the clincher for me.
Documentation
Cypress/PSOC 3, Arduino/AVR 10
The Cypress Application Note search tool is totally impossible to use. And their community site www.psocdeveloper.com is better but not "alive" like the Arduino or even avrfreaks. Its too tightly coupled with Cypress I think.
And none of this stuff comes up in google searches.
Note to Cypress -- you are NOT a SEARCH company! Just post all your App Notes in HTML form on a public site and let Google do the job. It will do it much better and you'll save some money.
One wild/good thing; I posted an issue bringing the chip up and actually got an essentially unsolicited telephone call from a real human being engineer the next day to help me (but had already figured it out). So that can make up for a lot of doc issues, but of course its pretty expensive for Cypress...
Hardware Design
Cypress 2, AVR 10
2. Application Schematic? It seems that Cypress didn't bother to put one in the datasheet. In fact I had to glean portions of the full "typical application schematic" from a bunch of "Application Notes" -- USB from here, ISSP from there. And of course those schematics were not necessarily for the chip variant I chose so there was lots of uncertainty in this process.
In contrast the Arduino project and all its variants are open hardware, so there are lots of circuit examples to choose from.
PSOC Designer vs Arduino IDE
Cypress 5, Arduno 5
PSOC is supposed to be some reconfigurable hardware "magic" that requires a fancy windows-only IDE. Not in my chip. Everything is just registers AFAIK. But still you can use a GUI to configure things and then it generates the code to write these registers for you. Now, this might seem cool, but actually it just gets in the way. It gives Cypress and excuse to not supply an API like the Arduino's "pinMode" and not to supply good docs. So what if you want to CHANGE the behavior of a pin while your program runs -- you've got to delve into the registers...
The rest of the IDE is everything you'd expect from a programmer's IDE. Good job Cypress! You are just as good as the free Eclipse :-).
However I do have one or 2 beefs. It:
1. Only runs on windows *sigh*
2. Pops up an irritiating "Programming" dialog box. This should be done in a small side-docked pane so the programmer can continue to WORK while the chip gets programmed...
Build Toolchain
Cypress/PSOC 5, Arduino/AVR 5
G++, GCC???
For some reason, instead of adding a gcc backend for the PSOC CPU, Cypress decided to go with some commercial C compiler. So no C++.
The result is a bit more like "Kiel" C then gcc and in particular has irritatingly difficult tranlation between a string stored in "flash" vs one in "ram". In fact, you have to define 2 functions one to handle "__flash" strings and one to handle normal "char *". *sigh*
But of course Arduino has this strange thing called "processing" with is actually C++ with some "try to help me but actually get in the way" thrown in so really average marks on both.
How to "Blink" (Basic programs/sketches)
Cypress/PSOC 7, Arduino/AVR 10
Its pretty INSANELY hard to figure out how to do simple things like configure a digital input (you use the GUI to graphically set the pin as CPU open-drain, then in code write the bit HIGH). Also standard C functions like "printf" are there but don't work... better that they not be there if they don't work.
Yet at the same time, it can be very EASY to do an entire USB HID device. So it just depends on how many Cypress libraries you can use.
Software Layers
Cypress/PSOC 9, Arduino/AVR 9
Ok, I've got to give cred to Cypress for being the 1st hardware company (AFAIK) to realise that we don't want to program at the register level. Yes, the GUI has "user modules" and you just pull them into your project to get massive functionality like a USB endpoint.
One nasty issue the use of lots of assembly??!!? All the Cypress libraries AFAIK are written in assembly. This makes reading the code hard :-). And also you can't ignore it; installing things like interrupt handlers requires you to get down in there and call out to your C. And this is NOT easy; to make the C compiler correctly save state, you have to basically trick the CPU into calling your C routine as if it was an interrupt even though you are already IN an interrupt. There's an entire App Note about how to do it :-(.
The advantage is probably smaller code sizes. But the cost is essentially that if you need to modify the library or add a feature, you have to either rewrite the whole thing yourself in C, or learn PSOC assembly which of course ties you and your work inseparably to this processor.
Summary:
Its a neat little device with lots of potential. Great hardware, great software/support philosophy but not so good implementation. But its a pretty steep learning curve...
Now, Arduino/AVR generally relies on the community to provide great programming libraries, examples, tutorials and general help. And we do.
Cypress seems to be doing all/most of the work on its own. It seems to be caught attempting to implement a modern philosophy with a traditional unidirectional information-flow structure.
So while I give cred to Cypress for the tremendous effort I'm amazed at its total disregard for the open source movement -- in compilers, in IDE, in software libraries.
And I'm surprised at its inability to truly capitalize on internet resources and community.
Feature Comparison
Cypress/PSOC 9, Arduino/AVR 5
Initially I chose PSOC because it has some great features packed into a tiny 16 pin QFN part at a cheap price. In particular it provides a full-speed USB device with very few external components -- not even a crystal! It runs at 24Mhz instead of the AVR's 20mhz and contains SPI, I2C, a bunch of IOs and so forth.
One issue is that it does not contain a serial UART (but other, bigger PSOC parts do), but I'm hoping to do a soft-serial implementation.
Perhaps its kind of silly but I didn't want my USB controller to be larger, more expensive, and have more pins than an embedded CPU itself (but when you get right down to it, it is in fact on par or more powerful than the 328p)! So the tiny part size combined with good features was the clincher for me.
Documentation
Cypress/PSOC 3, Arduino/AVR 10
The Cypress Application Note search tool is totally impossible to use. And their community site www.psocdeveloper.com is better but not "alive" like the Arduino or even avrfreaks. Its too tightly coupled with Cypress I think.
And none of this stuff comes up in google searches.
Note to Cypress -- you are NOT a SEARCH company! Just post all your App Notes in HTML form on a public site and let Google do the job. It will do it much better and you'll save some money.
One wild/good thing; I posted an issue bringing the chip up and actually got an essentially unsolicited telephone call from a real human being engineer the next day to help me (but had already figured it out). So that can make up for a lot of doc issues, but of course its pretty expensive for Cypress...
Hardware Design
Cypress 2, AVR 10
2. Application Schematic? It seems that Cypress didn't bother to put one in the datasheet. In fact I had to glean portions of the full "typical application schematic" from a bunch of "Application Notes" -- USB from here, ISSP from there. And of course those schematics were not necessarily for the chip variant I chose so there was lots of uncertainty in this process.
In contrast the Arduino project and all its variants are open hardware, so there are lots of circuit examples to choose from.
PSOC Designer vs Arduino IDE
Cypress 5, Arduno 5
PSOC is supposed to be some reconfigurable hardware "magic" that requires a fancy windows-only IDE. Not in my chip. Everything is just registers AFAIK. But still you can use a GUI to configure things and then it generates the code to write these registers for you. Now, this might seem cool, but actually it just gets in the way. It gives Cypress and excuse to not supply an API like the Arduino's "pinMode" and not to supply good docs. So what if you want to CHANGE the behavior of a pin while your program runs -- you've got to delve into the registers...
The rest of the IDE is everything you'd expect from a programmer's IDE. Good job Cypress! You are just as good as the free Eclipse :-).
However I do have one or 2 beefs. It:
1. Only runs on windows *sigh*
2. Pops up an irritiating "Programming" dialog box. This should be done in a small side-docked pane so the programmer can continue to WORK while the chip gets programmed...
Build Toolchain
Cypress/PSOC 5, Arduino/AVR 5
G++, GCC???
For some reason, instead of adding a gcc backend for the PSOC CPU, Cypress decided to go with some commercial C compiler. So no C++.
The result is a bit more like "Kiel" C then gcc and in particular has irritatingly difficult tranlation between a string stored in "flash" vs one in "ram". In fact, you have to define 2 functions one to handle "__flash" strings and one to handle normal "char *". *sigh*
But of course Arduino has this strange thing called "processing" with is actually C++ with some "try to help me but actually get in the way" thrown in so really average marks on both.
How to "Blink" (Basic programs/sketches)
Cypress/PSOC 7, Arduino/AVR 10
Its pretty INSANELY hard to figure out how to do simple things like configure a digital input (you use the GUI to graphically set the pin as CPU open-drain, then in code write the bit HIGH). Also standard C functions like "printf" are there but don't work... better that they not be there if they don't work.
Yet at the same time, it can be very EASY to do an entire USB HID device. So it just depends on how many Cypress libraries you can use.
Software Layers
Cypress/PSOC 9, Arduino/AVR 9
Ok, I've got to give cred to Cypress for being the 1st hardware company (AFAIK) to realise that we don't want to program at the register level. Yes, the GUI has "user modules" and you just pull them into your project to get massive functionality like a USB endpoint.
One nasty issue the use of lots of assembly??!!? All the Cypress libraries AFAIK are written in assembly. This makes reading the code hard :-). And also you can't ignore it; installing things like interrupt handlers requires you to get down in there and call out to your C. And this is NOT easy; to make the C compiler correctly save state, you have to basically trick the CPU into calling your C routine as if it was an interrupt even though you are already IN an interrupt. There's an entire App Note about how to do it :-(.
The advantage is probably smaller code sizes. But the cost is essentially that if you need to modify the library or add a feature, you have to either rewrite the whole thing yourself in C, or learn PSOC assembly which of course ties you and your work inseparably to this processor.
Summary:
Its a neat little device with lots of potential. Great hardware, great software/support philosophy but not so good implementation. But its a pretty steep learning curve...
Now, Arduino/AVR generally relies on the community to provide great programming libraries, examples, tutorials and general help. And we do.
Cypress seems to be doing all/most of the work on its own. It seems to be caught attempting to implement a modern philosophy with a traditional unidirectional information-flow structure.
So while I give cred to Cypress for the tremendous effort I'm amazed at its total disregard for the open source movement -- in compilers, in IDE, in software libraries.
And I'm surprised at its inability to truly capitalize on internet resources and community.
Wednesday, June 9, 2010
Proposal for an "Open Device" License
There is an interesting read about an "open hardware" license here:
http://www.tapr.org/ohl.html
But I am interested in something that goes much further in several ways.
First off, my license would enforce the right and ability to modify a product and (especially) its firmware/software after it has been produced. This is what I mean by "open device" as opposed to simply "open hardware". In a world where the PC is increasingly pushed into a niche market, it is very important to protect the right to run software on other hardware, cell phones for example. I believe that the openness of the IBM PC is what created the personal computer revolution -- and why Apple lost out... as much as I love what Apple is doing on the physical side with the ipod, iphone, ipad, we need to ensure that Apple's restrictive policies do not prevail in devices or we will lose innovation in the personal device marketplace to the detriment of everyone who uses the devices.
This "modifiable device" restriction is also nice because it lets the original producer (and others) can use a high volume producer's hardware, so long as its functionality is accessible.. I believe that this would satisfy many open hardware developers since some are not motivated to make money; they are simply building a device that does not currently exist, and would be happy instead to buy it at Wallmart for significantly less cost. On the other hand, the greatest IP "theft" would be for a company to take a piece of open hardware and inaccessibly embed it within some consumer product, thereby reaping all the rewards of the open hardware communities' efforts and giving nothing back in return.
Secondly, I disagree with the TAPR's reliance on the GPL license to protect software, since (as I said above) it does not protect the ability to run that software on some device. It is very common for a company to comply with GPL by releasing the source of a Linux port onto a new CPU but in fact have no way for the end user to actually upload that release onto the CPU within the company's product! And generally other available hardware will not exist for the new CPU... Ironically, this effect is what drives some open hardware development, because the community then must produce (at great personal expense) custom hardware to utilize the Linux port...
There is one instance that I know of where in fact the software was released and the hardware fortuitously provided an update mechanism. This was the WRT-54G router. This device was a tremendous market success, and open source community's modifications to this router were so popular that some features were actually pushed back into the commerical release, AND even though the company eventually built a cheaper version on vxworks (a different operating system), they continued to sell the original under the product name WRT-54GL (more...). What if this phenomemon was the norm instead of the exception!?
Therefore, I believe that the hardware and software in embedded devices is intrinsically related -- one is almost worthless without the other. And finally, my experience as a software architect within the telecom industry and my experience as an open hardware developer is that in fact the software/firmware is 90% or more of the time effort. Since it is the major cost, it provides great leverage to pry off the lid of "closed" devices.
When you add these and a few other ideas together, you end up not with "open hardware", but something that looks a lot more like an "open device".
http://www.tapr.org/ohl.html
But I am interested in something that goes much further in several ways.
First off, my license would enforce the right and ability to modify a product and (especially) its firmware/software after it has been produced. This is what I mean by "open device" as opposed to simply "open hardware". In a world where the PC is increasingly pushed into a niche market, it is very important to protect the right to run software on other hardware, cell phones for example. I believe that the openness of the IBM PC is what created the personal computer revolution -- and why Apple lost out... as much as I love what Apple is doing on the physical side with the ipod, iphone, ipad, we need to ensure that Apple's restrictive policies do not prevail in devices or we will lose innovation in the personal device marketplace to the detriment of everyone who uses the devices.
This "modifiable device" restriction is also nice because it lets the original producer (and others) can use a high volume producer's hardware, so long as its functionality is accessible.. I believe that this would satisfy many open hardware developers since some are not motivated to make money; they are simply building a device that does not currently exist, and would be happy instead to buy it at Wallmart for significantly less cost. On the other hand, the greatest IP "theft" would be for a company to take a piece of open hardware and inaccessibly embed it within some consumer product, thereby reaping all the rewards of the open hardware communities' efforts and giving nothing back in return.
Secondly, I disagree with the TAPR's reliance on the GPL license to protect software, since (as I said above) it does not protect the ability to run that software on some device. It is very common for a company to comply with GPL by releasing the source of a Linux port onto a new CPU but in fact have no way for the end user to actually upload that release onto the CPU within the company's product! And generally other available hardware will not exist for the new CPU... Ironically, this effect is what drives some open hardware development, because the community then must produce (at great personal expense) custom hardware to utilize the Linux port...
There is one instance that I know of where in fact the software was released and the hardware fortuitously provided an update mechanism. This was the WRT-54G router. This device was a tremendous market success, and open source community's modifications to this router were so popular that some features were actually pushed back into the commerical release, AND even though the company eventually built a cheaper version on vxworks (a different operating system), they continued to sell the original under the product name WRT-54GL (more...). What if this phenomemon was the norm instead of the exception!?
Therefore, I believe that the hardware and software in embedded devices is intrinsically related -- one is almost worthless without the other. And finally, my experience as a software architect within the telecom industry and my experience as an open hardware developer is that in fact the software/firmware is 90% or more of the time effort. Since it is the major cost, it provides great leverage to pry off the lid of "closed" devices.
When you add these and a few other ideas together, you end up not with "open hardware", but something that looks a lot more like an "open device".
Wednesday, June 2, 2010
Success, Wall Street Style
I just finished reading "Den of Thieves" by James Stewart which is about the junk bond scandal that hit wall street in the '80s. What is fascinating about it is the similarities between it and the recent financial meltdown. Just swap "toxic asset" mortgages for corporate loans (AKA junk bonds) and hit the fast forward button.
Since this is a blog, I'm going to skip all explanations (read the book) and just hop to my observations:
First off, the financial system essentially and intrinsically encourages abuse. Capitalism trends towards perfect markets -- therefore there is an ever decreasing profit spread for financial guys to take advantage of. But wall street types are self-selected to not be happy with ever decreasing profits. They will find or create an edge.
Second, the junk-bond related crimes were totally unnecessary; they just added a buck or two per share to an already over-inflated, highly profitable transaction and sometimes "encouraged" a deal to go through if it was stalling. Judging by the lack of major arrests in the toxic asset meltdown, Wall street learned that crime in fact doesn't pay nearly as well as the long, legal con.
Third, never trust finance guys even as part of a reputable institution! [In fact, let me go on a limb and say, its your life, don't trust anyone! For major life issues like financial and medical, respect the expert opinions but learn their biases (for example, surgeons LIKE to do surgery, duhh!) and then spend the time to figure it out yourself!]
Around 2007-2008 a couple of my friends were buying a house and I was alarmed at the tendency for people to trust the bank's evaluation of how large a loan you could bear. Essentially they ceded responsibility for picking a reasonable load to the banking "experts", and did not bother to do even the most basic math. "If the bank is willing to offer me that much I must be good for it" is how the thinking goes. I think that this happened on a nationwide level. But I would tell my friends "yes but the bank's goal is for you to be in debt for the rest of your life, your goal should be to not be in debt. Because when you are in debt, you are paying 10% or more to your creditor. You are going into debt to buy more stuff, but ironically you'll end up with less".
Little did we know that many banks did not even care whether the loan could be repaid...
Recipe for Wall Street Mega-Success
(slashdot style)
1. Identify an information advantage. Look in unregulated areas of finance. For extra credit, artificially create an information advantage in your favor. For example, bundle financial instruments so the underlying entities are hidden. Write contracts that only finanical lawyers can understand (insurance is a great area of opportunity for this method). Transform an out-of-favor, high-risk financial instrument into one that is "in-favor". Take advantage of people's trust in "experts" -- i.e. yourself.
2. Market, market, sell, sell, sell. Get college professors to write papers about how low risk your market historically was (before you entered it).
3. Jam increasingly ludicrious and high risk underlying entities into your framework since that maximizes your profit by reducing the base cost.
4. Use recursion to keep the aura of good times going -- if an issue is about to fail, grab it up, twist it around, and jam it back into the system (AKA refinancing).
3. ??? (this is where the optional crimes are committed)
4. Profit!!!
5. You have 3-7 years; the fall will be from the summit, sudden and hard. be ready to bail.
Since this is a blog, I'm going to skip all explanations (read the book) and just hop to my observations:
First off, the financial system essentially and intrinsically encourages abuse. Capitalism trends towards perfect markets -- therefore there is an ever decreasing profit spread for financial guys to take advantage of. But wall street types are self-selected to not be happy with ever decreasing profits. They will find or create an edge.
Second, the junk-bond related crimes were totally unnecessary; they just added a buck or two per share to an already over-inflated, highly profitable transaction and sometimes "encouraged" a deal to go through if it was stalling. Judging by the lack of major arrests in the toxic asset meltdown, Wall street learned that crime in fact doesn't pay nearly as well as the long, legal con.
Third, never trust finance guys even as part of a reputable institution! [In fact, let me go on a limb and say, its your life, don't trust anyone! For major life issues like financial and medical, respect the expert opinions but learn their biases (for example, surgeons LIKE to do surgery, duhh!) and then spend the time to figure it out yourself!]
Around 2007-2008 a couple of my friends were buying a house and I was alarmed at the tendency for people to trust the bank's evaluation of how large a loan you could bear. Essentially they ceded responsibility for picking a reasonable load to the banking "experts", and did not bother to do even the most basic math. "If the bank is willing to offer me that much I must be good for it" is how the thinking goes. I think that this happened on a nationwide level. But I would tell my friends "yes but the bank's goal is for you to be in debt for the rest of your life, your goal should be to not be in debt. Because when you are in debt, you are paying 10% or more to your creditor. You are going into debt to buy more stuff, but ironically you'll end up with less".
Little did we know that many banks did not even care whether the loan could be repaid...
Recipe for Wall Street Mega-Success
(slashdot style)
1. Identify an information advantage. Look in unregulated areas of finance. For extra credit, artificially create an information advantage in your favor. For example, bundle financial instruments so the underlying entities are hidden. Write contracts that only finanical lawyers can understand (insurance is a great area of opportunity for this method). Transform an out-of-favor, high-risk financial instrument into one that is "in-favor". Take advantage of people's trust in "experts" -- i.e. yourself.
2. Market, market, sell, sell, sell. Get college professors to write papers about how low risk your market historically was (before you entered it).
3. Jam increasingly ludicrious and high risk underlying entities into your framework since that maximizes your profit by reducing the base cost.
4. Use recursion to keep the aura of good times going -- if an issue is about to fail, grab it up, twist it around, and jam it back into the system (AKA refinancing).
3. ??? (this is where the optional crimes are committed)
4. Profit!!!
5. You have 3-7 years; the fall will be from the summit, sudden and hard. be ready to bail.
Saturday, February 6, 2010
Arduino PWM on all pins.
What is PWM?
PWM (pulse width modulation) is the art of faking a particular voltage by rapidly moving between 2 other voltages. For example if you have a digital logic line that is 0 volts when LOW or 5 volts when HIGH, you can "trick" a multimeter into reading 1 volt by setting the line to low for 4/5s of the time and high for 1/5 of the time. The ratio of high to low is called the "duty cycle" and is specified in a percentage.
Why Use PWM?
You can trick a lot of other things too if you toggle the line tens to hundreds of times a second. For example if you connect a LED it will appear dimmer due to the same "persistence of vision" effect that makes movies appear smooth.
Another example is driving motors. Motors contain electromagnets which cause electrical inductance (in analogy "momentum"). If you put a diode across the motor's leads (backwards) then when the motor is turned off, the collapse of the magnetic field continues to drive current through the wire, and through the diode back to the other side of the motor. This current maintains the magnetic field! If there was no resistance this would go on forever (BTW this is how superconductors float above magnets). But since there is resistance, the circulating current slowly dies out.
But if you are doing PWM on the motor, a new influx of energy will re-energize the motor's coils resulting in a smoothly turning motor. But the speed of the motor will vary based on the duty cycle of the PWM. So you can use PWM to change the speed of a DC motor.
The Arduino has some hardware-based PWM. But only on certain pins. For things like motors, you do not need to PWM very fast so it can be done in software. So I have made a software PWM class for Arduino sketches that works on all pins.
The Four Line states in an AVR microcontroller
Another cool feature is that it will do PWM between any 2 line states. You may normally think of a digital line as having only 2 states (high or low) but the Arduino actually offers 4 states, high, low, high impedence, and pull up.
A lot of beginners think of the "low" state as "off" but really it means driven to 0 volts. So if you put a light between a "low" pin and 5v, the light will turn on!
On the other hand "high impedence" actually means "disconnected" or "floating" -- at least as close as you can get to that using solid state electronics. So in a high impedence state, the light described above would NOT turn on. But one issue with a line in the "high impedence" state is that its voltage is undefined and can be sensed as high or low and change between the 2 due to vagaries of electric fields on the board, etc.
"Pull up" refers to a connection to 5v through a large resistor. So it is "high impedence" in the sense that it cannot drive anything, and if driven by some external device it will follow that device. But if the line is otherwise floating, the connection to 5v thru the resistor will make the line show as high.
DOWNLOAD
The Code
PWM (pulse width modulation) is the art of faking a particular voltage by rapidly moving between 2 other voltages. For example if you have a digital logic line that is 0 volts when LOW or 5 volts when HIGH, you can "trick" a multimeter into reading 1 volt by setting the line to low for 4/5s of the time and high for 1/5 of the time. The ratio of high to low is called the "duty cycle" and is specified in a percentage.
Why Use PWM?
You can trick a lot of other things too if you toggle the line tens to hundreds of times a second. For example if you connect a LED it will appear dimmer due to the same "persistence of vision" effect that makes movies appear smooth.
Another example is driving motors. Motors contain electromagnets which cause electrical inductance (in analogy "momentum"). If you put a diode across the motor's leads (backwards) then when the motor is turned off, the collapse of the magnetic field continues to drive current through the wire, and through the diode back to the other side of the motor. This current maintains the magnetic field! If there was no resistance this would go on forever (BTW this is how superconductors float above magnets). But since there is resistance, the circulating current slowly dies out.
But if you are doing PWM on the motor, a new influx of energy will re-energize the motor's coils resulting in a smoothly turning motor. But the speed of the motor will vary based on the duty cycle of the PWM. So you can use PWM to change the speed of a DC motor.
The Arduino has some hardware-based PWM. But only on certain pins. For things like motors, you do not need to PWM very fast so it can be done in software. So I have made a software PWM class for Arduino sketches that works on all pins.
The Four Line states in an AVR microcontroller
Another cool feature is that it will do PWM between any 2 line states. You may normally think of a digital line as having only 2 states (high or low) but the Arduino actually offers 4 states, high, low, high impedence, and pull up.
A lot of beginners think of the "low" state as "off" but really it means driven to 0 volts. So if you put a light between a "low" pin and 5v, the light will turn on!
On the other hand "high impedence" actually means "disconnected" or "floating" -- at least as close as you can get to that using solid state electronics. So in a high impedence state, the light described above would NOT turn on. But one issue with a line in the "high impedence" state is that its voltage is undefined and can be sensed as high or low and change between the 2 due to vagaries of electric fields on the board, etc.
"Pull up" refers to a connection to 5v through a large resistor. So it is "high impedence" in the sense that it cannot drive anything, and if driven by some external device it will follow that device. But if the line is otherwise floating, the connection to 5v thru the resistor will make the line show as high.
DOWNLOAD
The Code
#define PWM_NUM_PINS 16
#define PWM_MAX_DUTY 255
#define PWM_DEFAULT_FREQ (16000000.0/128.0) //2MHz for /8 prescale from 16MHz
//?? Software based PWM (Pulse width modulation) library for the ATMEGA168/328 (Arduino).
//
// This class implements PWM in software. PWM is a method whose purpose is to emulate an analog voltage by rapidly toggling a digital
// pin between the high and low states. By changing the duty cycle -- the percent of time the pin is "on" verses "off" the apparent voltage changes.
// This technique is only useful if the pin is controlling a device that averages voltages; for example:
// * Inductors (electromagnets, motors)
// * Capacitors
// * Human perception (via LEDs for example)
// This library does not work as efficiently as the hardware based PWM availabe in the ATMEGA, so that should be used if possible.
// However this library offers PWM on all pins, and also allows you to specify what the "on" and "off" pin states are. For example, you could choose the "off" state to be high impedence.
//
class SoftPWM
{
public:
typedef enum
{
DRIVEN_LOW = 2 | 0,
DRIVEN_HIGH = 2 | 1,
DRIVEN = 2,
FLOATING = 0,
PULL_UP = 1,
HIGH_IMPEDENCE = 0,
UNUSED = 4
} PinBehavior;
//?? Constructor
SoftPWM();
//?? Call this periodically to trigger a state change
void loop(void);
//?? Automatically call the loop() function periodically. Once you call this function YOU SHOULD NOT CALL LOOP()!
void startAutoLoop(int timer=2,int frequency=PWM_DEFAULT_FREQ);
//?? Stop automatic looping.
void stopAutoLoop(void);
//?? Duty Cycle. The fraction of time that the pin is HIGH is duty/255
uint8_t duty[PWM_NUM_PINS];
//?? Set what it means for a pin to be off or on.
// Typically you would want to PWM an output pin and toggle output voltage. This is what PWM normally means, and is the default.
// However, for other applications you may want to toggle the impedence and value simultaneously.
// For example, if the pin is sinking the base of a PNP transistor then you would switch from a high impedence (i.e. open circuit) state to a low output state (i.e. closed circuit, sinking current).
//
void enablePin(int pin, PinBehavior offMode=DRIVEN_LOW, PinBehavior onMode=DRIVEN_HIGH)
{
pinOnBehavior[pin] = onMode;
pinOffBehavior[pin] = offMode;
}
void disablePin(int pin) { pinOnBehavior[pin] = UNUSED; pinOffBehavior[pin] = UNUSED; }
//?? Set all duty cycles to 0
void zero(void)
{
for (int i=0;i != PWM_NUM_PINS;i++)
duty[i] = 0;
}
uint8_t pinOffBehavior[PWM_NUM_PINS];
uint8_t pinOnBehavior[PWM_NUM_PINS];
int bresenham[PWM_NUM_PINS];
};
SoftPWM::SoftPWM()
{
for (int c=0;c != PWM_NUM_PINS;c++)
{
bresenham[c] = 0;
pinOffBehavior[c] = UNUSED;
pinOnBehavior[c] = UNUSED;
}
}
void SoftPWM::loop(void)
{
boolean lvl;
unsigned char regLvlOut=0;
unsigned char regLvlIn;
unsigned char regDirOut=0;
unsigned char regDirIn;
for (int i=0;i != PWM_NUM_PINS;i++)
{
if (i==0) { regLvlIn = PORTD; regDirIn = DDRD; }
if (i==8) { regLvlIn = PORTB; regDirIn = DDRB; }
if (i==8)
{
DDRD = regDirOut;
PORTD = regLvlOut;
}
regLvlOut >>=1;
regDirOut >>=1;
if ((pinOnBehavior[i] & UNUSED) == UNUSED) // If its unused then keep the values the same
{
regDirOut |= (regDirIn&1);
regLvlOut |= (regLvlIn&1);
}
else
{
bresenham[i] += duty[i];
if (bresenham[i]>=PWM_MAX_DUTY)
{
bresenham[i] -= PWM_MAX_DUTY;
lvl = true;
}
else lvl = false;
if (lvl)
{
regLvlOut |= (pinOnBehavior[i]&1) ? 0x80:0;
regDirOut |= (pinOnBehavior[i]>>1) ? 0x80:0;
}
else
{
regLvlOut |= (pinOffBehavior[i]&1) ? 0x80:0;
regDirOut |= (pinOffBehavior[i]>>1) ? 0x80:0;
}
}
regLvlIn >>=1;
regDirIn >>=1;
}
if (1)
{
DDRB = regDirOut;
PORTB = regLvlOut;
}
}
typedef unsigned char byte;
int ledPin = 13;
void testSoftPWM()
{
SoftPWM pwm;
pwm.enablePin(ledPin, SoftPWM::DRIVEN_LOW, SoftPWM::DRIVEN_HIGH);
for (int i=0;i<25600;i++)
{
pwm.duty[ledPin] = i/100;
pwm.loop();
delay(1);
}
}
void setup() {}
void loop() { testSoftPWM(); }
Subscribe to:
Posts (Atom)