This past month at work has been very rewarding. We are at the initial prototype stage of development, and in many respects this is the most interesting stage. I have some cool new toys to play with.
At the moment on my desk I have several circuit boards hooked up together communicating with my computer over a USB connection. In addition I have 2 serial cables connected between these circuit boards and my computer.
What I am doing is writing software for one of the circuit boards. Actually I should use the term firmware, because at the end of the day, my code gets burned into an EEPROM (electrically erasable read only memory) chip which resides on the circuit board.
The situation is this. On my PC I am running an application program. This program talks to board A over a USB cable, which in turn talks to board B over a serial cable between them. Board B is the one I am writing software for.
Currently I am writing the communications handler for board B. This piece of software interprets the commands coming from board A, acts upon them, and then sends back a response.
Writing the software is in some respects the easy part. Testing it can be much harder. This is where another piece of software comes in called a debugger. The debugger runs on my computer and allows me to examine the code that is running on one of the boards. I can start and stop the code, view the contents of memory and generally interact with the software in such a way that I can understand what is going on. Hence the reason for the 2 serial cables connect between my computer and the circuit boards.
Why do I need two though since I am only debugging the software on board B?
The reason is that board A’s software normally will send commands to board B about every 5ms, that is 200 commands a second. That is well and good once the code for board B is working, but while testing the code, this is not desirable, I need to manually send commands back and forth between the two boards.
So even though I am not testing the software on board A, I need to use a debugger so that I can stop the code at will and only send commands to board B as I want them.
In summary I am using an application on my PC to send commands to board A via the USB cable. I then have a debugger running the code on board A which acts upon these commands and subsequently sends commands over to board B, when I want them. Finally I have the code under test running on board B using another debugger which acts upon the commands from board A and sends back responses, which subsequently get propagated back up to the application.
Which all together makes for a fun day at the office.
No comments:
Post a Comment