Post by thread:[PIC]: ISO 9141, UARTS, and Maximum baud rate

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.

>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.

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}> > > 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. > > -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

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}>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. > > > > > > > -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

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.

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}> 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. > > > > > -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

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_OUTlistservTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

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 .....listservKILLspam@spam@mitvma.mit.edu with SET PICList DIGEST in the body

>> 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-requestKILLspammitvma.mit.edu

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-requestKILLspam.....mitvma.mit.edu

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_OUTTakeThisOuTmitvma.mit.edu

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

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.

>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.

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.

[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.