Jump to content
 
  • 0
Sign in to follow this  
Marco

Change Baud Rate from 9600 to 19200 PIC16F1718 using MPLAB

Question

I have a program in MPLAB that works correctly when sending messages through the LIN system at a baud rate of 9600, but when I change it to 19200 it does not come out. I am using the MPLAB Code configurator V4 tool and in the window for Eusart I put the 19200 which are the Baud Rates to which I want to transfer.

 

It is expected to know the values in the eusart.c file of SP1BRGL and SP1BRGH for the Baud Rate corresponding to 19200.
Tried with SP1BRGL values of 0x40,0X65,0xFE, 0x3B, 0x3D keeping SP1BRGH at 0x00.

Also in the application in the Registers of the variables of Sp1BRGL and SP1BRGH so that they correspond to a Baud Rate of 19200.

For the calculation, the table for pic16 was used, it is expected in high transfer speed with a 16 Mhz oscillator an SPBRG of 51 but it still did not work.

I do not know what I am doing wrong, to read the data I am using a LIN analyzer tool and everything works at a Baud rate of 9600 but I take it to be 19600 for the application.

 

 

1.PNG

2.PNG

3.png

4.png

5.png

5.jpg

Share this post


Link to post
Share on other sites

0 answers to this question

Recommended Posts

There have been no answers to this question yet

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

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

Sign in to follow this  

 


  • Popular Contributors

    Nobody has received reputation this week.

  • Similar Content

    • By burkart
      Hello All,
      I am working on a project (in MPLAB v5.10) with a PIC18F27K40 (PIC18 library v1.77.0) and I'm using the MCC (v3.85.1) generated I2C drivers, I2CSIMPLE from the Foundation Services. I can read from and write successfully to devices on the I2C bus. The problem comes when I try to communicate with a device that's not on the bus, the micro goes into an endless loop waiting for i2c_status to not be busy. My knowledge of programming in C is about 6 on a scale of 10, and for programming for embedded purposes, about 5 out of 10. I would like to have it so that I can check if a specific device is present on the I2C bus, and also be able to recover from errors on the bus without it going into a loop indefinitely.

      This I2C driver is pretty complex, and I am having difficulties wrapping my head around it. How would I make it so that the driver just returns an error or something I can check for status, rather than loop endlessly until the operation completes, which it never will?

      I have not edited any of the MCC generated code. This includes leaving the IRQ enable line commented in the i2c_master.c file, so instead it polls instead of using an interrupt to check if the i2c operation has completed.
      // uncomment the IRQ enable for an interrupt driven driver. // mssp1_enableIRQ(); Following is an example of how I am calling the i2c driver.
      i2c_write1ByteRegister(address, 0x0D, 0x07); // GPPUB pull-ups on pins 0-2 I am attempting to initialize a port extender, MCP23018, specifically enabling some pull-up resistors. I would like to issue this command, and if the extender is not present, then the micro will perform some tasks differently. With the port extender present the write operation works as expected and everything is fine. Of course the problem is when the extender is NOT on the bus to acknowledge.
      I have another question as well. This driver seems to operate a little slow. When watching the bus with a logic analyzer I noticed a rather long pause between bytes. I went looking through the i2c driver and in i2c1_driver.c I found the following code which I suspect is the cause.
      inline void mssp1_waitForEvent(uint16_t *timeout) { // uint16_t to = (timeout!=NULL)?*timeout:100; // to <<= 8; if(PIR3bits.SSP1IF == 0) { while(1)// to--) { if(PIR3bits.SSP1IF) break; __delay_us(100); } } } What is the purpose of the 100 us delay in the while loop? Reducing or eliminating the delay results in reducing or removing the pause between byte transactions, but I don't know enough to know how else this edit will effect the driver. Also, what is the commented out code at the top of the function used for? Is this part of the infinite loop problem I mentioned above?

       
      --
      James Burkart
    • By Orunmila
      I am trying to use a linker script with MPLAB-X for my PIC32 project but for some reason the script is not being passed to the linker at all. I expected that all I had to do was add the .ld file to my project, typically by placing it in the "Linker Files" virtual folder in MPLAB-X in my project. I did this and the linker script is being ignored by the linker.
      This is one of those $100 questions (if you know the story of the mechanic asking $100 for knowing where to hit ...).
      So my question is how do I get MPLAB-X to use my linker script which I have added to the PIC32 project?
    • By N9WXU
      I was reviewing a Cypress data sheet for the CYW4390 and saw a line in the UART chapter saying that the total baud rate error budget for both ends had to be less than 2%.  With a large dependence upon internal oscillators these days, it seemed a good time to discuss these error budgets.  Is 2% reasonable or conservative?
      First here is a quick back of the envelope calculation for link budget for UARTS.  I will assume "perfect" rise & fall times, and 8, none, 1(8n1) framing.
      There are a total of 10 bits in a byte with 8n1 so each bit is 10% of the total byte time.  If your link budget is larger than 10%, you will miss a bit.  BUT WAIT... all UART implementations I am aware of try to sample in the center of the bit.  Generally, this is done by oversampling 16x and using the center 3 samples as a majority detect.  If you consider that slipping the byte time by 1/2 a bit time will cause a missed bit, our link budget is now 5%.  If you KNOW you are talking to a PERFECT receiver, then you can accept the entire 5% error.  (Of course, you can assume your design is perfect and pass the blame to the other side, but then you would not be reading this.). I am sure that perfect transmitters & receivers are not possible, so we shall reasonably accept 1/2 the responsibility for the link budget, making our baud rate error specification 2.5%.
      Hmm.  Something still seems rotten.  The data sheet states that the TOTAL budget is 2%.  Our envelope scribblings say 5%.  What gives?
      Here is a good writeup by Maxim Integrated (https://www.maximintegrated.com/en/app-notes/index.mvp/id/2141) that adds some more details.  Essentially, you have an uncertainty of ±1 sample-time detecting the START bit and a terrible link would have a 50% chance of detecting the midpoint of the stop bit.  The short of the story is a ±3 sample-time error budget out of a needed 152 sample-times (160 sample times less 1/2 a bit time) or ±2% error budget for the link.  That assumes you are over sampling 16x.  On a PICmicrocontroller, the UART has a high speed mode (BRGH = 1) which changes the sampling rate to x4 instead of x16.  This can have a profound effect on the error budget due to the ±1 bit sampling uncertainty.
      So here are a few recommendations:
      1) Always use the MAXIMUM sampling rate available in your UART.
      2) Consider a crystal (20ppm) or a resonator (0.5%) or if you must use an internal oscillator, I hope your temperature & power supply is stable so your oscillator accuracy is good.
      3) Consider using the auto baud features and internal oscillator tuning features if they are available in your controller.
      Good Luck
    • By ric
      This is my attempt to convert the blazingly fast assembler routine for calculating parity into a C function.
      The original comes from here: https://www.microchip.com/forums/m4762.aspx
      Unfortunately Microchip have killed off the board where the original discussion took place at http://asp.microchip.com/webboard/wbpx.dll/~DevTools/read?21443,5
      #include <xc.h> //returns 0x00 (even parity) or 0x80 (odd parity) unsigned char parity(volatile unsigned char dat) //("volatile" is required because no C code reads the parameter) { asm("swapf parity@dat,w"); //assume correct bank is still selected asm("xorwf parity@dat,w"); //W has 8 bits reduced to 4 with same parity asm("addlw 41h"); // bit 1 becomes B0^B1 and bit 7 becomes B6^B7 asm("iorlw 7Ch"); // for carry propagation from bit 1 to bit 7 asm("addlw 2"); // Done! the parity bit is bit 7 of W asm("andlw 80h"); // set NZ if odd parity, and leave 00 or 80 in W asm("return"); return 1; //dummy instruction to defeat "no return value" error } void main(void) { unsigned char idx=0; while(1) { PORTA = parity(idx); idx++; } } I'm not sure if there's a cleaner way to suppress the "no return value" error, without generating extra code.
    • By KM1
      Hello,
      This forum is very refreshing - good content and respectful users!
      I have a good amount of experience with PIC products, but not full-time day in and day out. My question is regarding the pros and cons of using the advanced versions of the PIC16f family vs the 18f family. I really like the analog peripherals amongst other features and I wonder what others think for new project development?
      For example, I am looking at a redesign of a product that currently has been using the PIC16f887 for the last 5 years. I am looking at the PIC16f18877 as a replacement unit and have spent some time wading through the 600+(!) page data sheet looking for opportunities to simplify the original circuit design and take advantage of some of these features. I am not looking for a way to avoid reading the data sheet, just some other points of view.
      Keith
×
×
  • Create New...