And at evanh, if it works it works, so I agree with what you're saying. But having multiple debuggers can be helpful, in fact having another one might even pick up some things another missed
They weren't asking for multiple debuggers, they want a perceived perfect deugger (using JTAG) built into the one and only official Parallax IDE.
Also, I wasn't saying debuggers are bad. Only that people whinging about the lack of dedicated debugging features need to get off thier high horses a little. Saying you want an integrated debugger is fine. Saying the Prop is unprofessional without it is, well, arrogant.
Actually, I'd like to see a debugger/JTAG-sampler be able to accurately handle the ISR debugging that I did with a few printf()'s. Either it'd fail to capture the important data or there would be a huge unnessary dump of data to sift through afterwards. A simulator may be up to it but would also have had to handle the added expansion cards that were in that setup.
All other 32-bit chips have on-chip debugging, and virtually all 16-bit and 8-bit devices as well. Most professional users expect it, and will be turned off by its omission.
Software developers don't work with hardware. Firmware engineers do. That's a
major the distinction IMO.
Nonsense. That is no distinction at all. It's all programming. Just that if it ends up
in a ROM, PROM, EPROM or some where hard to change it gets called "firmware".
I would really like the "firmware" that resides in the Boeing 777 flight controls, as an
example I have been involved with, to be written by competent software
engineers as it needs to be fast, reliable, fault tolerant etc etc.
During the years I spent testing safety critical software in avionics I never
saw anyone breaking out a debugger or ICE to fix a problem. At least not after
the initial boot loader is done.
How much of your code do you actually test prior to it getting any where near the
target hardware? What about coverage analysis or timing analysis?
PropGCC will use the gdb debugger in the LMM and XMM modes. I don't think it will be available in the COG mode, but there may a way to provide limited debugging functionality in that mode.
I am a software engineer, but only work in the embedded space as a hobby. Development platforms often go through a cycle where they are new and have little tooling, to mature with a lot of tooling. In a mature environment debuggers are expected development tools used during initial development, but not in QA or production. This is because when an esoteric production problem occurs you need logging to gather information on code flow and program state without development tools. The reason is that end users don't want debug tools deployed on their systems, but idiosyncratic environment issues often thwart attempt to reproduce the problem in house.
I know a small number of engineers who develop using logs. Their logic is they want to ensure the log has enough information added during development so that it will be useful during production support. Generally they are more productive on immature platforms, but less on mature ones.
Comments
Also, I wasn't saying debuggers are bad. Only that people whinging about the lack of dedicated debugging features need to get off thier high horses a little. Saying you want an integrated debugger is fine. Saying the Prop is unprofessional without it is, well, arrogant.
Actually, I'd like to see a debugger/JTAG-sampler be able to accurately handle the ISR debugging that I did with a few printf()'s. Either it'd fail to capture the important data or there would be a huge unnessary dump of data to sift through afterwards. A simulator may be up to it but would also have had to handle the added expansion cards that were in that setup.
Nonsense. That is no distinction at all. It's all programming. Just that if it ends up
in a ROM, PROM, EPROM or some where hard to change it gets called "firmware".
I would really like the "firmware" that resides in the Boeing 777 flight controls, as an
example I have been involved with, to be written by competent software
engineers as it needs to be fast, reliable, fault tolerant etc etc.
During the years I spent testing safety critical software in avionics I never
saw anyone breaking out a debugger or ICE to fix a problem. At least not after
the initial boot loader is done.
How much of your code do you actually test prior to it getting any where near the
target hardware? What about coverage analysis or timing analysis?
I know a small number of engineers who develop using logs. Their logic is they want to ensure the log has enough information added during development so that it will be useful during production support. Generally they are more productive on immature platforms, but less on mature ones.
So we don't need them in hardware, of course. Next question.