Hi Wolf !
The PIC16F1783 has an internal 4x PLL, which could be used in
conjunction with a typical 7.3728 MHz (external) crystal to gain
29.491200 MHz Fosc for your PIC. This is just 16 times the baudrate of
460800 Baud !
The RS232 level converters aren't a good choice for those high
frequencies, as Andy pointed out : An RS422 / RS 485 level IC would be
much better and work across considerable distance without problems. (Or
simply use the TTL-level outputs without any level shifters = bypass the
existing level shifters on the PCB).
The computing power of this 8 Bit PICs is limited (even at 32MHz), so it
cannot not do too much of computing beyond the serial communication task.
A simple protocol could e.g. use the highest or lowest Bit of each byte
to synchronize a 3-or more-Byte frame. At a high-high-low scheme of
these bits it's easy to get the payload decoded in correct sequence.
The A/D converter may run on higher samplerates than "recommended", as
we are digitizing "audio" and not DC. The FFT will show how high you can
go before the degradation starts. The datasheets mostly are conservative
on their data to avoid legal action... For a non-commercial project like
this we can push the limits considerably higher.
73 de dg3lv Tobias
Am 17.02.2016 um 21:58 schrieb Wolfgang Büscher:
Ok then - so the FTDI-chip based interfaces are the ones to use.
In the meantime I got the serial port adapter working at 460800 bits per
second (where the communication with the PIC16F1783 looks good) but not
at 500000 bits/sec (where the PIC could realize the bitrate without any
error). The rise- and fall time of the RS232 level converters seem to be
different, so when sending a loop of 0x55 bytes the '0101010' pattern
doesn't look like a square wave with 50 % duty cycle at all.
But anyway, for narrow band applications it's ok, and even the dsPICs I
have here at the moment (with 12 bits/sample from the ADC) are specified
for 200 kS/sec at the maximum (the PIC16F1783 was announced for 100 ksps
but the recent datasheet says its only 75 ksps). I will try to run it at
80 ksps and decimate down to 20 ks/sec for the output, with some of gain
from a CIC filter for effectively 16 bits per sample. 20 kHz * 2 bytes *
( 1 + 8 + 1 ) bits = 400 kBit/second (raw, including start + stop bit) -
that's close to what the 'Prolific' adapter can handle.
Brings up a crazy idea: Since there is not enough bandwidth for a 3rd
byte (for a sample frame), the receiver could examine the amount of
'noise' in the bits of each byte, to tell the high-byte from the
low-byte just in case an unknown number of bytes get lost on the way...
the least significant byte will have more toggling bits than the most
significant byte.
Well, it's good fun to push the 'midrange PIC' to its limits (haven't
been doing this for a long time, being more used to ARM controllers
these days). The PIC16F1783 has 4096 program steps, 256 bytes of RAM,
and (Andy will know what I'm talking about) it now has TWO 'address
pointers', FSR0 and FSR1 instead of only one, and an add-with-carry
instruction which the older PIC16's didn't have... makes efficient
programming in assembler a bit easier, even though the CIC filter (with
N=4, R=4, N=2) consume almost CPU time when running at 80 kHz sampling
rate. Oh well, there still is the option to use a dsPIC instead.
All the best,
Wolf .
Am 17.02.2016 um 16:23 schrieb Andy Talbot [email protected]
[rsgb_lf_group]:
I've just made some tests on the FTDI232 chip at high baud rates.
Using a custom routine written in PowerBasic (CC) , I used that
language's own interpretation and interface to the driver to pass
arbitrary baud rates to the chip. With the device set for 8 data, 1
stop bit and no parity, I repeatedly send the character 0x55 in a
continuous loop. This pattern of bits, if sent contiguously
(characters are sent LSB first) should therefore result in a square
wave being generated at a frequency exactly equal to half the
specified baud rate.
The FTDI232 data sheet states that baud rates are determined based on
a 3MHz input to a divisor of (N + M/8, where N = 2 to 16384, plus two
special cases on N = 0 and N = 1 for 3Meg and 1Meg rates
respectively. This setting is hidden from my application, and
happens transparently based on the baud rate I specify beign passed to
the driver via PowerBasic.
The following results were obtained :
Requested Frequency
Baud rate Generated
1M 500000
2M
On 12 February 2016 at 17:59, Wolfgang Büscher
<<mailto:[email protected]>[email protected]> wrote:
Thanks Andy. I wanted to keep it simple (but not necessarily
stupid), by using available hardware. In my case, the dreadful
(and, most likely, "faked") Prolific USB <-> RS232 adapter.
__._,_.___
------------------------------------------------------------------------
Posted by: Andy Talbot <[email protected]>
------------------------------------------------------------------------
Visit Your Group
<https://uk.groups.yahoo.com/neo/groups/rsgb_lf_group/info;_ylc=X3oDMTJmN2w3cWZmBF9TAzk3NDkwNTA1BGdycElkAzg1MDgwODk1BGdycHNwSWQDMTY5MDA2MzEwOARzZWMDdnRsBHNsawN2Z2hwBHN0aW1lAzE0NTU3MjI2MjQ->
Yahoo! Groups
<https://uk.groups.yahoo.com/neo;_ylc=X3oDMTJldmU1ajBtBF9TAzk3NDkwNTAzBGdycElkAzg1MDgwODk1BGdycHNwSWQDMTY5MDA2MzEwOARzZWMDZnRyBHNsawNnZnAEc3RpbWUDMTQ1NTcyMjYyNA-->
• Privacy
<https://info.yahoo.com/privacy/uk/yahoo/groups/details.html> •
Unsubscribe
<mailto:[email protected]?subject=Unsubscribe>
• Terms of Use
<https://info.yahoo.com/legal/uk/yahoo/utos/en-gb/details.html>
__,_._,___
|
