The idea of using a 3.3v pic is good, because the gps module gets 3.0v in
its vcc. This way I wouldn't need to do any voltage conversion as I'm doing
now. The thing is that I'm trying to test some concepts using the
development board, that's why I'm having this problem.
Another idea a colleague of mine had was to use to 5v NOT gates (I don't
know if this is the correct nomenclature). When gps sends 0v, then it is
converted to 5v and again to 0v, but when gps sends 2.5v, NOT gate inverts
to 0v then subsequently to 5v. Would it work in this case? Of course the
production board would either have the 3.3v pic of a proper level shifter.
Regarding the soft USART (bit-bang), I saw the help file of my pascal
compiler (mikropascal) and they have libraries to both hardware USART and
software USART. The later has the advantage of allowing you to choose which
port and which pin will be used for Rx/Tx.
Cheers,
Padu
----- Original Message -----
From: "Peter Moreton"
> Padu,
>
> You can bit-bang the second serial port using routines freely available on
> the web. (Alternatively, select a PIC with two USART modules!) You will
need
> to level shift the PIC pins to 1.8v for your GPS - are you sure the
> interface is 1.8?, if it is say 3.3v logic then you can use a PIC 'LF'
part
> that will run at 3.3v, and do away with level translation.
>
> Peter Moreton
>
>
> > {Original Message removed}
Most CMOS logic works reasonably well at 3.3V, although
not at full rated speed. Have you tried dropping the supply
voltage to your development board to see if it works
at 3V? As long as the crystal isn't up at 20Mhz, it
should run fine and you can test your GPS at nominal
voltage. You may have a problem with the low voltage
reset device (BOD or external part) holding the PIC
in reset. A quick slice through the trace disables
the LVD if it's external. If internal (BOD), you'd need to
reprogram the config reg and add a LVD one of your own.
MN13811-G (2.5V) is nice. TO92 or SMT with minimal
supply current and choosable trigger point.
If 20 Mhz, you may have to change the speed, by powers
of two so that you can choose lower baud rates and still
be able to communicate with the board.
I would suggest bit banging the GPS channel since NMEA
standard is 4800 baud, and most GPS's default to this speed,
and with once per second updates you'll have lots of time
to process the bits, leaving the UART free for high speed
comms with the PC.
> The idea of using a 3.3v pic is good, because the gps module gets 3.0v in
> its vcc. This way I wouldn't need to do any voltage conversion as I'm doing
> now. The thing is that I'm trying to test some concepts using the
> development board, that's why I'm having this problem.
> Another idea a colleague of mine had was to use to 5v NOT gates (I don't
> know if this is the correct nomenclature). When gps sends 0v, then it is
> converted to 5v and again to 0v, but when gps sends 2.5v, NOT gate inverts
> to 0v then subsequently to 5v. Would it work in this case? Of course the
> production board would either have the 3.3v pic of a proper level shifter.
>
> Regarding the soft USART (bit-bang), I saw the help file of my pascal
> compiler (mikropascal) and they have libraries to both hardware USART and
> software USART. The later has the advantage of allowing you to choose which
> port and which pin will be used for Rx/Tx.
>
> Cheers,
> Padu
>
> ----- Original Message -----
> From: "Peter Moreton"
>
>>Padu,
>>
>>You can bit-bang the second serial port using routines freely available on
>>the web. (Alternatively, select a PIC with two USART modules!) You will
>
> need
>
>>to level shift the PIC pins to 1.8v for your GPS - are you sure the
>>interface is 1.8?, if it is say 3.3v logic then you can use a PIC 'LF'
>
> part
>
>>that will run at 3.3v, and do away with level translation.
>>
>>Peter Moreton
>>
>>
>>
----- Original Message -----
From: "Robert Rolf"
<snip>
> I would suggest bit banging the GPS channel since NMEA
> standard is 4800 baud, and most GPS's default to this speed,
> and with once per second updates you'll have lots of time
> to process the bits, leaving the UART free for high speed
> comms with the PC.
>
> Robert
Here's where I suspect I'm going to have some problems in the future (but
before I believe I will have lot's of other things to worry about :-(
My application requires more than 1 fix per second, therefore I cannot use
NMEA. The chipset I'm using supports higher update rates since you use their
proprietary format (which is much better than NMEA - simpler and more
compact). For that they allow very high baud rates. In a perfect world, I
want to get messages from my gps unit at very fast speeds (more than 9600
baud), save them to a CF and output them to the PC via RS232, everything at
the same time... will my little pic be able to handle all of that?
> Here's where I suspect I'm going to have some problems in the future (but
> before I believe I will have lot's of other things to worry about :-(
> My application requires more than 1 fix per second, therefore I cannot use
> NMEA. The chipset I'm using supports higher update rates since you use
> their proprietary format (which is much better than NMEA - simpler and more
> compact). For that they allow very high baud rates. In a perfect world, I
> want to get messages from my gps unit at very fast speeds (more than 9600
> baud), save them to a CF and output them to the PC via RS232, everything at
> the same time... will my little pic be able to handle all of that?
You might want to consider the Ubicom SX chip for this application.
The SX is a 12-bit PIC clone that runs one instruction per clock at
speeds 50 Mhz. The design philosophy is to use raw speed to implement
things like UARTs in software rather than hardware. You can therefore
run as manu software UARTs as you have hardware pins for. You can run
a few UARTs very quickly, or a lot of UARTs at slower speeds.
Thinking of multiplexing the UART. Connecting the Tx and Rx pins of the
pic's UART to a input pin and a output pin on the same pic. With this you
can read the state of the UART's Tx output and the other pic output pin can
work the UART's Rx input. All under program control.
Now use two more pairs of the same pic's pins as input and output hooked to
the proper receiver/transmit drivers for the units you are interfacing.
Software must set a flag for which device communicates is to take place.
Then often, but not at a precise time, read the input pic pin for the
selected device and set the UART's Rx pin accordingly. Same for transmit
except read the pic pin connected to the UART's Tx pin and set the proper
device's output pin accordingly. Let the UART do all the time critical bit
banging.
And it will be possible to be sending to one device while receiving from the
other if baud rates are the same. Then ( if needed) with two more pic pins,
you can have a third device.
hummm.....
For fast baud rates and many devices, use a dedicated pic as a ABC....Z
switch. With the Rx,Tx and some select lines from the main pic going to the
multiplexer pic. Or two pics with one select line being a enable/enable_not
input for the pics?
Some place in this perverted mess you might even be able to broadcast to all
devices at the same time.
Bill & Pookie wrote:
> Thinking of multiplexing the UART. Connecting the Tx and Rx pins of
> the pic's UART to a input pin and a output pin on the same pic. With
> this you can read the state of the UART's Tx output and the other pic
> output pin can work the UART's Rx input. All under program control.
>
> Now use two more pairs of the same pic's pins as input and output
> hooked to the proper receiver/transmit drivers for the units you are
> interfacing. Software must set a flag for which device communicates is
> to take place. Then often, but not at a precise time, read the input
> pic pin for the selected device and set the UART's Rx pin accordingly.
> Same for transmit except read the pic pin connected to the UART's Tx
> pin and set the proper device's output pin accordingly. Let the UART
> do all the time critical bit banging.
Or if this is a low volume or hobby product, just use a 18F6520 with dual
UARTs and be done with it. Microchip is coming out with a 40 pin PIC with
dual UARTs, but I don't think it's available yet.
On Thu, 2004-10-21 at 08:23, Olin Lathrop wrote:
> Or if this is a low volume or hobby product, just use a 18F6520 with dual
> UARTs and be done with it. Microchip is coming out with a 40 pin PIC with
> dual UARTs, but I don't think it's available yet.
Another option of course is the dsPIC line, the 30F3011, 30F3013,
30F3014, 30F4011, and 30F4013 all have dual UARTs. Not sure on
availability of them all, but some are available as samples. TTYL
