Thursday, June 30, 2011

Happy eagle day...

While the summer isn't usually the ideal time to look for eagles, I had the day off so I gave it a shot anyway...

Way out of practice it took a bit to get comfortable again - totally misjudged the light a few times...

No way to get the wind at my back, but for a practice session working on tracking was more important.  Ended up being far more eagles about than I expected for this time of year.  The young ones are still learning to fish, but not too bad at it overall.  (but they really lack the strength and endurance to life the large fish).

Didn't realize that the herons could lift the big ones at all... (they don't have anywhere the power of the eagles though and would be really vulnerable if the eagles wanted to take it - it took a long time to get airborne and never got more than a few feet off the water level with this one).

From time to time the little birds (especially falcons) hassle the eagles, this little one played the mimic for a while but never caused a problem..

Probably worth heading up again soon... (more from the day here).

Wednesday, June 29, 2011

Why not tie the upper income and corporate tax rates to the percentage of unemployment?

Why not tie the upper income and corporate tax rates to the percentage of unemployment?

Setting up the corporate tax rates so that they become lower as the unemployment rate decreases and they become higher as the unemployment rate increases should provide a strong feedback mechanism that will self-motivate the business community to extremely rapidly create jobs -> at the same time it will allow them to increase profits, and it will increase the taxable income and taxable trade at both the state and federal level.

It would reestablish the concept that we are all parts of a whole and that we all have a responsibility and an interest in the success of the country.

Rather than conceptually backing high income people into a corner where they will fight for their right to profit - it would give them a way out (bring others up to a fair level of prosperity and then you can profit more). 

It would calm the potential class division (income division) social stresses from both the lower income/unemployed and the upper income people/business perspectives. 

It should directly and indirectly cause massive reinvestment in this county of sufficient capital to rapidly create jobs - which should feedback to the local economies and therefore increase the stability of not just the taxable income but also the taxable trade (so both the federal and state tax bases should increase). 

It ought to be more successful than the old "look for the union label" campaign in directing the flow of money back into the United States (without the international trade social problems).

It ought to provide a common framework for the more rational members of both political parties because it gives them each something that would positively benefit all of their constituents (rather than having to chose one group to benefit and one to suffer). 

By moving the guiding framework from the decisions of the government to the self interest of the business there should be a long term motivation for all businesses to hire as many people as possible.

Friday, June 24, 2011

Ugly troubleshooting...

Life always seems to go in stages -> alternating between the excitement of possibilities and the frustration of not having things work as well as you want them to...  Whether it's learning to walk across the floor, or electronic design there is always a learning curve (the academic hurdles of studying and thinking and planning I enjoy, building I enjoy, the implementation hurdles of finding design mistakes, understanding exactly what unanticipated things exist - not so much).  If there is only one thing wrong I find troubleshooting an interesting process; but sometimes there are going to be so many things wrong that my normal (comfortable) approaches don't work... at these times I need to be in the "right mood" to figure things out or I just make things worse.

So I finally set aside some time and started to figure things out.  The first problem I found was that while the basic msp430 / PIC communication worked if I used the niblet card (simple card) -> adding the apricot card locks the bus...

It didn't take long to figure out that the fpga was interfering with the EN1 and MSTEN lines, so I disabled the fpga -> and it still fails... So I pulled the msp430 and it still fails (which now became apparent that something was very wrong).  I wasn't thinking that I would have to program the fpga to test the msp430, but I thought to myself "ok, well I'll just throw a simple configuration on it and that should fix it.  Maybe it has odd behavior if it isn't programmed at all." -> hooked up the jtag wires -> nothing visible on the chain... ugh... (walked away from it for a few days).

So one day after work on a rainy day I looked at the problem again and decided to pull the msp430 and just jumper the power supply enables - I used a socket in the design so I could do this, but it didn't work as well as expected - sockets are great for probing but not ideal for jumping enables - better than nothing but I wish I added dip switches.  The power supplies 3v3 and 2v5 come up with the correct voltages, but still nothing on the jtag chain.  Checked the 1v2 core voltage and that's right too.  (walked away again).

Went back over the schematics and nothing jumped out as wrong to me so the next day I put a scope on the power supplies thinking that maybe there were transient problems that wouldn't show on a meter but could affect the fpga... nope 1v2,2v5,3v3 are all nice and clean.  Tried a few different options for setting up the bitstreams and those didn't work... Put the jtag wires on a scope and they looked right (didn't decode but they looked reasonable). (Walked away again because I was getting very frustrated).

Went back and re-read a lot of documents, hundreds of pages.  Made notes, made guesses, came up with a plan but didn't have time for a few days.  Rechecked the board traces and pads - no apparent shorts (good) - decided to pull the board off the backplane and only attach power -> yay JTAG chain worked - correct device seen - good, could write bitstream - good, failed verify - not good.  Checked configuration settings - checked voltages - checked jumpers - all looked good, but it didn't work... hrmm... tried changing lots of configuration settings, dropping the speeds way down, nothing seemed to make a difference (walked away).

Woke up in the morning and realized that I might have made a really stupid mistake - on many microcontrollers pins can have multiple functions and depending on the architecture there are different ways to assign them to a given pin (always through configuration bits and/or software accessible registers.  FPGAs also have multiple functions on some pins and I had assumed that the ucf and verilog setting would compile into a bitstream that would similarly configure the pins... big big big stupid stupid stupid mistake... doesn't work that way at all for configuration. (kind of happy that I now knew what the problem was though).

So I went back and re-read a lot of documents and found out that while the pins used in configuration can be used once the bitstream is loaded, they can indeed interfere with the configuration process.  M[2:0] were correct and the PUDC/INIT_B/DONE were fine but I screwed up VS[2:0] (my notes originally said that I didn't need these if I was using the internal flash on the S3AN - wrong -> I had used VS1 and VS0 as a differential pair and VS2 wasn't used -> I had tied all my unused pins to GND and this put the chip into an undocumented/reserved state... ugh... got home, desoldered the VS2 pin and bent it up so it wasn't connected (it has an internal pullup because of the M[2:0] settings) -> and now jtag worked to write the bitstream, to verify the bitstream, but I got the dreaded "DONE did not go high" result and so the chip couldn't be programmed.  Ugh... checked and indeed DONE was low.  Tried to change a bunch of configuration settings but nothing made a difference...

Now I thought about a warning that I was getting when generating the bitstream (an ambiguous warning that I couldn't find referenced anywhere online or in XILINX support documents or forums).  Ended up being the differential pair that I was using on pins that also have configuration functions - figured out when I just simplified the design to not use any differential pairs -> but that wasn't the problem with failure to configure.  Back to documents again...

Realized that the CCLK (the configuration clock generated internally to pull the data from the internal flash) should be coming out on a pin (which again I was using for something else) -> checked in on a scope -> no signal... Hrmmm... desoldered and ripped it off -> still no clock on the stub and DONE never goes high... ugh... (Went hiking and swimming)

Thought that maybe, just maybe the SPI lines (also multiuse pins) were messed up (I wasn't using an external flash chip so I didn't care about them but wired them to the SPI part of the backplane anyway -> I pulled the PIC off the packplane and bingo, jtag scans, configures, verifies, and the fpga programs.. yay... (but all the testing signals I expected to see on the bus were not present)

Checked the clock going into the fpga (50MHz XPRESSO from Fox) - nothing... checked the schematic and it looked right but clearly no signal... Soldered another oscillator on a testing pcb, wired GND, 3v3, and that one had a beautiful happy sine wave and 50 MHz.  Connected the GND and 3V3 from this one to the apricot board (same power sources as the onboard oscillator) and nothing... Whoops... Checked the voltage on the board and it's way way off...

At first I thought I might have added the wrong regulator, but that looked right (the voltage was still low though) - desoldered the onboard oscillator (not fun) and then the voltage was right...  Went back to the spec sheet and I had screwed up the pin numbering (while I thought I checked it before, apparently I flipped the pin sequence).  Rigged up a "dead bug" (in this case a dead bug flailing in the wind) with a new crystal (upside down chip individual wires pad to pad - still didn't work, but now the voltage was lower... ugh... (went out to the fields to play with the dog).

Came back and looked at the schematic and found a stupid mistake.  I had a small regulator that was always on for the msp430 and a big 3v3 regulator for the fpga that was under enable control with powergood feedback.  I had decided that the msp430 really didn't need a big bulk storage cap so I connected that one to the big regulator and left the small regulator without a big cap -> the msp430 doesn't need much power at all so this is fine -> it becomes not fine when you attach an oscillator to the little ldo and not the big one (This is why the voltage was low (RMS) and the oscillator couldn't run) -> jumped it to the big regulator and bingo the oscillator works and the fpga does what it's supposed to... yay... (I have a vague memory of thinking that there was so much available current on the little ldo that I can attach the oscillator there, but somehow the fact that I took the electrolytic cap off got lost).

So now I have something that works (but is ugly as hell and has lots of jumpers) - not all that useful overall, but a very very valuable learning experience.  It's always good to find out where you make mistakes, what things you tend to overlook, and more importantly where in the process of debugging you miss the obvious (many times in this whole process I partially tested an idea and stopped when I found the first thing wrong rather than completing that whole type of analysis - I think that because I have so much control of things at work I have gotten used to only changing one things at a time and I forgot that in an uncontrolled situation many variables can change at the same time.  I made this board with the intention of testing some signals and to test the power supply/filtering and control logic for a little fpga which I later plan to use with some ADCs that need differential IO (and I can't do this with coolrunners (cplds).  I totally screwed up the fpga configuration process - discovered some things I would do differently in the future - and discovered a few weaknesses in how I think... Not a bad experience overall considering how much I learned... just not a lot to show for the effort this time.

Sometimes you have to go through the ugly/awkward/frustrating stuff to get to the point that you an do what you want...

Monday, June 20, 2011

It's time for people to stop feeling helpless...

It seems that every day I run into more people that seem to feel that the world is going to hell, the economy is falling apart, hope for the future is lost and the world will be worse for the future generations... I'm not entirely certain whether this festering despair is spreading from person to person slowly or whether it is the result of some widely dispersed media.  Either way I don't believe that it's malicious (perhaps indented to sell products - but I have trouble believing that anyone wishes to spread despair).

Well the truth is that the world isn't going to hell, the economies aren't falling apart, hope is never lost and the world will be better in the future... (but perhaps not everywhere at the same time).

Recently there have been lots of scandals and increasingly scary stories predicting doom and gloom for all... (whether it's jobs or benefits or fuel of food or ideology - or just about anything else that might hold value).  It's not unexpected really...

From time to time some members of society figure out a "new" way to trick the rest of the population for their personal benefit - these "lucky" few get to wield power and over time acquire the majority of the assets - for a time... Then things change and eventually the cycle repeats (it will always repeat because there will always be someone that want's "more").  That's just the way it is...  It's not a bad thing or a good thing (perhaps it is better to say that it has both good and bad characteristics at the same time depending on where you stand).

What most individuals always seem to forget it that they have a choice in the matter (if people always made rational choices then these cycles wouldn't happen - but people have flaws and can be tricked and misled and taken advantage of when they give up their choices voluntarily).

If people decided to spend their money locally (in their village or town or state or country) on products that benefit that community (perhaps jobs or investment or whatever else is lacking at a given time) then the local economy will prosper and grow.  If people want the overall education quality to improve then they need to read books and study themselves rather than watching television (it's absurd to think that children will "get" an education from a school when they come home to parents that just sit in front of a television and can't discuss complex issues).  If people want excellence rather than mediocrity than the people themselves need to at least attempt to be "better" today than they were the the day before.  It people want more jobs in their community then spend the money locally rather than trading it away to a faceless company that will use it to gain more profits (which of course does not mean local investment).  There is no end to the little things an individual can do to affect the world.

It's not complicated, it doesn't take a revolution, it doesn't take a single powerful entity to fix the world...  If individual people just act rationally in their own interests and do what they "think" is right then society will advance in the right direction. 

The key is that people have to realize is that deciding for oneself is not a right or a privilege that can be taken away - it is as inherent to each person as their soul and therefore more valuable than anything else that exists.

Monday, June 13, 2011

The frustrations of what whould be simple...

Why I always seem to have the most problems with the things that should be easiest and the fewest problems with those that should be hard I will never know.  Lots of frustration working out the I2C interface between the backplane controller and the card controllers.

For the alpha backplane I am using an 18F26K22 microcontroller from Microchip - it's primary role here is to control the activation state of the cards (power on/off - run/idle - clear/reset) over the I2C bus.  On the cards I am using MSP430s (G series depending on requirements).  The significantly more powerful PIC on the backplane will also connect to a low voltage serial bus for console control/debugging and has wiring for an SPI bus across the cards with individual enables and a global master enable.

Doesn't sound difficult right... (I didn't think so either) -> but then you have to add the fact that I hate having to externally program cards after the debugging stage (which for the I2C bus I would need to - especially for multiple cards of the same type)... so I decided to have all the cards start with the same I2C address (as a default) and then identify them and assign a unique address for the I2C bus with the backplane controller.  I decided to do this by having the cards behave differently when the master enable (MSTEN) is low or high.

When MSTEN is low AND the unique enable is high the controller on the card will assign the byte written to it over the I2C bus to a new unique address on the I2C bus.  Once a card has a unique (non default) address it will always listen to the I2C bus and bytes written to is will set the board state (power/reset/run conbinations) and it will respond to the master with data about the card's identity, intentions, activation state and potentially additional data.

Even this shouldn't be that difficult, but then I ran into some problems... The TI controllers allow me to use interrupts (lots of them) to handle various changes in the pin states - it took a bit more work than I expected to really understand the many control bits and the way the flags are triggered and reset - would have been easier to do in software but I wanted an interrupt implementation (for the the I2C on the USI controller and the Port2 IO control (MSTEN and EN1) signals because of some potential things the controller will have to do on future cards...  The PICs don't have lots of interrupts, but they have a well thought out set of registers and flags that work nicely (but from a very different overall design perspective).

Lots of subtle little things about the ways each was designed and implemented (one of those learning curve things - turned out steeper than I expected).  It was made worse by the fact that I only had random 5 to 15 minute intervals to work on it lately (which is fine for software but not for this - at least for me).  Finally I set aside a few hours and worked through everything and not the basics (idle scan mode/set addresses, read states) works.  I still need to write the card specific code for the apricot card (FPGA) and then signal testing can start (this should be a lot easier since the framework works now).



One a different note, the worst signal interference I found (granted that these are not very high edge rate changing voltages) wasn't as bad as I expected - (here's a 100 fold difference in the scales here (but the same heights for full voltages).  Here the card specific enables are walked (yellow for slot 4) and one of the neighboring differential pairs is monitored (blue) - no termination.


Still lots of work to do, but when I finally get past something that was more frustrating than I expected I kind of need to vent a bit... The sources are here and here (although not fully complete - the I2C stuff is functional for interrupt I2C implementations.

Saturday, June 11, 2011

Even when it's hot...

Water still flows and the plants still grow...

The babys still grow...

and the dogs still love to play in the fields...

Friday, June 3, 2011

They start out fluffy and white...

Today I learned that turkey vultures (the ever circulating very large black ones with the unusual heads) start out as little quasi-dinosaur-ish white fluffs... These are about a week old, deep in the woods in a little cave on the side of a cliff over a river. 

Another interesting thing about these little ones is that they make a sound very very like a rattlesnake.  I didn't get too close (the mother was about 20 feet over my head watching the dog (in a platz 50 feet away on the top of the cliff) but the sound is loud enough that if I didn't know the cave was there I would have thought it was a snake.  Kind of a neat thing - I wondered why a fox wouldn't raid the nest... now I know...

I know they are about a week old because I checked the nest a week ago when the mom didn't leave the cave I when I got home I saw the broken shell...

A little before that I found the eggs in the cave... The mother flew up in a flurry of feathers and wind when I was hiking along the top of the cliff - sparked my interest - climbed down - found the eggs...

Happy Mischka loves the vultures... why I don't know... She was the one that scented out the cave, but I haven't let her close to it now that they've hatched.