William Wong
|
ED Online ID #13329 |
August 21, 2006
The PDT uses color coding of blocks to make text entry easier. It is also possible to view a file in full, condensed (no comments), summary, and documentation mode. This helps on navigation but summary mode only lists Spin functions, not cog functions.
The only options within the PDT are to edit and save a file or download it to RAM or flash on the target Propeller system. Once it is downloaded it begins to run. In general, debugging/testing an application is done by writing directly to RAM. This is very fast. Unfortunately, there is limited recourse if things go wrong.
Debugging A Spinning Propeller Shades of PBasic. That is probably the best way to describe debugging with the Propeller. Actually it is a bit more primitive because there is no sense of a PRINT statement because even the serial USB interface to the Propeller chip has no special significance.
Luckily there are some tools that are available to provide debugging services. Likewise, the PDT and the object oriented nature of the system lend itself to incremental development and testing.
First, consider the growing set of predefined objects such as LCD and display (VGA and composite video) that are already available. There are even serial interfaces that provide very basic debug monitor type functions such as dumping memory. These objects make it possible to develop a PRINT/INPUT style of debugging.
Unfortunately there is no way to easily implement a single step debugger for either cog or Spin code. In the former case there is no debug or single step mode for a cog. In the latter, the Spin interpreter store in ROM is only available to execute instructions. There are no hooks exposed to implement debug features like breakpoints or single stepping.
The only thing that limits this problem is the size of memory in a cog and in main memory. Applications simply cannot get that large with only 8Kwords of main memory especially since that must be split between Spin code, cog code, data and stacks.
The actual method used to debug a program will vary depending upon the experience of the developer, the complexity of the project and the use of existing, debugged objects.
In general, I found the lack of debug support a hassle after moving past the small sample applications. I did depend upon objects like the display monitor support but it takes a good deal of memory. If I were doing a major project I would probably take some time to implement a very simple, cog-level object to provide access to main memory via a serial link to a PC-based application. This actually is a good example of how to take advantage of the Propeller architecture since it would use a small bit of code and utilize a single cog.
Propeller Gripes And Grins The lack of a debugger is a definite problem. This means only a seasoned programmer should tackle the Propeller even at the Spin level. Sample applications and simple applications tend to be easy but venturing outside this boundary can be time consuming.
The mixing of online documentation with source code is a good idea but the implementation leaves a little to be desired. There is only one big documentation block. There is no correlation between it and any of the Spin or cog code. Jumping between the code and documentation to make changes is painful at best.
Reprints
