Searching \ for '[PIC]: ISO 9141, UARTS, and Maximum baud rate' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'ISO 9141, UARTS, and Maximum baud rate'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: ISO 9141, UARTS, and Maximum baud rate'
2002\07\23@104512 by Michael A. Powers

picon face
Hi,

I've been thinking about interfacing a PIC to my car's ISO 9141 bus.  ISO 9141 functions very similar to a three line RS-232 serial port, at about 10400 baud.  Is there a PIC with an onboard UART that can handle that data rate?  I've read in other places that the maximum rate is about 1200 baud, (when the clock is at 4MHz) which seems outrageously slow to me.  If I can't use an onboard UART, I guess I'll try to use a 16550 external UART to get an appropriate data rate.


BTW, are there any PICs with 2 onboard UARTS, for RS-232?  I didn't find any on Microchip's web.

Thanks,
-Mike

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\07\23@110812 by Alan B. Pearce

face picon face
>I've been thinking about interfacing a PIC to my car's ISO 9141 bus.

Are you sure it is not a CAN BUS?

>ISO 9141 functions very similar to a three line RS-232 serial port,
>at about 10400 baud.  Is there a PIC with an onboard UART that can
>handle that data rate?  I've read in other places that the maximum
>rate is about 1200 baud, (when the clock is at 4MHz) which seems
>outrageously slow to me.  If I can't use an onboard UART, I guess
>I'll try to use a 16550 external UART to get an appropriate data
>rate.

Well I am using a 16F876 at 19.2k with a 3.6864MHz crystal, and using Fr
MacGhee's routines as interrupt driven send and receive routines it works
perfectly.

>BTW, are there any PICs with 2 onboard UARTS, for RS-232?
>I didn't find any on Microchip's web.

I believe some of the 17 and/or 18 series have 2 uarts.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\07\23@111414 by Bob Blick

face picon face
Hi Mike,

I used the onboard uart for the PC side and bit-banged the car side.
Remember it is a shared bidirectional bus, not RS-232, with unusual
start/stop characteristics that would make the uart impractical
anyway.

Cheers,

Bob

On 23 Jul 2002 at 10:44, Michael A. Powers wrote:

> Hi,
>
> I've been thinking about interfacing a PIC to my car's ISO 9141 bus.  ISO 9141 functions very similar to a three line RS-232 serial port, at about 10400 baud.  Is there a PIC with an onboard UART that can handle that data rate?  I've read in other places that the maximum rate is about 1200
baud, (when the clock is at 4MHz) which seems outrageously slow to me.  If I can't use an onboard UART, I guess I'll try to use a 16550 external UART to get an appropriate data rate.
{Quote hidden}

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\07\23@111620 by M. Adam Davis

flavicon
face
IIRC, the onboard UART of any PIC can handle a baud rate up to Fosc/16.

If you felt so inclined, a 16MHz PIC will support a 1Mbps serial
conversation.

10.4kbps is /easily/ achievable, and is not difficult to bit-bang with a
chip that doesn't have a UART.

There are several PICs which have dual UARTS.  The product line card is
the ideal place to look:
www.microchip.com/download/lit/rlit/148g3.pdf
It'll show program memory, ram, A/D, UART, CAN, timers and many other
useful metrics for choosing a PIC.

Although my brief look only shows some 18x parts with dual uarts.  I'm
pretty sure some of the 17 parts have dual uarts...

-Adam

Michael A. Powers wrote:

{Quote hidden}

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\07\28@032251 by Rob Hamerling

flavicon
face
Alan B. Pearce wrote:
 >
 > Well I am using a 16F876 at 19.2k with a 3.6864MHz crystal, and using
 > Fr MacGhee's routines as interrupt driven send and receive routines
 > it works perfectly.

Hi Alan,

Where did you obtain these MacGhee routines? I located 2 URLs but got
stuck (missing page or authorisation).
The only other interrupt driven RS232 routines I found were those of
Tony Kubek (for 16F876).
As 'study' object I have written some interrupt driven RS232 routines in
C for 16F873, including CTS flow control. These seem to work OK, but
still I want to compare these with similar code in C (or ASM) to check
mine for completeness and possibly missing checks/features.

Regards, Rob

--
Rob Hamerling, Vianen, NL phone +31-347-322822
homepage: http://www.robh.nl/

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\07\28@133532 by M. Adam Davis

flavicon
face
Try here:
http://www.ubasics.com/mcgahee/

Although the server has been under maintenance for a few hours every so
often for the last few days (PHP and apache vulnerabilities being
fixed), but it shows up fine for me now.

-Adam

Rob Hamerling wrote:

{Quote hidden}

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\07\29@041524 by Alan B. Pearce

face picon face
Hi Rob, I did not pick up it was you here as well. Those on the MML, B&G and
IBX do tend to get around :)

I will forward the ZIP to you.

I don't know if you have caught up with Olin Lathrop's PIC development
environment and macro's, but I have a version of Fr. MacGhees routines
modified to run under this environment and macros as well.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spam_OUTlistservTakeThisOuTspammitvma.mit.edu with SET PICList DIGEST in the body


2002\07\29@163009 by Rob Hamerling

flavicon
face
Hi Alan,

Alan B. Pearce wrote:
> Hi Rob, I did not pick up it was you here as well. Those on the MML, B&G and
> IBX do tend to get around :)

The world (of lunatics?) is small.

> I will forward the ZIP to you.

Thanks, I received it!
The URLs I found with a Google search gave me trouble, but the URL Mark
Davis listed here (thank you Mark!) was OK.

> I don't know if you have caught up with Olin Lathrop's PIC development
> environment and macro's, but I have a version of Fr. MacGhees routines
> modified to run under this environment and macros as well.

Never heard of it, so I don't know what I'm missing.

I read MacGhee's source. It countains many valuable notes, but the code
example itself isn't very valuable to me. (1) It is written in ASM, I
prefer C for productivity, (2) doesn't use RS232 interrupts, (3) has no
CTS/RTS flow control, (4) doesnt use (circular) buffers, (5) and I have
some other experiences, for example I don't seem to need the dummy
character at start of communications.
I'll test my software a little more and publish it later (maybe here).
FYI I'm using LocoBuffer and LocoIO with 16F873 as hardware for my
learning excercises...

Regards, Rob.

--
Rob Hamerling, Vianen, NL phone +31-347-322822
homepage: http://www.robh.nl/

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservKILLspamspam@spam@mitvma.mit.edu with SET PICList DIGEST in the body


2002\07\30@042342 by Alan B. Pearce

face picon face
>> I don't know if you have caught up with Olin Lathrop's PIC development
>> environment and macro's, but I have a version of Fr. MacGhees routines
>> modified to run under this environment and macros as well.

>Never heard of it, so I don't know what I'm missing.



>Well if no-one else has already referred you to it, get the PIC development
>files from Olin Lathrop's web pages at http://www.embedinc.com/pic/ Check
>out the example project towards the bottom of this page as well for a good
>example of how to use these files. The macros contained in this package can
>make the hassles of dealing with the page and bank switching reduce to a
>minimum level. They do not stop you doing silly things however :0

Above is a quote from my reply to a previous question where I referred
someone to it. It is really for assembler people, and will not matter much
to you if doing things in C. However he does also have a handy utility for
converting *.wav files to assembler source for making sound using the PWM
output of the CCP.

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspamKILLspammitvma.mit.edu


2002\07\30@043709 by Alan B. Pearce

face picon face
Sorry, meant to incluse this with my previous post on this.

>I read MacGhee's source. It countains many valuable notes, but the code
>example itself isn't very valuable to me. (1) It is written in ASM, I
>prefer C for productivity, (2) doesn't use RS232 interrupts, (3) has no
>CTS/RTS flow control, (4) doesnt use (circular) buffers, (5) and I have
>some other experiences, for example I don't seem to need the dummy
>character at start of communications.
>I'll test my software a little more and publish it later (maybe here).
>FYI I'm using LocoBuffer and LocoIO with 16F873 as hardware for my
>learning excercises...

(1) Fair enough, but the code outline should be easily converted.

(2) Converting the code to use interrupts is not a big deal. I found it easy
enough to do.

(3) Again, should not be a big problem to do, I do not know which pins the
Locobuffer uses for RTS/CTS, but writing suitable code should not be a big
deal.

(4) Using Olin's macros I implemented separate tx and rx buffers using his
FIFO macros. These work great for me, but would need a bit more work to
handle handshaking. This would involve writing at least one more macro to
return the actual percent full of the FIFO, rather than just using the
"full" and "not full" macros. The biggest problem I see with this is dealing
with the FIFO in the PC uart which gets unloaded before the handshake comes
into force.

(5) The dummy character to TX at the beginning is a necessity to get the TX
buffer flag to work correctly. This is because the hardware just does not
initialise properly from a reset as the uart mode is setup. It does not go
true to say it wants another character until the first one has been sent.
The comments in the code make this pretty clear as a "gotcha". In my version
of the code I modified this to send CR/LF as it suited me more than a null
character.

happy programming.

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestKILLspamspam.....mitvma.mit.edu


2002\07\30@055820 by David Duffy

flavicon
face
Alan wrote:
>Sorry, meant to incluse this with my previous post on this.
><snip>
>(5) The dummy character to TX at the beginning is a necessity to get the TX
>buffer flag to work correctly. This is because the hardware just does not
>initialise properly from a reset as the uart mode is setup. It does not go
>true to say it wants another character until the first one has been sent.
>The comments in the code make this pretty clear as a "gotcha". In my version
>of the code I modified this to send CR/LF as it suited me more than a null
>character.

I haven't followed this thread but I always send the first byte manually, then
enable the transmitter interrupt to send the rest of the packet in the
interrupt
routine as each byte is done. I then disable the transmitter interrupt when I
know I'm sending the last byte in that packet. That has always worked for me.
Regards...

--
http://www.piclist.com hint: To leave the PICList
EraseMEpiclist-unsubscribe-requestspam_OUTspamTakeThisOuTmitvma.mit.edu



'[PIC]: ISO 9141, UARTS, and Maximum baud rate'
2002\08\01@033529 by Rob Hamerling
flavicon
face
Hello David,

David Duffy wrote:
>
> I haven't followed this thread but I always send the first byte
> manually, then enable the transmitter interrupt to send the rest
> of the packet in the interrupt routine as each byte is done.
> I then disable the transmitter interrupt when I know I'm sending
> the last byte in that packet. That has always worked for me.

Seems pretty similar to my solution!
Being rather new to PICs (me!) it costed me some time to find out about
having to enable/disable TX interrupts with each packet. At least it is
quite different from similar software I wrote for the PC....
The only interrupt driven RS232 PIC software I could find was Tony
Kubeks example in ASM, but this doesn't have all the features I want.
Do you (or anybody else) know about a published example?

Regards, Rob.

--
Rob Hamerling, Vianen, NL phone +31-347-322822
homepage: http://www.robh.nl/

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\08\02@083503 by o-8859-1?Q?Tony_K=FCbek?=

flavicon
face
Hi,

Rob Hamerling wrote:
<snip>
>The only interrupt driven RS232 PIC software I could find was Tony
>Kubeks example in ASM, but this doesn't have all the features I want.
>Do you (or anybody else) know about a published example?
>
>Regards, Rob.

Well, that wasn't complete :) anyway I have an old version
as a relocatable module that contains:
-isr based
-circular buffers
-option for 7bit even parity -add w as two ascii bytes ( send hex )
-etc..

I'll post it if anyone is interested ?

/Tony

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\08\02@091611 by Olin Lathrop

face picon face
>The only interrupt driven RS232 PIC software I could find was Tony
>Kubeks example in ASM, but this doesn't have all the features I want.
>Do you (or anybody else) know about a published example?

I don't know what features you are looking for, but perhaps my
QQQ_UART.ASPIC module does what you want.  It uses fully interrupt driven
I/O with separate input and output FIFOs.  There are global status bits
indicating whether the output FIFO has room for another byte and whether the
input FIFO has a byte available.  There interface to the rest of the
software is via the two status bits and the UART_PUT and UART_GET
subroutines.

Note that you can't just grab the UART module in isolation.  There are hooks
to it from the interrupt module, the initialization module, and the global
status bit definitions in the include file.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\08\02@131810 by Welch, Ken

flavicon
face
i'm interested...

Ken

Rob Hamerling wrote:
<snip>
>The only interrupt driven RS232 PIC software I could find was Tony
>Kubeks example in ASM, but this doesn't have all the features I want.
>Do you (or anybody else) know about a published example?
>
>Regards, Rob.

Well, that wasn't complete :) anyway I have an old version
as a relocatable module that contains:
-isr based
-circular buffers
-option for 7bit even parity
-add w as two ascii bytes ( send hex )
-etc..

I'll post it if anyone is interested ?

/Tony

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\08\02@140908 by Rob Hamerling

flavicon
face
[I wrote]
>>The only interrupt driven RS232 PIC software I could find was Tony
>>Kubeks example in ASM, but this doesn't have all the features I want.
>>Do you (or anybody else) know about a published example?

[Tony Kubek replied]
> Well, that wasn't complete :) anyway I have an old version
> as a relocatable module that contains:
> -isr based
> -circular buffers
> -option for 7bit even parity
> -add w as two ascii bytes ( send hex )
> -etc..
>
> I'll post it if anyone is interested ?

In the meantime I think have my own routines (in C) running. But maybe
I'm overlooking something. Reading in other similar programs could be
very educational. So yes please.
I assumed the receive part would be the hardest, but actually the
transmit part, esp. handling of TXIF/TXIE, took most of my time.

[Olin Lathrop replied]
> I don't know what features you are looking for, but perhaps my
> QQQ_UART.ASPIC module does what you want.  It uses fully interrupt
> driven I/O with separate input and output FIFOs.  There are global
> status bits indicating whether the output FIFO has room for another
> byte and whether the input FIFO has a byte available.

You mentioned about all the features I want to support, and have in
place in the meantime! In general: I want to support high speed, high
volume traffic between a PIC-based device and a PC, and be able to use
the hardware FiFo buffering of the COM-port of the PC (16 bytes load count).
Although it looks like my program is functionally OK now I still want
to compare if with some 'production' code before I publish it
(assuming someone is interested!)

Thanks so far.

Regards, Rob.


--
Rob Hamerling, Vianen, NL phone +31-347-322822
homepage: http://www.robh.nl/

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


More... (looser matching)
- Last day of these posts
- In 2002 , 2003 only
- Today
- New search...