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)