Thursday, June 30, 2011
Wednesday, June 29, 2011
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
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).
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...
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...
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
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
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.
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.