On 21/03/2011 15:47, Chris H wrote:> In message<im7nnd$r8a$1@speranza.aioe.org>, Mel<mwilson@the-wire.com> > writes >> Simon Clubley wrote: >> >>> On 2011-03-21, Chris H<chris@phaedsys.org> wrote: >>>> >>>> Methods of debugging are >>>> >>>> ICE (best method if available) >>>> Logic Analyser >>>> SWD (cortex) >>>> BDM >>>> JTAG >>>> serial monitor >>>> serial (manual debug) >>>> USB >>>> >>> >>> You missed out LED (+ current limiting resistor) connected to a GPIO pin. >>> :-) >> >> That's a Logic Analyzer :) > > Luxury! We had to debug in a darkened room with the off the MCU > watching the gates glow as they switched working with a print out of > the assembled (wot's a compiler?) binary...... > > You tell that to the kids these days and they don't believe you. >I remember debugging code on the ZX Spectrum by the buzzing sound of its power supply...
USB as standard debug interface
Started by ●March 18, 2011
Reply by ●March 21, 20112011-03-21
Reply by ●March 21, 20112011-03-21
On 21/03/2011 15:03, Simon Clubley wrote:> On 2011-03-21, Chris H<chris@phaedsys.org> wrote: >> >> Methods of debugging are >> >> ICE (best method if available) >> Logic Analyser >> SWD (cortex) >> BDM >> JTAG >> serial monitor >> serial (manual debug) >> USB >> > > You missed out LED (+ current limiting resistor) connected to a GPIO pin. :-) >And don't forget the burnt finger technique for hardware debugging.
Reply by ●March 21, 20112011-03-21
Chris H wrote:>... >Methods of debugging are >ICE (best method if available)Saddly gone, in this world of ball-grid-arrays and surface-mounted devices.>USB on the other hand requires a LOT more working software and it can >not debug itself it also requires far more of the system to be working. >Most engineers can knock up an RS232 debug system in a few minutes from >scratch. I doubt many if any can knock up a USB debug system from >scratch.We do it when forced to. But still the simplicity of uart + RS-232 is hard to beat. My 2nd choice would be CAN, but it is not available everywhere and in most cases cannot justify adding an externacl CAN controller to a design. -- Roberto Waltman [ Please reply to the group. Return address is invalid ]
Reply by ●March 21, 20112011-03-21
In message <im7oq5$57h$1@reader1.panix.com>, Grant Edwards <invalid@invalid.invalid> writes>On 2011-03-21, Chris H <chris@phaedsys.org> wrote: >> >>>You missed out LED (+ current limiting resistor) connected to a GPIO pin. :-) >> >> true >> >>>Great for debugging interrupt routines. >> >> But not as good as an ICE or LA > >On many platforms, ICE is useless for things like timeing measurement. >An LED (or better yet a few of them) works brilliantly for timing >measurements.Assuming they are available for the part AFAIK the ONLY thing that is any good for timing measurements are ICE or LA.>> The problem is you never really know what caused the LED to light. > >While I suppose that's true in a theoretical sense, it's not true in a >practical sense. In the real world (at least the one I work in), you >do know what cause the LED to light.No you don't you only think you do. -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by ●March 21, 20112011-03-21
In message <-dSdndhGOamK9hrQnZ2dnUVZ8umdnZ2d@lyse.net>, David Brown <david@westcontrol.removethisbit.com> writes>On 21/03/2011 15:47, Chris H wrote: >> In message<im7nnd$r8a$1@speranza.aioe.org>, Mel<mwilson@the-wire.com> >> writes >>> Simon Clubley wrote: >>> >>>> On 2011-03-21, Chris H<chris@phaedsys.org> wrote: >>>>> >>>>> Methods of debugging are >>>>> >>>>> ICE (best method if available) >>>>> Logic Analyser >>>>> SWD (cortex) >>>>> BDM >>>>> JTAG >>>>> serial monitor >>>>> serial (manual debug) >>>>> USB >>>>> >>>> >>>> You missed out LED (+ current limiting resistor) connected to a GPIO pin. >>>> :-) >>> >>> That's a Logic Analyzer :) >> >> Luxury! We had to debug in a darkened room with the off the MCU >> watching the gates glow as they switched working with a print out of >> the assembled (wot's a compiler?) binary...... >> >> You tell that to the kids these days and they don't believe you. >> > >I remember debugging code on the ZX Spectrum by the buzzing sound of >its power supply...Happy days....... -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by ●March 21, 20112011-03-21
>>> > Plus the constant annoyance of COM port numbers changing with the >>> > direction from which the wind is blowing. Today is COM739, tomorrow, >>> > who knows... >> >>I hope you don't seriously have COM739. > > Not yet, but it is just a matter of time... ;)Yep. We make products with COM ports on USB. My dev computer is up to COM63. It is just a matter of time when you hit some upper limit of who knows what. JJS
Reply by ●March 21, 20112011-03-21
On Mon, 21 Mar 2011 16:13:15 +0100, David Brown <david@westcontrol.removethisbit.com> wrote:><snip> >I remember debugging code on the ZX Spectrum by the buzzing sound of its >power supply...That goes back, though I can't recall doing that with my ZX81 (which I still have around, by the way.) And not as far as 1975 when I would debug my Altair 8800 programs using a nearby AM radio and using the tuning to select different parts of the program during debugging. (True, by the way.) Jon
Reply by ●March 21, 20112011-03-21
On Mon, 21 Mar 2011 16:13:56 +0100, David Brown <david@westcontrol.removethisbit.com> wrote:><snip> >And don't forget the burnt finger technique for hardware debugging.Used that. Sadly, the damned 1488 was always VERY HOT. Hard to know, with that infernal thing. At least the 1489 wasn't so bad. Jon
Reply by ●March 21, 20112011-03-21
On 2011-03-21, Chris H <chris@phaedsys.org> wrote:> In message <im7oq5$57h$1@reader1.panix.com>, Grant Edwards ><invalid@invalid.invalid> writes >>On 2011-03-21, Chris H <chris@phaedsys.org> wrote: >>> >>>>You missed out LED (+ current limiting resistor) connected to a GPIO pin. :-) >>> >>> true >>> >>>>Great for debugging interrupt routines. >>> >>> But not as good as an ICE or LA >> >>On many platforms, ICE is useless for things like timeing measurement. >>An LED (or better yet a few of them) works brilliantly for timing >>measurements. > > Assuming they are available for the part AFAIK the ONLY thing that is > any good for timing measurements are ICE or LA. > > >>> The problem is you never really know what caused the LED to light. >> >>While I suppose that's true in a theoretical sense, it's not true in a >>practical sense. In the real world (at least the one I work in), you >>do know what cause the LED to light. > > No you don't you only think you do. >Ok, it's time for me to learn something new because I don't know what you are getting at. Example setup: GPIO pin, with LED + resistor attached, is configured for output and is set low by writing a zero to the appropriate bit in the appropriate GPIO register at program startup. The interrupt handler sets the appropriate bit in the GPIO register when it's called, causing the LED to light and hence signalling that the interrupt handler has been triggered. Question: Why can't I assume that the interrupt handler has been successfully triggered ? If you are arguing that the code could scribble over the register causing the LED to light at random, then I accept it's possible in theory, but in practice, I have never seen a bug like that in my code. Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world
Reply by ●March 21, 20112011-03-21
On 2011-03-21, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:>>>> The problem is you never really know what caused the LED to light. >>> >>>While I suppose that's true in a theoretical sense, it's not true in a >>>practical sense. In the real world (at least the one I work in), you >>>do know what cause the LED to light. >> >> No you don't you only think you do. >> > > Ok, it's time for me to learn something new because I don't know what you > are getting at.Me neither.> Example setup: GPIO pin, with LED + resistor attached, is configured > for output and is set low by writing a zero to the appropriate bit in > the appropriate GPIO register at program startup. > > The interrupt handler sets the appropriate bit in the GPIO register > when it's called, causing the LED to light and hence signalling that > the interrupt handler has been triggered. > > Question: Why can't I assume that the interrupt handler has been > successfully triggered ?I've been using that assumption for 30 years. It's never been wrong yet.> If you are arguing that the code could scribble over the register > causing the LED to light at random, then I accept it's possible in > theory, but in practice, I have never seen a bug like that in my > code.Same here. -- Grant Edwards grant.b.edwards Yow! over in west at Philadelphia a puppy is gmail.com vomiting ...
