View previous topic :: View next topic |
Author |
Message |
duchonic
Joined: 14 Jul 2010 Posts: 9 Location: Switzerland
|
|
![](templates/subSilver/images/spacer.gif) |
MikeW
Joined: 15 Sep 2003 Posts: 184 Location: Warrington UK
|
|
Posted: Wed Jul 14, 2010 1:32 am |
|
|
It means they are future devices from Microchip, so not yet even sampling.
The PIC16F1823/22 is available now, but not the 1824-1829.
I see from the microchip user forums, that there are significant problems with the A/D converter, which will be fixed in a new rev, so probably the whole family will be available in September.
Mike |
|
![](templates/subSilver/images/spacer.gif) |
FvM
Joined: 27 Aug 2008 Posts: 2337 Location: Germany
|
|
Posted: Wed Jul 14, 2010 1:33 am |
|
|
A lot of newer devices hasn't be fully tested (e.g. involving all applicable built-in functions). It means, that there is a higher risk that specific features of the new chips are not correctly implemented, e.g. register addresses may be wrong. |
|
![](templates/subSilver/images/spacer.gif) |
duchonic
Joined: 14 Jul 2010 Posts: 9 Location: Switzerland
|
|
Posted: Thu Jul 15, 2010 7:31 am |
|
|
I see.
I am working with the 16F1827 (because i have to wait for the 16F1823) and found some problems...
-> Microchip says that each of the PORTA pins has an individually configurable internal weak pull-up.
But in reality the WPUA (WEAK PULL-UP PORTA REGISTER) only knows a pullup for PORTA pin 5
...hope the 16F1823 will come soon... |
|
![](templates/subSilver/images/spacer.gif) |
ralph79
Joined: 29 Aug 2007 Posts: 87
|
16F1823 INT_RDA problems |
Posted: Fri Oct 08, 2010 11:35 am |
|
|
Hi there,
I've been working with CCS 4.110 and the PIC 16F1823.
The problem that I have is that the INT_RDA interrupt is not been catch by the micro. I make the enable of the interrupts, I even did a different test, I defined a byte PIE1 to force the micro to enable the RDA and still it doesn't work.
Following a portion of code:
Code: |
#include <16F1823.h>
#device adc=8
#FUSES NOWDT //No Watch Dog Timer
#FUSES INTRC_IO //Internal RC Osc, no CLKOUT
#FUSES NOCPD //No EE protection
#FUSES PROTECT //Code not protected from reading
#FUSES NOMCLR //Master Clear pin enabled
#FUSES PUT //Power Up Timer
#FUSES BROWNOUT //Reset when brownout detected
#FUSES NOIESO //Internal External Switch Over mode enabled
#FUSES NOFCMEN //Fail-safe clock monitor enabled
#FUSES NODEBUG //No Debug mode for ICD
//#FUSES WDT_NOSL
#FUSES NOWRT //Program Memory Write Protected
#FUSES PLL
#FUSES STVREN //Stack full/underflow will cause reset
#FUSES NOLVP //No low voltage prgming, B3(PIC16) or B5(PIC18) used for I/O
#FUSES BORV25 //Brownout reset at 2.5V
#FUSES NOCLKOUT //Output clock on OSC2
#use delay(int=16000000)
#use rs232(baud=9600, parity=N, xmit=PIN_C4, rcv=PIN_C5, bits=8, STOP=1, errors)
#byte PIE1 = 0x91
#int_RDA
void RDA_isr(void) // rs232 receive data available
{
int8 ch = 0;
ch = getchar();
write_byte_eeprom(pos_eeprom_test++, ch);
}
#int_TIMER1
void TIMER1_isr(void)
{
}
void main(void)
{
setup_adc_ports(NO_ANALOGS|VSS_VDD);
setup_adc(ADC_CLOCK_DIV_2);
setup_spi(SPI_SS_DISABLED);
setup_timer_0(RTCC_INTERNAL|RTCC_DIV_256);
setup_timer_1(T1_INTERNAL|T1_DIV_BY_8);
setup_timer_2(T2_DISABLED,0,1);
setup_ccp1(CCP_OFF);
setup_comparator(NC_NC_NC_NC);
enable_interrupts(INT_TIMER1);
enable_interrupts(INT_RDA);
PIE1 = 0x20; // this was for test
enable_interrupts(GLOBAL);
while(1);
} |
|
|
![](templates/subSilver/images/spacer.gif) |
duchonic
Joined: 14 Jul 2010 Posts: 9 Location: Switzerland
|
Changed to PIC16F688 |
Posted: Mon Oct 11, 2010 1:34 am |
|
|
Hello
I changed to PIC16F688 and finished my project.
Didn't have the patience to work with 16F18x...
-> never used the rda with 16F18x |
|
![](templates/subSilver/images/spacer.gif) |
ralph79
Joined: 29 Aug 2007 Posts: 87
|
|
Posted: Tue Oct 12, 2010 11:29 am |
|
|
Hi duchonic,
I'm trying to change from the 16F688 that I'm using at this moment for the new 16F1823.
I will wait for a new updates from CCS or from any other user from this forum.
Thanks for your feedback
Regards |
|
![](templates/subSilver/images/spacer.gif) |
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Tue Oct 12, 2010 1:30 pm |
|
|
It's generating code for a software UART. But it appears to generate
the correct code if you specify 'UART1' instead of the Tx and Rx pins.
I looked at the .LST file and I think it will work. Example:
Code: |
#include <16F1823.h>
#fuses INTRC_IO,NOWDT,NOPROTECT,BROWNOUT,PUT,NOLVP
#use delay(clock=4000000)
//#use rs232(baud=9600, xmit=PIN_C4, rcv=PIN_C5, ERRORS)
#use rs232(baud=9600, UART1, ERRORS) // *** Use this line instead
#int_RDA
void RDA_isr(void)
{
int8 c;
c = getchar();
}
//===========================
void main(void)
{
enable_interrupts(INT_RDA);
enable_interrupts(GLOBAL);
while(1);
}
|
Both v4.110 and v4.112 have the problem. Using 'UART1' instead of the
pin numbers appears to fix it in both versions. |
|
![](templates/subSilver/images/spacer.gif) |
hwstar
Joined: 15 May 2010 Posts: 10
|
|
Posted: Wed Oct 13, 2010 1:40 pm |
|
|
I have a board with the 16F1823 on it. The code for the UART is generated correctly as PCM as commented, but the other thing you must do is make sure you set the APFCON register up to route the UART's TXD and RXD signals to the pins you wish to use. The APFCON register comes up with
zeros on all relevant bits at reset. If you need to use the alternate pins on the part for the UART, you'll have to set bits 2 and 7 to ones.
The #PIN_SELECT directive does not do this for you (At least with the 4.109 PCML compiler I have). |
|
![](templates/subSilver/images/spacer.gif) |
ralph79
Joined: 29 Aug 2007 Posts: 87
|
|
Posted: Thu Oct 14, 2010 10:40 am |
|
|
Dear PCM and hwstar,
I've tried the code that you give but still I don't have a correct response from my RDA interrupt. I've been making debugging with PIC KIT 3 and also with the normal write to the internal eeprom. Sometimes I have a byte receive from the getchar but after I think I have a internal block when I call the getchar function. So I think that even with the code from PCM:
Code: | #use rs232(baud=9600, UART1, ERRORS) // *** Use this line
instead
|
The micro doesn't have all the capabilities for the RDA interrupt.
Hwstar I have my RX pin in the PIN_C5 that I think is the normal one. Even so, I my first tests I have changed the APFCON to the value 0x00
I'm making all the tests to have a better conclusion. When I have news I will come back. If you have any other suggestion please give it to me.
Regards,
Ralph |
|
![](templates/subSilver/images/spacer.gif) |
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Fri Oct 15, 2010 3:19 pm |
|
|
Quote: | #int_RDA
void RDA_isr(void) // rs232 receive data available
{
int8 ch = 0;
ch = getchar();
write_byte_eeprom(pos_eeprom_test++, ch);
}
|
This is not a good method. Don't do eeprom write operations inside
the RDA isr. Find some better way to test the interrupt, so it does not
do any writing to eeprom.
Look in this section, in the back of the 16F1823 data sheet:
Quote: |
29.5 Memory Programming Requirements
Data EEPROM Memory
Erase/Write Cycle Time — 4.0 ms typical, 5.0 ms max
|
At 9600 baud, you can receive a character every 1.04 ms. The hardware
receive buffer is only 2 deep. So if you write to eeprom inside the isr,
the program is locked up in the isr for 4 ms or more. During that time,
if more than 2 characters come into the the Rx pin, all the additional
characters will be lost. |
|
![](templates/subSilver/images/spacer.gif) |
ralph79
Joined: 29 Aug 2007 Posts: 87
|
|
Posted: Mon Oct 18, 2010 1:39 am |
|
|
Yes your are right PCM
But I just want to test if I receive anything. I don't care, for now, to receive all my message, I just want to see if I'm receive anything. One of previous tests was filling a buffer each time I had a serial interrupt and each time I have more than 10 characters I putted it (during the while main statement) on the eeprom and I don't have anything.
I will continuing to test this micro with RDA capability.
Regards, |
|
![](templates/subSilver/images/spacer.gif) |
ralph79
Joined: 29 Aug 2007 Posts: 87
|
Solved |
Posted: Tue Nov 09, 2010 2:38 am |
|
|
After a couple of tests I discovered that the problem of the CCS with this micro was not only a problem of interrupt detection but also a problem of clock for the UART clock.
So for using this micro we have to use rs232 as follows:
Code: | #use rs232(baud=1200, UART1, ERRORS) |
And also to select a clock speed for the micro that is compatible with the clock of the uart.
Hope that this could help someone of the forum
With regards,
Ralp |
|
![](templates/subSilver/images/spacer.gif) |
|