CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to CCS Technical Support

PIC16F182x not yet been tested at CCS

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
duchonic



Joined: 14 Jul 2010
Posts: 9
Location: Switzerland

View user's profile Send private message

PIC16F182x not yet been tested at CCS
PostPosted: Wed Jul 14, 2010 12:51 am     Reply with quote

Hi
What does it means it the device it not yet been tested at CCS?
http://www.ccsinfo.com/devices.php?page=devices
have a nice day
MikeW



Joined: 15 Sep 2003
Posts: 184
Location: Warrington UK

View user's profile Send private message

PostPosted: Wed Jul 14, 2010 1:32 am     Reply with quote

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
FvM



Joined: 27 Aug 2008
Posts: 2337
Location: Germany

View user's profile Send private message

PostPosted: Wed Jul 14, 2010 1:33 am     Reply with quote

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



Joined: 14 Jul 2010
Posts: 9
Location: Switzerland

View user's profile Send private message

PostPosted: Thu Jul 15, 2010 7:31 am     Reply with quote

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



Joined: 29 Aug 2007
Posts: 87

View user's profile Send private message

16F1823 INT_RDA problems
PostPosted: Fri Oct 08, 2010 11:35 am     Reply with quote

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);
}
duchonic



Joined: 14 Jul 2010
Posts: 9
Location: Switzerland

View user's profile Send private message

Changed to PIC16F688
PostPosted: Mon Oct 11, 2010 1:34 am     Reply with quote

Hello

I changed to PIC16F688 and finished my project.
Didn't have the patience to work with 16F18x...

-> never used the rda with 16F18x
ralph79



Joined: 29 Aug 2007
Posts: 87

View user's profile Send private message

PostPosted: Tue Oct 12, 2010 11:29 am     Reply with quote

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
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Tue Oct 12, 2010 1:30 pm     Reply with quote

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



Joined: 15 May 2010
Posts: 10

View user's profile Send private message

PostPosted: Wed Oct 13, 2010 1:40 pm     Reply with quote

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).
ralph79



Joined: 29 Aug 2007
Posts: 87

View user's profile Send private message

PostPosted: Thu Oct 14, 2010 10:40 am     Reply with quote

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
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Fri Oct 15, 2010 3:19 pm     Reply with quote

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



Joined: 29 Aug 2007
Posts: 87

View user's profile Send private message

PostPosted: Mon Oct 18, 2010 1:39 am     Reply with quote

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,
ralph79



Joined: 29 Aug 2007
Posts: 87

View user's profile Send private message

Solved
PostPosted: Tue Nov 09, 2010 2:38 am     Reply with quote

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
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
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