Jump to content
eckertc

Pic16f628a Serial Usart

Recommended Posts

Hey all,

 

First let me just say sorry for the size of this post. its going to be a bit of a long winded one but I'm not sure how to get my full question accross without explaining it fully. With that said.... Here goes nothing....

 

I am moving on to working with Serial communications on the PIC16F628A now and i'm working with kind of a goofy protocol.

 

///////////////////////////////////////////////////////

// Desired setup result for PIC16F628A:

// ////////////////////////////////////////////////////

 

What i would like to see is the following:

 

 

// Baud Rate: 9600 NRZ

// Serial Bit Format:

// 1 Start Bit

// 8 Data Bits

// 1 Mode Bit(used as address bit)

// 1 Stop Bit

// -------------

// 11 Bits Total

//

// Details: This device will need to be set up like

// a slave device, answering only when

// addressed. a typical transmission from

// the master device will look like the

// the following:

// (address(mode) byte, data bytes, and a

// checksum byte.)

//

// If a byte is recieved with the "Mode"

// bit set to 1, proccess it as an address

// bit and react or dont react depending

// on if the sender was addressing you.

// If the sender WAS addressing you, and

// following bytes are recieved with the

// "Mode" bit set to 0, proccess it as a

// data bit and respond with appropriate

// responce.

//////////////////////////////////////////////////////////

My take on how to accomplish this is in as follows. Please let me know if you think this is being handled properly or if you have any advice on this type of setup.

 

//////////////////////////////////////////////////////////

// Pin8-(RB2): set RB2 as TX(out) line with a baud

// rate of 9600 at clock speed of 4Mhz.

// Enable 9bit transfer mode.

// Set USART for Synchronous Mode.

// Set Baud rate to High-Speed.

// Set Transmit Shift Register Status

// bit to 1 = TSR empty

// Set TX9D bit = 0

//

////////////////// - In other words - /////////////////

// TXSTA(0x98h) = 11110110 = 0xF6h

/////////////////////////////////////////////////////////

// Pin7-(RB1): set RB1 as RX(in) line with a baud

// rate of 9600 at clock speed of 4Mhz.

// Enable the serial port

// Set for 9bit reception.

// Single recieve enable.(doesnt matter)

// Enable continuous receive

// Enable Address Detect bit

// Disable Framing Error bit

// Disable Overrun Error bit

// Set TX9D bit = 1

////////////////// - In other words - /////////////////

// RCSTA(0x18h) = 11111001 = 0xF9h

/////////////////////////////////////////////////////////

 

I have read the Datasheet for the PIC16F628A all the way through multiple times (an exahsting 169 pages) and the above setup seems the closest to what I need to accomplish but being a complete beginner with PIC programming in general it is simply my best guess at this point. Any advice you could offer would be very helpfull.

Share this post


Link to post
Share on other sites

In addition to the above questions. i have another question reguarding the Rs232 driver provided with the samples.

 

could someone please explain in a bit of detail about what each of these are and what the values represent?

 

// PIC16F87x defaults for hardware USART support

//#define TX_PORT 0x07

//#define TX_TRIS 0x87

//#define TX_BIT 6

//#define RX_PORT 0x07

//#define RX_TRIS 0x87

//#define RX_BIT 7

//#define e_SPBRG 0x99

//#define e_RCREG 0x1a

//#define e_TXREG 0x019

//#define e_TXSTA 0x98

//#define e_RCSTA 0x18

//#define e_TXIF_PIR 0x0c

//#define e_RCIF_PIR 0x0c

//#define e_TXIF_BIT 4

//#define e_RCIF_BIT 5

//#define MODE (USART_reset_wdt | USART_HW)

Share this post


Link to post
Share on other sites

>> could someone please explain in a bit of detail about what each of these are and what the values represent?

The detail is in the datasheet so I'll refer you to specific pages of it (I'm going to go on the PIC16F876 cause I've used that with RS232, datasheet), and have the PIC16F876.h header file in Source Boost's include directory open.

 

//#define TX_PORT 0x07

//#define RX_PORT 0x07

TX: This is the port out of which serial data will be transmitted. Look in the header file for PORTC. It's #defined as 0x07. If you wanted the output to be on a different port you can set it here by choosing either the hex value for PORTA, or PORTB, or PORTC.

RX: Same idea as TX_PORT. However, it looks like you can have TX and RX on different banks, which is kind of neat.

 

//#define TX_TRIS 0x87

//#define RX_TRIS 0x87

Sets the tristate value of the transmit and receive tris, i.e. setting IO configuration. The same because they're on the same port bank.

 

//#define TX_BIT 6

//#define RX_BIT 7

The bits of the the port (input and input port), which will be used for transmitting and reveiving data. i.e. RC6 is for TX-ing, and RC7 is for RXing.

 

The rest of these values you asked about are register addresses within the PIC itself. I'll point you to page numbers from the datasheet where you can find their hex values, but I'm not to explain their use. You can read that in the second page I post for each of the registers. When searching in a datasheet for these registers neglect to search for the "e_" part. Just what follows them.

 

//#define e_SPBRG 0x99

Page 15 (for register values), and 97 (for explanations). "SPBRG 99h", comes from the datasheet. (99h means 99 in hex, hence 0x99)

 

//#define e_RCREG 0x1a

Page 15, and 101

 

//#define e_TXREG 0x019

Page 15, and 99

 

//#define e_TXSTA 0x98

Page 15, and 95

 

//#define e_RCSTA 0x18

Page 15, and 96

 

 

The next two groups are pretty similar.

//#define e_TXIF_PIR 0x0c

//#define e_RCIF_PIR 0x0c

The TXIF_PIR and RCIF_PIR are slightly different to find than the previous registers. The PIR register is called PIR1 in the datasheet (not sure why the discrepancy), and can be seen on page 15 (and 22 for explanations), again it can be read off as 0Ch.

 

//#define e_TXIF_BIT 4

//#define e_RCIF_BIT 5

Following on from PIR1, go to page 17 and in the register summary you can find PIR1 again. There are eight bits in this register and you can see that bits four and five are called: TXIF and RCIF respectively. That's where the above comes from.

 

 

//#define MODE (USART_reset_wdt | USART_HW)

This is the configuration.

The reset_wdt, I guess, means that the watch dog timer is reset after every transmit or receive stage.

The USART_HW means that it's a hardware implementation of the communications protocol, which I think means that you (the code in rs232_driver.h), fill registers within the PIC with data which the PIC will automatically transmit in its own time. I believe (but am not certain), that with the HW implementation you must set the baud-rate when calling the uart_init() function. Tables for the first and second parameters (see page 100), are given and you can just read off the value of parameter one (BRGH), and parameter two (SPBRG) for a given baud rate and a given oscillation frequency.

Alternatively you can use software implementation. This, I believe, relies you you #defining a variable called bit_time. See the header file for details on how to define it. Also, it appears that you can debug with the software implementation but not with the hardware implementation, which kind of makes sense.

 

I do not know the benefits of using the hardware implementation over the software implementation. Hopefully someone else can point out why.

 

Hope this helped.

Edited by twomers

Share this post


Link to post
Share on other sites

The rs232 driver rs232_driver.h (actually serial interface driver) supports either the use of an embedded hardware USART in the PIC if it has one or the software emulation of a USART. You would use software emulation if either the PIC does not have an embedded USART or if, for some reason you cannot use the embedded UART possibly because you have used the PICs supported by the hardware USART for some unrelated function.

 

Using the hardware USART is far far far better than the software emulated USART. The e_ designation on the driver variables signifies an emulated register with the same characteristics as the corresponding physical register for a hardware USART. The software USART, which can be used on any family of PIC, was modeled on the hardware USART used in the PIC18F452 microcontroller family.

 

If you are using a software USART, you need to tell the driver which port and which port bit is to be used for the transmit and receive pins. The following #defines tell the driver the port used for tx and rx, the TRIS setting to set the i/o direction for the specific bit and the specific port bit used for tx and rx on the associated port.

 

#define TX_PORT 0x07

#define RX_PORT 0x07

#define TX_TRIS 0x87

#define RX_TRIS 0x87

#define TX_BIT 6

#define RX_BIT 7

 

If you wanted to, you can examine the contents of the emulated ports just as if they were real hardware ports. You can place the emulated registers anywhere in memory.

 

The option USART_reset_wdt tells the driver that the wdt is to be reset within the serial handler. If you did not do this and where the application is looping waiting for a byte to be received, the WDT, if enabled, could cause the PIC to reset.

Share this post


Link to post
Share on other sites

Join the conversation

You are posting as a guest. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...