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 support@ccsinfo.com

16F1847 Out of ROM
Goto page Previous  1, 2
 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
kmp84



Joined: 02 Feb 2010
Posts: 345

View user's profile Send private message

PostPosted: Wed Feb 03, 2021 3:51 pm     Reply with quote

Hi mr."temtronic"

I also have many projects and more than thousand devices with 18F45/46K22. It's also favorite mcu for me. Very Happy
I'm not 'best' C-Programmer and needs good and fast ICD, when developing new projects.
For example my last project took about one month of hard software work with silabs c8051F58x and silabs 8-bit UDA(ICD). If it was with best 18F46K22 PIC and CCS ICD-U64 may be 2-3 month will not enough! Rolling Eyes

P.S
Starting/Stopping debugging session with CCS ICD U64 and PIC in best cases takes more than 15-20 sec! With Silabs 8-bit ICD and Keil IDE just 2-3 sec. Very Happy

Best Regards!
temtronic



Joined: 01 Jul 2010
Posts: 9081
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Thu Feb 04, 2021 6:34 am     Reply with quote

re:
Quote:
PIC in best cases takes more than 15-20 sec!

When I started 'playing with PICs', it'd take 15 MINUTES to erase a 16C84.

was great 'excuse' to grab another coffee...

Wink
kmp84



Joined: 02 Feb 2010
Posts: 345

View user's profile Send private message

PostPosted: Sat Feb 06, 2021 2:20 pm     Reply with quote

Hi,
I forgot to write that the project is being compiled successfully already with mr."Ttelmah" suggestion:
Quote:

Then if a routine, calls another routine, that is used just once, by default,
the compiler will tend to make this routine 'inline'. Attaching it into
the original routine. You have to add #separate to the declaration of the
routine, to force it to be kept as a separate entity.

Thanks mr."Ttelmah"!

Now I have another trouble Sad
For unknown reason MCU stop running and needs to make reset or power off/on cycle.
I suppose that problem come from software UART which I'm using with #int_ext ISR in receiver.

#use rs232(baud=9600,xmit=PIN_A2,rcv=PIN_B0,DISABLE_INTS,STREAM=SW_UART)
temtronic



Joined: 01 Jul 2010
Posts: 9081
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Sat Feb 06, 2021 3:15 pm     Reply with quote

software UART which I'm using with #int_ext ISR in receiver.

#use rs232(baud=9600,xmit=PIN_A2,rcv=PIN_B0,DISABLE_INTS,STREAM=SW_UART)

You'll have to show HOW you code the ISR with a software UART. While it may be possible,you'll have to play 'tricks' to get it to work. SW UARTs generally work fine for transmitting, but receiving involves a lot of coding.

Have to ask why not use the hardware UART ???
kmp84



Joined: 02 Feb 2010
Posts: 345

View user's profile Send private message

PostPosted: Mon Feb 08, 2021 9:17 am     Reply with quote

Hi,
Here is some part of code:
Code:

#include <16F1847.h>
#device *=16
#fuses INTRC_IO,NOPROTECT,NOMCLR,PUT,BROWNOUT,NOWDT,NOFCMEN
#use delay(clock=16MHz)

void main(void){
   
   unsigned int16 CurrTick, PrevTick;   
   
   setup_adc(ADC_OFF);
   SETUP_ADC_PORTS(NO_ANALOGS);   
   SETUP_DAC(DAC_OFF);   
   setup_comparator(NC_NC_NC_NC);   
   
   port_b_pullups(0b00000001);       // Enable PullUp res on Pin_B0 SwUart Rx
   
   enable_interrupts(INT_EXT_H2L);
   enable_interrupts(int_rda);
   enable_interrupts(GLOBAL);   
   
   while(TRUE){

      Task_1();   // Use HW_UART
     
      Task_2();   // Use SW_UART     
 
   }
}


Some part of code for Task_2 which use SW_UART:
Code:


#use rs232(baud=9600, xmit=PIN_A2, rcv=PIN_B0, stream=SW_UART, DISABLE_INTS)

...................

#int_ext
void EG_RxISR(void){
   
   //clear_interrupt(int_ext);
   U8 data_byte;
   
   data_byte = fgetc(SW_UART);                    // Get Rx DataByte
   RxBuffEg[RxIndxEg++] = data_byte;          // Put data byte in RxBuff
   
   if(RxIndxEg > RX_BUFF_SIZE_EG-1)            // RxBuff overflow check!
      RxIndxEg = RX_BUFF_SIZE_EG-1;
   
   PrevTickEg = CurrTickEg = get_ticks();      // Clr.Tick Counters   
}
temtronic



Joined: 01 Jul 2010
Posts: 9081
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Mon Feb 08, 2021 9:31 am     Reply with quote

There is a problem with using a SW UART to receive data in that by the time the ISR for the 'int_ext' executes, the actual incoming data won't be correct, also you need to disable ALL other interrupt sources while the PIC 'bitbangs' the incoming data.
Honestly, you should use a PIC with 2 HW UARTs..it makes life easier ! There's probably a pin compatible PIC with 2 HW UARTs ....and the small cost to upgrade is more than offset by the HUGE reduction in R&D time.
I chose the 18F46K22 years ago as the best 'overall' PIC for projects and products I do use the 26K22 ( 28 pin ) version sometimes, though not often.

just did a 'price check'.. 16f1847 is $3 cdn, 18f26k22 is $5 cdn
So $2 more gets you a very powerful PIC that WILL work.....
BTW, that $2 difference is less than 5 minutes of R&D cost,so it make $$ sense to use the 'costly' PIC as overall you're saving a lot of time and money.
kmp84



Joined: 02 Feb 2010
Posts: 345

View user's profile Send private message

PostPosted: Mon Feb 08, 2021 1:02 pm     Reply with quote

Hi mr."temtronic",

Quote:

There is a problem with using a SW UART to receive data in that by the time the ISR for the 'int_ext' executes, the actual incoming data won't be correc

I'm using software uart as many CCS's examples like modbus serial!
Quote:

also you need to disable ALL other interrupt sources while the PIC 'bitbangs' the incoming data.

I think that "DISABLE_INTS" do it..?
Quote:

just did a 'price check'.. 16f1847 is $3 cdn, 18f26k22 is $5 cdn
So $2 more gets you a very powerful PIC that WILL work.....
BTW, that $2 difference is less than 5 minutes of R&D cost,so it make $$ sense to use the 'costly' PIC as overall you're saving a lot of time and money.

I understand this very well but as I said at the beginning this is old hardware I am trying to upgrade. The main problem for me is not 2 dollars, but the fact that I do not remember any of the projects I did that did everything as I expect. Every time I either have a problem with the CCS compiler or the PIC errata sheet. Every time after the compiler upgrade, something stops working most often ICD devices, which also are updated!

P.S PIC16F1847 is not that so old PIC. Many people have been updating their systems for more than 10 years.
gaugeguy



Joined: 05 Apr 2011
Posts: 286

View user's profile Send private message

PostPosted: Mon Feb 08, 2021 2:59 pm     Reply with quote

Software UARTS work very will for receive if the processor can wait in a loop and do nothing else. If any other tasks must be handled then it becomes more complicated. Multiple software UARTS are possible for receive if the baud rate is low enough and with clever use of timers, interrupts and polling but this is a very advanced approach and does not use CCS built in UART functions.
temtronic



Joined: 01 Jul 2010
Posts: 9081
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Mon Feb 08, 2021 3:44 pm     Reply with quote

Did a quick read of the modbus driver/programs that CCS supplies...

re:
Quote:
For unknown reason MCU stop running and needs to make reset or power off/on cycle.


There's a comment about this in either the driver or master program...sounds like CCS had/has problems with PIC not running ?
Their 'driver' is a 'generic', hopefully works with all PICs and compilers so it should be reduced to exactly what you need for your PIC.

I don't know how good the internal RC clock is in that PIC but for reliable serial communications, it's always best to use an external xtal/caps, especially when using a SW UART.

I've not updated my compiler since I got the 46K22 family, so V4.2xx+- ?..it's been years.....No need to update, while newer PICs have more 'features', the 46K22 does more than I need. I have a huge library of custom functions like LCD, KPD, RTC, as well as a couple dozen sensors. By using the same 'family' PICs, I know my code will work and I don't have to lose time with a new buggy compiler version.
I don't use any ICD.... all testing is done in the 'real World'.

One possible problem. You do HAVE an ISR for the 'int_rda' ? Every enabled interrupt MUST have an ISR. Also when using a HW UART, you MUST add 'errors' to the option list...

Jay
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Tue Feb 09, 2021 8:17 am     Reply with quote

It's not made clear here, whether 'task 2', attempts to do anything that
could be full duplex?. Also, the relative baud rates used for the hardware and
software UARTs?.

Series of important things. The software UART, only supports half
duplex operation. Any attempt to do full duplex will fail. Then if the
software UART is used with INT_EXT, and it's character time exceeds
the character time used on the hardware UART, this can result in loss of
data for the hardware UART. The hardware UART, will become hung if
this happens, and 'ERRORS' is not used in it's setup. I'd suspect this is
the most likely cause of the hang.
The Modbus example uses RS485, and therefore half duplex operation.
kmp84



Joined: 02 Feb 2010
Posts: 345

View user's profile Send private message

PostPosted: Tue Feb 09, 2021 1:31 pm     Reply with quote

"Task_2()" act as serial master software uart at 9600 with INT_EXT receiver in half duplex mode. "Task_1()" act as serial slave hardware uart at 9600 with INT_RDA half duplex with added 'errors' directive.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Goto page Previous  1, 2
Page 2 of 2

 
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