Why I should get an....

The Vertical Power project would have been perfect for three people. It could have been a challenge for two people. And, it has been nearly impossible for less than two. I am not going to sit here and bash my partner but the question he had in the presentation session today about us going first and clear indications he wanted to leave after that to go study for another exam was indicative of the kind of committment I've seen throughout this project. I'm going to lay out what we've accomplished and what part of that was mostly my doing and I will let you, as the professor, decide what should go at the end of the title to this post.

Our first task was to understand how the Revolution system by Vertical Power worked and how the Small Switch Panel (SP) would need to integrate into the larger product. I studied the market requirements and the Control Unit functional requirements documents and talked extensively with Kevin at the start of this project about how everything was supposed to work. I believe that through our discussions we uncovered some weaknesses in the existing requirements and I hope that part of the process was helpful to Kevin.

The next task was to develop very specific functional requirements for the SP and write our requirements document. We had several brainstorming sessions to develop our requirements and Kevin was extremely helpful. I wrote the entire functional requirements section of our document. David wrote the rest but it seemed like more of a cut and paste job from what Kevin already had. David's input for the functional requirements was limited and showed he didn't have a clear grasp of the SP or how it fit into the overall system or the level of detail we needed. I tried to get David more involved and believed having him write the testing portion of our document would give him the insight he needed to help design and implement our functional reqs. One additional part of this process was the development of the communication protocol with definitions for all the packets. I scrubbed the requirements for all components and helped give Kevin the basis for the much more extensive and organized Internal Communication Document he finalized. It was a bit of work but helped me understand the system better and hopefully helped Kevin.

Our next task was to develop the design for the SP software. Although it was not listed as a specific requirement, the design and implementation of a multi-threaded type non-blocking serial IO interface and associated network protocol was instrumental to the function of the system and clearly the most difficult part of our problem. Again, Kevin helped a lot and gave a lot of direction with the comm sections but, so far, I have written the entire design document with the exception of the EEPROM module. At first I only focussed on control flow and the serial IO and protocol modules. David was to fill in the switch, light sensor, magneto dial, EEPROM, startup and shutdown sections. We decided to postpone any work for the bootloader as a last priority. The functionality of the non communication components is pretty simple and we felt this was a fair distribution of the work. I ended up filling in the blanks for everything except EEPROM, startup, and shutdown in the documentation. It still needs work but I believe the document will be ready for tomorrow even if it's not everything I would have liked it to be. At Kevin's request and what ended up being very productive for us, David and I developed a module interraction diagram. We were farther along in the project at this point and we probably wouldn't have gotten it right without David and I working together. David drew up a UML diagram for what we came up with and should be putting it into our design document. To tell the truth, I haven't had time to even look at it yet and have been working off my notes for that session. David will also be putting the readme section into the design document for getting any newcomer to the project started up quickly and I will be adding sections to each module for current implementation and problem areas.

Our next task was coding and testing. Again, initially I was focussed on the communications and David was going to focus on the rest of the essential functionality. At this point I have coded everything we have except for the EEPROM files. David had a great idea to use interrupts to synchronize the flashing of all lights when they needed to be blinking but his implementation of the PWM and the interrupts had a few problems. His implementation was hard to understand so I also ended up writing simpler timer file code in order to see some functionality.

We ended up being very individual units in the implementation and testing phase of our project. David was heavily wrapped up in doing the EEPROM stuff. Consistently, throughout this project I tried to explain what it was we needed to do, how the communications would work and how the rest might work, give him big chunks of the responsibility for design and implementation and try not to own the entire thing. Like I said earlier, this project would have been a challenge for two full students and I have other classes myself in addition to being a 24/7 single dad raising two young children. But when time would pass and I would hear questions and comments that just floored me, and there wasn't any design or coding getting done on the rest of the project, someone had to get everything going. David has tested his EEPROM code on the SDK kit. He has done some integration with the overall system but I haven't seen any stubs to hardcode initialization info into the EEPROM and use it to populate the switches at startup and I don't believe he has tested it on the real SP yet. The rest of what we have is basically my doing. I'm not proud of it at this point but testing and debugging has shown steady progress toward a completely functioning system.

I know it doesn't matter for the grade and there may be some doubts as to my commitment but I will see this project through. I've come tantalizingly close to seeing the functional requirements we layed out several months ago become a reality in the limited but very challenging and interesting world of microcontrollers. When I see a switch get flipped, the light go on, the new status properly communicated to the control unit, and the proper responses happening as a result of received messages I will be happy. When I reflect that we did it all on a microcontroller I knew absolutely nothing about 3 months ago I will also be proud.

I want to thank you for the opportunity to participate in a real project with a real company. It is an experience I think every student should have and I wish you all the luck in growing this class into the vision you have for it.

Thanks Again,
Marty Ridens

Our Demo

Well, demo night at Vertical Power was a bust. On Monday 12/11/06 at 7:00pm we hit the class deadline for showing functionality of the Small Switch Panel to Kevin. We will continue work on this project over the break but that isn't relevant at this point and for our class purpose.

We were doing well by Monday afternoon. There were issues with the communication system but we had reasonable functionality. We were sending and responding to messages and could show nearly all of the priority 1 items were met. We had most of the priority 2 ready to test and had seen succesful responses to several of these already. This still would put us well behind our original and even our revised schedules but at least we could show that some of what we did worked.

Alas, and I should know this, I did not commit the semi-working version to SourceSafe. While attempting to resolve comm issues I ended up breaking the communication software. When it was time to demo for Kevin, instead of sending a single message the SP would send many repeats of the same message, any responses were very sluggish if they occurred at all, and basically... we bit the dust. We weren't able to demonstrate even the most basic functionality. In another world I would have been up all night working with the system to get functionality back but we had missed our deadline and I had kids that needed to be put to bed. The looming and unshakable deadline of having quality documentation to submit for our class grade also took over and we had to bite the bullet and take whatever grade our work will earn us.

I am not a quitter. The final deadline for Vertical Power to have a fully tested and robust SP system is mid January and I am looking forward to solving the challenges remaining before us.