John,

> The main difference between embedded software and PC
> software is there is NO room for uncertainty........

That's why I want to be certain that it works :-)

USART is great, great when you have time for do something else than the real
thing. But the whole thing depends on timing, number of instructions etc
which is not very nice I know -- sometimes modifing only one instruction
takes as long as an hour. But that's my problem, I wanted to put it into the
smallest PIC :-) -- 10F2xx, no interrupts, only 1 8bit timer without knowing
that is overflowed etc.

I may able to debug it though in a higher chip, like 12F629/675 @20MHz, but
have to put debug macros to several points to slow it down as it was running
at 4MHz, so that I may be able to use USART -- sorry, just thinking 'loud'.

Thanks,
Tamas


On 01/09/06, John Chung <kravnus@yahoo.com> wrote:
>
> The main difference between embedded software and PC
> software is there is NO room for uncertainty........
> If it is going to fail or possibly fail than you have
> to write code that works in those condition. Generally
> blinking led is fine and straight forward but when it
> comes to interrupts and the orchestra than the ball
> game is different. In MCU like PIC you can use USART
> to print out areas of problem in your program. States
> or unhandled condition can be printed throught the
> UART when it is a REAL clock speed. No need to run the
> ICD2 or ICE since it may interrupt the timing of the
> chip? Anyway I believe Wouter  has written some
> program to print out the RAM contents through the
> USART periodically. That would help you identify the
> problematic areas.
>
> John
>
> --- Tamas Rudnai <tamas.rudnai@gmail.com> wrote:
>
> > Hi there,
> >
> > I have a problem on my project that when I debug my
> > code it is absolutely
> > perfect, however, in the real world it seems that
> > there are just much more
> > things that I did not take into account. My problem
> > is that as far as I know
> > there is no way to track down what's going on even
> > using a hardware debug
> > station -- but I may wrong. So that the PIC needs to
> > be run in the real
> > clock speed while I would need to watch the input
> > and output signals as a
> > logic analyzer and see the code flow so that I can
> > have a chance to detect
> > why my code enters to the bad state.
> >
> > I thought that I am lucky a bit because I can record
> > the input signal using
> > the sound card on my PC and put it to a WAV file, so
> > that I could analyze
> > it, which has already been done and still do not
> > have the answer for the
> > why. That's why I would like to convert it to
> > stimulus file to be able to
> > debug. Is anybody done something similar? Is there
> > any software or tool that
> > already doing this? Is that a bad idea or have a
> > simpler way to do? (I would
> > appreciate any thought on this).
> >
> > Thanks,
> > Tamas
> >
> >
> > --
> > unPIC -- The PIC Disassembler
> > http://unpic.sourceforge.net
> > --
> > http://www.piclist.com PIC/SX FAQ & list archive
> > View/change your membership options at
> > http://mailman.mit.edu/mailman/listinfo/piclist
> >
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
> --
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>



-- 
unPIC -- The PIC Disassembler
http://unpic.sourceforge.net
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist