Found the OpenUSART function on the PIC18 peripheral libraries, but it's no enabled for my PIC16s.

 

Please see post #180

 

Here is a tutorial for using the communication libraries for the pic16f and mplabx. If there anything helpful in there:

http://extremeelectronics.co.in/pic16f877a-tutorials/usart-library-for-pic-setup-on-mplab-x-ide/

Thanks, I also found that page and was about to try it.

 

Got it!!!!

Well, more or less...

At first it didn't work with the PICkit2 UART tool, but I could see on the oscilloscope that it was sending data through the TX pin (RC6). So, I connected the TX pin directly to the pin that is connected to the PICkit2 RX pin (RB7), and now I can see characters on the serial monitor.

Hope there's nothing wrong it connecting RC6 and RB7 directly; though maybe the right way to do it was to pass the value of RC6 to RB7 by software.

I did a program this morning that sent data directly to the RX pin of the PICkit2, and I could see the data going out on the oscilloscope and through the "busy" light on the kit; but I guess the bauds didn't match, so nothing came out the monitor.

With this test I can see characters on the monitor, but not the ones sent. I think the problem has also to do with a mismatch between bauds, because the example is tuned for a device running at 20Mhz, and with the internal oscillator I can only achieve 8Mhz; so I had to recalculate the "SPBRG" values using the formula on the device's datasheet.

 

I had to go through steps of "progress" to get mine to work too. Sounds like you're moving along. We all have to learn sometimes. I'd be more help if I used PICKIT2 and PIC16, but I don't.

 

Thanks. This example is easy to understand, and I think I'll be able to modify it to make the serial monitor work; which will be a great help to continue learning.

 

What transmission format are you using for the communication, if any, RS232/RS485 etc.
Max.

 

What transmission format are you using for the communication, if any, RS232/RS485 etc.
Max.

I changed to the other PIC -the loose 16F88 instead of the 16F887 on the demo board-, recalculated the SPBRG and changed the frequency to 8Mhz, built 2 circuits -one for programming and another for the serial communication- and the example is now working without problems.

I have a question though about in-circuit programming. What is the right way to do it in this case: have 2 circuits like I did, and change the programmer all the time depending on whether you are programming or testing; or have just one circuit with the RX/PGD and RT/PGC overlapped?

About the transmission format: I don't know that is called, it's: asynchronous, 8bits data, no parity, and 1 stop bit.

 

About the transmission format: I don't know that is called, it's: asynchronous, 8bits data, no parity, and 1 stop bit.

That's not the interface standard, RS232/RS485 etc apply to the communication levels, not the content.
Max.

 

That's not the interface standard, RS232/RS485 etc apply to the communication levels, not the content.
Max.

Then I don't know what you are referring to... what standards can I use, and how are they going to influence the PICKIt2 uart monitor?

 

I wasn't sure if you were using any of the common communication standards.
When using serial transmission data, especially over long distance, the signal is 'conditioned' in an attempt to prevent spurious interference of the data, if you looked at the Nigel Goodwin tutorial you would see he used RS232 via a MAX232 IC.
They won't necessarily affect the way you are doing it as long as both ends can communicate.
Max.

 

I wasn't sure if you were using any of the common communication standards.
When using serial transmission data, especially over long distance, the signal is 'conditioned' in an attempt to prevent spurious interference of the data, if you looked at the Nigel Goodwin tutorial you would see he used RS232 via a MAX232 IC.
They won't necessarily affect the way you are doing it as long as both ends can communicate.
Max.

I see what you mean.

The problem was a mismatch in the frequencies between the device and the kit; I recalculated the baud rates and now it's working fine.

 

A Arduino also has a boot loader stored in the Atmel controller. This is what all Arduino boards have in common. So to get a PIC to do the same, look for someone who has done the same. The only one that comes to mind is the Basic Stamp, but the Stamp actually compiles the Basic as it runs it on the chip, so that is rather lame when it comes to speed. The chip you want to checkout is the picaxe. So Google that.

As for your code being protected on a PIC, it is done when you burn the program, you set fusible links in an option register. Once you do, that chip is locked.

There are far more PIC controllers than there are Atmel controllers with or without boot loaders. If you go the PIC route, the code you write for a low level device, can easily be ported over to a more powerful device with more abilities. My gut notion about PIC is that you can do way more with it than you can do with any Atmel chip. The focus of Arduino is education, and not the sale of Atmel chips. The goal of Microchip is to sell chips, and it might surprise some to know that the sale of 8 bit PIC's has exploded in sales this year.
Arduino is much easier to get running for someone new to Micro-controller programming. Also, Arduino teaches C programming, and some people think C is difficult to learn. Arduino proves that to be wrong. In any case, PIC has a few good Basic compilers. If you intend to stay with programming micro-controllers, start with C. C compiles to smaller code, and has much more user based support on the Internet and in downloadable PDF books. Joe

 

A Arduino also has a boot loader stored in the Atmel controller. This is what all Arduino boards have in common. So to get a PIC to do the same, look for someone who has done the same. The only one that comes to mind is the Basic Stamp, but the Stamp actually compiles the Basic as it runs it on the chip, so that is rather lame when it comes to speed. The chip you want to checkout is the picaxe. So Google that.

As for your code being protected on a PIC, it is done when you burn the program, you set fusible links in an option register. Once you do, that chip is locked.

There are far more PIC controllers than there are Atmel controllers with or without boot loaders. If you go the PIC route, the code you write for a low level device, can easily be ported over to a more powerful device with more abilities. My gut notion about PIC is that you can do way more with it than you can do with any Atmel chip. The focus of Arduino is education, and not the sale of Atmel chips. The goal of Microchip is to sell chips, and it might surprise some to know that the sale of 8 bit PIC's has exploded in sales this year.
Arduino is much easier to get running for someone new to Micro-controller programming. Also, Arduino teaches C programming, and some people think C is difficult to learn. Arduino proves that to be wrong. In any case, PIC has a few good Basic compilers. If you intend to stay with programming micro-controllers, start with C. C compiles to smaller code, and has much more user based support on the Internet and in downloadable PDF books. Joe

Thanks Joe,

At the moment, rather than attempting to pass the code from Arduino to PIC, or try both to do the same, I'm staring from scratch learning to program the PICs and then develop the same code again. I had plans to start with PICs long before this project, so I'm taking the opportunity to do both at the same time.

 

I'm having problems with one of the PICs (the PIC16F88); it's not behaving at it should, or as the other one (the PIC16F887).

When I change an individual output bit on an I/O port -say using the "PORTAbits.RA0" to light an LED on RA0- it sets to 0 all other bits in that port. For example: if I turn on an LED on RB0, and then turn on RB1, the LED on RB0 will go off. This does not happen with the PIC16F887; you can change independently the value of any bit in a I/O port and the rest will retain their previuos value.

I don't think I'm doing anything wrong; since it works as expected win one of the pics; but just in case, take this example:

TRISA = 0;

    PORTAbits.RA0 = 1;
    PORTAbits.RA1 = 1;

If you have an LED on RA0 and another on RA1; how many should be on after this piece of code? ... both, isn't it? ... Well, not on the PIC16F88; only the last one you turn on remains.

Anyone knows why?

 

how many should be on after this piece of code? ... both, isn't it? ... Well, not on the PIC16F88; only the last one you turn on remains.

Anyone knows why?

That's exactly the reason why LATs were introduced in newer chips.

The operation is done through bsf instruction. It reads PORTA, changes one bit, then writes in back. Therefore, all other bits except the one you're setting, are changed to whatever was read from PORTA. And this could be:

0 if the pin is configured as analog. To fix: you need to reconfigure as digital

0 if it hasn't been ebough time since it's been set. To fix: insert some delay between setting bits.

or

get a PIC with LATs.

 

That's exactly the reason why LATs were introduced in newer chips.

The operation is done through bsf instruction. It reads PORTA, changes one bit, then writes in back. Therefore, all other bits except the one you're setting, are changed to whatever was read from PORTA. And this could be:

0 if the pin is configured as analog. To fix: you need to reconfigure as digital

0 if it hasn't been ebough time since it's been set. To fix: insert some delay between setting bits.

or

get a PIC with LATs.

Thanks a lot; I was already giving it for impossible and looking for ways to just write the whole word every time.

I set the port to digital and now is working without problems. But why this didn't happen with the other PIC; nor with any other example I saw, since I never saw one using ANSEL first?

 

But why this didn't happen with the other PIC; nor with any other example I saw, since I never saw one using ANSEL first?

Not all pins have analog capabilities.

 

Not all pins have analog capabilities.

I see. Yes, the other pic doesn't have the analog I/O on the same pins.

What about the I/O pins that also share the MCLR? I can't get anything out from that pin, either with the CONFIG MCLR on or off. Furthermore, if I have an LED attached to that pin the programmer will not even find the device; it says: "PICkit 2 VPP voltage level error. Check target & retry operation."

I also tried adding an isolation resistor, and both with the MCLR pull-up resistor and capacitor, and without them.

 

I see. Yes, the other pic doesn't have the analog I/O on the same pins.

What about the I/O pins that also share the MCLR? I can't get anything out from that pin, either with the CONFIG MCLR on or off. Furthermore, if I have an LED attached to that pin the programmer will not even find the device; it says: "PICkit 2 VPP voltage level error. Check target & retry operation."

I also tried adding an isolation resistor, and both with the MCLR pull-up resistor and capacitor, and without them.

That pin is not accessible for output.

Your LED resistor is too low, try 2.2 K Ohms or more.