gnupic: gpsim stimulus
Subject:
Re: gpsim stimulus
From:
Scott Dattalo ####@####.####
Date:
11 Aug 2000 03:48:02 -0000
Message-Id: <Pine.LNX.4.21.0008102211550.9077-100000@tempest2.blackhat.net>
On Thu, 10 Aug 2000, John Duncan wrote:
> hello,
>
> i am hoping that someone can help me. I have been experimenting with
> stimulus files with gpsim 00.20.1. I just can't get things to work as I
> expect for example the following file:
>
> processor p16f84
>
> load -s test1.cod
>
> node test_node
>
> stimulus asynchronous_stimulus
>
> start_cycle 0x10
> initial_state 1
> period 0x50
>
> 0x20 0
> 0x25 1
> 0x30 0
>
> name asy1
>
> end
>
> attach test_node asy1 portb0
>
>
> My understanding is that this would result in portb0 going high at 0x10
> then low at 0x20, high at 0x25, low at 0x30, then high again at 0x60 and
> repeating
>
> What I get is high at 0x25, low at 0x30, then high again at 0x75. It
> appears that the initial_state of 1 is not occurring. When gpsim starts
> I get.
>
> new node : test_node
> period = 50
> phase = 0
> start_cycle = 0
> Next break cycle = 20
>
> What have I missed??
The latest stuff in CVS.
The initial state thing was broken.
Your understanding is almost correct - but your misunderstanding is no fault of
yours. gpsim's stimuli are powerful, yet extremely difficult to use...
Let me clarify each of the parameters for an asynchronous stimulus.
initial_state - This is the state that the asynchronous stimulus will be in
until the stimulus is driven to a new state.
start_cycle - This is the pic instruction cycle when the asynchronous stimulus
will begin to function
phase - not used and will be removed
period - the number of cycles for repeating the stimulus
So let's take your example and see what it is supposed to do:
> start_cycle 0x10
> initial_state 1
> period 0x50
>
> 0x20 0
> 0x25 1
> 0x30 0
>
When the stimulus is created, it will be driven high. It will remain high until
the first sample drives it low. This occurs at start_cycle + sample[0].cycle or
0x10 + 0x20 = 0x30. At cycle 0x10+0x25 = 0x35, it will be driven high. And
finally at cycle 0x40 it will be driven low.
The period is 0x50 cycles, so at cycle 0x60 the stimulus repeats. At cycle 0x60
+ sample[0].cycle = 0x60 + 0x20 = 0x80, the stimulus will be driven
low. However, it is already low from the previous period. Note that the
"initial_state" of 1 doesn't mean that the stimulus will go high at 0x60. At
cycle 0x85, the stimulus goes high, 0x90 it goes low.
If I wanted to create a pulse stream to drive the RX line on the UART I'd do
something like this (actually I'd write a script to do it for me...)
# send a string of 0x55's to the UART
# assume about 9600 baud - bit time ~ 100 cycles
stimulus asynchronous_stimulus
start_cycle 10000 # wait a while for the system to come up
initial_state 1 # quiescent state
period 4000 # Send a byte every 4ms or so
0 0 # start bit
100 1 # lsb
200 0
300 1
400 0
500 1
600 0
700 1
800 0 # msb
900 1 # stop bit
name uart_stim
end
Does that clear it up a little?
Scott
