>
>So if I am understanding correctly from what you said, I should be using the
>serial_software.jal library, is that correct?
>
>Not really. While serial_software allows a wider variety of baud rates, it
>comes at the cost of 100% processor load. While waiting for input from the
>laptop, the PIC will not be able to set any motor or read any sensor. So, for
>"live" interaction, serial_software is not an option.
My solutions would be, most preferred first:
1. Use another PIC with internal oscillator. Microchip recommends the 16F887 as
a replacement, which has a 8MHz oscillator built in.Recent PICs like 18F43K22
can run at 64MHz from the internal oscillator, and are cheaper than the 16F877.
2. Change the Crystal. 4MHz, 8MHz, 12MHz, 16MHz, 20MHz should all be fine.
3. Reduce the baud rate. 57600 should be fine with a 10MHz crystal.
4. Try if setting the PIC to 125000 baud works. The serial_hardware lib is a
bit strict on bit rate accuracy to keep reliability running on a +/-2% internal
oscillator. Using a +/-0.00001% crystal, you can deliberately "mistune" the
baud rate a percent or two, keeping the lib happy while still keeping pace with
the transmission.
5. It may be possible to use the serial_software approach, but it is much more
difficult and error-prone. The PIC must poll data from the laptop, the latop
can't send any data when not asked to do so.
6. Write an interrupt-controlled serial_software lib which is able to receive
without announcement. Quite a bit of work. Can be reliable if no other
interrupts are used.
Greets,
Kiste
--
You received this message because you are subscribed to the Google Groups
"jallib" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/jallib.
For more options, visit https://groups.google.com/groups/opt_out.
