| View previous topic :: View next topic |
| Author |
Message |
Fabtronics
Joined: 17 Jun 2007
Posts: 3
|
| Problems with PIC16F1936 |
 Posted: Wed Oct 14, 2009 4:35 pm |
 |
|
We are having heaps of problems with the ccs complier (V4.099) and wonder if anyone has found work arounds.
1. Memory allocation
The compiler appears to be overlapping two arrays so that the start of the second is actually addressing the end of the first
| Code: |
volatile signed int16 lastChannelSample[8] = {0};
static int8 debounceCounter[8] = {0};
|
Addresses in the .sym file are
| Quote: |
062-0A1 lastChannelSample
0A0-0A7 debounceCounter
|
2. write_eeprom command generates wdt resets
3. setup_wdt command doesn't work (this has previously been reported)
We have to use
| Code: | #byte WDTCON = getenv("SFR:WDTCON")
WDTCON=0b00010101; |
Has anyone else had experience with items 1 and 2 above? |
|
 |
Ttelmah
Guest
|
|
| Posted: Thu Oct 15, 2009 2:44 am |
|
|
Hm.
The arrays (as shown), are not overlapping, but the allocation for the first, is 'screwy'.
Think about it. 8* int16 (2 bytes per entry), requires just 16 bytes of RAM. If the array starts at 062, It'll end at 071. The sym lines, appear to show enough space being allocated for an array four times the size....
As a 'comment', it would appear, that there is no point in the volatile declaration. From the sym listing, it appears that both arrays are global.
Best Wishes |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Thu Oct 15, 2009 4:13 pm |
|
|
| Quote: | | We are having heaps of problems with the ccs complier (V4.099) and wonder if anyone has found work arounds. |
The 16F1936 is substantially different from the normal 16F-series.
The register map is very different. Expect a lot of problems with the
compiler and this PIC, at least initially. It might take several versions to
correct all of them. Example:
http://www.ccsinfo.com/forum/viewtopic.php?t=40438
| Quote: |
The compiler appears to be overlapping two arrays so that the start of
the second is actually addressing the end of the first.
Addresses in the .sym file are
062-0A1 lastChannelSample
0A0-0A7 debounceCounter
|
I made a test program and it doesn't show that problem. Here's what I get:
| Quote: |
020-02F lastChannelSample
030-037 debounceCounter
|
This is from the .SYM file. It was compiled with vs. 4.099. It has
16 bytes for the first variable and 8 for the 2nd one. That's correct.
Here's the test program:
| Code: | #include <16F1936.h>
#fuses XT,NOWDT,BROWNOUT,PUT,NOLVP
#use delay(clock=4000000)
volatile signed int16 lastChannelSample[8] = {0};
static int8 debounceCounter[8] = {0};
//======================================
void main(void)
{
while(1);
} |
|
|
|
Fabtronics
Joined: 17 Jun 2007
Posts: 3
|
|
| Posted: Mon Oct 19, 2009 7:25 pm |
|
|
| Thanks for the feedback. I only showed the two offending lines from the .h file as it is part of a large program but it did cause a problem as shown. CCS have given us a new 1936.h file and a dll that we are now testing that will hopefully fix our issues |
|
|
asmboy
Joined: 20 Nov 2007
Posts: 2128
Location: albany ny
|
|
| Posted: Tue Oct 20, 2009 6:28 am |
|
|
can't help the curiosity:
what is the design goal here that can ONLY be satisfied with this VERY new part and using the very VERY new compiler version ?
Why are there no other 16F or 18F 28 pin parts (that have been on the market , and SUPPORTED by CCS ) for a a longer time that will work for you?
if being a pioneer is your thing- then you have to love the new 16f1xxx
parts and
you don't seem to mind arrows in the back.
-thanks for the trail blazing.
But i would not start a new project with this family for ANY amount of $$ |
|
|
Fabtronics
Joined: 17 Jun 2007
Posts: 3
|
| Why PIC16F1936 |
| Posted: Mon Nov 16, 2009 10:01 pm |
|
|
We used the 1936 as we needed 8 inputs for touch sensing and were forced to use the 16F726 but it didn't have eeprom so we then had to add external eeprom which is a pain.
Microchip multiplex options for touch didn't work
Don't want to trail blazer!!
I'd like to know why Microchip released the 726 in the first place without eeprom!!!!!!! |
|
|
asmboy
Joined: 20 Nov 2007
Posts: 2128
Location: albany ny
|
|
| Posted: Tue Nov 17, 2009 7:08 am |
|
|
as to the "lacking eeprom' part
There are an appalling number of 18F chips that lack eeprom too.
Even @ the wafer process level there is no reason not to have it
since primary program memory is built up using the SAME wafer
process steps required for user EEPROM.
The REAL reason dear friend is MARKETTING - to force U to buy the more
$ version - as there is NO cost -to-fab- justification to omit this useful feature.
u can blame the sales yield forecasters for your problem - it is an
economic decision by Mchip pure and simple. |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
