On 12/7/2014 2:34 PM, Oliver Betz wrote:> rickman wrote: > > [...] > >>>>> it's often (not always) inefficient compared to on-chip-debugging. >>>> >>>> Define inefficient. I can do the TTY thing with the absolute minimum of >>>> hardware and nearly no supporting software. How exactly is that >>> >>> SWD / JTAG / BDM / whatever debugging is usually "for free" if you use >>> this interface also for production programming. Otherwise it has the >>> same hardware cost as TTY. And it gives you extensive access to your >>> system without the need of instrumenting your code. >> >> "Not instrumenting your code" is a red herring. It can take me as much >> if not more time to configure a debugger as adding some output code to >> my program. > > It takes seconds to get a live display of dozens of variables, > including structs and arrays. Hardly possible by "adding output code" > and likely a runtime execution speed problem. BTW instrumenting code > is usually more invasive than background debug.Getting the data out is not the hard part. The hard part is getting to the point in the program at the right time to see the data and that is the real trick in any situation. If you are just stepping through your code you are grabbing at the low hanging fruit where a debugger is not needed at all. I'm sure there are plenty of times when a debugger made it easier to "see" some signal. A complex trigger definition may have made it easier to get to the right point in the code at the right time. But if you reread the thread you said print statements were "inefficient". I find they are often expedient since I don't need to deal with the ginormous complexity of a debugger and the *thinking* involved in each case is the same.>> I don't get the "for free" part. There is always a *special* debugger >> pod that requires a unique connector on the board... a connector which > > cheap these days, e.g. Segger J-Link comes with free eval boards. > Better adapters starting below 1000EUR.What??? Which eval boards are "free"? 1000 Eur is far from free. I'm not sure what you are saying. The "cost" is the added hardware on the target as well as the equipment cost.>> is virtually never used in the intended app of the unit while a serial > > The port is usually necessary for in-system-programming.I have *never* used a JTAG port in production programming other than FPGAs where there is no choice. Manufacturing tells me they don't want the complexity. For MCUs there is nearly always a serial interface to load the production code.>> port can serve double duty in minimal hardware designs or a built in >> display can serve double duty. >> >>> Consider also automated testing with original binaries, no >>> instrumentation. >> >> Not sure what you mean. The debugger interface can be used in > > A scriptable debugger enables automated tests in the target hardware.Tests that are often built into the MCU as a selftest. It's not just the factory where such tests are performed.>> production for programming the Flash, but my experience has been that >> production people don't want to deal with design tools in production. > > Production people use production tools but the same "connector" on the > target. Can be just four <1mm diameter test pads. Add two holes > beneath and something like http://www.tag-connect.com/I guess we have had different experiences. -- Rick
Modern debuggers cause bad code quality
Started by ●December 2, 2014
Reply by ●December 9, 20142014-12-09
Reply by ●December 9, 20142014-12-09
rickman wrote: [...]>>> "Not instrumenting your code" is a red herring. It can take me as much >>> if not more time to configure a debugger as adding some output code to >>> my program. >> >> It takes seconds to get a live display of dozens of variables, >> including structs and arrays. Hardly possible by "adding output code" >> and likely a runtime execution speed problem. BTW instrumenting code >> is usually more invasive than background debug. > >Getting the data out is not the hard part. The hard part is getting to >the point in the program at the right time to see the data and that isI'm writing about data ("variables") stored in memory, and by SWD/BDM... I can access them permanently, regardless what the program does at this time. [...]>>> I don't get the "for free" part. There is always a *special* debugger >>> pod that requires a unique connector on the board... a connector which >> >> cheap these days, e.g. Segger J-Link comes with free eval boards. >> Better adapters starting below 1000EUR. > >What??? Which eval boards are "free"?many.> 1000 Eur is far from free. I'm >not sure what you are saying.There are free (or cheap) eval boards with SWD debugger to start. And you can get "better" interfaces for less than 1000EUR.>The "cost" is the added hardware on the target as well as the equipment >cost.There is no additional hardware on the target.>>> is virtually never used in the intended app of the unit while a serial >> >> The port is usually necessary for in-system-programming. > >I have *never* used a JTAG port in production programming other thannot my problem.>FPGAs where there is no choice. Manufacturing tells me they don't want >the complexity. For MCUs there is nearly always a serial interface to >load the production code.with the same complexity. [...]>>>> Consider also automated testing with original binaries, no >>>> instrumentation. >>> >>> Not sure what you mean. The debugger interface can be used in >> >> A scriptable debugger enables automated tests in the target hardware. > >Tests that are often built into the MCU as a selftest. It's not just >the factory where such tests are performed.I'm writing about code testing / verification.> >>> production for programming the Flash, but my experience has been that >>> production people don't want to deal with design tools in production. >> >> Production people use production tools but the same "connector" on the >> target. Can be just four <1mm diameter test pads. Add two holes >> beneath and something like http://www.tag-connect.com/ > >I guess we have had different experiences.likely even different languages. Oliver -- Oliver Betz, Munich http://oliverbetz.de/
Reply by ●December 9, 20142014-12-09
On 12/9/2014 1:04 PM, Oliver Betz wrote:> rickman wrote: > > [...] > >>>> "Not instrumenting your code" is a red herring. It can take me as much >>>> if not more time to configure a debugger as adding some output code to >>>> my program. >>> >>> It takes seconds to get a live display of dozens of variables, >>> including structs and arrays. Hardly possible by "adding output code" >>> and likely a runtime execution speed problem. BTW instrumenting code >>> is usually more invasive than background debug. >> >> Getting the data out is not the hard part. The hard part is getting to >> the point in the program at the right time to see the data and that is > > I'm writing about data ("variables") stored in memory, and by > SWD/BDM... I can access them permanently, regardless what the program > does at this time.The value of a signal is not nearly as important as the timing. I don't care that the value went to zero, I already *know* that, I want to know *where* in the code and *why* it went to zero. That means I have to watch the value change in the context of the program. That is the hard part of using a debugger.>>>> I don't get the "for free" part. There is always a *special* debugger >>>> pod that requires a unique connector on the board... a connector which >>> >>> cheap these days, e.g. Segger J-Link comes with free eval boards. >>> Better adapters starting below 1000EUR. >> >> What??? Which eval boards are "free"? > > many. > >> 1000 Eur is far from free. I'm >> not sure what you are saying. > > There are free (or cheap) eval boards with SWD debugger to start. > And you can get "better" interfaces for less than 1000EUR.Please send me some of these "free" boards...>> The "cost" is the added hardware on the target as well as the equipment >> cost. > > There is no additional hardware on the target. > >>>> is virtually never used in the intended app of the unit while a serial >>> >>> The port is usually necessary for in-system-programming. >> >> I have *never* used a JTAG port in production programming other than > > not my problem. > >> FPGAs where there is no choice. Manufacturing tells me they don't want >> the complexity. For MCUs there is nearly always a serial interface to >> load the production code. > > with the same complexity. > > [...] > >>>>> Consider also automated testing with original binaries, no >>>>> instrumentation. >>>> >>>> Not sure what you mean. The debugger interface can be used in >>> >>> A scriptable debugger enables automated tests in the target hardware. >> >> Tests that are often built into the MCU as a selftest. It's not just >> the factory where such tests are performed. > > I'm writing about code testing / verification.Then why do you need "automated" tests? That says production to me.>>>> production for programming the Flash, but my experience has been that >>>> production people don't want to deal with design tools in production. >>> >>> Production people use production tools but the same "connector" on the >>> target. Can be just four <1mm diameter test pads. Add two holes >>> beneath and something like http://www.tag-connect.com/ >> >> I guess we have had different experiences. > > likely even different languages. > > Oliver >-- Rick
Reply by ●December 9, 20142014-12-09
Den tirsdag den 9. december 2014 19.12.52 UTC+1 skrev rickman:> On 12/9/2014 1:04 PM, Oliver Betz wrote: > > rickman wrote: > > > > [...] > > > >>>> "Not instrumenting your code" is a red herring. It can take me as much > >>>> if not more time to configure a debugger as adding some output code to > >>>> my program. > >>> > >>> It takes seconds to get a live display of dozens of variables, > >>> including structs and arrays. Hardly possible by "adding output code" > >>> and likely a runtime execution speed problem. BTW instrumenting code > >>> is usually more invasive than background debug. > >> > >> Getting the data out is not the hard part. The hard part is getting to > >> the point in the program at the right time to see the data and that is > > > > I'm writing about data ("variables") stored in memory, and by > > SWD/BDM... I can access them permanently, regardless what the program > > does at this time. > > The value of a signal is not nearly as important as the timing. I don't > care that the value went to zero, I already *know* that, I want to know > *where* in the code and *why* it went to zero. That means I have to > watch the value change in the context of the program. That is the hard > part of using a debugger. > > > >>>> I don't get the "for free" part. There is always a *special* debugger > >>>> pod that requires a unique connector on the board... a connector which > >>> > >>> cheap these days, e.g. Segger J-Link comes with free eval boards. > >>> Better adapters starting below 1000EUR. > >> > >> What??? Which eval boards are "free"? > > > > many. > > > >> 1000 Eur is far from free. I'm > >> not sure what you are saying. > > > > There are free (or cheap) eval boards with SWD debugger to start. > > And you can get "better" interfaces for less than 1000EUR. > > Please send me some of these "free" boards... >http://www.st.com/web/catalog/tools/FM116/SC959/SS1532/LN1847/PF260000 is $10, that is one beer at the pub -Lasse
Reply by ●December 9, 20142014-12-09
On 12/9/2014 1:27 PM, langwadt@fonz.dk wrote:> Den tirsdag den 9. december 2014 19.12.52 UTC+1 skrev rickman: >> On 12/9/2014 1:04 PM, Oliver Betz wrote: >>> rickman wrote: >>> >>> [...] >>> >>>>>> "Not instrumenting your code" is a red herring. It can take me as much >>>>>> if not more time to configure a debugger as adding some output code to >>>>>> my program. >>>>> >>>>> It takes seconds to get a live display of dozens of variables, >>>>> including structs and arrays. Hardly possible by "adding output code" >>>>> and likely a runtime execution speed problem. BTW instrumenting code >>>>> is usually more invasive than background debug. >>>> >>>> Getting the data out is not the hard part. The hard part is getting to >>>> the point in the program at the right time to see the data and that is >>> >>> I'm writing about data ("variables") stored in memory, and by >>> SWD/BDM... I can access them permanently, regardless what the program >>> does at this time. >> >> The value of a signal is not nearly as important as the timing. I don't >> care that the value went to zero, I already *know* that, I want to know >> *where* in the code and *why* it went to zero. That means I have to >> watch the value change in the context of the program. That is the hard >> part of using a debugger. >> >> >>>>>> I don't get the "for free" part. There is always a *special* debugger >>>>>> pod that requires a unique connector on the board... a connector which >>>>> >>>>> cheap these days, e.g. Segger J-Link comes with free eval boards. >>>>> Better adapters starting below 1000EUR. >>>> >>>> What??? Which eval boards are "free"? >>> >>> many. >>> >>>> 1000 Eur is far from free. I'm >>>> not sure what you are saying. >>> >>> There are free (or cheap) eval boards with SWD debugger to start. >>> And you can get "better" interfaces for less than 1000EUR. >> >> Please send me some of these "free" boards... >> > > http://www.st.com/web/catalog/tools/FM116/SC959/SS1532/LN1847/PF260000 > > is $10, that is one beer at the pubYep, that is a lot less than $1000 Euro, but hardly free. More importantly it is one brand of MCU. Does this help me with other MCUs? This board is two separate sections, one is the MCU and the other is the debugger support hardware... notice the debugger support is a third as large as the MCU section. Hardly inconsequential to include on your target board. -- Rick
Reply by ●December 9, 20142014-12-09
Ed Prochak wrote:> On Saturday, December 6, 2014 2:58:11 PM UTC-5, Les Cargill wrote: > [] >> >> Ah - well, it takes some digging and you have to be prepared to ignore >> differences that are smaller :) but all human languages can be arranged >> in a tree structure. Turns out there might be more in common than in >> difference. Differences tend to be things added after a population >> moved to a different place and the language evolved. >> > [] >> -- >> Les Cargill > > (maybe we really need to start another thread on languages) > > Sorry but after trying to learn some Chinese recently I have to disagree on that the differences in human languages can be described as small. >Oh, certainly - but there still appears to be "hardware support" for learning, say, Mandarin just as there is for English. This is basically the Chomsky "large structure" argument. SFAIK, no refutation of it has been developed. �the syntactical structures of human languages are the products of innate features of the human mind, and they have no significant connection with communication� ( appears to be Searle, not Chomsky ) https://blogs.commons.georgetown.edu/cctp-748-spring2013/2013/01/30/when-colorless-green-ideas-sleep-furiously/> yes human languages can be arranged hierarchically, just asprogramming languages can. But there are some large divergences in both trees.> > English for the most part is based on vowels and consonants and is basically atonal. (Words mean the same thing whether you speak in a monotone or in a song.) > > Chinese and other oriental languages are tonal. The same consonant and vowel combination can mean vastly different things depending on the inflection. > > In programming languages the divide is between ones like C and languages like LISP. > > I'll say one last thing today, then I have to get back to work. (This is more directed to the entire group, not you Les.) > > There is no one language that can be used for all problems. > > Someone else posted about high level languages not being flexible enough. > Maybe you chose the wrong language. A specialized language has great > advantages over a general purpose language within its problem domain. > > You can write C programs to read and write databases, but it is much easier > and clearer to express the program in SQL. You can write a compiler in COBOL, but it may be easier and clearer to use LEX and YACC. you can write a GUI in PERL and X, but maybe C# and XAML will be easier. > > In terms of programming, think like a mechanical engineer, and pick the right tool for the job. >Well said, Ed. -- Les Cargill
Reply by ●December 10, 20142014-12-10
Den tirsdag den 9. december 2014 22.42.23 UTC+1 skrev rickman:> On 12/9/2014 1:27 PM, langwadt@fonz.dk wrote: > > Den tirsdag den 9. december 2014 19.12.52 UTC+1 skrev rickman: > >> On 12/9/2014 1:04 PM, Oliver Betz wrote: > >>> rickman wrote: > >>> > >>> [...] > >>> > >>>>>> "Not instrumenting your code" is a red herring. It can take me as much > >>>>>> if not more time to configure a debugger as adding some output code to > >>>>>> my program. > >>>>> > >>>>> It takes seconds to get a live display of dozens of variables, > >>>>> including structs and arrays. Hardly possible by "adding output code" > >>>>> and likely a runtime execution speed problem. BTW instrumenting code > >>>>> is usually more invasive than background debug. > >>>> > >>>> Getting the data out is not the hard part. The hard part is getting to > >>>> the point in the program at the right time to see the data and that is > >>> > >>> I'm writing about data ("variables") stored in memory, and by > >>> SWD/BDM... I can access them permanently, regardless what the program > >>> does at this time. > >> > >> The value of a signal is not nearly as important as the timing. I don't > >> care that the value went to zero, I already *know* that, I want to know > >> *where* in the code and *why* it went to zero. That means I have to > >> watch the value change in the context of the program. That is the hard > >> part of using a debugger. > >> > >> > >>>>>> I don't get the "for free" part. There is always a *special* debugger > >>>>>> pod that requires a unique connector on the board... a connector which > >>>>> > >>>>> cheap these days, e.g. Segger J-Link comes with free eval boards. > >>>>> Better adapters starting below 1000EUR. > >>>> > >>>> What??? Which eval boards are "free"? > >>> > >>> many. > >>> > >>>> 1000 Eur is far from free. I'm > >>>> not sure what you are saying. > >>> > >>> There are free (or cheap) eval boards with SWD debugger to start. > >>> And you can get "better" interfaces for less than 1000EUR. > >> > >> Please send me some of these "free" boards... > >> > > > > http://www.st.com/web/catalog/tools/FM116/SC959/SS1532/LN1847/PF260000 > > > > is $10, that is one beer at the pub > > Yep, that is a lot less than $1000 Euro, but hardly free. More > importantly it is one brand of MCU. Does this help me with other MCUs? > > This board is two separate sections, one is the MCU and the other is the > debugger support hardware... notice the debugger support is a third as > large as the MCU section. Hardly inconsequential to include on your > target board. >you don't include it on a target board, all you need on the target is a connector they just made it easy and put both the debugger and the target on the same board -Lasse
Reply by ●December 10, 20142014-12-10
Niklas Holsti <niklas.holsti@tidorum.invalid> writes:> In this example, it seems simple for the compiler to warn (perhaps > only under some option asking for such warnings) that it has generated > code for "(x+1)>y" under the assumption that x+1 does not > overflow.No really, the compiler almost never can tell if x+1 might overflow. So it would have to emit a warning anytime the program says x+1. Note that if x is a signed int, then the >y is irrelevant: signed integer overflow is an undefined condition, i.e. nasal demons.> Such warnings would please the traditionalists, especially if the > compiler has options to suppress optimisations, like this one, that > assume no overflow. Understandably, the modernists are not eager to > bloat the compiler's optimiser and code-generator with such warnings > and options, which they feel are not in the modern C spirit.Gcc has the -wrapv option which ensures wraparound arithmetic (what the "portable assembler" crowd wants), and -trapv which signals an exception on overflow. Both of these potentially bloat the output code, of course.
Reply by ●December 10, 20142014-12-10
Ed Prochak <edprochak@gmail.com> writes:> yes that may mean turning off most optimizations when I want the > compiler to emit machine code the way I wrote it in C code. So I have > control.Turning off optimizations doesn't make undefined behavior defined. You have to either use compiler flags like -wrapv to specify the behavior that you want, or else write the code to avoid undefined cases.
Reply by ●December 11, 20142014-12-11
rickman <gnuarm@gmail.com> writes:> On 12/9/2014 1:27 PM, langwadt@fonz.dk wrote: >> Den tirsdag den 9. december 2014 19.12.52 UTC+1 skrev rickman: >>> On 12/9/2014 1:04 PM, Oliver Betz wrote: >>>> rickman wrote: >>>> >>>> [...] >>>> >>>>>>> "Not instrumenting your code" is a red herring. It can take me as much >>>>>>> if not more time to configure a debugger as adding some output code to >>>>>>> my program. >>>>>> >>>>>> It takes seconds to get a live display of dozens of variables, >>>>>> including structs and arrays. Hardly possible by "adding output code" >>>>>> and likely a runtime execution speed problem. BTW instrumenting code >>>>>> is usually more invasive than background debug. >>>>> >>>>> Getting the data out is not the hard part. The hard part is getting to >>>>> the point in the program at the right time to see the data and that is >>>> >>>> I'm writing about data ("variables") stored in memory, and by >>>> SWD/BDM... I can access them permanently, regardless what the program >>>> does at this time. >>> >>> The value of a signal is not nearly as important as the timing. I don't >>> care that the value went to zero, I already *know* that, I want to know >>> *where* in the code and *why* it went to zero. That means I have to >>> watch the value change in the context of the program. That is the hard >>> part of using a debugger. >>> >>> >>>>>>> I don't get the "for free" part. There is always a *special* debugger >>>>>>> pod that requires a unique connector on the board... a connector which >>>>>> >>>>>> cheap these days, e.g. Segger J-Link comes with free eval boards. >>>>>> Better adapters starting below 1000EUR. >>>>> >>>>> What??? Which eval boards are "free"? >>>> >>>> many. >>>> >>>>> 1000 Eur is far from free. I'm >>>>> not sure what you are saying. >>>> >>>> There are free (or cheap) eval boards with SWD debugger to start. >>>> And you can get "better" interfaces for less than 1000EUR. >>> >>> Please send me some of these "free" boards... >>> >> >> http://www.st.com/web/catalog/tools/FM116/SC959/SS1532/LN1847/PF260000 >> >> is $10, that is one beer at the pub > > Yep, that is a lot less than $1000 Euro, but hardly free.They are as close to free as makes no difference, you only need one per engineer! My rep gave me a handful of the things out of the boot of his car!> More importantly it is one brand of MCU. Does this help me with > other MCUs?Yes it does, it should work on anything with a SWD port, i.e. all ARM cortex MCUs. Which is likely the majority of new microcontrollers by now.> This board is two separate sections, one is the MCU and the other is > the debugger support hardware... notice the debugger support is a > third as large as the MCU section. Hardly inconsequential to include > on your target board.You just reserve a few pins on the target, there is no other per-target debug hardware needed. Maybe a pullup or some such. You will generally need a way to program the device anyway. -- John Devereux
