This has truly been a great learning experience. Not only have I received a great refresher course in C and developed a pretty good understanding of microcontrollers, but the insights into the software development process this project has provided are phenomenal. I am constantly revising the design document as new challenges and unforeseen issues arise. Our document is not in the shape it should be yet because it is missing several key components like the "readme" to indoctrinate newcomers and provide a high level view of the project. I feel the highest priority is getting Kevin some decent code which will hopefully work, is very well documented so that Doxygen can generate a great API for it, and has a solid basis in the design document. I have only concentrated on the design aspects of our document so far and all my code is heavily documented now following Kevin's coding conventions and Doxygen formats.
The Doxygen output will largely be a duplication of the design document so I don't think including it would be a good idea. I would like to submit the code I've written for some small part of my grade though. My plan is to finish coding over the next week and then spend time with the real board at Vertical Power testing while using the evening and night hours to refine our documents to include some of the nicer tidbits which should be part of a comprehensive document.
I must admit there were two or three weeks where I had pressing issues with my children and my custody battle to attend to and I only put 5-10 hours in. I felt bad about those weeks since this project was so immense (considering all that had to be learned and done). The rest of the time I have been committing at least 15 and usually 20+ hours to getting this thing done and I'm finally beginning to see the benefits of all I've learned. I'm also starting to feel a little proud of what we've done. Kevin's faith will not be totally misplaced, and that's another good thing.
Monday, November 27, 2006
Sunday, November 26, 2006
Big Dump
Well, the coding has been going well... it's the testing that really bites. I believe the code for the serial io and protocol modules is very solid. Extensive debugging last week and over the weekend uncovered several problems with my original code. Part of the problem is my unfamiliarity with C but that is diminishing as each session progresses. I still do not have basic functionality though. David has helped with a few things like extern declarations to help clear up my code. I really need to go over it with Kevin though and he was tied up through all the time and testing we did down at Vertical Power Wed, Fri, and Sat. I just thought of a new test method though. I can leave the line from the PC to the serial port we use for downloading code to the microcontroller hooked up instead of trying to send messages from one MC port to the other. I ought to be able to open up a hyperterm and then see if I'm at least sending anything.
Frustration with my lingering io/network bug and our rapidly approaching deadline has produced some benefit though. Tonight I coded up the Light Sensor and Magneto Switch modules so we at least have the code for those. Testing is always the bugger though. The bright spot is this stuff is much, MUCH simpler and really should work with very limited debugging. The Switch Module behavior is smilar but slightly more complicated so we should be able to kill it tomorrow and meet most of our prority 1 deadlines... at least coded. It's going to be hard to test any of this stuff without a functioning network.
David has been working on the EEPROM and reset modules and he took the SDK home to work on for Saturday night and Sunday. Hopefully, he made some good progress. If his stuff is solid then all we'll need after getting the switch module coded is shutdown and boot loader. Oh, except that dang function table to respond to incoming messages. I'll need help from Kevin with that too but I'm finally thinking we might be able to actually pull this thing off in the next two weeks. And that is a very good thing.
Frustration with my lingering io/network bug and our rapidly approaching deadline has produced some benefit though. Tonight I coded up the Light Sensor and Magneto Switch modules so we at least have the code for those. Testing is always the bugger though. The bright spot is this stuff is much, MUCH simpler and really should work with very limited debugging. The Switch Module behavior is smilar but slightly more complicated so we should be able to kill it tomorrow and meet most of our prority 1 deadlines... at least coded. It's going to be hard to test any of this stuff without a functioning network.
David has been working on the EEPROM and reset modules and he took the SDK home to work on for Saturday night and Sunday. Hopefully, he made some good progress. If his stuff is solid then all we'll need after getting the switch module coded is shutdown and boot loader. Oh, except that dang function table to respond to incoming messages. I'll need help from Kevin with that too but I'm finally thinking we might be able to actually pull this thing off in the next two weeks. And that is a very good thing.
Wednesday, November 15, 2006
Trouble with C
Getting back to programming with C is tougher than I thought it would be. Now, Im the one who will be dragging the project down. Ive found a few good references and am climbing a steep learning curve yet again on this project.
Atman kicks!!
The IDE Kevin has requested we use, Atman, is fantastic. Got it upand running over the weekend and began coding for the project. Atman takes care of setting up the framework for the code and handles initialization of the USARTs, IO ports, PWM, timers, and ADC with a very easy to use and understand interface. The code for the IO and protocol modules is not working yet but that is more a result of how long its been since I've used C than anything else. My plan is to have those modules working and sent to Kevin by our meeting on Thursday so I can help David get the rest of everything else running.
Tuesday, November 07, 2006
Meeting 11-07-06
Kevin and I both have some concerns over David's commitment and willingness to take on the level of work required for this project.
To date, I feel I have done an overwhelming amount of the work we have accomplished. I wouldn't mind so much if I was beginning to get a feeling he has worked to understand the Revolution system, the Atmel MEGA1280, our requirements, or the software design. It often appears he hasn't even learned enough to ask the right questions and seems to want to minimize everything from the requirements to the design. "Let's just do it, it's so easy" is a sentiment I feel he has conveyed but then he doesn't show a clear enough undertsanding to just do it.
Maybe I have been more dominant and not as much of a team player as I should. I know I have tried to communicate the importance of studying and understanding the documentation we have available. I have tried to work over the functional and design requirements but then I'll get a comment or question which makes me wonder if he's done much reading at all.
Today, Kevin and I decided that I should talk to him. We expected meat on the bones of the design I provided for handling changes to the switches and sensors. This is really a pretty easy thing to do, especially since I had provided control flow and several algorithms, but again we don't have what we need. Kevin is preventing us from writing code until he is confident we understand enough to move forward. This can only be displayed through clear and concise design work. I will talk with David and work with him on Thursday. I will be direct on asking him if he has any questions and trying to ascertain how much he really understands. I'll lay out the expectations clearly. I think Kevin has done a pretty good job of this already but we want to make sure we haven't failed in our communications.
On Friday, 11-10-06, we need to have a solid design for the complete system. I've taken on the hardest part of the project in designing the serial IO and protocol modules. We are basically ready to go there. I understand the registers and bits that need to be manipulated to make the microcontroller do what I need it to do. There is a big learning curve here since there are many details hidden in the datasheet for control register requirements. The code needs to be written in a certain way and all bits must be at their proper setting to enable the microcontroller to perform as expected. It isn't as simple as just writing code. Kevin and I both hope we will see David step up to the plate.
To date, I feel I have done an overwhelming amount of the work we have accomplished. I wouldn't mind so much if I was beginning to get a feeling he has worked to understand the Revolution system, the Atmel MEGA1280, our requirements, or the software design. It often appears he hasn't even learned enough to ask the right questions and seems to want to minimize everything from the requirements to the design. "Let's just do it, it's so easy" is a sentiment I feel he has conveyed but then he doesn't show a clear enough undertsanding to just do it.
Maybe I have been more dominant and not as much of a team player as I should. I know I have tried to communicate the importance of studying and understanding the documentation we have available. I have tried to work over the functional and design requirements but then I'll get a comment or question which makes me wonder if he's done much reading at all.
Today, Kevin and I decided that I should talk to him. We expected meat on the bones of the design I provided for handling changes to the switches and sensors. This is really a pretty easy thing to do, especially since I had provided control flow and several algorithms, but again we don't have what we need. Kevin is preventing us from writing code until he is confident we understand enough to move forward. This can only be displayed through clear and concise design work. I will talk with David and work with him on Thursday. I will be direct on asking him if he has any questions and trying to ascertain how much he really understands. I'll lay out the expectations clearly. I think Kevin has done a pretty good job of this already but we want to make sure we haven't failed in our communications.
On Friday, 11-10-06, we need to have a solid design for the complete system. I've taken on the hardest part of the project in designing the serial IO and protocol modules. We are basically ready to go there. I understand the registers and bits that need to be manipulated to make the microcontroller do what I need it to do. There is a big learning curve here since there are many details hidden in the datasheet for control register requirements. The code needs to be written in a certain way and all bits must be at their proper setting to enable the microcontroller to perform as expected. It isn't as simple as just writing code. Kevin and I both hope we will see David step up to the plate.
Overall Comments
This project is much larger than it might appear. To begin with, we are dealing with a microcontroller instead of a full system. This is a totally foreign environment to many CS, and apparently CE, undergrads so the first hurdle is to understand the microcontroller, the different approaches to design and coding required, and what tools are available.
The second issue is our integration to a much larger project. We are developing software to control the Small Switch Panel component of the Revolution system. The other, and much larger, systems are the Control Unit and the Display Unit. In order to understand how our component integrates with the others we need to understand the requirements of the other components. A second version of the system does not include the Display Unit but has an expanded switch panel called the Large Switch Panel. We are not writing the code for the large switch panel but our code will be used as a basis for the later development of that component. We must always be aware of the overall system requirements and make sure we don't do anything that will restrict the later development required.
The third issue is the tools we will need to utilize. The Atmel microcontrollers can use several different cross-platform compilers and IDEs for software development. All of these were foreign to us at the onset of this project. Kevin has defined the Coding Conventions so we also need to become familiar with those. Kevin has also required we use Doxygen for our comments and eventual documentation and manuals. While Doxygen may be easy to jump in to there is still a big learning curve if we want to utilize it to the best of its capabilities.
There is a huge amount to do and every day must be used wisely.
The second issue is our integration to a much larger project. We are developing software to control the Small Switch Panel component of the Revolution system. The other, and much larger, systems are the Control Unit and the Display Unit. In order to understand how our component integrates with the others we need to understand the requirements of the other components. A second version of the system does not include the Display Unit but has an expanded switch panel called the Large Switch Panel. We are not writing the code for the large switch panel but our code will be used as a basis for the later development of that component. We must always be aware of the overall system requirements and make sure we don't do anything that will restrict the later development required.
The third issue is the tools we will need to utilize. The Atmel microcontrollers can use several different cross-platform compilers and IDEs for software development. All of these were foreign to us at the onset of this project. Kevin has defined the Coding Conventions so we also need to become familiar with those. Kevin has also required we use Doxygen for our comments and eventual documentation and manuals. While Doxygen may be easy to jump in to there is still a big learning curve if we want to utilize it to the best of its capabilities.
There is a huge amount to do and every day must be used wisely.
The Design Document
All through the requirements elicitation process I was mulling design ideas over in my head. I have scoured through the requirements for the other components of the Revolution system to understand exactly what our component needs to do and how it will integrate with the other components. I have also read most of the Atmel MEGA1280 microcontroller datasheet to understand the limitations and requirements of the environment we need to work in.
A few weeks ago I created a hand written version of the Control Flow required for the software running the small switch panel. I identified the needed functionality to meet our requirements and developed a few algorithms to handle the difficulties we faced working in a microcontroller environment, especially regarding timing and making sure we can blink lights at the correct rate and ensure a change has really occurred to any of the switches or sensors before responding to them. I developed a timing mechanism we can utilize for the entire system to handle all of our timing requirements and also developed the basic outline for handling all of the switch and sensor changes we need to respond to. I developed the data structures required for overall system functionality but admit these still need some refinement.
The most difficult part of this design is dealing with the limitations of the serial communication we have available in the Atmel MEGA1280 microcontroller. The serial port and USART only transmit or receive one character at a time. Kevin made it clear that all communications need to be non-blocking. It took me a little while but with Kevin's prodding and advice, research of other solutions that have been developed, studying the 1280 datasheet, and sheer determination I developed the design for the serial communication layer and the protocol layer of our network communications.
Last week, in order to make sure we had discussion material for our meeting with Kevin, I wrote the entire design document we have to date. It included Serial IO, Protocol, Main Loop, Switch, Light Sensor, Magneto Switch, and Reset modules. Last Friday I was aware, and Kevin reinforced that just thowing everything we needed down on paper was not enough and thr document needed refinement, the design needed better flexibility and detail, and we needed to be done by our meeting today.
David and I agreed that I would continue to work on the Serial IO and Protocol modules and he could take what I have developed (basic design and control flow) for the other components and refine the design.
Today, the Serial IO and Protocol modules are basically done. I have two minor changes to implement in the design and will have these done tomorrow. I will begin coding these modules and be ready to make sure everything else gets done so Vertical Power will meet its deadlines.
A few weeks ago I created a hand written version of the Control Flow required for the software running the small switch panel. I identified the needed functionality to meet our requirements and developed a few algorithms to handle the difficulties we faced working in a microcontroller environment, especially regarding timing and making sure we can blink lights at the correct rate and ensure a change has really occurred to any of the switches or sensors before responding to them. I developed a timing mechanism we can utilize for the entire system to handle all of our timing requirements and also developed the basic outline for handling all of the switch and sensor changes we need to respond to. I developed the data structures required for overall system functionality but admit these still need some refinement.
The most difficult part of this design is dealing with the limitations of the serial communication we have available in the Atmel MEGA1280 microcontroller. The serial port and USART only transmit or receive one character at a time. Kevin made it clear that all communications need to be non-blocking. It took me a little while but with Kevin's prodding and advice, research of other solutions that have been developed, studying the 1280 datasheet, and sheer determination I developed the design for the serial communication layer and the protocol layer of our network communications.
Last week, in order to make sure we had discussion material for our meeting with Kevin, I wrote the entire design document we have to date. It included Serial IO, Protocol, Main Loop, Switch, Light Sensor, Magneto Switch, and Reset modules. Last Friday I was aware, and Kevin reinforced that just thowing everything we needed down on paper was not enough and thr document needed refinement, the design needed better flexibility and detail, and we needed to be done by our meeting today.
David and I agreed that I would continue to work on the Serial IO and Protocol modules and he could take what I have developed (basic design and control flow) for the other components and refine the design.
Today, the Serial IO and Protocol modules are basically done. I have two minor changes to implement in the design and will have these done tomorrow. I will begin coding these modules and be ready to make sure everything else gets done so Vertical Power will meet its deadlines.
The ICD Document
The ICD is the Internal Communication Document. It contains the guidelines for network communications between the various components of the Revolution product. Kevin asked us to help him out with completing this document. Kevin had the format of a network packet defined and several of the command packets defined also. I scrubbed our requirements doc and the requirements docs Kevin had for the other components to develop a complete list of the communications required for the Revolution system.
My discussions with Kevin during this process refined our concept of how the network would need to behave and developed additional requirements.
Kevin provided the details for the kind of information I had identified we needed to transmit and I edited the final draft to incorporate his suggestions and details.
My discussions with Kevin during this process refined our concept of how the network would need to behave and developed additional requirements.
Kevin provided the details for the kind of information I had identified we needed to transmit and I edited the final draft to incorporate his suggestions and details.
The Requirements Document
The requirement elicitation process and the creation of our requirements document was somewhat of a team effort. David and I did hold brainstorming sessions down at Vertical Power, but he didn't quite grasp the level of detail we needed for the functional requirements and didn't seem to have studied the documents Kevin provided (marketing reqs and the CU functional reqs) enough to have a clear understandingof exactly what we needed to do. I developed probably 95% of the functional requirements and did all of the write up for that section of the document. David did contribute by creating the rest of the requirements document but I think we could have done a much better job following the examples in the book and the Volere template rather than the bare bones Vertical Power version we did use as a guideline.
In an attempt to try and get David more familiar with the functional reqs we would need to implement I suggested he develop the test procedures and requirements to prove out each of our functional requirements. He took on the assignment but both Kevin and I feel that portion of our project needs a bit more work.
In an attempt to try and get David more familiar with the functional reqs we would need to implement I suggested he develop the test procedures and requirements to prove out each of our functional requirements. He took on the assignment but both Kevin and I feel that portion of our project needs a bit more work.
Subscribe to:
Posts (Atom)