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".
Wednesday, June 9, 2010
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(); }
Monday, January 25, 2010
Browser Hacking
Firefox has a cool extension called pyxpcomext that sticks a Python interpreter inside your browser!
But as is it is pretty hard to use unless you are already a browser geek. For example, it is hard to figure out how to access stuff like a page in the browser because all of the Firefox extension documentation is for either C or JavaScript. So you have to sort of read those APIs and translate them thru XPCOM into Python. This is tricky.
So I extended the pyxpcomext example "PyShell" into something a lot more user friendly (it wraps the most common XPCOM stuff into normal Python function calls) and useful. You can access and read details about it here: http://code.google.com/p/juicedpyshell/
Now, what's the point of this, you ask?
Well, what this means is that you can write a Python program that can interact with your browser as you are browsing and even modify the page (sort of like greasemonkey, but in Python) or even "click" the browser to another page for you!
But that's still technology, how about applications?
0. Automation of repetitive browser tasks.
1. Automated test of your live web site if you are a web developer.
2. Sophisticated ad elimination.
3. I'm thinking of a history database that remembers not only the link, i.e. "www.cnn.com" but also the contents of a page. Don't you hate it when you browse to an article only to find it gone!
4. Python XML/HTML development. If you are writing a Python back end server then your python is generating HTML. Its pretty cool to just be able to write hprt(" <> My Header < /h1 >") in the Juiced Python Shell, and actually SEE the rendered HTML appear. Its just like the Python standard "print" command but understands html! This really speeds up the dev/test cycle.
But why not...?
...just write an app that grabs pages as an http client? Well, because your app can't execute Javascript so it won't work on all of the new Web 2.0 sites.
...use greasemonkey? Because everyone hates Javascript :-)!! Seriously, because you can spawn multiple threads in your Python program (however, only the main thread can "touch" the browser). Because you have access to the incredibly rich set of Python libraries. Because Python has a real console and debugger. Greasemonkey is a toy to markup web pages. A very cool toy of course! But still your program will always be limited in complexity by inherent Javascript limitations.
But as is it is pretty hard to use unless you are already a browser geek. For example, it is hard to figure out how to access stuff like a page in the browser because all of the Firefox extension documentation is for either C or JavaScript. So you have to sort of read those APIs and translate them thru XPCOM into Python. This is tricky.
So I extended the pyxpcomext example "PyShell" into something a lot more user friendly (it wraps the most common XPCOM stuff into normal Python function calls) and useful. You can access and read details about it here: http://code.google.com/p/juicedpyshell/
Now, what's the point of this, you ask?
Well, what this means is that you can write a Python program that can interact with your browser as you are browsing and even modify the page (sort of like greasemonkey, but in Python) or even "click" the browser to another page for you!
But that's still technology, how about applications?
0. Automation of repetitive browser tasks.
1. Automated test of your live web site if you are a web developer.
2. Sophisticated ad elimination.
3. I'm thinking of a history database that remembers not only the link, i.e. "www.cnn.com" but also the contents of a page. Don't you hate it when you browse to an article only to find it gone!
4. Python XML/HTML development. If you are writing a Python back end server then your python is generating HTML. Its pretty cool to just be able to write hprt(" <> My Header < /h1 >") in the Juiced Python Shell, and actually SEE the rendered HTML appear. Its just like the Python standard "print" command but understands html! This really speeds up the dev/test cycle.
But why not...?
...just write an app that grabs pages as an http client? Well, because your app can't execute Javascript so it won't work on all of the new Web 2.0 sites.
...use greasemonkey? Because everyone hates Javascript :-)!! Seriously, because you can spawn multiple threads in your Python program (however, only the main thread can "touch" the browser). Because you have access to the incredibly rich set of Python libraries. Because Python has a real console and debugger. Greasemonkey is a toy to markup web pages. A very cool toy of course! But still your program will always be limited in complexity by inherent Javascript limitations.
Friday, October 9, 2009
A well deserved plug
I did not populate my Lightuino LED board with excessive LEDs. In retrospect, that is kind of ironic. But the board is made for you to put the light where YOU want it to go :-).
In particular I left off the TX and RX LEDs so you can't tell if it's downloading the sketch. But it does have power and the pin 13 LED. So... I decided to hack the bootloader to blink the pin 13 LED as the sketch comes down. Well guess what! Its already been done! And it worked flawlessly, without me even having to do a compile.
Thank you LadyAda and Brian! These are people who are building the community, not just selling knockoffs. So I say, if she stocks it here or he stocks it there then buy it from them!
[Disclamer: My only affiliation is as a satisfied customer of adafruit -- I use her USBtinyISP and the Boarduino]
In particular I left off the TX and RX LEDs so you can't tell if it's downloading the sketch. But it does have power and the pin 13 LED. So... I decided to hack the bootloader to blink the pin 13 LED as the sketch comes down. Well guess what! Its already been done! And it worked flawlessly, without me even having to do a compile.
Thank you LadyAda and Brian! These are people who are building the community, not just selling knockoffs. So I say, if she stocks it here or he stocks it there then buy it from them!
[Disclamer: My only affiliation is as a satisfied customer of adafruit -- I use her USBtinyISP and the Boarduino]
Tuesday, October 6, 2009
Lightuino Design Thoughts
 |
| From references |
In designing the Lightuino I wanted to improve on my existing CCShield in several ways and provide an alternative to the Rainbowduino (which is also an Arduino compatible LED display board).
New Features!
NOT (necessarily) a shield!
The biggest change is the addition of the ATMEGA CPU, clock, etc logic, making the Lightuino a standalone board!
Of course, you can still use it as a shield, either WITH the ATMEGA populated or WITHOUT (if the ATMEGA is not populated, it MUST be used as a shield of course). And you can stack them. If it is stacked, it ought to let you do some really interesting distributed computing stuff.
By integrating the ATMEGA on-board, the total cost is a lot less, since you don't need the Arduino board. And its a lot smaller too!
Separate LED power Regulator
An LM317T was added to the board, with a 10k adjustable POT, so you can deliver consistent power to the LEDs (or to whatever) even if your wall-wart is unregulated. As long as your wall-wart provides the voltage, you can go up to 30+ volts, allowing each CCShield sink to control a string of LEDs. However the M5451 chips can only handle a 13 volt differential, so you must make sure that the voltage has dropped down to this before it enters the chip.
IDE cable headers
If you are stacking Lightuinos, the IDE cable header does not quite fit in a stack, so right angle headers are available.
The IDE cable pinout was also changed to put all of the power lines on one end, and to NOT provide a ground line unless a jumper is inserted on the board. Additionally, the pinout is the same on both sides (instead of upside down). This makes it a lot easier to wire up the LEDs AND also makes it very difficult to accidently burn out a LED by wiring it up to ground (for example) instead of to a current sink.
Finally, one of the lines is unassigned, and accessible via a pin on the board. So you can push whatever signal out that you want!
Pin Selection
Just like the CCShield, you can select whatever Arduino (digital) pins you want to control the LED portion of the board. But the CCShield's pin selection was difficult as it used extremely small SMT pads. The Lightuino simply has a section of the board with some thru-holes and you use jumper wires to make the selection.
Brightness Adjustment
It turns out that the M5451 chips can drive the LEDs at a barely discernible difference in brightness, so trim pots were added to the brightness adjustment to allow you to make the chips output the exact same light intensity (or actually, you could make one chip output bright, and one dim). Of course, this can be simply populated with resistors to save $ if exact brightness levels are not needed. It is unlikely that these will be needed for casual use.
Extras
The ATMEGA 328 QFN package has 2 additional analog inputs, so I brought those out by simply extending the Arduino standard pinout.
Also, I had extra space so I threw in the footprint of a voltage divider per analog input pin since that is a very common circuit. Just add your own resistors, and you are all set!
Comparison with Rainbowduino
Matrix?
Let me start by saying that I don't have a Rainbowduino, so this is all conjecture from reading the specs. It seems to me that it was mostly focused on driving an RGB 8x8 LED matrix display. In fact you can even plug a matrix directly into it. I was more interested in driving individually placed LEDs for art projects. While LED matrices are cool and have their uses in signage, frankly, if I wanted a big screen I'd just buy a flat screen TV! But whatever floats your boat. :-)
Of course, you can always use a LED matrix electrical connection, but not have the LEDs in a grid, but it is trickier to do that wiring... additionally you can use the Lightuino to "sink" the columns of an matrix (70 columns instead of just 24!)... but you would need to power the rows with some other circuitry. So again, its trickier :-).
Shield Compatiblitity
Additionally, the Rainbowduino does not seem to be Arduino shield compatible. This seemed to me to be a major drawback as it does not take advantage of the vast community of shields out there that can add so many cool features to a project!
CPU Power
The ATMEGA 168 is pretty limited in RAM, as I found when working with the normal Arduino, so I moved up to the 328 with double the RAM.
LED Capability
I opted for 2 chips that can drive 70 constant currents outputs at 20mA, the Rainbowduino allows you to drive fewer outputs (24) at higher capacity (120mA).
PWM Dimming
I wanted to experiment with POV art (i.e. a light strip that forms an image floating in space when your eyes flick by it, or spinning a strip to form in image in a circle) and to do that you need precise control of when the LEDs are ON vs OFF. In other words, a separate PWM chip won't work. However, this means that the Lightuino has to drive PWM in software, just like what the Arduino's PWM pins do. At very low PWM levels (say 10 on out of 256 counts) you can perceive the LED blinking (and of course more Arduino processor time is used). Therefore, you end up with another tradeoff, precise control over the blinking of each LED verses faster blink rates (note, I'm just assuming the Rainbowduino has an external PWM, but I haven't verified that).
Saturday, October 3, 2009
Lightuino V2.0 -- An Arduino compatible optimized for driving LEDs
The CCShield board was pretty successful and I had a lot of fun with it, so I decided to do another run. I wanted to attempt some surface mount work but at the same time not produce a lemon if it did not work, so I created the hybrid board you see above. The board has a complete Arduino-compatible subsection on it implemented using surface mount parts and the CCShield (plus some extra goodies) implemented using thru-hole parts. The idea is that the board can be used as a shield if the surface mount parts are not populated, or used standalone if the parts are.
Another cool feature is that you can stack them -- so I can experiment with running a bunch of processors simultaneously.
I'll be adding a couple of posts about this board. This first is about building up the surface mount parts. The image above is the board with the surface mount parts baked on and the minimum thru hole parts added to bring power and the ICSP programmer on.
I used the smallest part I could find for the CPU, QFN-32 and 0603 parts for the resistors and caps. The tricky part of the QFN32 package is that the leads are underneath the part, making it hard to repair solder bridges.
To make my surface mount station, I "rescued" an old toaster oven from the dump and "splurged" on some solder paste, rosin, and wick from dealsextreme dealextreme. Then I bought some .5mm mechanical pencils from Staples, some tweezers from Walgreens. Total cost about $20.
This supplemented my current thru-hole solder station that consists of a plastic clamp (Home Depot) to hold a circuit board, a radio-shack 40 watt soldering iron, and an old a magnifying glass/light on arm combo from the basement (really its the bright light that's important).
I then used the mechanical pencil to "paint" the solder paste on the leads. For the QFN part, I just laid the paste across the leads and then used an Exacto-knife to "cut" the spaces between them. It seems like the biggest pitfall is simply using TOO MUCH PASTE. You want just the thinnest layer, and do not even cover the entire pad!
Then I just placed the components in their positions using the tweezers, and did fine adjustment of the QFN32 part with the edge of the tweezers.
Baking was easy. I followed the temperature profile here. But not really... I used the thermostat on the oven, not a real temperature gauge. Basically, just set your oven for 170 C put the boards in and wait 3 minutes. Then raise the temperature to 220 C and shine a bright light in so you can see the boards clearly. After a minute or two the solder will go from grey to silvery. Wait another 30 sec to a minute to be sure that ALL the solder has gone silvery. Then turn off the oven (but leave the boards in there) and crack open the door. You want to cool the boards evenly. After a few minutes, open the door fully, and when they are cool to the touch, pop them out!
I did 4 boards and had 2 solder bridges on the QFN parts. Every other part worked without any issues.
If you have a bridge (you can see it), paint the entire side of the part with a gob of rosin. Then place your solder wick over all of the leads and heat it all up with a clean iron on top of the wick. The rosin will help the solder flow and it will either flow onto the pins, or onto your wick. Easy!
So if you are a DIYer who has been leery of using SMT parts, I'd say "go for it"!
[edit oct 15, 2009: I just did 12 successful boards without any solder bridges. Mix 50/50 paste and flux so the result is viscous like maple syrup]
Friday, September 11, 2009
Solar Powered Arduino
I am working on an outdoor LED coffee table. The idea is for it to charge up all day long and then to drive a bunch of LEDs (blinking in cool patterns via an Arduino) for as long as it has power at night.
There are 5 components to the electronics:
In the photo, clockwise from the top left are the solarcells, the battery, the charging circuit and finally the Arduino (actually a boarduino), LEDs, and LED driver chip.
I chose some flexible solar cells I had lying around from
www.flexsolarcells.com. It turned out that they are a great choice for generic Arduino use because a single thin film cell generates 7.2 volts which is enough to power an Arduino! In contrast, one of the silicon cells only produces .5 volts (you need from 4.5 to 5.5 volts to power an Arduino).
In fact just one of the cells pictured here can power the arduino even in the shade. You could image one of these on top of a small device... however, they are not ideal for my project because I will have plenty of room under the glass of my table to put a lot of cells. And the silicon cells are cheaper per watt and more efficient per unit area.
I chose 4 1.2 volt Nmh (nickel-metal-hydride) batteries. I chose Nmh batteries because they can be trickle charged with a very simple circuit. They actually generate 1.3 (5.2 total) volts when fully charged. But that is less then the Arduino's limit of 5.5 volts, so I can connect directly to the Arduino's 5v line instead of the Vin. This bypasses the Arduino's voltage regulator and so is much more efficient but a little dangerous. It for some reason the voltage ever does exceed 5.5 volts, I could burn out the chip.
Basically, when the battery voltage is above that generated by the solar cells, current can flow from the top through the base (middle) of the upper right transistor and then backwards through the solar cells. This turns on the transistor, which then turns on the bigger transistor at the bottom and so power can flow through the Arduino. So the solar cells themselves are used both to charge and to sense when it gets dark. In practice, they turn the system on at dusk, so I put the Arduino to sleep for 45 minutes before actually turning on the LEDs.
The diode near the solar cells is so cells can only charge the battery, the battery can't attempt to "charge" the cells!
And finally a close up of the charging circuit itself:
The orange wires to the left go to the Arduino. The upper right ones go to the battery and the lower right to the cells. The wires on the bottom of the photo are basically electrical ground.
I use an M5451 constant-current LED driver chip to light the LEDs. If you are interested in this, there is a lot more information in prior blog posts, or at: http://code.google.com/p/arduino-m5451-current-driver/
Share your solar projects! :-)
There are 5 components to the electronics:
- The Arduino
- The LED driver
- Solar Cells
- Battery pack
- Charging/light sensor circuit
In the photo, clockwise from the top left are the solarcells, the battery, the charging circuit and finally the Arduino (actually a boarduino), LEDs, and LED driver chip.
The Solar Cells
I chose some flexible solar cells I had lying around from
www.flexsolarcells.com. It turned out that they are a great choice for generic Arduino use because a single thin film cell generates 7.2 volts which is enough to power an Arduino! In contrast, one of the silicon cells only produces .5 volts (you need from 4.5 to 5.5 volts to power an Arduino).
In fact just one of the cells pictured here can power the arduino even in the shade. You could image one of these on top of a small device... however, they are not ideal for my project because I will have plenty of room under the glass of my table to put a lot of cells. And the silicon cells are cheaper per watt and more efficient per unit area.
The Batteries
I chose 4 1.2 volt Nmh (nickel-metal-hydride) batteries. I chose Nmh batteries because they can be trickle charged with a very simple circuit. They actually generate 1.3 (5.2 total) volts when fully charged. But that is less then the Arduino's limit of 5.5 volts, so I can connect directly to the Arduino's 5v line instead of the Vin. This bypasses the Arduino's voltage regulator and so is much more efficient but a little dangerous. It for some reason the voltage ever does exceed 5.5 volts, I could burn out the chip.
Charging Circuit
Basically, when the battery voltage is above that generated by the solar cells, current can flow from the top through the base (middle) of the upper right transistor and then backwards through the solar cells. This turns on the transistor, which then turns on the bigger transistor at the bottom and so power can flow through the Arduino. So the solar cells themselves are used both to charge and to sense when it gets dark. In practice, they turn the system on at dusk, so I put the Arduino to sleep for 45 minutes before actually turning on the LEDs.
The diode near the solar cells is so cells can only charge the battery, the battery can't attempt to "charge" the cells!
And finally a close up of the charging circuit itself:
The orange wires to the left go to the Arduino. The upper right ones go to the battery and the lower right to the cells. The wires on the bottom of the photo are basically electrical ground.
The LEDs
I use an M5451 constant-current LED driver chip to light the LEDs. If you are interested in this, there is a lot more information in prior blog posts, or at: http://code.google.com/p/arduino-m5451-current-driver/
Share your solar projects! :-)
Tuesday, July 7, 2009
Arduino + wireless + reconfigurable hardware: A proposal
I am thinking about doing a quadruple whammy Arduino board: Atmel Mega 640 + CPLD + wireless + MicroSD card.
For those of you who are unfamiliar with the term "CPLD", it is a reconfigurable hardware chip. Essentially, today's CPUs all follow what is called the "von Neumann architecture" in which a CPU executes a set of instructions in a sequential fashion. A CPLD is very different. It is a "sea of logic gates", so it essentially executes every instruction simultaneously. So if you visualize a plot with the horizontal axis being what can be done per unit time, and the vertical being how much time to do a task, the CPU plot looks long and thin. It can't DO much per unit time, but you can string together many instructions to do complex tasks. The CPLD plot looks short and fat. It can DO a lot per unit time, but cannot do complex tasks since tasks must be completed in essentially 1 time unit. CPUs are much more well known both because they are programmed in a manner more intuitive to people and because ultimately you can get a lot more done with a CPU. However, their linear nature means that there are things that CPUs do not do well, like simultaneously and monitoring rapidly fluctuating inputs.
The reasoning behind integrating a wireless network and MicroSD is much simpler. First of all, the MicroSD card has a very simple interface (8 wires) so its easy to plop down and very useful for data recording, etc. Its so simple there is no reason to NOT integrate it. Purchased separately, a wireless network is expensive. You must buy a shield ($20-30) and a wireless module (another $20-$30). So this ends up being an additional $40-$60, not that expensive until you consider that the most interesting uses are to have not just one or 2 devices but to have a "cloud" of them. So for 10 devices, that would cost $500 -- outside of the casual hobbyiest budget. However the basic wireless chips cost about $4 for single quantities, and maybe $5 when the few additional parts are added. So an integrated wireless would cost an extra $50.
It seems to me that once you leave thru-hole chipsets, the casual user can't just plop the AVR down on his own handwired circuit board... but if people are OK with that (and it seems like they are given how many other surface mount Arduino clones exist), then it really opens the door for a base platform that hits key features that the Arduino is missing today. If the chips are integrated into the base platform, this platform becomes MUCH cheaper and smaller then buying all the shields separately. The final result is a tiny computer with the all the essential components of a "standard" PC (CPU, network, disk) AND the components required for a high performance/high IO embedded device (CPLD running at 100mhz with 50+ digital IOs). This combination can be used for sensor networks, cooperative mini-robotics, illumination, art/design projects etc and would probably cost around $50 or less.
For those of you who are unfamiliar with the term "CPLD", it is a reconfigurable hardware chip. Essentially, today's CPUs all follow what is called the "von Neumann architecture" in which a CPU executes a set of instructions in a sequential fashion. A CPLD is very different. It is a "sea of logic gates", so it essentially executes every instruction simultaneously. So if you visualize a plot with the horizontal axis being what can be done per unit time, and the vertical being how much time to do a task, the CPU plot looks long and thin. It can't DO much per unit time, but you can string together many instructions to do complex tasks. The CPLD plot looks short and fat. It can DO a lot per unit time, but cannot do complex tasks since tasks must be completed in essentially 1 time unit. CPUs are much more well known both because they are programmed in a manner more intuitive to people and because ultimately you can get a lot more done with a CPU. However, their linear nature means that there are things that CPUs do not do well, like simultaneously and monitoring rapidly fluctuating inputs.
The reasoning behind integrating a wireless network and MicroSD is much simpler. First of all, the MicroSD card has a very simple interface (8 wires) so its easy to plop down and very useful for data recording, etc. Its so simple there is no reason to NOT integrate it. Purchased separately, a wireless network is expensive. You must buy a shield ($20-30) and a wireless module (another $20-$30). So this ends up being an additional $40-$60, not that expensive until you consider that the most interesting uses are to have not just one or 2 devices but to have a "cloud" of them. So for 10 devices, that would cost $500 -- outside of the casual hobbyiest budget. However the basic wireless chips cost about $4 for single quantities, and maybe $5 when the few additional parts are added. So an integrated wireless would cost an extra $50.
It seems to me that once you leave thru-hole chipsets, the casual user can't just plop the AVR down on his own handwired circuit board... but if people are OK with that (and it seems like they are given how many other surface mount Arduino clones exist), then it really opens the door for a base platform that hits key features that the Arduino is missing today. If the chips are integrated into the base platform, this platform becomes MUCH cheaper and smaller then buying all the shields separately. The final result is a tiny computer with the all the essential components of a "standard" PC (CPU, network, disk) AND the components required for a high performance/high IO embedded device (CPLD running at 100mhz with 50+ digital IOs). This combination can be used for sensor networks, cooperative mini-robotics, illumination, art/design projects etc and would probably cost around $50 or less.
Tuesday, March 24, 2009
Thoughts on GPL, the Open Company concept, and making $ therein
One aspect of the philosophy of GPL is to contribute back to the community. However, as we all know in the GPL license the only way to contribute is by submitting code.
This creates several problems; the primary being a chasm between it and all other economic activity. This has resulted in lots of people coming up with very creative but ultimately ancillary ways to fund GPL activity, the primary being support. There is probably a mountain of literature written about this and so I won't go into them more deeply here other than to summarize:
These methods are not satisfactory because the effort/reward relationship is obscure at best and at worst rewards the wrong activities.
So let us modify the GPL with a economic clause. This would essentially state, "If you want to use this software without licensing your derivative software via GPL, then simply pay us money.
In this way a company or individual can contribute back to the project in the traditional ($) manner (as an aside, does it also allow code contributions to be valued monetarily and therefore taxed?). But of course what should the project do with that cash? While many projects could definitely use the money to pay for server space and bandwidth; we can imagine an extremely successful piece of OSS that is actually generating a surplus of money. It would obviously be inappropriate for the project founder to keep it since in theory the software has benefited from submissions from many individuals.
That observation cannot sit in anyone's mind without producing the obvious answer within a modern meritocracy:
Project surplus should be distributed to individuals according to level of contribution
If the project is successful, one might imagine that this could become key contributors primary source of income. Essentially they would be "employees" of the project's "company", but without some of the pain associated with corporate involvement (and perhaps also without some of the benefits).
Of course, this brushes all kinds of issues under the rug such as how to measure "level of contribution". Let me throw out an initial breakdown formula:
contribution = "Trust Network" opinion * (alpha * sum(cool feature values) + beta * lines of code + delta * sum(bug fix value) - epsilon*(sum bugs you created))
"Trust Network opinion" = how other people rate you; used to catch people who are padding out their contributions by writing wordy code, etc.
Alpha, beta, and delta = arbitrary weighting factors depending on what's most important.
"cool feature values" = How much people like the feature you added (or maybe real-time feedback reporting what features the users are using)
"lines of code" should be obvious
"bug fixes" = Fixing bugs is a boring nasty job but someone has to do it.
And of course your contribution should be penalized by the # of bugs found; after all, if someone has to essentially rewrite your stuff; I'm not sure if you deserve too much credit.
But this only focuses on the code. How about the community? We can imagine similar metrics created for support forums; # of posts, response time, quality of posts, etc, and combined into a monster "value" equation. And documentation...
Even the necessary evil of "hierarchy and planning" can perhaps be captured by a pyramid scheme whereby section owners "contribution value" includes a tiny % of all contribution values to that section.
All of this begs the question: "Is it possible to capture all business activities?" To create an "Open Company?"
All of the above are my own ideas except for the word "Open Company". I was inspired to blog about them today because I think we are about to take the initial steps in regard to feasibility; there is a company out there who is going to try to do just that.
You can read a bit about it at: http://e-texteditor.com/blog/2009/opencompany
This creates several problems; the primary being a chasm between it and all other economic activity. This has resulted in lots of people coming up with very creative but ultimately ancillary ways to fund GPL activity, the primary being support. There is probably a mountain of literature written about this and so I won't go into them more deeply here other than to summarize:
These methods are not satisfactory because the effort/reward relationship is obscure at best and at worst rewards the wrong activities.
So let us modify the GPL with a economic clause. This would essentially state, "If you want to use this software without licensing your derivative software via GPL, then simply pay us money.
In this way a company or individual can contribute back to the project in the traditional ($) manner (as an aside, does it also allow code contributions to be valued monetarily and therefore taxed?). But of course what should the project do with that cash? While many projects could definitely use the money to pay for server space and bandwidth; we can imagine an extremely successful piece of OSS that is actually generating a surplus of money. It would obviously be inappropriate for the project founder to keep it since in theory the software has benefited from submissions from many individuals.
That observation cannot sit in anyone's mind without producing the obvious answer within a modern meritocracy:
Project surplus should be distributed to individuals according to level of contribution
If the project is successful, one might imagine that this could become key contributors primary source of income. Essentially they would be "employees" of the project's "company", but without some of the pain associated with corporate involvement (and perhaps also without some of the benefits).
Of course, this brushes all kinds of issues under the rug such as how to measure "level of contribution". Let me throw out an initial breakdown formula:
contribution = "Trust Network" opinion * (alpha * sum(cool feature values) + beta * lines of code + delta * sum(bug fix value) - epsilon*(sum bugs you created))
"Trust Network opinion" = how other people rate you; used to catch people who are padding out their contributions by writing wordy code, etc.
Alpha, beta, and delta = arbitrary weighting factors depending on what's most important.
"cool feature values" = How much people like the feature you added (or maybe real-time feedback reporting what features the users are using)
"lines of code" should be obvious
"bug fixes" = Fixing bugs is a boring nasty job but someone has to do it.
And of course your contribution should be penalized by the # of bugs found; after all, if someone has to essentially rewrite your stuff; I'm not sure if you deserve too much credit.
But this only focuses on the code. How about the community? We can imagine similar metrics created for support forums; # of posts, response time, quality of posts, etc, and combined into a monster "value" equation. And documentation...
Even the necessary evil of "hierarchy and planning" can perhaps be captured by a pyramid scheme whereby section owners "contribution value" includes a tiny % of all contribution values to that section.
All of this begs the question: "Is it possible to capture all business activities?" To create an "Open Company?"
All of the above are my own ideas except for the word "Open Company". I was inspired to blog about them today because I think we are about to take the initial steps in regard to feasibility; there is a company out there who is going to try to do just that.
You can read a bit about it at: http://e-texteditor.com/blog/2009/opencompany
Subscribe to:
Posts (Atom)