Sign in
Search rabbit-semi
Subscribe to rabbit-semi
Ads
Discussion Groups
Discussion Groups | Rabbit-Semi | Re: Newbie Rabbit vs. Netburner question...
This is a group for folks designing and programming embedded systems using the Rabbit Semiconductor C-programmable microcontroller. Rabbit Semi is a spin-off from Z-World who makes a variety of embedded modules and tools. This group is not affiliated with either Rabbit or Z-World, but is a user forum for sharing ideas, asking questions, flaunting knowledge, and other typical user group stuff. The Rabbit is a powerful uC, supported by a full-featured C-compiler.
Re: Newbie Rabbit vs. Netburner question... - seulaterbuddy - Mar 5 20:51:22 2008
>every time you stick in the code to "wave the flag" so to speak, you
>have to recompile, and start over.
Mike, i dont know why that would be such a big deal. add the printf
hit the compile button, 1-2 seconds later press teh download button,
4-5 seconds after that start your back in business.
you have made me think about why is it that i have this stubbornness
to move out of printf's. i have a vague memory of working with a
debugger years ago. i noticed that the device worked in debug mode
but when i ran her flat out she behaved differently. as it turns out
when you run something in single step you may get different results,
because is running that slow. when she's full out she will act
different. so since i know that she will be running full out all the
time i prefer to keep it that way and stick a printf here and there.
i must say that i cannot see using anything beyond printf. if in time
you think of a solid reason to use a debugger shoot it to me.
-cheers...
--- In r...@yahoogroups.com, Mike van Meeteren
wrote:
>
> At 12:53 AM 3/6/2008 +0000, you wrote:
> >The fact of the matter is that in all my years working with uP's i
> >have yet to have one person show me a definitive example of why a
> >debugger is better than a simple printf.
>
> printf is fine for watching variables. How about finding rogue
code? A
> single step debug is often the only way to find it. For example,
this week
> I had a PC program (yeah I know, not Rabbit, but the example
applies) I had
> a nil deference in. The program crashed with an exception error,
but I had
> no idea where. I knew how to cause it though. So I hit the button
that
> caused the exception and just single stepped until the program
crashed, and
> then I knew exactly what code was causing it.
>
> Sure, you can do that with turning on an LED and sticking the code
to turn
> that on to see how far you got in the execution, but every time you
stick
> in the code to "wave the flag" so to speak, you have to recompile,
and
> start over. A tedious process, expecially if it happens on the
304th
> iteration through a loop.
>
> Single stepping, variable watches, and all the other normal
debugging tools
> you get when you work with a debugger on a PC program, make it SOOO
much
> easier and faster than flying blind. Don't get me wrong, I've done
it both
> ways, especially when working with small chips (AVR parts for
example) that
> have no on chip debugging facilities, but I much prefer a real
debugger as
> opposed to watching from the outside.
>
> -Mike
> --
> Mike vanMeeteren FASTechnologies Corp.
> Wakeboarding as much as possible, on a 2007 Air Nautique SV-211.
>
(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )
>have to recompile, and start over.
Mike, i dont know why that would be such a big deal. add the printf
hit the compile button, 1-2 seconds later press teh download button,
4-5 seconds after that start your back in business.
you have made me think about why is it that i have this stubbornness
to move out of printf's. i have a vague memory of working with a
debugger years ago. i noticed that the device worked in debug mode
but when i ran her flat out she behaved differently. as it turns out
when you run something in single step you may get different results,
because is running that slow. when she's full out she will act
different. so since i know that she will be running full out all the
time i prefer to keep it that way and stick a printf here and there.
i must say that i cannot see using anything beyond printf. if in time
you think of a solid reason to use a debugger shoot it to me.
-cheers...
--- In r...@yahoogroups.com, Mike van Meeteren
wrote:
>
> At 12:53 AM 3/6/2008 +0000, you wrote:
> >The fact of the matter is that in all my years working with uP's i
> >have yet to have one person show me a definitive example of why a
> >debugger is better than a simple printf.
>
> printf is fine for watching variables. How about finding rogue
code? A
> single step debug is often the only way to find it. For example,
this week
> I had a PC program (yeah I know, not Rabbit, but the example
applies) I had
> a nil deference in. The program crashed with an exception error,
but I had
> no idea where. I knew how to cause it though. So I hit the button
that
> caused the exception and just single stepped until the program
crashed, and
> then I knew exactly what code was causing it.
>
> Sure, you can do that with turning on an LED and sticking the code
to turn
> that on to see how far you got in the execution, but every time you
stick
> in the code to "wave the flag" so to speak, you have to recompile,
and
> start over. A tedious process, expecially if it happens on the
304th
> iteration through a loop.
>
> Single stepping, variable watches, and all the other normal
debugging tools
> you get when you work with a debugger on a PC program, make it SOOO
much
> easier and faster than flying blind. Don't get me wrong, I've done
it both
> ways, especially when working with small chips (AVR parts for
example) that
> have no on chip debugging facilities, but I much prefer a real
debugger as
> opposed to watching from the outside.
>
> -Mike
> --
> Mike vanMeeteren FASTechnologies Corp.
> Wakeboarding as much as possible, on a 2007 Air Nautique SV-211.
>
(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )
Re: Newbie Rabbit vs. Netburner question... - cirusrabbit - Mar 6 11:29:10 2008
--- In r...@yahoogroups.com, "seulaterbuddy" wrote:
> different. so since i know that she will be running full out all the
> time i prefer to keep it that way and stick a printf here and there.
> i must say that i cannot see using anything beyond printf. if in time
> you think of a solid reason to use a debugger shoot it to me.
Hey, different strokes for different folks. I wasn't trying to change
the way you debug, just letting you know that there are tools out
there that save significant time over watching from the outside.
I've been at this a LONG time, and I've watched tools develop to where
I actually enjoy debugging on some platforms.
When I first started in software, I was working on a CAD/CAM package
running on DOS, built using Turbo Pascal, 1/4 million lines of source,
and you had to write your own display drivers. A complete build of
that project took 25 minutes on a 486/25, and you could get a cup of
coffee, stand around and chit chat, and still come back to watch the
last 5 minutes of the build. Debugging was done via a monochrome
monitor while you watched the program run on the main VGA tube. But
you could still single step :)
Anyway, today, I still maintain a version of that program. It's
shrunk to about 200,000 lines of code because some of the display
stuff went away with Windows. It now builds in about 10 seconds.
Lets just say debugging is a WHOLE lot faster today than it was 15
years ago.
Use the tools you want. Personally I am waiting for the day where
compilers are good enough to point out = and == errors, and forgetting
the () behind a function call results in a sensible warning. (Such is
life programming in multiple languages).
-Mike
(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )
> different. so since i know that she will be running full out all the
> time i prefer to keep it that way and stick a printf here and there.
> i must say that i cannot see using anything beyond printf. if in time
> you think of a solid reason to use a debugger shoot it to me.
Hey, different strokes for different folks. I wasn't trying to change
the way you debug, just letting you know that there are tools out
there that save significant time over watching from the outside.
I've been at this a LONG time, and I've watched tools develop to where
I actually enjoy debugging on some platforms.
When I first started in software, I was working on a CAD/CAM package
running on DOS, built using Turbo Pascal, 1/4 million lines of source,
and you had to write your own display drivers. A complete build of
that project took 25 minutes on a 486/25, and you could get a cup of
coffee, stand around and chit chat, and still come back to watch the
last 5 minutes of the build. Debugging was done via a monochrome
monitor while you watched the program run on the main VGA tube. But
you could still single step :)
Anyway, today, I still maintain a version of that program. It's
shrunk to about 200,000 lines of code because some of the display
stuff went away with Windows. It now builds in about 10 seconds.
Lets just say debugging is a WHOLE lot faster today than it was 15
years ago.
Use the tools you want. Personally I am waiting for the day where
compilers are good enough to point out = and == errors, and forgetting
the () behind a function call results in a sensible warning. (Such is
life programming in multiple languages).
-Mike
(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )
Re: Re: Newbie Rabbit vs. Netburner question... - Scott Henion - Mar 6 11:39:53 2008
seulaterbuddy wrote:
>> every time you stick in the code to "wave the flag" so to speak, you
>> have to recompile, and start over.
>>
>
> Mike, i dont know why that would be such a big deal. add the printf
> hit the compile button, 1-2 seconds later press teh download button,
> 4-5 seconds after that start your back in business.
>
As opposed to a fraction of a second for each single-step?
The last time I used DC it took about 25 seconds to compile/download.
You must be using very small programs..
> you have made me think about why is it that i have this stubbornness
> to move out of printf's. i have a vague memory of working with a
> debugger years ago. i noticed that the device worked in debug mode
> but when i ran her flat out she behaved differently. as it turns out
> when you run something in single step you may get different results,
> because is running that slow. when she's full out she will act
> different. so since i know that she will be running full out all the
> time i prefer to keep it that way and stick a printf here and there.
> i must say that i cannot see using anything beyond printf. if in time
> you think of a solid reason to use a debugger shoot it to me.
>
Yes, DC runs considerably slower with the debug code enabled. Most never
compile a version without the code as it may run different. One of the
advantages of Softools is it runs code the same speed with or without
the debugger. Using printf's in DC slows code way down as their stdio
support is not interrupt driven. It can have a real effect on performance.
I debug most of my code via my debug interface over the LAN. That
provides printf output and I can look at variables in semi-real time.
Usually printf's are already in the code anyway, and I can do much of
the debugging with it. Real help on the board controlling my generator.
Don't want to drag laptop outside in the freezing code to debug. I just
connect via the LAN and view the debug output. I can add watches for
variables and structures so I can see what is going on. When the
debugger is not connected, printf's are thrown out. So it has minimal
effect on arunning system.
A lot of the debugging has to do with the large amount of code in libs.
There you often have to use the debugger to see what the lib code is
doing A lot of my code is interrupt driven (external ints, timer ints),
printf's are no use there.
There are uP's that do not support printf's or serial ports. I use DSP
processors in my designs, they don't even support a char type in
hardware. The ONCE debugger has been real helpful although, once I wrote
my own debug interface, I don't need it.
I use PIC processors in a lot of designs. Most do not have a serial
port. They do support a debug interface. Real helpful as the chip has
only a few external pins.
I must admit I do not use the DC debugger, it is too slow, buggy and
cumbersome. I usually compile a .bin download it via ethernet then debug
via LAN debug. If that does not work, then I do use their debugger.
--
------------------------------------------
| Scott G. Henion| s...@shdesigns.org |
| Consultant | Stone Mountain, GA |
| SHDesigns http://www.shdesigns.org |
------------------------------------------
Rabbit libs: http://www.shdesigns.org/rabbit/
today's fortune
Hope that the day after you die is a nice day.
(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )
>> every time you stick in the code to "wave the flag" so to speak, you
>> have to recompile, and start over.
>>
>
> Mike, i dont know why that would be such a big deal. add the printf
> hit the compile button, 1-2 seconds later press teh download button,
> 4-5 seconds after that start your back in business.
>
As opposed to a fraction of a second for each single-step?
The last time I used DC it took about 25 seconds to compile/download.
You must be using very small programs..
> you have made me think about why is it that i have this stubbornness
> to move out of printf's. i have a vague memory of working with a
> debugger years ago. i noticed that the device worked in debug mode
> but when i ran her flat out she behaved differently. as it turns out
> when you run something in single step you may get different results,
> because is running that slow. when she's full out she will act
> different. so since i know that she will be running full out all the
> time i prefer to keep it that way and stick a printf here and there.
> i must say that i cannot see using anything beyond printf. if in time
> you think of a solid reason to use a debugger shoot it to me.
>
Yes, DC runs considerably slower with the debug code enabled. Most never
compile a version without the code as it may run different. One of the
advantages of Softools is it runs code the same speed with or without
the debugger. Using printf's in DC slows code way down as their stdio
support is not interrupt driven. It can have a real effect on performance.
I debug most of my code via my debug interface over the LAN. That
provides printf output and I can look at variables in semi-real time.
Usually printf's are already in the code anyway, and I can do much of
the debugging with it. Real help on the board controlling my generator.
Don't want to drag laptop outside in the freezing code to debug. I just
connect via the LAN and view the debug output. I can add watches for
variables and structures so I can see what is going on. When the
debugger is not connected, printf's are thrown out. So it has minimal
effect on arunning system.
A lot of the debugging has to do with the large amount of code in libs.
There you often have to use the debugger to see what the lib code is
doing A lot of my code is interrupt driven (external ints, timer ints),
printf's are no use there.
There are uP's that do not support printf's or serial ports. I use DSP
processors in my designs, they don't even support a char type in
hardware. The ONCE debugger has been real helpful although, once I wrote
my own debug interface, I don't need it.
I use PIC processors in a lot of designs. Most do not have a serial
port. They do support a debug interface. Real helpful as the chip has
only a few external pins.
I must admit I do not use the DC debugger, it is too slow, buggy and
cumbersome. I usually compile a .bin download it via ethernet then debug
via LAN debug. If that does not work, then I do use their debugger.
--
------------------------------------------
| Scott G. Henion| s...@shdesigns.org |
| Consultant | Stone Mountain, GA |
| SHDesigns http://www.shdesigns.org |
------------------------------------------
Rabbit libs: http://www.shdesigns.org/rabbit/
today's fortune
Hope that the day after you die is a nice day.
(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )
Re: Newbie Rabbit vs. Netburner question... - seulaterbuddy - Mar 6 12:24:41 2008
I am waiting for the day where compilers are good enough to point out
= and == errors,
aint that the truth!!!
--- In r...@yahoogroups.com, "cirusrabbit" wrote:
>
> --- In r...@yahoogroups.com, "seulaterbuddy"
wrote:
> > different. so since i know that she will be running full out all
the
> > time i prefer to keep it that way and stick a printf here and
there.
> > i must say that i cannot see using anything beyond printf. if in
time
> > you think of a solid reason to use a debugger shoot it to me.
>
> Hey, different strokes for different folks. I wasn't trying to
change
> the way you debug, just letting you know that there are tools out
> there that save significant time over watching from the outside.
>
> I've been at this a LONG time, and I've watched tools develop to
where
> I actually enjoy debugging on some platforms.
>
> When I first started in software, I was working on a CAD/CAM package
> running on DOS, built using Turbo Pascal, 1/4 million lines of
source,
> and you had to write your own display drivers. A complete build of
> that project took 25 minutes on a 486/25, and you could get a cup of
> coffee, stand around and chit chat, and still come back to watch the
> last 5 minutes of the build. Debugging was done via a monochrome
> monitor while you watched the program run on the main VGA tube. But
> you could still single step :)
>
> Anyway, today, I still maintain a version of that program. It's
> shrunk to about 200,000 lines of code because some of the display
> stuff went away with Windows. It now builds in about 10 seconds.
> Lets just say debugging is a WHOLE lot faster today than it was 15
> years ago.
>
> Use the tools you want. Personally I am waiting for the day where
> compilers are good enough to point out = and == errors, and
forgetting
> the () behind a function call results in a sensible warning. (Such
is
> life programming in multiple languages).
>
> -Mike
>
(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )
= and == errors,
aint that the truth!!!
--- In r...@yahoogroups.com, "cirusrabbit"
>
> --- In r...@yahoogroups.com, "seulaterbuddy"
wrote:
> > different. so since i know that she will be running full out all
the
> > time i prefer to keep it that way and stick a printf here and
there.
> > i must say that i cannot see using anything beyond printf. if in
time
> > you think of a solid reason to use a debugger shoot it to me.
>
> Hey, different strokes for different folks. I wasn't trying to
change
> the way you debug, just letting you know that there are tools out
> there that save significant time over watching from the outside.
>
> I've been at this a LONG time, and I've watched tools develop to
where
> I actually enjoy debugging on some platforms.
>
> When I first started in software, I was working on a CAD/CAM package
> running on DOS, built using Turbo Pascal, 1/4 million lines of
source,
> and you had to write your own display drivers. A complete build of
> that project took 25 minutes on a 486/25, and you could get a cup of
> coffee, stand around and chit chat, and still come back to watch the
> last 5 minutes of the build. Debugging was done via a monochrome
> monitor while you watched the program run on the main VGA tube. But
> you could still single step :)
>
> Anyway, today, I still maintain a version of that program. It's
> shrunk to about 200,000 lines of code because some of the display
> stuff went away with Windows. It now builds in about 10 seconds.
> Lets just say debugging is a WHOLE lot faster today than it was 15
> years ago.
>
> Use the tools you want. Personally I am waiting for the day where
> compilers are good enough to point out = and == errors, and
forgetting
> the () behind a function call results in a sensible warning. (Such
is
> life programming in multiple languages).
>
> -Mike
>
(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )
RE: Re: Newbie Rabbit vs. Netburner question... - Marcelo Richter - Mar 6 12:44:50 2008
Several of them generate warnings on this...but on Rabbit...that is not a
compiler in first place. :)
Discipline himself to do that way: if (constant =3D=3D something) not (some=
thing
=3D=3D constant).
Marcelo
> -----Original Message-----
> From: r...@yahoogroups.com [mailto:r...@yahoogroups.com] On
> Behalf Of seulaterbuddy
> Sent: quinta-feira, 6 de mar=E7o de 2008 14:11
> To: r...@yahoogroups.com
> Subject: [rabbit-semi] Re: Newbie Rabbit vs. Netburner question...
>=20
> I am waiting for the day where compilers are good enough to point out
> =3D and =3D=3D errors,
>=20
> aint that the truth!!!
>=20
>=20
>=20
>=20
> --- In r...@yahoogroups.com, "cirusrabbit" wrote:
> >
> > --- In r...@yahoogroups.com, "seulaterbuddy"
> wrote:
> > > different. so since i know that she will be running full out all
> the
> > > time i prefer to keep it that way and stick a printf here and
> there.
> > > i must say that i cannot see using anything beyond printf. if in
> time
> > > you think of a solid reason to use a debugger shoot it to me.
> >
> > Hey, different strokes for different folks. I wasn't trying to
> change
> > the way you debug, just letting you know that there are tools out
> > there that save significant time over watching from the outside.
> >
> > I've been at this a LONG time, and I've watched tools develop to
> where
> > I actually enjoy debugging on some platforms.
> >
> > When I first started in software, I was working on a CAD/CAM package
> > running on DOS, built using Turbo Pascal, 1/4 million lines of
> source,
> > and you had to write your own display drivers. A complete build of
> > that project took 25 minutes on a 486/25, and you could get a cup of
> > coffee, stand around and chit chat, and still come back to watch the
> > last 5 minutes of the build. Debugging was done via a monochrome
> > monitor while you watched the program run on the main VGA tube. But
> > you could still single step :)
> >
> > Anyway, today, I still maintain a version of that program. It's
> > shrunk to about 200,000 lines of code because some of the display
> > stuff went away with Windows. It now builds in about 10 seconds.
> > Lets just say debugging is a WHOLE lot faster today than it was 15
> > years ago.
> >
> > Use the tools you want. Personally I am waiting for the day where
> > compilers are good enough to point out =3D and =3D=3D errors, and
> forgetting
> > the () behind a function call results in a sensible warning. (Such
> is
> > life programming in multiple languages).
> >
> > -Mike
> >
>=20
>=20
>=20
>=20
>=20
>
=20
(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )
compiler in first place. :)
Discipline himself to do that way: if (constant =3D=3D something) not (some=
thing
=3D=3D constant).
Marcelo
> -----Original Message-----
> From: r...@yahoogroups.com [mailto:r...@yahoogroups.com] On
> Behalf Of seulaterbuddy
> Sent: quinta-feira, 6 de mar=E7o de 2008 14:11
> To: r...@yahoogroups.com
> Subject: [rabbit-semi] Re: Newbie Rabbit vs. Netburner question...
>=20
> I am waiting for the day where compilers are good enough to point out
> =3D and =3D=3D errors,
>=20
> aint that the truth!!!
>=20
>=20
>=20
>=20
> --- In r...@yahoogroups.com, "cirusrabbit"
> >
> > --- In r...@yahoogroups.com, "seulaterbuddy"
> wrote:
> > > different. so since i know that she will be running full out all
> the
> > > time i prefer to keep it that way and stick a printf here and
> there.
> > > i must say that i cannot see using anything beyond printf. if in
> time
> > > you think of a solid reason to use a debugger shoot it to me.
> >
> > Hey, different strokes for different folks. I wasn't trying to
> change
> > the way you debug, just letting you know that there are tools out
> > there that save significant time over watching from the outside.
> >
> > I've been at this a LONG time, and I've watched tools develop to
> where
> > I actually enjoy debugging on some platforms.
> >
> > When I first started in software, I was working on a CAD/CAM package
> > running on DOS, built using Turbo Pascal, 1/4 million lines of
> source,
> > and you had to write your own display drivers. A complete build of
> > that project took 25 minutes on a 486/25, and you could get a cup of
> > coffee, stand around and chit chat, and still come back to watch the
> > last 5 minutes of the build. Debugging was done via a monochrome
> > monitor while you watched the program run on the main VGA tube. But
> > you could still single step :)
> >
> > Anyway, today, I still maintain a version of that program. It's
> > shrunk to about 200,000 lines of code because some of the display
> > stuff went away with Windows. It now builds in about 10 seconds.
> > Lets just say debugging is a WHOLE lot faster today than it was 15
> > years ago.
> >
> > Use the tools you want. Personally I am waiting for the day where
> > compilers are good enough to point out =3D and =3D=3D errors, and
> forgetting
> > the () behind a function call results in a sensible warning. (Such
> is
> > life programming in multiple languages).
> >
> > -Mike
> >
>=20
>=20
>=20
>=20
>=20
>
=20
(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )
Re: Re: Newbie Rabbit vs. Netburner question... - Scott Henion - Mar 6 13:35:14 2008
seulaterbuddy wrote:
> I am waiting for the day where compilers are good enough to point out
> = and == errors,
>
> aint that the truth!!!
>
Hmm, most of my compilers do.
You should see the dozens of warnings from:
if (x=func())
when compiling DC code under softools ;) .
same for if (x=y)
and
..code
x==y; // warning do nothing code.
Yes, not pointed as errors, but does make you go look.
--
------------------------------------------
| Scott G. Henion| s...@shdesigns.org |
| Consultant | Stone Mountain, GA |
| SHDesigns http://www.shdesigns.org |
------------------------------------------
Rabbit libs: http://www.shdesigns.org/rabbit/
today's fortune
An ounce of mother is worth a ton of priest.
-- Spanish proverb
(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )
> I am waiting for the day where compilers are good enough to point out
> = and == errors,
>
> aint that the truth!!!
>
Hmm, most of my compilers do.
You should see the dozens of warnings from:
if (x=func())
when compiling DC code under softools ;) .
same for if (x=y)
and
..code
x==y; // warning do nothing code.
Yes, not pointed as errors, but does make you go look.
--
------------------------------------------
| Scott G. Henion| s...@shdesigns.org |
| Consultant | Stone Mountain, GA |
| SHDesigns http://www.shdesigns.org |
------------------------------------------
Rabbit libs: http://www.shdesigns.org/rabbit/
today's fortune
An ounce of mother is worth a ton of priest.
-- Spanish proverb
(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )