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 23:13:41 2008
>> You must be using very small programs..
no, i really dont use DC. as per the topic discussion.
--- In r...@yahoogroups.com, Scott Henion wrote:
>
> 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| shenion@... |
> | 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 )
no, i really dont use DC. as per the topic discussion.
--- In r...@yahoogroups.com, Scott Henion
>
> 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| shenion@... |
> | 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 )