A Response to a Developer
A developer who was thinking of trying Falch.net Developer Studio posted a list of problems with CodeWarrior today. I think his list is pretty fair, but I wanted to respond to him, so I'm posting my response here, rather than clutter the groups dedicated to non-CodeWarrior tools.
1. My development device is an m505. Thus it comes standard with a USB cradle. I have had problems for months, and was part of the reasons I stopped developing on the Palm. I was frustrated with crashes in the USB driver (which might not be Metrowerks fault), but I've posted multiple messages regarding this that no one was able to help. I finally moved over to using a serial connection and my problems regarding debugging have improved dramatically. Regardless, I'm upset that Metrowerks would release something that was so unusable. I doubt I was the only person with these problems, because this happened to me on multiple machines.
We have had a hard time getting USB debugging to work. We initially supported this on the Handspring Visor, using code that Handspring supplied to us. When Palm introduced their USB devices (the m500 and m505), we wanted to support that too, but it took us a long time to get the needed information, and we had to discover most of the details of talking USB to the device from the Palm OS Emulator source code. PalmSource has been more cooperative lately, and I hope we can solidfy the USB support in the near future.
2. The documentation states that you can stop/break your application (like every other debugger is capable of doing), yet it's disabled in Codewarrior. When I did a search on the newsgroups, people mentioned it was disabled and someone from Metrowerks stated they just haven't implemented it yet. This was a post from 2000. Why is the button or menu entry there if it doesn't work. That's disappointing.
The user interface button for "stop" appears because its a standard part of the CodeWarrior debugger UI. We don't implement a custom debugger for every product we sell; instead we have a core debugger user interface, and debugger plugins that provide the actual connections to the devices to the IDE. If you read the document describing the Palm OS debug protocol, you will see no commands that actually tell the device to halt execution. Because no stop command was provided in the protocol, we have never implemented a stop in the IDE. Recently, I learned that the status command may cause the device to stop when used, so we will experiement with that, and if it works, we will hook up this functionality for the next release.
3. I was playing around with the standalone debugger (PalmDebugger.exe), and I liked all of the commands that I could enter. When I attempted to load an application into the debugger it asked for my symbol file (.sym). Codewarrior apparently creates a symbol file with the extension .psym. Maybe they're the same format, maybe not. But it's my understanding that the PalmDebugger.exe was created for GCC users. I'd love to use the PalmDebugger. Either that, or have all of those commands integrated into Codewarrior (specifically what I was looking for was a way to view a memory location in the UART 0XFFFFF902). In the standalone I would do something like "dm fffff902 2". Well, I went looking for this functionality in Codewarrior, and I only see a memory window. Of course if I look at that memory location in the memory window I get a bus error. I'm guessing this is because the window displays so many addresses, that it is attempting to access another piece of memory that is illegal - but it shouldn't have a problem accessing 0xFFFFF902. If there is a way, why is it so hard to find.
This is a symptom of the origins of the CodeWarrior debugger as one used for desktop applications. There is a way to just display a single memory address -- you open the expressions window, and add an expression. For this, you'd use the expression:
(unsigned short *)(0xFFFFF902)
The one issue with this is that the expression window can refresh itself frequently, and when it refreshes, it will reread the memory location from the device. If you're trying to view a memory-mapped peripheral like the UART, this could trigger odd behavior. There isn't a good solution for this problem. On some of our embedded products, we've started adding command-line debuggers to enable things like this, and we may consider adding this functionality in future Palm OS products.
For instance, there is another bug where an exception is thrown up with a modal dialog box. I close it, another one pops up. The only way to get control is to kill CW from the TaskManager. Unacceptable. I would tell you how to reproduce it, but I don't remember off the top of my head. I'm sure I'll run into again. I recently embarked on a new Palm project which is why I reinstalled CW back on my machine the other day. In the last few days I cant count the number of times I've had to manually kill CW.
I don't have a fix for this in the current CW tools, but in IDE 5.0, we redid the exception catching mechanism, and IDE or tools crashes now give a much more sane dialog, allowing you to create a crash log and terminate the current program. This will be part of the next CW for Palm OS release. Ideally, we don't want any crashes at all, but this tool actually gives us a fighting chance of diagnosing problems that lead to crashes on end-user machines.
Don't get me wrong, CW has improved, and I don't know what your sales are between Mac and Windows, but maybe you guys need a few more developers working on your Windows port.
We've recognized the need for more Win32 development. Right now, only the Palm OS and Macintosh products are sold hosted on Mac OS; most of our products are hosted on Win32, Solaris, or Linux. IDE 5.0, which was released in May, was a big step forward on the Windows side, finally implementing features like docking windows and workspaces that users have been requesting for years. I'm currently deep in development on V9 of the Palm OS tools, which will use the new IDE, and I'm doing most of my development on Windows.
I really value your feedback. I'm glad that most of your issues are things that we've already recognized as problems and are working on addressing, and I hope you give our tools another try when V9 is ready to go later this year.
Send feedback to combee@techwood.org
Copyright © 2004 Benjamin L. Combee
Palm OS is a registered trademark of PalmSource, Inc.
Metrowerks and CodeWarrior are registered trademarks of Metrowerks Inc.
The views expressed on this website/weblog are those of mine alone and do not necessarily reflect the views of PalmSource or Metrowerks.
qwertYAK / frobnovich
|
