 |
 |
| View previous topic :: View next topic |
| Author |
Message |
quicksilver
Joined: 04 Feb 2009
Posts: 31
|
| PIC 18f4455 + RS232 at 115200 |
 Posted: Fri Jan 31, 2014 11:44 am |
 |
|
OK, here is my problem. I cannot get the correct characters in my hyperterminal, I have checked already in Proteus too and I get the same. I thing that I'm not working with the proper fuses. Here is my short program.
| Code: | #include <18f4455.h>
#fuses HS, NOWDT, BROWNOUT, NOLVP, NOMCLR
#use delay(clock=20000000)
#USE rs232 (baud=115200, xmit=pin_c0, rcv=pin_c1)
void main()
{
delay_ms(1000);
// Open
putc(85);
putc(170);
putc(01);
putc(00);
putc(00);
putc(00);
putc(00);
putc(00);
putc(01);
putc(00);
putc(01);
putc(01);
delay_ms(2000);
putc(85);
putc(170);
putc(01);
putc(01);
putc(00);
putc(00);
putc(00);
putc(00);
putc(18);
putc(00);
putc(19);
putc(01);
delay_ms(3000);
output_high(pin_e1);
}
|
Please, I can´t find why I´m not having the right communication. Thank you guys.
  
_________________
everything that has a beginning, has an end |
|
 |
temtronic
Joined: 01 Jul 2010
Posts: 9164
Location: Greensville,Ontario
|
|
| Posted: Fri Jan 31, 2014 12:07 pm |
|
|
step #1: cut a '1Hz flashing LED' program and see if THAT works.
You could have the fuses set wrong, a bad chip, compiler bug ???
step #2: use the CCS 'loopback' example program and see if THAT works !
It's set for 9600 baud,easier to check.
step #3: disable any/all peripherals that use c0 and c1. ADC, comp., etc could be the defaults and corrupting program operation.
step #4: report back with what you find out.
ps: Proteus is, itself, FULL of bugs so never trust it.
hth
jay |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9164
Location: Greensville,Ontario
|
|
| Posted: Fri Jan 31, 2014 12:08 pm |
|
|
| step 2B: be sure to have a MAX232 or equal between PIC and PC !!! |
|
|
quicksilver
Joined: 04 Feb 2009
Posts: 31
|
|
| Posted: Fri Jan 31, 2014 12:18 pm |
|
|
Thank you for your quick answer. Let me explaint further what I´m doing and what I have done already.
I'm connecting my pic to a peripheral which work with that speed.
The LED programa I already did it, and works good, I´ll post the program of the LED soon.
I have checked already with 9600 baudios in Proteus, just Proteus and I can see the hex data in the virtual terminal. Works good for me. However, when I set the baudrate at 115200, it´s all messed up. The data are wrong.
I´ll try your step 3, however, as I said before, it works great at 9600.
And thank you for the Proteus advice, it´s true, it´s full of bugs, however, with this specific applications, it works fine with 9600. Still struggling with 115200.
Once again, thank you.
_________________
everything that has a beginning, has an end |
|
|
quicksilver
Joined: 04 Feb 2009
Posts: 31
|
|
| Posted: Fri Jan 31, 2014 12:41 pm |
|
|
OK, here it is the program for the LED.
| Code: |
#include <18f4455.h>
#FUSES NOWDT //No Watch Dog Timer
#FUSES PLL1 //No PLL PreScaler
#FUSES HSPLL //High Speed Crystal/Resonator with PLL enabled
#FUSES NOMCLR
#use delay(clock=20000000)
#use rs232(baud=9600,xmit=PIN_C0,rcv=PIN_C1)
void main()
{
while(true)
{
output_high(pin_e1);
delay_ms(1000);
output_low(pin_e1);
delay_ms(1000);
}
} |
I tested in my board and it´s not exactly one second, it is around 800ms measured with an oscilloscope. Could it be the problem?. I did some modifications to the fuses, trying to get something right, without good results.
_________________
everything that has a beginning, has an end |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19346
|
|
| Posted: Fri Jan 31, 2014 12:54 pm |
|
|
Do you really have a 5MHz crystal?.
Proteus does no testing of the clock being 'possible', so you need to be really careful that clock settings are right.
If your LED test is running at 800mSec, things are never going to work. Suggests you might have an 6MHz crystal. CLOCK=24MHz....
Long term though, switch to using pins C6 & C7 for your RS232.
You are using _software_ RS232 emulation. Though the compiler will tell you if it cannot achieve the rate at all, at fast rates the software RS232 gets increasingly less accurate. Worse, if you then want to receive something on the link, you have to poll the serial line at something over 250000* per second to not miss anything...
That is why the hardware is there.
Best Wishes |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9164
Location: Greensville,Ontario
|
|
| Posted: Fri Jan 31, 2014 12:58 pm |
|
|
Yikes 800ms instead of 1000ms !!! YUP, BIG error, something is NOT correct.
You need to get it working very close to 1000ms( <2%) for sure, in order for serial communications to work right.
I don't use that PIC, but check the fuses and datasheet to be sure they are getting configured as required.A long shout might be wrong caps for your 20MHz xtal...but that's a remote one.Check the xtal itself,maybe it's say 16MHz or 24MHz and not 20MHz ?
There is NO point proceeeding until the 1Hz LED program is running correctly.
hth
jay |
|
|
quicksilver
Joined: 04 Feb 2009
Posts: 31
|
|
| Posted: Fri Jan 31, 2014 1:33 pm |
|
|
Guys, thank you for everybody who is helping me. I´m using a board that I designed, with the same board I run an USB connection with the same 20MHz crystal. I´m prety sure that the fuses are wrong. However, it´s difficult to find it out which one from the datasheet. I´ll try different combinations to have my LED working at 1Hz, however, the strange thing is that the communication at 9600 works just fine (In proteus, damn). Anyways, let´s keep trying, and I´ll keep posting my progress. I know that there is a lot of people out there struggling with 115200.
Best wishes.
_________________
everything that has a beginning, has an end |
|
|
quicksilver
Joined: 04 Feb 2009
Posts: 31
|
|
| Posted: Fri Jan 31, 2014 1:42 pm |
|
|
I forgot something, I used the pins TX and RX without good results, still having the same error. All the data messed up.
_________________
everything that has a beginning, has an end |
|
|
quicksilver
Joined: 04 Feb 2009
Posts: 31
|
|
| Posted: Fri Jan 31, 2014 2:42 pm |
|
|
Guys, good news. I did it. I got my LED working at 1000ms. Here it is the program.
| Code: | #include <18F4455.h>
#FUSES NOWDT //No Watch Dog Timer
#FUSES WDT128 //Watch Dog Timer uses 1:128 Postscale
#FUSES PLL5 //Divide By 5(20MHz oscillator input)
#FUSES CPUDIV4 //System Clock by 4
#FUSES NOUSBDIV //USB clock source comes from primary oscillator
#FUSES ECPLL //External Clock with PLL enabled and Fosc/4 on RA6
#FUSES NOFCMEN //Fail-safe clock monitor disabled
#FUSES NOIESO //Internal External Switch Over mode disabled
#FUSES NOPUT //No Power Up Timer
#FUSES NOBROWNOUT //No brownout reset
#FUSES BORV20 //Brownout reset at 2.0V
#FUSES VREGEN //USB voltage regulator enabled
#FUSES PBADEN //PORTB pins are configured as analog input channels on RESET
#FUSES LPT1OSC //Timer1 configured for low-power operation
#FUSES MCLR //Master Clear pin enabled
#FUSES STVREN //Stack full/underflow will cause reset
#FUSES NOLVP //No low voltage prgming, B3(PIC16) or B5(PIC18) used for I/O
#FUSES ICPRT //ICPRT enabled
#FUSES NOXINST //Extended set extension and Indexed Addressing mode disabled (Legacy mode)
#FUSES NODEBUG //No Debug mode for ICD
#FUSES NOPROTECT //Code not protected from reading
#FUSES NOCPB //No Boot Block code protection
#FUSES NOCPD //No EE protection
#FUSES NOWRT //Program memory not write protected
#FUSES NOWRTC //configuration not registers write protected
#FUSES NOWRTB //Boot block not write protected
#FUSES NOWRTD //Data EEPROM not write protected
#FUSES NOEBTR //Memory not protected from table reads
#FUSES NOEBTRB //Boot block not protected from table reads
#FUSES NOMCLR
#use delay(crystal=20000000, clock=5000000)
#use rs232(baud=9600,xmit=PIN_C6,rcv=PIN_C7)
void main()
{
while(true)
{
output_high(pin_e1);
delay_ms(1000);
output_low(pin_e1);
delay_ms(1000);
}
}
|
I did the configuration with the PIC Wizard. I don´t exactly which is the fuse. However, it´s working right at least. Next step. The RS232 communication. I´ll be posting my progress.
PD: First time that turning a LED on and off cause me a lot of troubles. Do not judge me please. Still learning a lot.
_________________
everything that has a beginning, has an end |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9164
Location: Greensville,Ontario
|
|
| Posted: Fri Jan 31, 2014 3:56 pm |
|
|
glad to see you're blinking correctly !!!!
small steps...will get you to the end of the race!
as for the fuses and clock, what really helps is to printout the datasheet diagram of the clock signal paths. Then highlight the paths you know it should take. Xtal is 20MHz....feeds into PLL for USB, but must be /5 to give the PLL module 4MHz source. Yes, it'll take a coffee or two to finally get the 'flow' but you'll see it eventually, and then the 'fuses' should make sense.
When I get a working set of fuses, I copy them into a separate file ( PICtype_fuses.h) for future projects with that PIC.Instead of copy/paste from past projects it's easier to #include the file and I KNOW it works.
It also makes 'main(). Physically smaller, easier to read. I do the same with the I/O pin usage. I define every pin, unused ones are unA0, unA1, that way I can easily change pis around, have a chart of them, and again makes main() smaller.
Also I use the 'flashing led' as the base program. Copy it to newprogram_V1.c, edit, compile, test, make a few changes. After a few(not too many !) changes I again copy v1 to v2, and do it all again. This way I can go back to a previous version, that I know was working. I can have 20-30 versions on file, not a big deal PCs have tons of storage. When program is final, then I get rid of all but the last 3 versions.
As for RS232 , always add 'errors' to the use rs232(...options...). Without it, the UART will 'lockup' after 2-3 characters come in and you'll start scratching your head....huh ????? Now what's wrong !!
hth
jay |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19346
|
|
| Posted: Sat Feb 01, 2014 1:50 am |
|
|
You have two sets of configurations slightly disagreeing with one another here.
ECPLL, says 'use an external clock, and take the CPU clock from the USB PLL'.
Then (crystal=20000000, clock=5000000) can only be done using 'HS' or 'EC', not ECPLL. Do you really want to run the CPU this slowly?. USB, can give problems on slower clock rates. Also this is going to be getting slow for handling data at 115200bps...
Then EC, says to use an external oscillator (not a crystal, but a complete oscillator module). However the clock line says to use a crystal....
What is happening, is that the clock setup line is overriding the incorrect fuses, but as such potentially a bit 'dangerous'.
Then beware of CCS's 'comments' on their fuses. CPUDIV4, gives /4, when fed from the HS, or EC oscillator route, but /6 when fed from the PLL routes!... It is a pity they named the fuses the way they did.
There are a couple of other clashes in the fuses. You have MCLR selected, and NOMCLR. You have ICPRT, which must _only_ be set on 44pin devices (look at the register definitions for CONFIG4L in the data sheet). Then if in the future you want to use the PORTB pins, you have them set for analog. Rarely wanted. You have NOUSBDIV selected, which will mean USB can't ever work (this setting must only be used with a 24MHz crystal). You should always use PUT, when running with a crystal, or initial things will go wrong for a few uSec.
I'd suggest it is running, because the compiler is overriding the errors, but there are a couple left which will prevent you from using USB.
I'd suggest changing your setup to:
| Code: |
#FUSES NOWDT //No Watch Dog Timer
#FUSES PLL5 //Divide By 5(20MHz oscillator input)
//PLL is now fed with 4MHz
#FUSES CPUDIV1 //System Clock by 1 (back to 20MHz)
#FUSES USBDIV //USB clock source comes from PLL
#FUSES HS //External CRYSTAL - CPU fed from this
#FUSES NOFCMEN //Fail-safe clock monitor disabled
#FUSES NOIESO //Internal External Switch Over mode disabled
#FUSES PUT //Power Up Timer
#FUSES BROWNOUT //You do want brownout
#FUSES BORV43 //Brownout reset at 4.3v
#FUSES VREGEN //USB voltage regulator enabled
#FUSES NOPBADEN //PORTB pins are configured as digital input channels on RESET
#FUSES LPT1OSC //Timer1 configured for low-power operation
#FUSES STVREN //Stack full/underflow will cause reset
#FUSES NOLVP //No low voltage prgming, B3(PIC16) or B5(PIC18) used for I/O
#FUSES NOICPRT //ICPRT disabled
#FUSES NOXINST //Extended set extension and Indexed Addressing mode disabled (Legacy mode)
#FUSES NODEBUG //No Debug mode for ICD
#FUSES NOPROTECT //Code not protected from reading
#FUSES NOCPB //No Boot Block code protection
#FUSES NOCPD //No EE protection
#FUSES NOWRT //Program memory not write protected
#FUSES NOWRTC //configuration not registers write protected
#FUSES NOWRTB //Boot block not write protected
#FUSES NOWRTD //Data EEPROM not write protected
#FUSES NOEBTR //Memory not protected from table reads
#FUSES NOEBTRB //Boot block not protected from table reads
#FUSES NOMCLR
#use delay(clock=20000000)
|
This puts you back to running at 20MHz, with a set of fuses that will also support USB in the future (I'm assuming you do intend to use USB, since you are turning on the voltage regulator).
Now see if 115200 works. The same comment applies though - much better to use the hardware UART.....
Worth understanding that the USB PLL _always runs_. The 'PLL' in the fuses selects whether the CPU clock comes from the USB PLL, or from the external crystal. So with HS selected, CPUDIV1 gives 20MHz. CPUDIV2, 10MHz, CPUDIV3, 6.66MHz, and CPUDIV4 5MHz. However select HSPLL, and CPUDIV1 gives 48MHz (USB 96MHz/2), CPUDIV2, 32MHz, CPUDIV3, 24MHz, and CPUDIV4, 16MHz. Note that the dividers are different from the CCS fuse names. Technically the dividers are two bits, and give:
| Code: |
name binary div_primary div_PLL
1 00 1 2
2 01 2 3
3 10 3 4
4 11 4 6
|
So the CCS names are the division when running off the primary oscillator, but are wrong when running off the PLL. 'Beware'.....
I wish they had just called then CPUDIV00, CPUDIV01 etc., then a glance at the data sheet would say exactly what they will do.
Best Wishes |
|
|
quicksilver
Joined: 04 Feb 2009
Posts: 31
|
|
| Posted: Tue Feb 11, 2014 12:47 pm |
|
|
Ttelmah... Thank you very much, I have tried your fuses, I had some compilations errors, however. I deleted some fuses and works fine. I haven't tried the communication yet, I'm still working on it. Besides, I think that I'll work with 9600bps. Still figuring out how to send some data to my rs2323 port. I´m doing it with the putc function, without any luck, in the proteus hyperteminal works great, not as good as I would like it in my board. Well.. I very thankful with all of you who helped me in my quest. I'll keep you guys posted, and probably with more doubts. 
_________________
everything that has a beginning, has an end |
|
|
quicksilver
Joined: 04 Feb 2009
Posts: 31
|
|
| Posted: Fri Feb 28, 2014 11:33 am |
|
|
OK guys. I'm thinking to start a new post. Why? Because a couple of things have changed since the last time I posted. I'm using this fingerprint module. (Fingerprint Scanner - TTL (GT-511C3) https://www.sparkfun.com/products/11792.
I posted this because I read in the manual that the communication is at 115200 bps. However it is possible to run it at 9600 bps. Although, I have not succeed in my quest.
Here is the code.
| Code: | #include <18F4455.h>
#FUSES NOWDT //No Watch Dog Timer
#FUSES PLL5 //Divide By 5(20MHz oscillator input)
//PLL is now fed with 4MHz
#FUSES CPUDIV1 //System Clock by 1 (back to 20MHz)
#FUSES USBDIV //USB clock source comes from PLL
#FUSES HS //External CRYSTAL - CPU fed from this
#FUSES NOFCMEN //Fail-safe clock monitor disabled
#FUSES NOIESO //Internal External Switch Over mode disabled
#FUSES PUT //Power Up Timer
#FUSES BROWNOUT //You do want brownout
#FUSES BORV43 //Brownout reset at 4.3v
#FUSES VREGEN //USB voltage regulator enabled
#FUSES NOPBADEN //PORTB pins are configured as digital input channels on RESET
#FUSES LPT1OSC //Timer1 configured for low-power operation
#FUSES STVREN //Stack full/underflow will cause reset
#FUSES NOLVP //No low voltage prgming, B3(PIC16) or B5(PIC18) used for I/O
#FUSES NOICPRT //ICPRT disabled
#FUSES NOXINST //Extended set extension and Indexed Addressing mode disabled (Legacy mode)
#FUSES NODEBUG //No Debug mode for ICD
#FUSES NOPROTECT //Code not protected from reading
#FUSES NOCPB //No Boot Block code protection
#FUSES NOCPD //No EE protection
#FUSES NOWRT //Program memory not write protected
#FUSES NOWRTC //configuration not registers write protected
#FUSES NOWRTB //Boot block not write protected
#FUSES NOWRTD //Data EEPROM not write protected
#FUSES NOEBTR //Memory not protected from table reads
#FUSES NOEBTRB //Boot block not protected from table reads
#FUSES NOMCLR
#use delay(clock=20000000)
#use rs232(baud=9600,xmit=PIN_C6,rcv=PIN_C7)
void main()
{
//55 aa 01 00 00 00 00 00 01 00 01 01 send first: 55 sec; aa …. so on send last: 01
putc(0x55);
putc(0xAA);
putc(0x01);
putc(0x00);
putc(0x00);
putc(0x00);
putc(0x00);
putc(0x00);
putc(0x01);
putc(0x00);
putc(0x01);
putc(0x01);
output_high(pin_e1);
delay_ms(1000);
output_low(pin_e1);
delay_ms(1000);
//ledOn 55 aa 01 01 00 00 00 00 12 00 13 01
putc(0x55);
putc(0xAA);
putc(0x01);
putc(0x01);
putc(0x00);
putc(0x00);
putc(0x00);
putc(0x00);
putc(0x12);
putc(0x00);
putc(0x13);
putc(0x01);
output_high(pin_e1);
delay_ms(1000);
output_low(pin_e1);
delay_ms(1000);
while(true)
{
output_high(pin_e1);
delay_ms(1000);
output_low(pin_e1);
delay_ms(1000);
}
} |
Explanation of the code: I'm sending hexadecimal data through the serial port. (According to the manual, I have to send those hexadecimal numbers to get an answer from the module). After that, I'm blinking a LED to see if the program is really running.
Let's be honest, Proteus it's a great help and it can gives us some ideas before running something in a board. I can see in the hyper terminal that I'm sending exactly what I need. Here is my question. Am I sending a hexadecimal data, am I using the right function to send hexadecimal data?. Am I using the right fuses for this task?. Something that I've been noticing is that PIC18F are extremely sensible when we talk about fuses. If some of you have worked with Fingerprint Scanner - TTL (GT-511C3) and have some hint about how to run it properly, please share with us. And if someone knows if I have a mistake in my code, please, point it out. I know that probably is a question that is frequent in the forum.
Thank you.
_________________
everything that has a beginning, has an end |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9164
Location: Greensville,Ontario
|
|
| Posted: Fri Feb 28, 2014 11:49 am |
|
|
tip:
when using ...
#use rs232(baud=9600,xmit=PIN_C6,rcv=PIN_C7)
ALWAYS add 'errors' to the options....
#use rs232(baud=9600,xmit=PIN_C6,rcv=PIN_C7,errors)
this will prevent the UART from 'locking up' due to overrun conditions.
Also,if receiving several bytes of data, look at the CCS example 'ex_sisr.c' in the examples folder. When getting a lot of serial data it's best to use an ISR and buffer approach. that way you will not lose any data.
As for the sensor, sparkfun does have some code on the product page, seems like a great place to start(though you'll have to translate to CCS C( not that hard)).
hth
jay |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
