part 0 44 bytes his is a multi-part message in MIME format. part 1 253 bytes content-type:text/plain; charset=ISO-8859-1; format=flowed (decoded 7bit)
Using a basic compiled program using a for-next loop, a flash PICchip.
can I expect toget a pulse every 55 ms. or about 18pulses per second?
I know a lot of it will depend on what speed I am running the chip at.
part 2 391 bytes content-type:text/x-vcard; charset=utf-8; (decoded 7bit)
begin:vcard
fn:Robert I. Nelson
n:Nelson;Robert I.
org:RIN Designs
adr:;;P.O. BOX 373;RIPON;WI;54971;USA
email;internet:spam_OUTrindesignsTakeThisOuTcharter.net
tel;work:1-(920)-229-7152
tel;home:1-(920)-748-7443
note;quoted-printable:Custom design and building of small electro mechanical devices.=0D=0A=
AUTOCAD work ver2002
x-mozilla-html:FALSE
version:2.1
end:vcard
part 3 35 bytes content-type:text/plain; charset="us-ascii" (decoded 7bit)
There is a lot more to think about than just the oscillator speed. How
precise do you need this pulse? Can you post the for loop? Do you have its
disassembly listing? What is your oscillator frequency?
What PIC part are you using?
James
On 11/28/05, R. I. Nelson <.....rindesignsKILLspam@spam@charter.net> wrote:
>
> Using a basic compiled program using a for-next loop, a flash PICchip.
> can I expect toget a pulse every 55 ms. or about 18pulses per second?
>
> I know a lot of it will depend on what speed I am running the chip at.
>
>
>
>
Even more than the speed you run the PIC at, the compiler makes a big
difference.
Some BASIC implementations compile the program to a bytecode that is stored
in the EEPROM and interpreted by code running in the PIC. This is obviously
orders of magnitude slower than true compiled code.
Once you have figured out that you have actual compiled code, you can still
change the performance by orders of magnitude depending on how competent the
compiler is. However, if the PIC were running in the megahertz range, and
the compiler was 'pretty good', I would expect you could flash the LED at a
kilohertz kind of rate. If your PIC had a 4 MHz or igher clock, and you did
nothing in the loop besides turn the LED on and off, I would not expect you
could see the LED flash unless the compiler was very poor.
Obviously, you could choose to clock the PIC at 32 kHz instead of 20 MHz,
and that would make a huge difference. And the compiler could be lame,
and .... and .... and ...
> Using a basic compiled program using a for-next loop, a flash PICchip.
> can I expect toget a pulse every 55 ms. or about 18pulses per second?
>
> I know a lot of it will depend on what speed I am running the chip at.
Yes, and on the BASIC compiler.
Let me see, hypothetically (non working code, just counting a bit):
FOR A = 0 TO 255
PORTC = PORTC & 254
PORTC = PORTC | 1
NEXT A
; FOR A = 0 TO 255
movlw 0
movwf A
goto NEXT1002
NEXT1001
movlw 255
xorwf A,w
btfsc STATUS,Z
goto NEXT1003
incf A,f
NEXT1002
; PORTC = PORTC & 254
movlw 254
andwf PORTC,f
; PORTC = PORTC | 1
movlw 1
iorwf PORTC,f
; NEXT A
goto NEXT1001
NEXT1003
Which indicates there are 4 cycles of setup and 11 cycles per loop.
Given a not unreasonable clock frequency of 4 MHz, that means you get
a pulse every 11us, so about 90909 pulses per second.
As said, this highly depends on the clock frequency, but also on the
BASIC compiler (the code could be further optimized using
incfsz/decfsz, which would make it faster. Or the BASIC compiler
outputs more generic code, allowing values greater than 255, which
would make things slower... Also if it would allow full expressions in
the FOR loop this might add superfluous dummy variables, slowing
things down).
But 90909 pulses per second seems a lot closer to reality than 18. If
you DO want 18 pulses per second, you might need to add a suitable
PAUSE command, of known duration.
> Using a basic compiled program using a for-next loop, a flash PICchip.
> can I expect toget a pulse every 55 ms. or about 18pulses per second?
>
> I know a lot of it will depend on what speed I am running the chip at.
Wow. As open ended a question as I've ever seen.
There are literally hundreds of ways to solve this. In Basic, though, you
will have a much harder time than just sussing out how to do it in
assembler. Best is if your Basic compiler lets you drop inline assembly
into your code (see the Asm/EndAsm directives in PicBasic).
Have you considered setting up an interrupt to occur? 55 ms should be
well within the grasp of most timer based interrupts, and then you don't
need to worry about timing once you've started it up.
Not sure where you get the 55ms from, but 55ms/18hz is the timer interrupt
frequency of the PC (personal computer) and should not have any effect on
pic except for maybe reading or writing to the pic from the PC. It is a PC
thing.
>> Using a basic compiled program using a for-next loop, a flash
>> PICchip.
>> can I expect toget a pulse every 55 ms. or about 18pulses per second?
>>
If your question boils down to "can a PIC, programmed with a compiler,
execute a typical program loop at least 18 times per second", the answer
is almost certainly yes. In general, it's annoying to slow things down
that much; taking several nested empty loops if your loop counters are
only 8 bits. Something like
for I = 0 to 255
next I
PROBABLY takes on the order of 5 mS (assuming: 20 instructions per loop,
1uS per instruction. A GOOD compiler should do much better.)
part 0 44 bytes his is a multi-part message in MIME format. part 1 1089 bytes content-type:text/plain; charset=ISO-8859-1; format=flowed (decoded 7bit)
55ms (or 55.55555ms to be more exact) is about 18 pulses per second.
Bill & Pookie wrote:
> Not sure where you get the 55ms from, but 55ms/18hz is the timer
> interrupt frequency of the PC (personal computer) and should not have
> any effect on pic except for maybe reading or writing to the pic from
> the PC. It is a PC thing.
>
> Bill
>
> {Original Message removed}
R. I. Nelson <.....rindesignsKILLspam.....charter.net> wrote:
> Bill & Pookie wrote:
> > R. I. Nelson <EraseMErindesignsspam_OUTTakeThisOuTcharter.net> wrote:
> > > Using a basic compiled program using a for-next loop, a flash PICchip.
> > > can I expect to get a pulse every 55 ms. or about 18pulses per second?
> >
> > Not sure where you get the 55ms from, but 55ms/18hz is the timer
> > interrupt frequency of the PC (personal computer) and should not have
> > any effect on pic except for maybe reading or writing to the pic from
> > the PC. It is a PC thing.
>
> 55ms (or 55.55555ms to be more exact) is about 18 pulses per second.
Actually, if you're trying to emulate a PC, it's 18.2065096768466
pulses/sec, or 54.9254095238095 ms period. Convenient numbers, huh? :-)
It's derived from the original PC CPU clock, which was a standard
14.31818 MHz crystal divided by three to generate 4.772727 MHz.
This was subsequently prescaled by a factor of four and then divided
by 65536 in a timer chip to generate the 18.2 Hz "tick" interrupt.
If you want 55.55555 ms, that's *exactly* 18 pulses/second.
Russell McMahon <apptechspam_OUTparadise.net.nz> wrote:
> I wrote:
> > > 55ms (or 55.55555ms to be more exact) is about 18 pulses per
> > > second.
>
> > ... 4.772727 MHz.
>
> which was chosen because that's the NTSc color burst frequency and the
> crystals are cheap.
Nope. The NTSC color-burst frequency is 3.579545 MHz, which is
14.31818 MHz divided by four, not three.
The PC used the 14.3 MHz crystal partly because it was cheaply available
as a result of its wide use in the TV industry, and partly because the
early video cards wanted to be compatible with TV monitors. The early
8088s could run at up to 5 MHz, and they figured 4.77 MHz was "close
enough" without requiring a separate oscillator.
> > If you want 55.55555 ms, that's *exactly* 18 pulses/second.
>
> In engineering at least, 'about' includes 'exactly' :-)
Yes, but I was emphasizing the point that this rate is not the PC's rate
of 18.2 Hz. I wasn't sure if that's what the OP was looking for or if he
cared about the difference.
>
>
>
> On 11/30/05, Russell McMahon <KILLspamapptechKILLspamparadise.net.nz> wrote:
> >
> > >> 55ms (or 55.55555ms to be more exact) is about 18 pulses per
> > >> second.
> >
> > > ... 4.772727 MHz.
> >
> > which was chosen because that's the NTSc color burst frequency and the
> > crystals are cheap.
>
>
> I thought that was PAL.
>
> James
>
>
>
On 11/30/05, Russell McMahon <RemoveMEapptechTakeThisOuTparadise.net.nz> wrote:
>
> >> 55ms (or 55.55555ms to be more exact) is about 18 pulses per
> >> second.
>
> > ... 4.772727 MHz.
>
> which was chosen because that's the NTSc color burst frequency and the
> crystals are cheap.
charter.net
