Searching \ for '[PIC] Stimulus file from real signals' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'Stimulus file from real signals'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Stimulus file from real signals'
2006\09\01@075117 by Tamas Rudnai

face picon face
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

2006\09\01@085410 by John Chung

picon face
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 <spam_OUTtamas.rudnaiTakeThisOuTspamgmail.com> wrote:

{Quote hidden}

> --

2006\09\01@094723 by Tamas Rudnai

face picon face
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 <.....kravnusKILLspamspam@spam@yahoo.com> wrote:
{Quote hidden}

2006\09\01@095900 by Wouter van Ooijen

face picon face
> 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.

I don't recall having done that but I would not hesitate doing so as
part of a debugging effort. It is no big deal, the art is to decide what
to print and how often.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2006\09\01@100324 by Maarten Hofman

face picon face
>
> 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 would be a bit scared doing a serial interface on a PIC using its internal
oscillator. In the past I've had issues of drift (not sure where the drift
came from, but i guess it could be temperature or just the phase of the
moon) where I had to readjust the speed of USART to compensate for a change
in the oscillator frequency. Of course, you can calibrate the 10F200, and
its oscillator might be more accurate than the one in the 16F628A and the
16F688, so it might be less of an issue. Also, you are coding it yourself,
so your base accuracy could be higher.

Greetings,
Maarten Hofman.

2006\09\01@101648 by Jinx

face picon face
> 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

What exactly is the problem ? Maybe we can sort it out logically.
So often things look hopeless, but a few fresh eyes and brains
can do wonders. Sometimes ;-)

2006\09\01@102815 by Wouter van Ooijen

face picon face
> I would be a bit scared doing a serial interface on a PIC
> using its internal oscillator.

But you are not limited to asycnhronous NRZ encoding - you can use any
encoding you like, optimized for speed/size as you like. There are
numerous encoidings that can tolerate >>10% clock uncertainty. Have
another PIC decode the data and send it out using its UART. Maybe with a
FIFO inbetween. For electrical isolation use an IR LED and a TSOP
receiver (OK, abit slow) or IRDA.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2006\09\01@102959 by Alan B. Pearce

face picon face
> 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.

What sort of I/O is giving you these problems?

I know that when I was debugging some I/O events I put specific breakpoint
labels in so I could step up to the breakpoint before the I/O happened, run
the code that handled the event and detected when it finished, and then had
another breakpoint immediately after that. This way the I/O went at normal
speed, but I could examine the states before and after.

2006\09\01@103440 by Tamas Rudnai

face picon face
Actually, what is the real percentage of the internal osc preciosity? I
know, 1-2% according the manual but seriously :-)
I do not mind if it's running in a different freq than 4MHz -- between
3.something and 4.something is OK as long as after I switch it on it keeps
the freq.

Anyway, I've just put that tool together, and will see if I could do
something in the debugger, and considering to keep your advise. I have a
spare 20MHz crystal at home and a MAX232 so may be I will put that debug
circuit together this weekend.

Thanks,
Tamas


On 01/09/06, Maarten Hofman <.....cashimorKILLspamspam.....gmail.com> wrote:
{Quote hidden}

> -

2006\09\01@104352 by Scott Dattalo

face
flavicon
face

On Fri, 2006-09-01 at 12:51 +0100, Tamas Rudnai wrote:

> 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.

Tamas,

You may wish to consider gputils and gpsim. With these tools, it's
possible to instrument your PIC source code with a variety of
debugging mechanisms to simulate real world behavior.

For example, you may know that at a certain point in your code that
some variable is in a certain range. However, you suspect that somehow
this variable is getting corrupted. In your source PIC code, you can
place an assertion:

SomeSubroutine:
 .assert "(my_var>=0x20) && (my_var<0x30)"
  movf  temp,W

When the movf instruction is executed, the assertion will examine that
the contents of 'my_var' are in the expected range.

Or you may just want catch the point where the upper two bits of 'my_var'
are set:

 .sim "break w my_var, (my_var&0xf0) == 0xc0"

There are many, many more assertions and breakpoint mechanisms
supported.


Or, you may wish to stimulate I/O pins or variables. gpsim supports an
"asynchronous_stimulus" mechanism that essentially allows you to
create any type of waveform imaginable. Waveforms can be attached to
I/O pins to simulate real world devices. Or, you can create a register
stimulus to simulate the changing of a register value. (Actually this
concept is extended to all simulator "attributes". Nearly anything
that can be written to can also have an attribute stimulus connected
to it. This is useful for driving external modules).

If it turns out that the built in simulator mechanisms are
insufficient, then you may wish to check out the external
modules. Probably the most popular is the USART. But there are others
like switches, LEDs, LCDs, resistors, simple logic devices, etc.

And if the built in modules are inadequate, you can always write your
own modules.

I use gpsim to test my personal PIC. Probably my most complicated project
is an 18F452 based design that has an RS232 interface, a proprietary
RF interface, a graphic LCD, several switches, an external 32kHz
crystal and a few other minor resistors. With this setup, I can
validate that an RF data stream is received correctly (or more
importantly, can test that the corner cases work and that erroneous
streams are recognized as such). I use the USART interface for
debugging and displaying information about the system. With gpsim's
USART module, I can design the UART output without having to burn a
chip. Similarly, I can design user interface screens in a simulation
environment by using gpsim's graphics LCD module.

Scott

2006\09\01@105544 by Tamas Rudnai

face picon face
Well, the problem is that I have an input signal that I would like to
filter. The input is a 50Hz PWM - erm, strange PWM as the period is at 50Hz
(around 20ms) but the duty cycle is between 1-2ms. That is used for
controlling servos used for modelling and robotics. The receiver is a dumb
thing, demultiplexes whatever it gets to several channels and puts the
signal out whatever it was -- even if it is not a PWM signal. From outside
the radio you just see square signals, and that's where you have to decide
whenever it is a valid or a not valid.

What you can do basically is that see if the signal is in between 1-2ms,
that's no problem. The other thing I thought is that you can see if the
signal arrives in time (every 20ms). Also no problem finding out whenever
the signal arrives.

Now the problem is that, I do not know why but it seems that 20ms is not
always kept -- it sometimes extends to longer, which is seems that depends
on the noise comming in. Also sometimes a noise could produce duty cycles
1-2ms so you have to do additional measurements. Avareging not always works
and also slows down the reaction time, but it's already in, anyway.
Comparing to 'left and right' is not always works and also slows down a bit
the reaction time, but it is also already in.

My basic problem is to determine if the signal is so bad it has to go to a
safe position and wait until good signal can be received. Interestingly when
I switch off the thransmitter it knows trait away that there is no signal so
shuts down the system after a couple of moments. But when just noise comming
in or the received signal is too weak it just do not want to realize that
the signal is too bad. It is very interesting to me as I could still see
strange duty cycles when the transmitter is off.

Maybe there is a good method for dealing with such a problem, but I thought
it is very specific, that't why did not want to bother you with the details.

Tamas






On 01/09/06, Jinx <EraseMEjoecolquittspam_OUTspamTakeThisOuTclear.net.nz> wrote:
>
> > 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
>
> What exactly is the problem ? Maybe we can sort it out logically.
> So often things look hopeless, but a few fresh eyes and brains
> can do wonders. Sometimes ;-)
>
> -

2006\09\01@110331 by Tamas Rudnai

face picon face
Scott,

That's what I wanted to do, so I have a WAV file with the real signals, and
wanted to put it into a stimulus file, which is quite good but not
documented and supported by Microchip -- I do not know why. So that I can
feed my app with waiting to the relevant us, then put pins high or low, then
wait again etc...

But will try out gpsim, as from Microship those assertations are missing as
far as I know - used 'debug glitches' for this purpose, so that a certain
pin set to high and low so I could see in the virtual logic analyzer what's
going on. But it is a real pain so thanks for that :-)

Tamas




On 01/09/06, Scott Dattalo <scottspamspam_OUTdattalo.com> wrote:
{Quote hidden}

> -

2006\09\01@120238 by Alan B. Pearce

face picon face
>and wanted to put it into a stimulus file, which is
>quite good but not documented and supported by
>Microchip -- I do not know why.

My memories of using a stimulus file is that it was quite easy to set up. It
is an ordinary text file that specifies the time between signal changes on a
pin. ISTR using GWBASIC to set up a file to simulate a UART input waveform
to do exactly what you are doing, and I did it all from the MPLAB
documentation.

It is a while since I did it, but do have another one to do soon, so will
have a look again.

2006\09\01@153852 by Tamas Rudnai

face picon face
part 1 1325 bytes content-type:text/plain; charset=ISO-8859-1; format=flowed (decoded 7bit)

This message previously bounced back as was to large, here it is again:

Yes, actually MPLAB documents only how to use the IDE to generate the file
(click here and there). But SCL files are much more powerful, it uses a HVDL
- or whatever is called - language, and you can use variables, loops etc to
generate a more sophisticated input to your debugee. All I wanted to do is
to convert my WAV file into that SCL file so that I hope I will find out why
it was doing that. (Just finishing that tool, anyway, so will see :-))

Thanks,
Tamas
PS: The attachment is an example of the noisy signal.


On 01/09/06, Alan B. Pearce <@spam@A.B.PearceKILLspamspamrl.ac.uk> wrote:
{Quote hidden}

> -

2006\09\01@161747 by Jan-Erik Soderholm

face picon face
Tamas Rudnai wrote :

> erm, strange PWM as the period is at 50Hz
> (around 20ms) but the duty cycle is between 1-2ms.

That is not strange at all, It's a plain standard RC-servo
signal !!

> What you can do basically is that see if the signal
> is in between 1-2ms, that's no problem....

Yes, the "pulse", correct. The timing of the pulse lenght
is what's important. The 20 ms interval is not (as important).

> I do not know why but it seems that 20ms is not
> always kept...

And why do you think that it should ? The function of
the servo is not dependant on the intervall beeing
"exactly" 20 ms. It can probably be 15-25 ms without
a real problem.

> My basic problem is to determine if the signal is so
> bad it has to go to a safe position and wait until
> good signal can be received.

Are you designing a "modell-saver" ?

> Interestingly when I switch off the thransmitter it knows
> trait away that there is no signal so shuts down the
> system after a couple of moments.

What is "it" and "system" ?
The RC-receiver should see that there is no 27 (or 40)
Mhz carrier and stopp producing pulses on it''s servo
connectors. It that what you are saying ?

> It is very interesting to me as I could still see
> strange duty cycles when the transmitter is off.

So the receiver still produces pulses ? Funny...

> Maybe there is a good method for dealing with such a problem,
> but I thought it is very specific, that't why did not want to
> bother you with the details.

What you have descibed *now* seems to be very important
to understand your problem...

Jan-Erik.



2006\09\01@190816 by Tamas Rudnai

face picon face
Jan,

On 01/09/06, Jan-Erik Soderholm <KILLspamjan-erik.soderholmKILLspamspamtelia.com> wrote:
>
> > erm, strange PWM as the period is at 50Hz
> > (around 20ms) but the duty cycle is between 1-2ms.
>
> That is not strange at all, It's a plain standard RC-servo
> signal !!


I know, I know, I just meant that normally you would say Xms period and Y%
duty cycle, so many times the duty cycle almost fills out the period -- but
not with these servos (5-10% duty cycle).

Yes, the "pulse", correct. The timing of the pulse lenght
> is what's important. The 20 ms interval is not (as important).


OK, but at least I thought that I can synchonize to the period and drop all
signals that are out of synchron no matter the length is in between the
valid range. But I was actually wrong on this: it is not just about the
receiver, but also if I change other analog channles on th econtroller the
period just a bit changes (but not as much as the duty cycle). That is
enough to not to count on that, and of course the receiver also produces
strange periods and loosing the syncron means loosing the control.
Resynchronizing is very hard as out of synchron happens only when the noise
is too much.

And why do you think that it should ? The function of
> the servo is not dependant on the intervall beeing
> "exactly" 20 ms. It can probably be 15-25 ms without
> a real problem.


It would not be a problem as I thought I could measure the signals when
switching on the device, so that the rest of the time I could measure that
one. But it changes during the operation...

Are you designing a "modell-saver" ?


Yep, but not just a failsafe as there are many of them already, but a
filter, so it supposed to work even in bad conditions -- you still will be
able to control, not just put the device into a safe state. That latter one
is the latest choice when the signal lost for a long time or the noise is as
bad as there is no valuable signal for so long.

> Interestingly when I switch off the thransmitter it knows
> > trait away that there is no signal so shuts down the
> > system after a couple of moments.
>
> What is "it" and "system" ?


it = my little device
system = device + servo (failsafe mode)

The RC-receiver should see that there is no 27 (or 40)
> Mhz carrier and stopp producing pulses on it''s servo
> connectors. It that what you are saying ?


Unfortunatly the  receiver receives noise and treat that one as a valid
signal. It is an analog receiver, so that it does not check if the signal is
valid. It just demultiplexes tha channels and puts out the signals (duty
cycles).

So the receiver still produces pulses ? Funny...


I was surprised too...

Actually I have mad a good progress on that this evening using that WAV to
Stimulus converter I have just wrote. Still have some issues, but now it is
quite stable :-)

Tamas

More... (looser matching)
- Last day of these posts
- In 2006 , 2007 only
- Today
- New search...