Debugging applications
Leon
Posts: 7,620
Neither the new Parallax Semiconductor web site or the Propeller Manual discuss debugging techniques. I feel that the lack of conventional debug hardware will puzzle many prospective professional users and that the matter should be addressed.
Comments
Good point. I wrote exactly this in C/PASM last night to debug some code. Pick a location or group of locations in hub. Write a little pasm debug routine that stores values there at certain points in the program, and then print them out either from a higher level language, or via another cog (to a serial port, vga display, alphanumeric LCD display, or even to 32 leds, one on each pin).
This can be all done in software. However, I had to invent all the above from scratch and it probably is reinventing the wheel, and I could not have done this without having played around with the prop for over a year, so maybe a discussion of such techniques could be added to any future versions of the manual?
It would be nice to have an official / supported debug option. There are times when there's just no substitute for a decent debugger. You can't easily put a printf in the middle of a high-speed I2C routine in a PASM cog. :-)
Could it be because no-one who uses the Propeller seems to have a need for them?
Ross.
Prospective users *are* going to ask about debugging; Parallax Semiconductor doesn't mention it, and it's hardly mentioned in the documentation. I feel that some official documentation on debugging techniques is required.
You presumably debug your software using various techniques that you have found to work, as have we all. However, we have had to find them out for ourselves, or via the forum. Parallax themselves hasn't got any material on it, AFAIK.
Perhaps there are several people slaving over hot keyboards at this very moment, preparing such documentation.
There is some trash on the sidewalk. A couple walks up to it and says "That is just terrible". A few more people walk up and they are all discussing how terrible it is that people litter.
Finally there is a whole crowd of people talking about the litter and pointing.
Finally someone walking by, just picks up the litter and puts it in a nearby trash can. The crowd of people just look at each other and go on about their way.
Bean
Or, do you think I shouldn't have raised the issue in the first place and the thread is trash? You are a moderator, just delete the thread if you consider it off-topic or objectionable in some way.
Some people may not need or want a debugger, but personally I might not NEED one, but I'd really like to have one. And I agree with Leon that newbies and pros expect a debugger for a 32-bit microcontroller.
The point of my comment was, instead of all the discussion about if one is needed or not, we should be talking about how would be the best way to implement a debugger.
Bean
I did think that it might be something like Churchill's view that "we are two nations divided by a common language", though!
In another thread I replied to you on this subject and indicated that we'll give this some thought and address it on the Parallax Semiconductor web site. The same intent still holds true - nothing has changed about our plan to address the point you have brought up. As you probably know there's quite a bit going on here and you know it from reading the forums (trade shows, launch of Parallax Semiconductor, scheduling of a GCC/GNU developer's meeting, UPEW, etc.). It would be considerate of you to give us an opportunity to reply by the end of this week knowing that we've already received this same comment from several threads.
You mention that the FAEs have not replied to this thread. That's because all of them have been getting familiar with the new processes we've developed along with customer support responsibilities. The topic is on a list of discussion points for today's meeting.
This isn't the right forum for the particular topic. It really belongs in the "Suggestions to Parallax" forum, where I will move this thread at some point today.
Thanks,
Ken Gracey
I don't think I saw your reply, and can't find it. I can't even remember which thread it was!
Found it! It *was* in the Suggestions for Parallax Semiconductor thread, and I didn't get a reply, which is why I started a new thread.
The best technique I've used for debugging time critical routines without messing up the timing is instruction trace, where the instruction stream is captured to a buffer on the debugger and later analyzed.
-Phil